Hacker News new | ask | show | jobs
by skydhash 382 days ago
> But what I find is that most large, complex applications I've worked on are not in particular hindered by the choice of React as a technology.

AKA, React is accidental complexity. Solving accidental complexity issues may be required some time, but more often than not, it's just something you endure as the alternative choices are not that much better.
1 comments
owebmaster 382 days ago
Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).

State management and optimized DOM manipulation can be achieved with vanillajs nowadays and I'm not saying that as a purist, it is just good enough that React is not needed. To help a bit with the ergonomics, I use lit-html/uhtml for the templating but they are both based on template literals, a native JS feature.

link
skydhash 382 days ago
> Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).

The essential complexity was the interactive need of your UI. Any of the current web framework can be a solution. The only reason to go for React is hireability (almost anyone knows it) and devex (so many prebuilt components). But it's not like that the others are so hard to learn and components are hard to build.

link
exceptione 382 days ago 

  > and devex.
Indeed, devex is the strong point of react. See this thread: https://news.ycombinator.com/item?id=43770579

  > But it's not like that  components are hard to build.
I really want to like other frameworks, but if I'd have to build a MUI(x) by hand, I'll accidentally pivot our business model to "component library maker" as a result.

I think we need to be clear about what scope we are talking about. A full fledged data-heavy B2B application, or something simpler like a web shop?

link