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

831–840 of 866 posts

Re: React is winning by default and slowing innovation

#831

Post by austin-cheney »

MrJohz wrote: post #827
austin-cheney wrote: post #609

Earlier quoted context omitted.

Here is an example: /lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.

First off, thanks for sharing this, because I've seen a lot of your comments on these sorts of threads about web development, and it's helpful to see what your approach looks like in practice. There are a bunch of amber flags that immediately stand out, like this being an almost 4k line file with a commit history by only one person, and an idiosyncratic approach to naming and formatting. None of that is necessarily b…

This is an amazing comment. Thank you so much!!!

Re: React is winning by default and slowing innovation

#832

Post by tcoff91 »

bave8672 wrote: post #359
tcoff91 wrote: post #330

Earlier quoted context omitted.

A great native app on an iPhone feels far superior to a mobile website. The gestures, the stack navigator, haptics, scrolling, native ui primitives, etc… Also iOS accessibility screen reader APIs are way better than the web. Accessibility actions for instance are great.

It doesn't have to be this way though. What you're describing is a result of Apple intentionally prioritizing native over web apps to maintain control of their lucrative walled garden.

There’s no way within web standards to match iOS native api UX. Even on Android where you have chrome as the mobile browser you can’t match it.

Even if you could ship chrome renderer on iOS you won’t be able to make a mobile web app feel as good as an iOS app. The little details, animations, and microinteractions that come with native apps are better, plus there are other less visiual capabilities like background uploads and prefetching. The moment you need something like an in app camera, a native app is going to be so much better.

Re: React is winning by default and slowing innovation

#833

Post by [deleted] »

skowron wrote: post #824
whoknowsidont wrote: post #747

Earlier quoted context omitted.

No. I'm speaking from experience having used React from its very first release. You're not only factually wrong about me being wrong, your knowledge is obviously quite limited. React has always initially rendering components on the server, then hydrated on the client. You don't have to take my word for it, download the initial release and try it out yourself: https://github.com/facebook/react/releases/tag/v0.4.0 Go a…

Aren't you a treasure, thank the gods you're here to condescend us plebs.

[deleted]

Re: React is winning by default and slowing innovation

#834

Post by whoknowsidont »

skowron wrote: post #824
whoknowsidont wrote: post #747

Earlier quoted context omitted.

No. I'm speaking from experience having used React from its very first release. You're not only factually wrong about me being wrong, your knowledge is obviously quite limited. React has always initially rendering components on the server, then hydrated on the client. You don't have to take my word for it, download the initial release and try it out yourself: https://github.com/facebook/react/releases/tag/v0.4.0 Go a…

Aren't you a treasure, thank the gods you're here to condescend us plebs.

Claiming something is objectively wrong while stating something that can be refuted with 10 seconds of Googling means you're massaging your own ego at the expense of everyone else's time.

Grow up.

Re: React is winning by default and slowing innovation

#835

Post by hbrn »

b_e_n_t_o_n wrote: post #793
hbrn wrote: post #719

Earlier quoted context omitted.

> React feels natural because it never asks you to stop writing JavaScript I want to increment some counter on the webpage. Which approach feels natural? increment = () => { this.setState((prevState) => ({ count: prevState.count + 1 })); }; const increment = () => setCount((count) => count + 1); function increment() { count += 1; } No one wakes up saying "please let me mutate simple state with function calls".

The third example is missing the data binding that you get automatically with React. It should look more like this: function increment() { count += 1; dispatchEvent(new CustomEvent( "count-incremented", { detail: { count } } )); } I think I prefer not having to manage events all over the place.

Third example was supposed to be Svelte.

Vue also isn't too far:

  function increment() {
    count.value += 1
  }
In 2025, React state management is complete shitshow compared to Svelte and Vue.

How in the world people are claiming "React is just Javascript" is beyond me.

Re: React is winning by default and slowing innovation

#836

Post by Etheryte »

rimunroe wrote: post #810
Etheryte wrote: post #784

Earlier quoted context omitted.

If this was the case, why do we need to define the dependency list to begin with? If this was both the mainline right thing to do and the compiler can do it, why are we doing it manually? In that case we could just as well omit it by default and only have users define it when they want something different. The answer, in my opinion, is that it's just a patch over what's a leaky abstraction and the added overhead cost…

> In that case we could just as well omit it by default and only have users define it when they want something different. I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparis…

For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable. For two, this is exactly what I mean with leaky abstractions. The fact that you even have to think about this at all is a strong design smell. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. They come with their own bag of problems, but I would argue that their smells are considerably smaller than what hooks bring to the table.

Re: React is winning by default and slowing innovation

#837

Post by hajile »

recursive wrote: post #734
patates wrote: post #568

Earlier quoted context omitted.

Nitpick: React compiler is not a transpiler. JSX needs to be transpiled, and that's usually done by TS compiler. React compiler is another optional thing on top that's relatively very recent. https://react.dev/learn/react-compiler/introduction#what-doe...

All compilers translate one language to another language. Historically compilers targeted lower-abstraction languages than the source language. "Transpiler" is a compiler whose input and output abstraction levels are similar. The React cinematic universe has a habit of repurposing existing terminology, but they're both transpilers, to the extent that "transpiler" is even a word.

In JS land, transpile was used to distinguish something like elm->JS from ES6->ES3. One was the same language with different versions and the other was different source languages.

Yes, all transpilers are compilers, but not all compilers are transpilers.

Re: React is winning by default and slowing innovation

#838

Post by hajile »

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…

You are complaining about the libraries around it rather than react itself.

    function MyForm() {
      const [isHidden, setIsHidden] = useState(false)
      return (
        
          setIsHidden(!isHidden)}>{isHidden ? ‘Show’ : ‘Hide’}
          {!isHidden &&your same stuff}
        
      )
    }
As you can see, you’ll be writing less code than you’d write if you were using something like jQuery. At the same time, if you’re needs grow due to something like client-side validation, you at least have an easy path forward.

At it’s core, React isn’t very complex and you can build a lot of stuff without much complexity.

The problem I often see is developers overengineering stuff. It’s not react specific and you’ll find this issue everywhere, but the form it takes in react land is adding massive solutions to little problems. I’ve worked on apps with giant routing solutions for a handful of routes or complicated stores with almost nothing in them.

I suspect tech influencers and those of us writing actually large apps have an outsized voice if only because those devs keeping simple react projects simple just don’t have that much to write about.

Re: React is winning by default and slowing innovation

#839

Post by jonny_eh »

wahnfrieden wrote: post #757
jonny_eh wrote: post #365

Earlier quoted context omitted.

It's not React's fault that people either don't know what they're doing, or don't care enough to make their software performant. This is not a new phenomenon, bad/rushed software has always existed.

GitHub somehow became instantly slow to this day after they started introducing React but I guess it’s just their devs faults

Well, ya

Re: React is winning by default and slowing innovation

#840

Post by spicebox »

the_gipsy wrote: post #707
patates wrote: post #591

Earlier quoted context omitted.

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.

The whole reason that hooks were created was that they could composed, as opposed to stuff like renderprops or mixins. When you create a custom hook that uses a useState and a useEffect, that's composition. They have the caveat that they can only be composed into new hooks, but that's just like async functions only being able to be called from other async functions.
Post reply on HN