Lodash, Ramda, TypeScript…?

[tripu]

TypeErrors of all kinds are by far the most common RTEs in JS.

Using utility packages, or transpiling from a strongly-typed superset of JS, helps prevent them.

What are your thoughts on, and experience with, Lodash (classic), Ramda (cooler), TypeScript (heavier), etc?

[xfq]

The problems Lodash and Ramda solve are not the same as TypeScript/Flow.

TypeScript mainly solves the dynamic type-changing issues with JavaScript. Although Lodash/Ramda can solve this kind of issue to a certain extent, TypeScript can solve this problem better (but we should restrict the use of any).

TypeScript is also supported by many libraries and frameworks, like:

• Ant Design
• Svelte
• Apache ECharts
• nest

[ericprud]

I don't have much experience with Lodash (mostly removing dependencies on it for functions like flatmap that js now offers) and none at all with Ramda (though I like the architecture). Given my limited experience, I'm not sure how they help you with TypeErrors (maybe their ubiquitous isX functions?).

IMO, TypeScript is a mild pain to set up, another mild pain to return to after you've swapped out, limits your potential contributors, but indispensable for large or complex projects. I tend to do either very small things (couple files in one directory) or very big things with it. On the small end, if you're trying to work through some algorithm , type-checking is a godsend. On the large side, I programatically ported a large-sh Java library to typescript, spent a couple weeks on the converter, XMass and New Years cleaning up the translated code, and a couple days tracking down the one bug that type-safety didn't catch for me (promise execution order, naturally).

For mid-sized projects, I find the overhead of futzing around with search paths and sprinkling tsconfig.json's everywhere too daunting and typically don't bother, even if I might have saved time by shifting effort from debugging to baby-sitting compile-time type errors.