6 ms·

Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it tha

Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it that virtual dom is not necessary, and not the best solution for a scalable UI. At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtual DOM.

badbanana 5y ago
Not React code but SolidJS uses JSX to produce reactive code compile time in the same vein as Svelte.
- daok 5y ago
  IMP SolidJS fixes a lot of issue React as without leave the "React-ish" way to build components.
- josephg 5y ago
  Yeah I threw together a simple wiki on top of a CRDT using solidjs a couple weeks ago. It’s delightful - it’s basically react but compiled to be smaller and faster. (It looks and feels like react but there’s no giant runtime, and no vdom diffing). And it has a really nice API for reactive state. I haven’t built anything big with it yet but I like what I see so far!
tehbeard 5y ago
I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.
- dham 5y ago
  If you think Svelte is magic, wait until you see how hooks work.
  - nightski 5y ago
    Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
    - dmitriid 5y ago
      > Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
      - Spivak 5y ago
        Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant. Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run. Like it's janky and reaches through layers but it's not up and rewriting your code.
        dmitriid 5y ago
        > hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
picardo 5y ago
What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.
- judofyr 5y ago
  I’ve worked on React applications where a single key press would cause lags over 300ms. The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal. There’s some real overhead of React’s virtual DOM.
  - brundolf 5y ago
    That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place I'm really curious what was going on in your app
    - danielvaughn 5y ago
      I've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff. Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
      - brundolf 5y ago
        I think we're talking about two different things- I've definitely seen that much delay before, but it always came down to inefficient rendering logic and/or components that re-rendered excessively often, both of which are easy to detect in profiling and usually not too hard to solve This is the part I thought I was bizarre: > The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal
MuffinFlavored 5y ago
Does anybody use https://preactjs.com/ https://preactjs.com/ seriously? I thought React and React-DOM were separate? https://www.npmjs.com/package/react https://www.npmjs.com/package/react https://www.npmjs.com/package/react-dom https://www.npmjs.com/package/react-dom
- richeyryan 5y ago
  I have used it on production projections and it's seamless. It works with third party React packages with no problems whatsoever and is much lighter. For a stock standard SPA with no need for the upcoming server rendering stuff in React, it's excellent!
vmware513 5y ago
Luckily, there is Ember.js, which provides the best developer and user experience for a decade now, with smooth and consistent update and improvements. Still the best choice for huge, corporate frontend projects.

badbanana 5y ago

Not React code but SolidJS uses JSX to produce reactive code compile time in the same vein as Svelte.

daok 5y ago
IMP SolidJS fixes a lot of issue React as without leave the "React-ish" way to build components.
josephg 5y ago
Yeah I threw together a simple wiki on top of a CRDT using solidjs a couple weeks ago. It’s delightful - it’s basically react but compiled to be smaller and faster. (It looks and feels like react but there’s no giant runtime, and no vdom diffing). And it has a really nice API for reactive state. I haven’t built anything big with it yet but I like what I see so far!

tehbeard 5y ago

I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.

dham 5y ago
If you think Svelte is magic, wait until you see how hooks work.
- nightski 5y ago
  Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
  - dmitriid 5y ago
    > Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
    - Spivak 5y ago
      Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant. Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run. Like it's janky and reaches through layers but it's not up and rewriting your code.
      - dmitriid 5y ago
        > hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.

picardo 5y ago

What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.

judofyr 5y ago
I’ve worked on React applications where a single key press would cause lags over 300ms. The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal. There’s some real overhead of React’s virtual DOM.
- brundolf 5y ago
  That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place I'm really curious what was going on in your app
  - danielvaughn 5y ago
    I've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff. Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
    - brundolf 5y ago
      I think we're talking about two different things- I've definitely seen that much delay before, but it always came down to inefficient rendering logic and/or components that re-rendered excessively often, both of which are easy to detect in profiling and usually not too hard to solve This is the part I thought I was bizarre: > The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal

MuffinFlavored 5y ago

Does anybody use https://preactjs.com/ https://preactjs.com/ seriously? I thought React and React-DOM were separate? https://www.npmjs.com/package/react https://www.npmjs.com/package/react https://www.npmjs.com/package/react-dom https://www.npmjs.com/package/react-dom

richeyryan 5y ago
I have used it on production projections and it's seamless. It works with third party React packages with no problems whatsoever and is much lighter. For a stock standard SPA with no need for the upcoming server rendering stuff in React, it's excellent!

vmware513 5y ago

Luckily, there is Ember.js, which provides the best developer and user experience for a decade now, with smooth and consistent update and improvements. Still the best choice for huge, corporate frontend projects.