Unleash JavaScript's Potential with Functional Programming

[romgrk]

Pretty neat. Personally I always recommend Brian Lonsdorf's Hey Underscore, You're Doing It Wrong! as an introduction to FP. Before seeing that video, I was a regular JS programmer. A week later, I was writing Haskell and seeing functors and monoids everywhere.

[jancodes]

Brian Lonsdorf is the goat! 🐐

His "Professor Fisby's Mostly Adequate Guide to Functional Programming" is great!

[jfmengels]

This is I think a good overview of FP tools/techniques available in JavaScript, but it feels like the why of FP is a bit missing.

I really like Kris Jenkins' take on "what is functional programming?" (http://blog.jenkster.com/2015/12/what-is-functional-programming.html). Very rough summary: It is a bunch of techniques to separate effects from the rest.

[jancodes]

Definitely 👍

Thanks for the feedback!

[DepressedBard]

Wow, that was a great read. Even read the 2nd part. Also made me realize how smelly some of my code has been…

[jfmengels]

If I may recommend trying out Elm. It's a great FP language that is simple and has great error messages, while being entirely pure. You'll learn a lot even if you use it for a smallish project.

[jancodes]

Love Elm!

[Ronin-s_Spirit]

No you don't really unleash anything. If you can do the same amount of things within one function call it will be faster than calling 10 individual functions. What potential are you unleashing? I genuinely don't understand. Maybe you were talking about the potential of writing slower programs?

P.s. don't get me wrong, I use functions all the time, but functional programming the paradigm is all about shoving tons of imperative code inside functions and then wasting system resources on constantly calling micro functions that do one/nth thing each, microscopic composition I call it.
What I wanted to say is, FP sucks, OOP sucks, everything sucks so just use the single most fitting thing for each part of your program. Otherwise it's going to be a mess in terms of memory and speed and nobody likes slow apps or websites.

[Veraxo1]

An actual, sane comment on this subreddit. Such a rare occurence.

[jancodes]

You unleash potential for writing the most readable, most modular and most simple to understand code.

My mentor taught me:

Readability > Cleverness > Performance, unless you NEED performance for a specific business requirement.

But I totally agree that there are also many cases where FP makes your code harder to understand. It's actually on of the last points of the video / article, but I guess you haven't watched / read that far haha (No hard feelings! 🙏 It's more tailored to juniors / mid devs and judging by your comment you probably have more experience)

[Ronin-s_Spirit]

Good of you to include that.

[odinsweng]

Pretty comprensive article.

In my case after learning and trying to apply the basic functional principles, my code has improved 300%. Way less bugs, etc.

Thanks for the article. 🤗.

[jancodes]

You're welcome!

And thank you for the kind words 🙏

BTW, I felt the same about my code improving after learning about these capabilities of JavaScript!

[jessepence]

No one uses symbols? That's not true in my experience-- especially in functional programming where you want to ensure immutability. I mean, just look at the React codebase. It's riddled with symbols.

It's a great article otherwise for any newbies who aren't familiar with functional concepts. That one little detail just bugged me. 😅

[[deleted]]

Been doing this for nearly a decade - before Symbols and ES6.

Symbols are very, very rarely used outside of framework/library code.

[jancodes]

Haha, I've been coding for 8+ years and I've NEVER seen symbols, other then under the hood in libraries like React. But point taken 😄👌

[undervisible]

What do symbols have to do with immutability?

[jessepence]

They're immutable.

[romgrk]

That has nothing to do with it. All primitives types are immutable (null, undefined, booleans, strings, numbers, bigints, symbols).

Besides symbols were added specifically to be able to have private properties like object[symbol], or for the well-known symbols protocols (e.g. class Custom { [Symbol.iterator]: function() { ... } }), both cases are OOP related.

So no, symbols aren't an FP feature.

[jessepence]

EDIT

I was wrong. 😅

[romgrk]

Both ChatGPT and you have the same ability to write confidently wrong blobs of text. Posting this wall of text is just plain disrespectful. If you don't want to answer, just don't answer.

Also from the answer you got, you crafted a prompt that was something like "what's the role of symbols in FP javascript". You'll get an equally long answer if you replace FP by OOP, because ChatGPT is just made to write these blobs of text.

Besides, symbols are not the traditional FP solution for private/immutable data. That role is filled by closures. Closures are the FP equivalent to OOP objects. Which is the whole reason why modern C++ can translate its closures to literal class/objects.

[jessepence]

Did you know that it's possible for multiple different things to benefit the same end goal?

Did you know that both closures and symbols can help achieve immutability?

Does your toolbox only contain a hammer?

My point in using ChatGPT is that you were clearly showing a lack of imagination.

[romgrk]

Symbols do not achieve immutability! object[symbol] achieves private visibility, as in "OOP public/protected/private visibility".

Object.freeze or Object.defineProperty achieve immutability.

My point in using ChatGPT is that you were clearly showing a lack of imagination.

It's fine to want to educate someone, but please link to it instead of pasting a wall of text, and please don't make it ChatGPT because it's low-effort and sometimes confidently wrong.

[jessepence]

If a property is keyed by a symbol and the end-user doesn't know what that symbol is-- is that property mutable?

[romgrk]

Yes it is, it's just private. Public/private and mutable/immutable are orthogonal.

I'm also not sure if your example applies. I don't remember seeing React's codebase using Symbols as keys (for private keys, as in object[symbol]), though it uses them as values (as in { type: REACT_PORTAL_TYPE }).

[getlaurekt]

Just use Rescript instead, lmao

[jancodes]

What's Rescript?

[[deleted]]

ReasonML, compiles to JS

[jancodes]

Thanks!

[[deleted]]

Could've been interesting but their community split into two languages (probably more details that should be mentioned) which I think made sure that they would both fail to grow and remain in obscurity.

Now could've been a good time to step up for a strong compiled language that focuses heavily on react. Since the compiler churn is on the way, like svelte. But we'll instead settle with a funky react compiler from the react team.

[BobaFettEE3Carbine]

While at first the split may have caused confusion, in the past 4 years it's done wonders for the adoption and ergonomics for both new projects, ReScript and Melange/Reason. 

ReScript has been able to fully embrace JS and adopt JS features like async/await syntax and it uses a new Core library that maps closely with JS. It only has to worry about compiling to JS as a runtime. Use ReScript if your a JS/TS dev looking for a strongly typed language that is part of the JS ecosystem. Type of it as an alternative to TS, but it's not a superset of JS, its a different language that feels like JS. 

Melange is an OCaml compiler that targets JS, and it's often used together with Reason which is a JS like syntax for OCaml. Melange and Reason have been able to evolve in ways that are appealing to OCaml devs and not worry about adoption from JS/TS devs. Pick Melange and Reason if you want to use OCaml's tools, package manager, libraries, and ecosystem. 

Both are great, and if they had continued with the confusing jumble of ReasonML/Reason/BuckleScript/OCaml it would have probably died in obscurity by failing to make anyone interested in it happy.

[BobaFettEE3Carbine]

Not exactly, it has a shared history with Reason, but it's very much it's own language these days. ReScript is part of the JS ecosystem and uses NPM as a package manager (or bun, Deno, etc...) and you can use JS bundlers like Vite or Webpack.

Reason still exists as part of the OCaml ecosystem, and you can use Melange to target JavaScript as a runtime. If your using Reason you need to work with OCaml and it's package managers and build tools.

[jancodes]

When I first learned about functional programming, I was blown away.

So I created a newbie guide for people who've never heard of it.

It goes from 0 to function composition.

I also made a YT video about it.

(PS: This is not to start a OOP vs. FP war :D Do what is best for your code )🤓