Hacker News new | past | comments | ask | show | jobs | submit login

This is very vague. Can you give some examples?



The question asking for clarification is itself vague. Examples of which part?

Look at JS that's written for serious applications today, identify the stuff that you'd label as "idiomatic", and then look at code that was written 10 years ago for serious applications, and see if it matches what your conception of "idiomatic JS" is. Good references for the way JS was written for high-quality applications without the negative influence of the new idioms (because they didn't exist yet): the JS implementing Firefox and the JS implementing the Safari Web Inspector.

Examples of how "idiomatic JS" is often written by people who are working against the language instead of with it:

- insistence on overusing triple equals despite the problems that come with it

- similarly, the lengths people go to to treat null and undefined as if they're synonymous

- config parameter hacks and hacks to approximate multiple return values

- `require`, NodeJS modules, and every bundler (a la webpack) written, ever

- `let self = this` and all the effort people go through not to understand `this` in general (and on that note, not strictly pure JS, but notice how often the `self` hack is used for DOM event handlers because people refuse to understand the DOM EventListener interface)

- every time people end up with bloated GC graphs with thousands of unique objects, because they're creating bespoke methods tightly coupled via closure to the objects that they're meant for because lol what are prototypes

These "idioms" essentially all follow the same "maturation" period: 1. A problem is encountered by someone who doesn't have a solid foundation 2. They cross-check notes with other people in the same boat, and the problem is deemed to have occurred because of a problem in the language 3. A pattern is adopted that "solves" this "problem" 4. Now you have N problems

People think of this stuff as "idiomatic JS" because pretty much any package that ends up on NPM is written this way, since they're all created by people who were at the time trying to write code like someone else who was trying to write code like the NodeJS influencers who are considered heroes within that particular cultural bubble, so it ends up being monkey-see-monkey-do almost all the way down.


Hi, I'm also a new JS coder, but I'd like to avoid becoming one of "those people" you're talking about. I've been struggling with exactly what you mention - how to find out the "correct" way to apply patterns/do relatively complex things, but all I get on search results are Medium articles written by bootcamp grads.

Can you recommend any sources of truth/books that can guide down the right path? Of course I'll be going through all the things you mention but I'm just curious if there's somewhere I can get the right information besides just reading through Firefox code, for example.

Thanks!!!


I'd say Eloquent Javascript (available for free online, I think) is a good book to read. "You Don't Know JS" is also a good one!

Basically, go for anything that teaches you non-js-specific approaches as well as as a solid understanding of the fundamentals.


Thank you! I'll check both of those out


And Crockford’s JavaScript: The Good Parts. Although and older book, JavaScript fundamentals never change and it describes a lot of those forgotten foundations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: