[SPascareli13]

Not a critic to the article itself, in fact I know nothing about React and learned a lot from the it, but...do we REALLY need all of this to render web pages? Even if it is a web application and not just a page, doesn't this ecosystem seem too complicated for the problem it solves?

[apsurd]

I made my career on open source web technologies before both GitHub and Stackoverflow were a thing. I love the web! And I love making UIs and I can spend untold hours with CSS even! And I agree the state of frontend is completely bonkers.

React absolutely improved things from spaghetti jQuery. The zero-to-one productivity for interactive UIs goes through the roof, but growing and maintaining your project for any serious business use case is a complete nightmare.

I don't wish isometric javascript on any one. Javascript was infamously created in a week or whatever and now it's the browser standard, so be it, by why in god's name would you ever pick it for your server?

I burned myself out working on a personal project completely on my own using nextjs. I was super productive at the start, then as business logic increased... typing and flowing everything through components, state, reducers, selectors, async network calls, good God I grew to hate all of it.

I came crawling back to Rails. Everything and the kitchen sink is loaded in a controlled and blocking env. You can abuse the fuck out of it and it smiles at you. I'm sorry I left you Rails. (rails backend for all business logic: "the brain". Thin/dumb React JS client that consumes view-based APIs. React is great for interactive UIs. Not your fledgling business logic)

[cynicalsecurity]

Spaghetti jQuery has become the boogie man to peddle the ridiculously overcomplicated solutions like React or Angular. Which, ironically, also have got spaghetti, but in a different form.

[whstl]

React by itself is not "overcomplicated", or even "complex" at all.

The majority of the complexity is in the ancillary tools and ecosystem extras, which are not strictly necessary. You don't need bundlers and transpilers, for example. The only reason they are popular is because JSX is a good convenience, though.

You can get away with very basic React for the majority of cases. Things like advanced lifecycle shenanigans are also not necessary, unless you’re doing something extra-smart, or inherently complex (due to browser APIs, third-party APIs, or just complex design patterns). But those are also not necessary: just nip complexity in the bud if possible, but if something becomes impossible to avoid, the complex side of React will have your back.

The main difference between jQuery and React-the-library is that React handles a lot of the complexity around state and component abstraction all by itself.

With jQuery the complexity and spaghetti appears much earlier than in React. It's even difficult to compare, it is much simpler to keep a React codebase cleaner than a jQuery one.

Of course, if your app is simple enough, you don't need the "extra complexity" brought in by React, and jQuery will serve you well.

But this is also true even for "simpler things" like jQuery and Ajax: if your app is simple enough, you don't need Javascript at all, you can handle 100% with server rendering. And so on.

[klysm]

Nope we don’t, but it solves a lot of the problems people frequently encounter while building web pages without too much of a downside. It’s a big trade off space and react sits in a very nice spot in that space.

[vcarl]

Phenomenal answer. No, you don't need it, but if you build something long enough you'll avoid a couple categories of common problems by starting with it (and choose a different set of common problems)

[klysm]

I like to think about framework choices as choosing which kind of problems you are okay with experiencing. This choice can be made from a product perspective much easier

[echelon]

These aren't just web pages. They're full applications with robust, rich state.

Web apps can reach the complexity of a desktop app with a GUI, a game, etc.

I say this as a mostly backend / systems engineer: there is an incredible wealth of complexity in the frontend. In user interaction, making and transforming API calls, and in UI/UX design.

[bobthepanda]

so long as browsers don't have a great way to be stateful, and tie that state to markup, then there will be a couple of major frameworks trying to square that circle.

the moment you have to keep track of any type of state, managing dozens of UI elements quickly becomes extremely tedious.

[MartijnHols]

You don’t really need to know the majority of what’s in this article to make good apps with React. It goes in-depth into how the framework works. Any framework will look complicated when you look under its hood; it’s meant to make everything possible after all.

Actual React apps are as simple and elegant as a complex (web) application ever could be. Separating your app into functional components where most complexity is always local is a great way to make the application structure as simple as they can be. Where developers often go wrong, is trying to force patterns from other frameworks or languages into React and TS/JS.

[SPascareli13]

The thing about looking under the hood into the complexity of the tool you're using is that is can make you consider my initial question in this thread: Do I REALLY need all of this for my use case?

I think if more people would do this exercise they would find that they don't need it, or at least that they might need some form of state reconciliation, but not enough to really warrant all the complexity the tool introduces. Some will find that they don't need it but will still use it for other reasons, like familiarity or because that's what their team uses.

[itronitron]

It isn't needed. Teams could develop complex web applications before React existed and they can still do so.

If the developers have experience with other languages and native UI frameworks then they probably won't want to use any of the Javascript frameworks when developing a web application as they already have a mental model for how to setup the structure of function callbacks for handling user interactions and state changes.

[continuational]

The problem with using the DOM or similar UI frameworks is that you have to code the delta from any state to any state by hand.

This is exceedingly complex, error prone (because you might miss parts of the state that should change) and often slow (because you tend to overcorrect).

[itronitron]

Well, yes and no, it depends...

It does require a lot of thinking before hand about the user interactions and their impact on the application state, user workflows, etc. However that thinking should already be happening regardless of the choice of implementing technology (granted it doesn't in a lot of cases :| )

[SPascareli13]

The problem seems to be that the fundamental abstractions in web (HTML and the DOM) are not suited to modern web apps. This much complexity around state management shouldn't be needed.