React is winning by default and slowing innovation • Hacker News Board

Re: React is winning by default and slowing innovation

#261

Post by harry_m » Tue, Sep 16, 2025, 12:46 AM UTC

apsurd wrote: post #225

recursive wrote: post #222

Earlier quoted context omitted.

Neither react's JSX nor vue's template language are HTML. But rejecting vue's template on grounds that it's not HTML seems odd. React's JSX deviates from HTML in many ways. Like class vs className. XML self-closing vs HTML self-closing. onchange vs oninput. On purely aesthetic grounds, I can't understand how the react idiom of array.map() would ever be preferable to an affordance in the (non-HTML) template language f…

it's not about feigning html purity it's the opposite. Why pretend we're using HTML when it's not? so with react it becomes a js flavor, jsx, which some people hate but it's very clear that it's a made up language IN real javascript. edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not…

Both the Vue template language and JSX are supersets of HTML. However, when it comes to integrating with CSS, JSX significantly worsens DX.

Re: React is winning by default and slowing innovation

#262

Post by e_y_ » Tue, Sep 16, 2025, 12:51 AM UTC

LAC-Tech wrote: post #214

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…

A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex. There's like an escalation ladder in my mind: - just write HTML - statically generate the HTML - dynamically generate the HTML - dynamically generate the HTML at a smaller granularity (HTMX et all) - augment your HTML with…

To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.

For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.

There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.

Re: React is winning by default and slowing innovation

#263

Post by spartanatreyu » Tue, Sep 16, 2025, 12:51 AM UTC

ikrenji wrote: post #114

rossant wrote: post #111

In simple applications, can we replace JS frameworks by a document with guidelines and best practices? What if I want to avoid frameworks and stick to vanilla JS, following instead good strategy and coding conventions for managing state, reacting to events, etc, all in pure JavaScript while avoiding spaghetti code. Does a document like this exist?

so you want to avoid using a framework in order to basically code something in pure JS that does what the framework does? whats the point of that?

I think the point is to not have to untangle another developer's middleware in a router from a bunch of state when all you needed was an anchor tag.

Re: React is winning by default and slowing innovation

#264

Post by apsurd » Tue, Sep 16, 2025, 12:51 AM UTC

LAC-Tech wrote: post #214

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…

A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex. There's like an escalation ladder in my mind: - just write HTML - statically generate the HTML - dynamically generate the HTML - dynamically generate the HTML at a smaller granularity (HTMX et all) - augment your HTML with…

i'm bookmarking this comment. great cascading list!

agree as a 10+ year customer facing product person doing tons of react.

Re: React is winning by default and slowing innovation

#265

Post by apatheticonion » Tue, Sep 16, 2025, 12:54 AM UTC

b_e_n_t_o_n wrote: post #258

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.

I explored JS decorators in the past but decorators are different in that they are a runtime operation that can't be statically compiled and can't be used on non-class properties.

You probably know this already but macros on the other hand are just dumb expansions/computations of syntax transformed at compile time, like

    let result = add!(1 + 2);

Would compile into

    let result = 3;

Including macros into the JavaScript spec is a bit weird because it's an interpreted language so compile-time concepts don't really make sense (which is probably why decorators were proposed).

But JavaScript is compiled more frequently than it isn't and we apply a crazy amount of transformations to it (typescript, tsx, path manipulation, styled-components, etc). IMO standardized compile-time manipulation with LSP integration would go a long way for language ergonomics.

That would also mean transformations for things like jsx could be run _in the browser_ allowing people who don't want to use a bundler to run their code without one.

    // Removed by the bundler, can also be used in the browser
    import jsx from "react/jsx" 

    const App = () => jsx!(>Foo)

Projects like this : https://github.com/developit/htm are an expression/symptom of that need

Re: React is winning by default and slowing innovation

#266

Post by apsurd » Tue, Sep 16, 2025, 12:54 AM UTC

e_y_ wrote: post #262

LAC-Tech wrote: post #214

Earlier quoted context omitted.

A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex. There's like an escalation ladder in my mind: - just write HTML - statically generate the HTML - dynamically generate the HTML - dynamically generate the HTML at a smaller granularity (HTMX et all) - augment your HTML with…

To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep…

fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client.

being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web"

edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.

Re: React is winning by default and slowing innovation

#267

Post by user3939382 » Tue, Sep 16, 2025, 12:56 AM UTC

HTTP and JS have to go

Re: React is winning by default and slowing innovation

#268

Post by c-hendricks » Tue, Sep 16, 2025, 12:56 AM UTC

sapiogram wrote: post #118

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…

What is Vercel doing to React? I just know them as a simple hosting solution.

For one they're shifting React to require a hosting solution.

/snark

Re: React is winning by default and slowing innovation

#269

Post by rTX5CMRXIfFG » Tue, Sep 16, 2025, 12:58 AM UTC

thinkxl wrote: post #168

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…

If React implodes because of bad architectural decisions, Vite should fork it. It's crazy that the best React DX is provided through Vue's community projects.

Why don’t we just switch over to Vue? If DX is such a driver for deciding to use a web framework, Vue kicks React’s ass, and that’s just objectively speaking.

Re: React is winning by default and slowing innovation

#270

Post by thomasfromcdnjs » Tue, Sep 16, 2025, 12:59 AM UTC

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

They kind of are not though, you can't call them out of order and other things which is checked at runtime by the React "engine" and will stop script execution. If they were regular functions you could call them anytime.