[sombremesa]

Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.

Jokes aside, everything has its place. You're still allowed to hate it though. For example, I hate Redux because everyone uses it for every React app and it's got boilerplate up the wazoo.

Just know that if you "hate" things, though, you won't learn as much in life, like I won't learn how to use time travel debugging. Almost anything that gets this popular has at least a few core ideas we should probably learn, or learn from.

[randomsearch]

I’m not sure this is true. For example, what can I learn from JS that isn’t in better languages? In tech we have this weird situation where many things become popular without good reason. It’s ironic, because a group of people (nerds) who think they are the epitome of rationality are actually the opposite: we make very emotional decisions when we could be entirely rational, as we have access to data other fields do not.

[simongray]

Frontend doesn't always mean using JS. You can use a well-designed, modern language like ClojureScript instead that isn't anything like using JS, yet nevertheless has the same access to the browser.

[austincheney]

Well... there are only two standard APIs for the front end: DOM and the web API (browser stuff and HTML5 things). Once comfort with those is achieved you suddenly need so much less code to do radically more ambitious things.

The time saved in both authoring and maintenance pays for itself in learning the standards.

[sombremesa]

> For example, what can I learn from JS that isn’t in better languages?

I only said "at least a few core ideas" -- not, "at least a few unique core ideas". Sure there are other places you can learn the same things, which of course doesn't mean that JS is now somehow stripped of that value.

[sophiebits]

The web community has a focus on byte size which is rarely found anywhere else in application development.

[wolco]

Is there a way to cutdown the bloat?

[munchbunny]

Not in a substantial way. The boilerplate is a consequence of the functional “workaround”: representing a mutation as the result of applying a state transition to a complex state, and then computing what to display as a function of both the current and previous states.

The way to reduce the boilerplate is to use a mutable paradigm, but then you lose the simplifications that the immutable paradigm gives you.

[acemarke]

There's a fantastic library called Immer [0] that uses ES6 Proxies to let you write "mutative" update logic that is tracked and turned into a safe immutable update.

We recommend using Immer as the best way to write immutable logic with Redux [1], and our new Redux Toolkit package [2] automatically uses Immer internally to let you write reducers like this:

    const reducer = createReducer(initialState, {
      updateItem(state, action) {
        state.first.second[action.payload.id].fourth = action.payload.value
      }
    })

[0] https://immerjs.github.io/immer/

[1] https://redux.js.org/style-guide/style-guide/#use-immer-for-...

[2] https://redux-toolkit.js.org

[rictic]

Check out lit-html. You write functional style code, but the library does efficient minimal mutations of the dom with no virtual dom, and no dom diffing.

[Richicoder]

I'd recommend checkout out Redux Toolkit and reading over the docs. Severely cuts down the boilerplate, but still walks you through the general ideas and fundamentals in a great way.