6 ms·

People loved React because it solved a problem. They just happened to solve it using virtual DOM. but theses next generation frameworks are showing that there'

People loved React because it solved a problem. They just happened to solve it using virtual DOM. but theses next generation frameworks are showing that there's a better way to solve the same problem.

tarkin2 6y ago
VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?
- ryansolid 6y ago
  Sort of. I don't think you can write off the virtual Dom. But this is basically my area of research. I'm saying that a specific approach to reactive programming is more performant. I have an article for that too: https://medium.com/better-programming/the-fastest-way-to-render-the-dom-e3b226b15ca3 https://medium.com/better-programming/the-fastest-way-to-ren...
  - tarkin2 6y ago
    Thanks. The whirlwind of changing benefits of various frameworks can be rather confusing. I do wonder how much this matters for most apps and at what cost of complexity it brings. But advancements in the field is a obvious good thing.
    - Aeolun 6y ago
      From my perspective, the things are a bit like this: 1. Make all updates manually with jQuery. This is fast, but hard to keep track of. 2. React, create a virtual DOM, then compare the current DOM with the virtual one, and figure out what needs to change. 3. Solid, Svelte, don’t create a virtual DOM, but have the JS compile all the possible changes so you can make them directly in the DOM like with jQuery.
      - nsomaru 6y ago
        If you’re “compiling all possible changes” that’s a diff, right? If there’s no VD, what’s being diffed?
        cocktailpeanuts 6y ago
        the question is not what, but when
        ludami 6y ago
        Exactly. Think of is as the classic compiled vs. interpreted languages debated. One is clearly faster than the other but the slower one may have different advantages.
        hajile 6y ago
        Ahead-of-time vs Just-in-time is a more accurate description. In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests). This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm up (a couple hundred executions before all the optimizations kick in). With the vDom, you warm up ONE set of code that then runs forever. With the precompile, it has to warm up for EVERY new component and potentially slightly different codepaths within the same component. The JS framework benchmark reuses the same components for everything which is a huge advantage to precompiled frameworks while not having much impact on vDom ones (as the actual components in both cases usually won't optimize very much due to being polymorphic).
        ryansolid 6y ago
        > In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests). I mean I agree with most of your post, but I'm not sure I would necessarily make that highlighted claim from the benchmark results. I mean the +- seems to be pretty run dependent for most libraries on there. And while I agree that the differences in performance is neglible, there is one. Solid is clearly faster in most tests even if by a small amount. Anyone interested you can look at: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... And then isolate Solid and Inferno and then do a comparison against one library. It will color highlight the degree of certainty the difference is between the libraries in terms of significance of the results.
- lukeramsden 6y ago
  This is a good talk on the matter from the creator of Svelte himself, if you're interested: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.
  - tarkin2 6y ago
    Thanks!
  - olah_1 6y ago
    My annoyance with that talk is he never compared Svelte with multi-threaded React. It was the natural next thing to look at but it was like “okay my point stands let’s move on” haha.
    - EGreg 6y ago
      Well maybe we should compare apples to apples. With React you go down a rabbithole of workarounds around their initial concepts (like hooks) until you wonder why you chose it in the first place.
      - uryga 6y ago
        why do you consider Hooks a "workaround around [React's] initial concepts"?
        ryansolid 6y ago
        I think Hooks are genius truthfully. But they are definitely shoehorning something into a place that didn't expect it. You are calling these render functions with the purpose of creating new transformations every cycle, and the injection mechanism has to include the initialization the first time. So you basically have these slotted things that allocate memory every time to just use what's cached most of the time. Now don't get me wrong I've benchmarked Hooks like crazy and I don't think they are much consideration on performance at all. It's just the mental model of always update on the outside with bubbles of things that don't update creating these closures is a little unnatural. By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update. Wrap what needs to be updated. Done. There are no out of date closures. No inconsistent mental model. It's as straightforward as registering event handlers. Still I have to admit the solution is genius. They have managed to get 90% of the benefits with simply repositioning things. At one point this was one of my biggest arguments against React. People didn't appreciate it before hooks. But can you imagine knowing you could write applications this way years ago and trying to convince someone using React classes there was a better way? I just sort of gave up and did my own thing.
- austincheney 6y ago
  Perhaps faster than other framework implementations but there is no way it’s faster than the standard DOM methods. https://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode#23995928 https://stackoverflow.com/questions/21109361/why-is-reacts-c...
  - deleted 6y ago
    [deleted]
- Vinnl 6y ago
  VirtualDOM allows you to roughly code your UI as a function of state. It's never been a magic bullet to better performance, except perhaps compared to Angular.js 1.x's "change detection" methods.
- deleted 6y ago
  [deleted]

tarkin2 6y ago

VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?

ryansolid 6y ago
Sort of. I don't think you can write off the virtual Dom. But this is basically my area of research. I'm saying that a specific approach to reactive programming is more performant. I have an article for that too: https://medium.com/better-programming/the-fastest-way-to-render-the-dom-e3b226b15ca3 https://medium.com/better-programming/the-fastest-way-to-ren...
- tarkin2 6y ago
  Thanks. The whirlwind of changing benefits of various frameworks can be rather confusing. I do wonder how much this matters for most apps and at what cost of complexity it brings. But advancements in the field is a obvious good thing.
  - Aeolun 6y ago
    From my perspective, the things are a bit like this: 1. Make all updates manually with jQuery. This is fast, but hard to keep track of. 2. React, create a virtual DOM, then compare the current DOM with the virtual one, and figure out what needs to change. 3. Solid, Svelte, don’t create a virtual DOM, but have the JS compile all the possible changes so you can make them directly in the DOM like with jQuery.
    - nsomaru 6y ago
      If you’re “compiling all possible changes” that’s a diff, right? If there’s no VD, what’s being diffed?
      - cocktailpeanuts 6y ago
        the question is not what, but when
        ludami 6y ago
        Exactly. Think of is as the classic compiled vs. interpreted languages debated. One is clearly faster than the other but the slower one may have different advantages.
        hajile 6y ago
        Ahead-of-time vs Just-in-time is a more accurate description. In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests). This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm up (a couple hundred executions before all the optimizations kick in). With the vDom, you warm up ONE set of code that then runs forever. With the precompile, it has to warm up for EVERY new component and potentially slightly different codepaths within the same component. The JS framework benchmark reuses the same components for everything which is a huge advantage to precompiled frameworks while not having much impact on vDom ones (as the actual components in both cases usually won't optimize very much due to being polymorphic).
        ryansolid 6y ago
        > In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests). I mean I agree with most of your post, but I'm not sure I would necessarily make that highlighted claim from the benchmark results. I mean the +- seems to be pretty run dependent for most libraries on there. And while I agree that the differences in performance is neglible, there is one. Solid is clearly faster in most tests even if by a small amount. Anyone interested you can look at: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... And then isolate Solid and Inferno and then do a comparison against one library. It will color highlight the degree of certainty the difference is between the libraries in terms of significance of the results.
lukeramsden 6y ago
This is a good talk on the matter from the creator of Svelte himself, if you're interested: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.
- tarkin2 6y ago
  Thanks!
- olah_1 6y ago
  My annoyance with that talk is he never compared Svelte with multi-threaded React. It was the natural next thing to look at but it was like “okay my point stands let’s move on” haha.
  - EGreg 6y ago
    Well maybe we should compare apples to apples. With React you go down a rabbithole of workarounds around their initial concepts (like hooks) until you wonder why you chose it in the first place.
    - uryga 6y ago
      why do you consider Hooks a "workaround around [React's] initial concepts"?
      - ryansolid 6y ago
        I think Hooks are genius truthfully. But they are definitely shoehorning something into a place that didn't expect it. You are calling these render functions with the purpose of creating new transformations every cycle, and the injection mechanism has to include the initialization the first time. So you basically have these slotted things that allocate memory every time to just use what's cached most of the time. Now don't get me wrong I've benchmarked Hooks like crazy and I don't think they are much consideration on performance at all. It's just the mental model of always update on the outside with bubbles of things that don't update creating these closures is a little unnatural. By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update. Wrap what needs to be updated. Done. There are no out of date closures. No inconsistent mental model. It's as straightforward as registering event handlers. Still I have to admit the solution is genius. They have managed to get 90% of the benefits with simply repositioning things. At one point this was one of my biggest arguments against React. People didn't appreciate it before hooks. But can you imagine knowing you could write applications this way years ago and trying to convince someone using React classes there was a better way? I just sort of gave up and did my own thing.
austincheney 6y ago
Perhaps faster than other framework implementations but there is no way it’s faster than the standard DOM methods. https://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode#23995928 https://stackoverflow.com/questions/21109361/why-is-reacts-c...
- deleted 6y ago
  [deleted]
Vinnl 6y ago
VirtualDOM allows you to roughly code your UI as a function of state. It's never been a magic bullet to better performance, except perhaps compared to Angular.js 1.x's "change detection" methods.
deleted 6y ago
[deleted]