5 ms·

> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling c

> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because the patterns around things like state management still have a lot of warts. The terminology of redux drives me crazy because it’s really difficult to explain things like reducers.

pwdisswordfish4 6y ago
What most people have in mind as "idiomatic JS" isn't that. It's usually meant to refer to some patterns that appeared and started getting popular around 8 years ago. And often, code written in this not-idiomatic way works _against_ the language and/or the underpinnings of the Web in general. It's just that the circles promoting the pseudo-idioms have outsized and seemingly inescapable influence.
- rlt 6y ago
  This is very vague. Can you give some examples?
  - pwdisswordfish4 6y ago
    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.
    - CptFribble 6y ago
      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!!!
      - mercer 6y ago
        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.
        CptFribble 6y ago
        Thank you! I'll check both of those out
        d13 6y ago
        And Crockford’s JavaScript: The Good Parts. Although and older book, JavaScript fundamentals never change and it describes a lot of those forgotten foundations.
mrh0057 6y ago
Redux is not idiomatic JavaScript though. It’s trying to make JavaScript immutable and have adt which it doesn’t. If you use elm, reasonml, rescript, etc this pattern is a lot easier to implement than with JavaScript.
- will_pseudonym 6y ago
  I wasn't readily familiar with the acronym ADT. It's "Algebraic Data Types" for anyone else in the same boat. https://en.wikipedia.org/wiki/Algebraic_data_type https://en.wikipedia.org/wiki/Algebraic_data_type
  - tartoran 6y ago
    In CS it also refers to Abstract Data Types
    - will_pseudonym 6y ago
      Ah, good call. Thank you! Here's a reference I found that explains the differences between those two concepts, as applied to Scala: https://stackoverflow.com/questions/42833270/what-is-the-difference-between-abstract-data-types-and-algebraic-data-types https://stackoverflow.com/questions/42833270/what-is-the-dif...
- d13 6y ago
  Yup, it’s beautiful in Elm and makes no sense in JavaScript, which doesn’t need it.
howlinbash 6y ago
A good starting point to explaining reducers is that you are reducing two things into one. A redux reducer: The action and the current state reduce into the new state. And of course it doesn't matter how many reducers or combined reducers your state uses - they're all ultimately just doing this. This also works for Array.prototype.reduce(). You're reducing two things into one.
- rlt 6y ago
  The concept of a reducer isn’t the hard part of Redux... it’s designing your state, organizing actions/reducers/selectors, reducing (no pun intended...) boilerplate, dealing with side effects and asynchrony, etc.

pwdisswordfish4 6y ago

What most people have in mind as "idiomatic JS" isn't that. It's usually meant to refer to some patterns that appeared and started getting popular around 8 years ago. And often, code written in this not-idiomatic way works _against_ the language and/or the underpinnings of the Web in general. It's just that the circles promoting the pseudo-idioms have outsized and seemingly inescapable influence.

rlt 6y ago
This is very vague. Can you give some examples?
- pwdisswordfish4 6y ago
  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.
  - CptFribble 6y ago
    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!!!
    - mercer 6y ago
      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.
      - CptFribble 6y ago
        Thank you! I'll check both of those out
        d13 6y ago
        And Crockford’s JavaScript: The Good Parts. Although and older book, JavaScript fundamentals never change and it describes a lot of those forgotten foundations.

mrh0057 6y ago

Redux is not idiomatic JavaScript though. It’s trying to make JavaScript immutable and have adt which it doesn’t. If you use elm, reasonml, rescript, etc this pattern is a lot easier to implement than with JavaScript.

will_pseudonym 6y ago
I wasn't readily familiar with the acronym ADT. It's "Algebraic Data Types" for anyone else in the same boat. https://en.wikipedia.org/wiki/Algebraic_data_type https://en.wikipedia.org/wiki/Algebraic_data_type
- tartoran 6y ago
  In CS it also refers to Abstract Data Types
  - will_pseudonym 6y ago
    Ah, good call. Thank you! Here's a reference I found that explains the differences between those two concepts, as applied to Scala: https://stackoverflow.com/questions/42833270/what-is-the-difference-between-abstract-data-types-and-algebraic-data-types https://stackoverflow.com/questions/42833270/what-is-the-dif...
d13 6y ago
Yup, it’s beautiful in Elm and makes no sense in JavaScript, which doesn’t need it.

howlinbash 6y ago

A good starting point to explaining reducers is that you are reducing two things into one. A redux reducer: The action and the current state reduce into the new state. And of course it doesn't matter how many reducers or combined reducers your state uses - they're all ultimately just doing this. This also works for Array.prototype.reduce(). You're reducing two things into one.

rlt 6y ago
The concept of a reducer isn’t the hard part of Redux... it’s designing your state, organizing actions/reducers/selectors, reducing (no pun intended...) boilerplate, dealing with side effects and asynchrony, etc.