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

281–290 of 866 posts

Re: React is winning by default and slowing innovation

#281

Post by slmjkdbtl »

b_e_n_t_o_n wrote: post #255
AlexErrant wrote: post #145

Earlier quoted context omitted.

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

Based on how they are run they are completely not just ordinary JavaScript functions, hook era components are also not just JavaScript functions, it's a very complicated system. React calling them "just functions" is untrue, just marketing buzz words, and it leads developers into traps.

Re: React is winning by default and slowing innovation

#282

Post by interstice »

epolanski wrote: post #181
interstice wrote: post #148

Earlier quoted context omitted.

I remember vividly the chaos before React and what it was like to not know whether it was worth investing in a framework because it might not be around for long. Vue was the first one that I stuck with for a while, but Nuxt was being updated slowly at the time and none of the packages ever seemed quite as seamless as the guys in React land had it. I don't even use more than a handful of unique packages per site gener…

> Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements. React's performance are way more severe and ubiquitous and user impacting. I'd really love to see the websites you're writing in React and lunch a lighthouse or to simulate how do they perform for somebody on a slightly slower connection or not…

We target <3s to usable on lighthouse mobile, ideally less but I don’t design the sites so only so much I can do about large above fold images etc. the truth is react isn’t that bad compared to latency or other issues on the kind of use case you’re describing

Re: React is winning by default and slowing innovation

#284

Post by slmjkdbtl »

It's very sad this is what's happening. React hooks was a major innovation but a very bad one, people in the front-end world seem to value more about radical innovation and marketing buzzwords like "functional UI" (which is not true) than truly evaluating a system. The earliest momentum started from trend chasing, also a lot of people use React because they see the JSX looks pretty nice in the examples.

Re: React is winning by default and slowing innovation

#285

Post by ozim »

jgalt212 wrote: post #103
mrsilencedogood wrote: post #92

Earlier quoted context omitted.

I think part of the problem is that browsers don't really serve their original purpose anymore. Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want (and not do whatever they don't want to do). So that standards still mostly can't do anything google isn't enthusiastic about dumping dev time into. And they're just barely not enough of a monopoly that they can'…

> there are strong technical forces that want the browser to finally finish morphing from a document viewer to an application runtime I really hope that never happens if only because the web dev on ramp will discourage anyone without preexisting technical chops.

We are mostly there and I am all for it.

No other GUI runtime or framework delivers true cross platform implementation. HTML, CSS and js are as open and as standard as it gets.

GTK sucks in its own ways and is not international standard.

Re: React is winning by default and slowing innovation

#286

Post by __MatrixMan__ »

mhitza wrote: post #83

The javascript people should stop innovating for a couple of years. To much innovation that lead nowhere. How many ways can one build a web javascript project? Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamen…

I'd go further and suggest that we need maybe five or six browsers. One for shopping, one for banking, one for socializing...

Let the platforms for these things compete on the back end only and provide a uniform experience on the front end across competitors. This way the people writing the code that runs on our devices don't have conflicts of interest that lead them to betray their users.

It would also be easier to use because once you know the structure/flow/hotkeys for one bank you're now wizardly at navigating the interface for every other bank.

It's just such a waste to have each business writing a separate front end even though what they end up with is always more or less identical to their competitor.

Sandwich shops should compete by making a better sandwich, not by outmaneuvering each other re: how they leverage the app they managed to get 8% of their customers to install.

Re: React is winning by default and slowing innovation

#287

Post by spartanatreyu »

notapenny wrote: post #65
kypro wrote: post #31

React's dominance is genuinely baffling to me, and even more so popularity of Next.js. In my experience React is rarely the best solution and adds a huge amount of complexity which is often completely unnecessary because React is rarely needed. In the early days my very controversial view was that frontend developers tend to be fairly mediocre developers, and this is why a lot of frontend frameworks suck and frontend…

For sure it isn't the perfect solution for everything, and I say that as someone who spends most of their time in either React or Angular now. For application-like development or just sites with tons of interaction it's become as standard as reaching for Spring or PSQL though. I can't speak to the complexity you've encountered, but for me it's pretty much zero. A button component is just a function. React-Router is g…

> I can't speak to the complexity you've encountered, but for me it's pretty much zero. A button component is just a function. React-Router is good enough and code splitting is pretty much just changing how to import something. Component state is dead-easy to write by just adding a useState hook. Bundlers pretty much handle everything these days so not to much concern about size.

For me, everything depends on the site and the host.

For 80% of websites, a button is , a router is just URLs that point to files, a state is just a json object in localStorage.

For 15% of websites, a button is , a router is a single file that imports an auth provider and a storage provider which are chosen based on the host.

For the remaining 5% of websites which are actually true applications, I'd reach for a RoR inspired framework (so Laravel for PHP host, Adonis for js host, etc...).

No react needed.

Re: React is winning by default and slowing innovation

#288

Post by interstice »

interstice wrote: post #282
epolanski wrote: post #181

Earlier quoted context omitted.

> Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements. React's performance are way more severe and ubiquitous and user impacting. I'd really love to see the websites you're writing in React and lunch a lighthouse or to simulate how do they perform for somebody on a slightly slower connection or not…

We target <3s to usable on lighthouse mobile, ideally less but I don’t design the sites so only so much I can do about large above fold images etc. the truth is react isn’t that bad compared to latency or other issues on the kind of use case you’re describing

I should clarify - this is headless international ecommerce, so that 3s includes localisation, currency, inventory, cart, video, tracking scripts etc. If you'd like 200ms to live on a static site I can do that too, it's just a bit different.

Re: React is winning by default and slowing innovation

#289

Post by AcquiescentWolf »

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…

React is popular in the modern days only because, well, it's popular. Developers use it because companies use it, and companies use it because developers use it. It's not popular because it's better than all the alternatives, it's just that it has reached critical mass, and it's now "too big to fail". It takes constant effort to avoid React's many footguns. Supporters often call this a “skill issue,” but even if that’s true, why wouldn’t you prefer a framework that does the same things with less code, faster, and with far less mental overhead?

Re: React is winning by default and slowing innovation

#290

Post by nosefurhairdo »

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…

> I groan every single time I run into (yet another) hook rule.

There are only two rules:

1. Only call Hooks at the top level

2. Only call Hooks from React functions

Per https://react.dev/reference/rules/rules-of-hooks

Not sure I understand the conditional beef, perhaps you can give example? I would assume if you want `if condition, useEffect(...)` you could simply replace with `useEffect(() => if condition...)`, no?

Post reply on HN