mostly-adequate-guide VS fp-ts

This project might serve as inspiration: https://github.com/MostlyAdequate/mostly-adequate-guide

i like reading this book directly from github with dark mode, also the subheading don't work in the gitbook website and gitbook is abandoned, here's the github link: https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/SUMMARY.md

It’s been a while since I focused on FP, but I recall finding this useful quite often and gleaning the concepts from it relatively easily.

https://github.com/MostlyAdequate/mostly-adequate-guide

I found a lot of articles like the OP, and ultimately they left me confused about the benefits in the beginning. I found it more useful to avoid one off articles and dig into larger pieces of work where the author put in much more care.

On the book front, there are two that I am fond of which have a focus on JavaScript and FP, Professor Frisby’s Mostly Adaquate Guide, and Functional Light JavaScript. They are nice practical books that help you lean into JS’s strength as an FP language while writing real code.

So, this is going to be an uphill battle for you. I suggest you actually learn Haskell first, and then you'll be able to apply its lessons to TypeScript.

Its tricky because these are patterns that are familiar in Haskell but are not really taught in other settings.

Additionally, to really learn these, you need to experiment with them. Use them. etc. That's pretty hard to do if the learning resources are mostly in haskell and you don't really understand it.

Alternatively, this might help: https://github.com/MostlyAdequate/mostly-adequate-guide

Also alternatively, what I would do is just go slowly through the fp-ts code. Look at it a piece at a time and slowly grow your understanding.

This may also help https://www.amazon.com/Domain-Modeling-Made-Functional-Domai...

While I certainly agree, I've found that this is often an indication of too-complex an architecture, and a fundamental re-think being necessary. I've had projects that depend on [fp-ts], which end up incredibly generic-heavy, but still make it entirely through a typecheck(not build- typescript's just worse at that than other tools like esbuild) in seconds-at-worse.

Obviously depends on your organization/project/application, but I do like these things as complexity-smells.

[fp-ts]: https://gcanti.github.io/fp-ts/

Unlike more comprehensive functional libraries like fp-ts, each module can be imported and resolved separately. If you just need options, simply add the option module and you're good to go.

While it's quite abstract, I believe it may be useful to those of you who is interested to learn more about functional programming [in Typescript] and also get more intuition on diverse programming ideas. I use fp-ts as a functional programming library there.

The library for TypeScript that this is influenced by is here:

https://github.com/gcanti/fp-ts

Interesting how both languages with this library converge to a similar syntax, due to heavy use of functions.

Learn something that pays the bill first - nowadays it's Golang/Rust react/typescript. Then you can try some pure fp libs like fp-ts and fp-core.rs, and look through existing scala cats docs. If you'll feel bad about it - that's totally fine and expectable, fp takes a paradigm shift and not that many dev able to shift their brains way of thought due to basic psychological rigidity) (inability to change habits and to modify concepts/attitudes once developed). And that's purely a staffing and management issue - folks hired randoms out of the blue, and called 'em a team.

fp-ts, a library that caters to functional programming in TypeScript, comes with some micro-abstractions that already solve a few of our needs.

Also, don't underestimate how powerful TypeScript can be in capable hands (namely Giulio Canti's). Check out fp-ts, for instance.

You are able to type it using function overloads, an example can be found here - link, line 236.

looks like more ergonomic/focused version of fp-ts[1]

[1] https://gcanti.github.io/fp-ts/

We used a functional programming library that pretty much mimicked haskell (https://github.com/gcanti/fp-ts) so we still had to train folks for months before they could be useful on a consistent basis. the team fucked up