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

701–710 of 866 posts

Re: React is winning by default and slowing innovation

#701

Post by whoknowsidont »

actinium226 wrote: post #379
whoknowsidont wrote: post #341

React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…

>I think it's very hard to argue that React is effective or well designed.

This is a foolish take. React is the reason the modern web is as usable as it is. Anyone who contests otherwise is simply ignorant of web development history.

>(and even Netflix is moving away from React

They're not moving away from React, they're doing pure SSR with it. https://react.dev/reference/react-dom/server/renderToPipeabl...

You don't need the compiler client side. What level of confusion leads you to believe that? That's not even a detail about React, that's simply a mistake in how software works.

React has ALWAYS, by default, done SSR first and then hydrates state on the client. It's trivial, and always has been, to simply do SSR only if you so wish.

>But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more.

I find it hard to take this characterization in good faith. If you have trouble learning about the component life cycle in React, I don't see how you have any hope of successfully building a production level application without any guard rails.

You will, without a singular doubt, simply get "it" wrong. Even with modern JS.

Re: React is winning by default and slowing innovation

#702

Post by whoknowsidont »

mike_hearn wrote: post #503
cpckx wrote: post #397

Earlier quoted context omitted.

Netflix didn't move away from react. They render landing pages with static react components through server-side rendering and only add the minimal interactivity on top through client side js to avoid shipping all of react's state management etc. to the client.

That way of using it is so different to how you're supposed to use that it might as well not be React at all. It was designed as an in-browser framework and is poorly designed for server-side template rendering.

React has always done SSR first and then hydrated state on the client. What leads you to believe that this is not how you're supposed to use it? Doing pure SSR with React is simply... do not hyrdrate state on the client.

Really really straightforward.

This is such a vanilla setup and was kind of the big selling point to start with from the get-go?

Why do you claim otherwise?

Re: React is winning by default and slowing innovation

#703

Post by mattgreenrocks »

paulryanrogers wrote: post #636
mattgreenrocks wrote: post #620

Earlier quoted context omitted.

Please. Let’s get real about the biggest issue with Svelte/Vue/Solid: it wasn’t written by Meta, and had no chance at the clout game that is essential for mindshare. (Not saying React is bad, just that DSLs impeding adoption rings hollow in light of Tailwind/JSX.)

Doesn't Meta also use Vue?

It’s about marketing, not internal use.

Re: React is winning by default and slowing innovation

#704

Post by chrismorgan »

spankalee wrote: post #683
chrismorgan wrote: post #534

Earlier quoted context omitted.

If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.

No, React sets properties by default now. It was one of the last holdouts, but they finally fixed this in 19.

Ah, didn’t know that, thanks for the info.

From the release announcement https://react.dev/blog/2024/12/05/react-19#support-for-custo...>:

> Server Side Rendering: props passed to a custom element will render as attributes if their type is a primitive value like string, number, or the value is true. Props with non-primitive types like object, symbol, function, or value false will be omitted.

> Client Side Rendering: props that match a property on the Custom Element instance will be assigned as properties, otherwise they will be assigned as attributes.

And as https://custom-elements-everywhere.com/ puts it:

> As of v19, React now uses a runtime heuristic to determine if it should pass data to Custom Elements as either properties or attributes. If a property is already defined on the element instance, it will use properties, otherwise it will fallback to attributes.

All up it sounds fragile, and I’m not fond of how JSX syntax makes properties look like attribute, and I hate the way you lose the sometimes-crucial distinction of whether something is a property or an attribute ( is the most obvious example of this), but I guess it’ll be fine in practice. I’m a little curious how they handle some of the event stuff, since React’s synthetic event system is such a legacy mess. And I never did like the way several popular libraries/frameworks (definitely not just React) special-case /^on.*/ attributes, so stupid how you now can’t safely use an attribute or property named “once”, “one” or “online”, all of which would be the most sensible name in certain situations.

Re: React is winning by default and slowing innovation

#705

Post by mrsilencedogood »

branko_d wrote: post #394
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'…

> app-runtime version of NAND In the last 10 years, 3D NAND memory has scaled 10x (in bits per unit area). So… maybe not the best analogy?

I mean NAND circuit primitives. Jokingly referring to the fact that NAND operations are all you need to build a complete logic system, but it's not very fun/ergonomic. And I'm joking that js is basically doing that but with whatever random js stuff browsers provide - which is basically just "js can do function calls. I guess let's build our entire framework on function calls."

Re: React is winning by default and slowing innovation

#706

Post by the_gipsy »

cjonas wrote: post #679
motorest wrote: post #635

Earlier quoted context omitted.

> React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. I agree with JSX, and function components are nice, but React is most definitely not just function composition. Hooks add state and introduce life cycle events that take…

So basically react class components? It definitely was not easier in those days. When your just using vanilla react, I've never had a problem with hooks being that hard to reason about. Once you add in SSR, routers, query caching frameworks, etc the "lifecycle & state" starts to get confusing. This is mostly a problem with the additional complexity of these frameworks (nextjs, tanstack) and not react at its core. Bui…

But you cannot really develop anything meaningful without adding frameworks.

I guess redux solves both "state" and "messages" at once, that's good. But what you work with then is not "vanilla react" at all. I don't even think "vanilla react" can really exist, beyond toy examples. You either use frameworks or write them yourself (worse).

Re: React is winning by default and slowing innovation

#707

Post by the_gipsy »

patates wrote: post #591
WickyNilliams wrote: post #573

Earlier quoted context omitted.

It's not confusing. It's an observation on their nature. The colouring isn't specific to promises, or even async/await. It applies to continuation style callbacks too. If you haven't, I recommend reading the (original?) article https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

I read the original article and many surrounding discussions & follow-up articles. Not confusion perhaps, but many see it as friction, including the complaints from the original article. From where I'm looking at, it's just a side effect of dealing with concurrency with no threads, what the article also mentions. So, you know, it is what it is, at the end? Now we have people coming up with different definitions of co…

The complaint is that it's not just "function composition" (per GP) at all anymore. You're dealing with "component lifecycles". Composition doesn't really work out with hooks, for reference see any non-toy React codebase.

Re: React is winning by default and slowing innovation

#708

Post by LegionMammal978 »

muspimerol wrote: post #564
cosmic_cheese wrote: post #93

Earlier quoted context omitted.

Not directly, but when you have devs who only know how to build with the framework and don’t have a grip on what’s going on under the hood or how it all interacts in the browser environment (increasingly common), performance is sure to take a hit.

This happens regardless of which framework is used or even if no framework is used. Plenty of web developers do not understand how the browser or JS work at a deep level.

Yeah, it's pretty close to the "Imagine how great the world would be if everyone used Lisp/Haskell/WhateverLang instead of Java/JS everywhere!" take you sometimes see. As if the common developer wouldn't just write in all those languages like they're Java/JS, and keep clear of the advanced macros/type systems/whatever.

Even languages or environments that try to "steer the developer into the correct direction" have only really managed it when the new direction is something they already might've chosen to write. Otherwise, you just end up with many square pegs filed down to fit in round holes.

Re: React is winning by default and slowing innovation

#709

Post by Eric_WVGG »

> The problem isn’t React itself, it’s the React-by-default mindset.

I think this is not-seeing-the-forest-for-the-trees.

The reason why we’ve been having this discussion for 20+ years is because HTML was not designed to be an app platform. It’s a document standard that we’ve grafted an app ecosystem on top of.

In Windows, Mac, or iPhone software development, there’s One Correct Way to develop apps. Yeah, there’s some fringe technologies — Electron, React Native, is MS Silverlight still a thing? — but when a fresh new developer says “I wanna make an iPhone app” the first thing you do is put a SwiftUI book in front of them.

Back over here in web-land, we’ve been re-inventing the wheel for thirty years. For most of that time, the best advice one could get new devs is to start playing around with javascript and just wing it. React (and specifically NextJS) is the closest thing the web has seen to a SwiftUI or AppKit or DotNet and to say that's a bad thing is bonkers.

IMO anyone who wants radical re-invention and innovation in web should be pushing the W3C into new standards that make interactivity as baked-in as CSS is — that is, turn it into a real application platform — and move toward deprecating Javascript itself.

Re: React is winning by default and slowing innovation

#710

Post by snemvalts »

conartist6 wrote: post #619
zero_shift wrote: post #504

Earlier quoted context omitted.

> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? It would be best to think of it as syntax sugar for create Element() function calls. You enter JSX with angle tags and insert expressions in braces > React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on…

Hooks are magic syntax without any doubt. All magic syntax is made up of non-magic parts, that's kinda the point. The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.

You can write const [a, b] = useState('x') in vanilla js and typescript. Hence it is not magic syntax.
Post reply on HN