Hacker News Reader

Comment by mlsarecmg | Hacker News Reader

useMutableSource fixes these concerns. they all will light up green. some have it already as a draft or experimental, for instance zustand: https://github.com/react-spring/zustand/pull/160

with concurrent mode i think of what could be, web applications that can compete against native for the first time. as well as making making components that are resilient to async issues / making async a high level concept. there's a little churn for sure (for library devs, and a specific subset), but imo completely worth it.

View on HN

> with concurrent mode i think of what could be, web applications that can compete against native for the first time

Native apps feel better than web apps because they have robust UI libraries that web apps do not. React concurrent mode will have zero effect on that.

If the argument is "React concurrent mode will make web apps faster so that they feel more native", my response would be to use something like Svelte, which is available today and is considerably faster than React. React is slow.

Concurrent mode may make React faster but it'll just be making up for React's past mistakes, not the web's.

It's really unfortunate that Web Components are utterly useless. They simply are not components. It's insane.

I am not sure what you mean. Youtube is built on web components. Github is using web components. There are various libraries that can do web components, including Preact, Vue, or Svelte: https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...

In what way are they not components? They have identity, state, can draw output, and accept user input.

What's your definition of component?

If you have an application that renders more items than Svelte can handle (not many, we're in the web, you have 15ms max per frame, on a single thread), it will simply keel over and die. Scheduling is natural in native systems, you have occlusion, prioritization and threading of course. Svelte has no means whatsoever to counter load.

With what React is attempting currently your app will render as much as it possibly can while maintaining stable 60fps, the rest gets deferred while it can differ between lesser and higher-priority updates. If you doubt how important scheduling is, look at practically any feasible list component, they're all virtualized. With React every aspect and corner of the application is like that. In theory it could outperform native apps.

Btw, there are countless of robust desktop apps being made with HTML: VSC, Whatsapp, Skype, Spotify, Notion, Hyper, Discord, Slack, ... thought most of them will still feel sluggish compared to a native counterpart. React will change that.

Half of the "robust" apps you mentioned including the context of performance are neither robust nor performant. On really good hardware.

That is my point. They are robust from a UI perspective, but none them can compete against native due to the slow nature of the dom. This is why React is building a scheduler.

> countless of robust desktop apps being made with HTML: VSC, Whatsapp, Skype, Spotify, Notion, Hyper, Discord, Slack

VSC: chokes on files larger than several mb Slack: eats all of your memory, often hangs and just whites-out while I figure out what to do. Skype: has this app ever actually been good? Spotify: not sure I'd call it robust, but it's functional...enough.

> In theory it could outperform native apps....thought most of them will still feel sluggish compared to a native counterpart. React will change that.

My understanding is that native apps hook into far lower-level functionality and run with _signficantly_ less overhead. They simply execute faster, and far more directly. I don't see how React and needing to go through react-framework -> JS -> V8 -> etc would possibly compete with that, let alone outstrip them.

These apps all fall flat, which is the point i'm trying to make. They're robust from a design perspective, the tools we have to build UI are good enough, but they can't compete against native. Do you think that using Svelte in any those would make a difference? This is why React is attempting to find a solution.

The problem is essentially the same. Native apps are also conflicted with load, they have better means than we have on the web to deal with it, but it's still low-level and complex to orchestrate, threading for instance. Any one of those means pushes your app into async issuee, race conditions that you need to reconcile. With concurrent mode scheduling is a first class concept, your components won't be subject to race conditions. React maintains 60fps, high-priority content (user input, animations, transitions) can be ran fluidly while lesser priority content gets deferred. It has a good chance of outperforming multithreaded native apps with that model.

This demo illustrates the issue: https://youtu.be/nLF0n9SACd4?t=172 which is universal. You run into this on native platforms as well as on the web.

> not many, we're in the web, you have 15ms max per frame, on a single thread

Isn't the likely way forward to move the computationally heavy parts of the app over to web workers and to keep the main thread almost exclusively for UI work?

Reply on news.ycombinator.com