5 ms·

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/r

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

untog 6y ago
> 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.
- api 6y ago
  It's really unfortunate that Web Components are utterly useless. They simply are not components. It's insane.
  - azangru 6y ago
    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-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...
  - spankalee 6y ago
    In what way are they not components? They have identity, state, can draw output, and accept user input. What's your definition of component?
- mlsarecmg 6y ago
  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.
  - milankragujevic 6y ago
    Half of the "robust" apps you mentioned including the context of performance are neither robust nor performant. On really good hardware.
    - mlsarecmg 6y ago
      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.
  - FridgeSeal 6y ago
    > 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.

untog 6y ago

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

api 6y ago
It's really unfortunate that Web Components are utterly useless. They simply are not components. It's insane.
- azangru 6y ago
  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-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...
- spankalee 6y ago
  In what way are they not components? They have identity, state, can draw output, and accept user input. What's your definition of component?
mlsarecmg 6y ago
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.
- milankragujevic 6y ago
  Half of the "robust" apps you mentioned including the context of performance are neither robust nor performant. On really good hardware.
  - mlsarecmg 6y ago
    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.
- FridgeSeal 6y ago
  > 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.