Comment by somewhereoutth | Hacker News Reader

Comment by somewhereoutth | Hacker News Reader

Probably its time somebody wrote something that could be titled 'The Unreasonable Effectiveness of JavaScript' - the language has of course been wildly successful, if measured in terms of adoption at any rate, and it might be good to try to understand why (beyond 'it's on every browser, dummy').

Enjoy:

- record and array literals

- arrow syntax for lambdas

- spread operator

- map, reduce, forEach

- string template literals

- default values with ||

- single thread memory model

- all the pretty colours

Avoid:

- Formal OO constructs, i.e. 'class' and whatever goes on inside it. They feel out of place, and e.g. the this.function() syntax is clanky. Special hate reserved for those magic proxy getters - breaks the simple record model.

- Formal typing, i.e. Typescript. Becomes unnecessarily verbose and boilerplated, tooling is not quite there, and you almost always need to poke holes in the type system to do anything interesting anyway.

- Lodash and friends. Not needed now the core language has so much out the box.

Where Javascript seems to shine is in being a simple, functional language, with concise syntax, and without heavy OO or type formalisms.

You lost me at avoid formal typing and lodash.

At least to me, Lodash is absolutely necessary even in new projects — such a wealth of functionality and most of it isn’t available OOB in the standard library. It’s easily tree shakable as well.

As for formal typing, TypeScript was a boon for my productivity. Curious about any examples of use where it’s been inadequate?

The lodash functions have built in guards so you can do _.map() and not have to care if the argument you pass in is, in fact, an Array.

I can’t tell you how many times I see “can’t call function toLowerCase of undefined”, etc.

“but Typescript!”, doesn’t do runtime type checking.

I very much prefer defensive programming. Assume nothing.

>I can’t tell you how many times I see “can’t call function toLowerCase of undefined”, etc.

Think that should be addressed by optional chaining now.

Partly but optional chaining doesn't make sure that the function actually exists on the target. So if "const a = 10" and you call "a?.toLowerCase()" you'll still get an error.

Shit, TypeScript's the first time JavaScript's been not-terrible. If I squint and tilt my head it sometimes even looks almost good.

I'm also a fan of "class" since it makes the deeply-embedded-but-awful OO system actually usable without twisting into a pretzel or engaging in a whole lot of "OMG why, why did you do that?".

I prefer to have data structures (records, arrays, primitives), then organise the functions operating over those structures into logically sensible places, instead of tying them into the structures themselves via classes.

Occasionally it is necessary for structures to act polymorphically, thence it is but a simple matter to put a function in the structure for that behaviour (maybe with a reference to the enclosing structure in scope)

Perhaps avoid lodash if possible, i.e. prefer the new built-ins. Otherwise it becomes yet another way of doing a simple thing.

Typescript is another language layer, devs will tend to write even more code for a given problem - often not helpful. It should be possible to do a lot of static type checking without annotations.

It should be possible, but probably is not very well due to how crazy JS does implicit type conversions and other footguns.

> Typescript is another language layer, devs will tend to write even more code for a given problem - often not helpful.

That "even more code" is communication. It's documentation that you ought to be recording somewhere anyway, for the most part. The nice part about using TypeScript for that particular documentation is that then your tools can help you with both the reading and the writing.

Reply on news.ycombinator.com