Comment by stevepotter
18 days ago
Right. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain
i’ve tried this, and it almost almost works to just rebuild the Dom on every state change as a pure function of state without any react or anything. The resulting interface is actually way snappier than react – but preserving local state of elements like what text is highlighted, where the cursor is, which radio button is tabbed to etc turns into a nightmare.
With all due respect, I don't believe it is "more snappier than react".
React itself with nothing else is plenty fast. You would have to go way out of your way to see performance differences between different UI approaches, computers are just way too fast to notice whether this click resulting in the div's text changing to +1 is slow or fast, even if the implementation were crazy convoluted.
What makes react apps slow is using it badly, and having 10 other libraries getting in the picture loading fat UI elements, etc.
And frankly these would be much slower in your render everything anew approach.
This is where "react is a library, not a framework" kinda lets it have its cake and eat it too. preact is 4 kb, React + react dom is like 30 kb, but when I use it under commercial pressure to deliver it seems to climb into the megabytes. I'm working on a react native app right now that is a completely embarrassing 150 Mb. The experiment in no react, build UI from scratch every state change has stayed around 65 kb without much attention paid to bundle size, with 10 kB of that being a bunch of linear algebra and differential equation solving code and 50 kb of that a plotting library that's completely nonblocking for the rest of the app.
Based on your description it sounds like you were halfway into reimplementing the virtual dom that react uses (or use to use? unsure if they moved away from that with the implementation of a compiler).
Yep. The “I’m sick and tired of of X (re-implements X)” cycle haunts me- I think I’m the wrong mix of picky, whiny and industrious
And, you'll know why this statement
> But for several years we've been able to style radio buttons however we want using a few CSS tools
proves how good the current state is, where a dev can think things will just be ok, for everyone, if you just ripped all that complexity and ship it (which should be the attitude for a good framework).
It's not even the young devs. It looks like most of those complaining are back end developers who "rarely tinker with frontend" but think they can teach everyone else how to make it simple because "it should be static forms".
A great example of all-world-is-a-nail stance mixed with extreme hubris.
I did spend a serious amount of commercial time developing fronted UIs in React, Angular, and the before times in vanilla JS/css. I even wrote my own UI framework in Web Components, developed my own CSS framework used by an agency churning out projects for years. You get the idea, I did the thing, commercially, for over a decade. React and Angular are absolutely more complex in practice. That's fine, if you want the features go ham. But you don't need them, and most people mis-use the power and end up with a slow complex mess.
Perhaps those same people would have a slow complex mess in vanilla tools too though, so maybe React is a scapegoat like PHP was, and Javascript was.