[timw4mail]

The more I deal with it, the more I hate React, and the very idea that websites must require Javascript to just show HTML.

[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.

[duxup]

If all you want to do is serve up HTML... you don't pick react.

[wldlyinaccurate]

I've used React as a server-side templating language on many projects small and large. The main feature that makes React great for rendering HTML is higher-order components. In my experience any project of sufficient complexity starts to get ugly with a "regular" templating language. React encourages composition of small isolated components, which tends to result in code that is easier to understand and maintain.

Admittedly this works best on projects that don't require a massively complex interactive front-end, like news sites[0] and data reporting tools. But at some point you can just choose to start hydrating the interactive components in the browser without changing your back-end setup at all.

[0]: https://wildlyinaccurate.com/introducing-a-faster-bbc-news-f...

[duxup]

Yeah that's totally true.

Really everything is delivering HTML ... and maybe something else.

I was thinking in the simplest form as the person I was responding to seemed to be saying that just to do something ultra basic react was not something they liked.

[fake-name]

Yeah, now if only people actually did that.

[qwerty1234599]

React isn't used for webSITES. It's used for web applications.

[timw4mail]

Hah, I wish.

[duxup]

It's a choice really.

There's ways to do a lot of things (I swear that is the real sticking point on HN when it comes to react discussions).

But just serving up straight HTML, you could actually use react, but you don't have to do it "just" to do that.

If you're stuck in a spot where you HAVE to use it, that's the fault of whomever decided that, not react.