-
-
styled-components
Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress đź’…
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
immutable-js
Immutable persistent data collections for Javascript which increase efficiency and simplicity.
-
-
milewski-ctfp-pdf
Bartosz Milewski's 'Category Theory for Programmers' unofficial PDF and LaTeX source
-
adventofcode
Advent of Code solutions of 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 and 2023 in Scala (by sim642)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
If you are stuck writing JavaScript, I would still encourage the functional programming approach, but you'll have to watch out for certain strategies that just won't work because the language does not support them. (By the way, TypeScript does not solve any of these issues and makes some of them worse.) Elitist functional programmers would disallow the use of chainable/fluent code, but I personally think that is the best approach to writing clean code in JavaScript. I certainly wouldn't go out of my way to implement method chains for every object in my code, but any library that adheres to the Fantasy Land spec (including Ramda) already provides some great chainable methods.
As already mentioned in the previous section, a certain flavor of functional programming can be quite elegant in JavaScript. The simplicity of the object model makes it very convenient to organize and operate on data. Dynamic typing and type coercion allows you to take certain shortcuts (unless you are trying to sort a list of numbers...). Use the strengths of whatever language you are using to your advantage. It is good to push the boundaries of the language to create new things. For example, styled components and GraphQL have normalized the use of tagged template literals for domain specific languages (DSLs). But in general, you'll have a much better time working with the grain of the language than against it.
If you are stuck writing JavaScript, I would still encourage the functional programming approach, but you'll have to watch out for certain strategies that just won't work because the language does not support them. (By the way, TypeScript does not solve any of these issues and makes some of them worse.) Elitist functional programmers would disallow the use of chainable/fluent code, but I personally think that is the best approach to writing clean code in JavaScript. I certainly wouldn't go out of my way to implement method chains for every object in my code, but any library that adheres to the Fantasy Land spec (including Ramda) already provides some great chainable methods.
I have been a huge proponent of functional programming in JavaScript. As seen throughout this series, the Haskell solutions can almost always be translated into decent looking JavaScript code. But as some have pointed out, the lack of certain features such as persistent data structures or tail call optimization makes it impossible to implement many real world applications. Using something like ImmutableJS would probably help, but replacing every single data structure with something from a library is objectionable.
Although I have spent a lot of time learning functional programming from an academic perspective, putting it into practice with real problems required more deliberation. I am certainly not going to give up, but I recognize that forcing myself to solve a problem each day with a difficulty growth rate that was larger than my learning growth rate was unhealthy. My plan is to continue practicing Haskell using Exercism, which makes learning pretty much any language an exciting journey.
My definition of functional programming has been shaped by my studies on category theory, particularly through the writings and videos of Bartosz Milewski and others. I enjoyed learning about monoids, functors, monads, algebraic data types, typeclasses, currying, and more. Haskell has been the quintessential functional programming language in my view, and if a language claimed to support functional programming, there were certain features that it needed to have.
This year, I tried doing Advent of Code for the first time. My goal was to write code solutions in Haskell and JavaScript with more or less equivalent implementations. I have been learning functional programming academically for five or six years, so Advent of Code gave me an opportunity to practice what I have been learning. Unfortunately, things didn't go exactly as planned, so here are some of the lessons I learned: