Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

Post reply on HN
Print view View original

251–260 of 866 posts

Re: React is winning by default and slowing innovation

#251

Post by mickael-kerjean »

throwaway-0001 wrote: post #99
j45 wrote: post #90

Earlier quoted context omitted.

React is great at solving complex problems. Not all problems are complex to begin with, and having a complex tool as default otherwise adds complexity to the project and also inflexibility to iterate quickly. This is in addition to having to maintain a relatively brittle ecosystem from past feature as well as future features but that can be true for more than one area of JavaScript or other technologies. Looking for…

And the moment you need to increase complexity in your app, you need to add back react.

I'm a counter example of your claim. Migrating away from React did made the complexity of my app a lot more manageable and unlocked new business opportunities that would have been impossible with React without following the JIRA route of making the software worse for 99% of users because 1% of those needed something. The project in question is Filestash (https://github.com/mickael-kerjean/filestash), what made me switch are those 2 reasons:

- Performance ceiling. Past the point where you have used all the react specific optimisation tricks (useMemo, etc...), React just gets in the way, once you start to optimise things to reduce the memory footprint, optimise for 60FPS, dig into heap snapshots and allocation traces, your life starts to become miserable where you need a complete understanding of not only your app but also the inner working of React, and the intersection of both React with your app. At that point, you either accept the ceiling or rewrite everything to vanilla JS and have complete control over every piece of the code you are shipping to the client

- Extensibility. I am now shipping plugins which patch frontend on the fly without any build step. In practice, after a plugin author packaged their plugin (as a zip file containing a manifest), the patches are applied in real time by the server without a prior frontend build system (open up the demo instance with the network tab open to see this working from: https://demo.filestash.app/). This powers themes with icons swaps, new behaviors (e.g. a "recall" button for files in Glacier), and other things plugin authors come up with that that makes the app far more customizable and opened for new niches without falling onto the JIRA trap

Re: React is winning by default and slowing innovation

#252

Post by sthuck »

wavemode wrote: post #235

Sticking with React because of "stability" / "ecosystem" seems very strange to me - I've never seen more churn than in codebases making heavy use of the React ecosystem. Constant breakage. Constant rewrites as functions, features, and sometimes entire packages are deprecated. I also tend to see a lot of the "left-pad" phenomenon in such codebases. Large swathes of the "React ecosystem" are libraries whose relevant fu…

Css in js was like a fever dream that lasted 2-3 years and seems to mostly go away. It's a good example as to how the frontend world just seems to make bad decisions.

Like if you take React's server components, it has a ton of problems and gets excessive focus from react devs, but fundamentally I can agree on what's its trying to solve. I understand the need, even if i disagree in almost anything else regarding it. I still don't know what the css in js phase was about.

Re: React is winning by default and slowing innovation

#254

Post by hardwaregeek »

827a wrote: post #102

React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies. If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decis…

Remix 3 appears to not be based on React. The React Router/Remix people write great libraries. The problem is that they're constantly chasing the next great library. By the time you use their latest creation, they've already started making a new library that they'll tweet about

Re: React is winning by default and slowing innovation

#255

Post by b_e_n_t_o_n »

AlexErrant wrote: post #145
apsurd wrote: post #112

Earlier quoted context omitted.

+1 React DX is really great. It started really great and it got weird and bloated but it's still really great relative to the JS landscape hell. But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements. Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in t…

React DX is hot garbage. Words cannot express how much I LOATHE hook rules. Coming from a Solid JS background, where reactive primitives are just Javascript functions... I groan every single time I run into (yet another) hook rule. I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost ce…

Hooks are also just JavaScript functions...?

Re: React is winning by default and slowing innovation

#257

Post by zachwill »

827a wrote: post #102

React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies. If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decis…

Super insightful. I hadn’t been able to articulate the same feelings.

    Even as Next seppukus itself,
    people will likely just fall back 
    to React on Vite…
This is my exact read on the situation, as well. I’m not sure if anything can meaningful affect React’s domination in the short-term or medium-term, even with the accumulation of poor choices.

Re: React is winning by default and slowing innovation

#258

Post by b_e_n_t_o_n »

apatheticonion wrote: post #221

One of the issues I find is that JavaScript itself holds back the ability of tool makers to experiment with practical novel alternatives. TypeScript's tsx macro is designed with React-like libraries in mind and alternative frameworks need to create custom file types and LSPs just to get off the ground. I'd love to see the JavaScript spec define a generic macro system to enable experimentation (with IDE support) for a…

Js has decorators for class fields so you wouldn't even need a macro for that. `@state accessor value = "hello world"` works.

I do like the idea of macros in general though.

Re: React is winning by default and slowing innovation

#259

Post by cies »

I'd say it's more "JS is winning by default and slowing innovation".

React (and TypeScript) is a mere band aid trying to make something out of it.

I say this from an Elm perspective: so much you do not need (code and libs) because the language is "sound".

Also true: some things are quite a bit harder in Elm than in JS, but usually that because it wants you to handle all corner cases that'd be runtime errors in JS/TS.

Re: React is winning by default and slowing innovation

#260

Post by conrs »

It's uncontroversial that with high traffic websites these sort of frameworks are necessary, but the decision to use React is much more commonly being applied at tiny companies as the new "right way" of building things.

What is unclear is what you lose by not using React. This is similar to how trendy MEAN was back around a decade - "it's web scale", etc...

This gets into necessary versus unnecessary complexity, which is nuanced. But the large scale companies get this, and are doing just fine handling it. It's the small ones that can't draw the distinction. Discourse on these sites or articles is much more likely to matter to these smaller companies, and so in general the best "universal advice" is probably to recommend the simplest thing that doesn't close any doors.

Post reply on HN