5 ms·
First off, I am always happy to see people trying out new things because it creates innovation. Congratulations on launching! That said, the big feature here s
by kristiandupont 4y ago
First off, I am always happy to see people trying out new things because it creates innovation. Congratulations on launching!
That said, the big feature here seems to be what the headline says: no virtual DOM. As a user of frameworks, I don't care much about implementation details unless they result in benefits like performance improvements. Does this perform better than React and/or Vue? Or is there some other benefit to it?
- andy_ppp 4y agoYes was going to say exactly this, tell my updates are faster or the library is smaller but just saying we built it without virtual DOM doesn’t explain the trade offs in this approach.
- larsonnn 4y agoI wouldn’t call it a new thing. We began without virtual DOM and then Facebook sold us the vDOM as the ultimate way to go. Which svelte clearly shows, by removing the unnecessary layer for the vdom it’s much faster and is still reactive.
- nailer 4y agoSolid too. But yes Svelte seems to have been the current thing for a few years now.
- szastamasta 4y agoThey did this while introducing a lot of compiler magic and automatic dependency discovery that not always works. I’m not sure I’m sold on it. Code you write is not code you execute.
- romualdr 4y agoYou're correct, it's not new. Still, the question remains, what's the improvement over Svelte or SolidJS which doesn't use VDOM as well ?
- richeyryan 4y agoOr there is Inferno which is VDOM based and outperforms Svelte on most benchmarks. The whole narrative of "VDOM is pure overhead" doesn't hold out in practice, and I suspect really just an excuse to attack React and promote Svelte. https://krausest.github.io/js-framework-benchmark/2023/table_chrome_110.0.5481.77.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL2FuZ3VsYXIiLCJrZXllZC9lbG0iLCJrZXllZC9lbWJlciIsImtleWVkL2luZmVybm8iLCJrZXllZC9yZWFjdC1ob29rcyIsImtleWVkL3NvbGlkIiwia2V5ZWQvc3ZlbHRlIiwia2V5ZWQvdmFuaWxsYWpzIl0sImJlbmNobWFya3MiOlsiMDFfcnVuMWsiLCIwMl9yZXBsYWNlMWsiLCIwM191cGRhdGUxMHRoMWtfeDE2IiwiMDRfc2VsZWN0MWsiLCIwNV9zd2FwMWsiLCIwNl9yZW1vdmUtb25lLTFrIiwiMDdfY3JlYXRlMTBrIiwiMDhfY3JlYXRlMWstYWZ0ZXIxa194MiIsIjA5X2NsZWFyMWtfeDgiLCIyMV9yZWFkeS1tZW1vcnkiLCIyMl9ydW4tbWVtb3J5IiwiMjNfdXBkYXRlNS1tZW1vcnkiLCIyNV9ydW4tY2xlYXItbWVtb3J5IiwiMjZfcnVuLTEway1tZW1vcnkiLCIzMV9zdGFydHVwLWNpIiwiMzRfc3RhcnR1cC10b3RhbGJ5dGVzIl0sImRpc3BsYXlNb2RlIjoxLCJjYXRlZ29yaWVzIjpbMSwyLDMsNCw1XX0= https://krausest.github.io/js-framework-benchmark/2023/table...
- vlovich123 4y agoOutperforms? Solid, svelte and inferno all look to have very similar numbers in that table unless I’m terribly misreading it. So similar, that I think which way it goes is possibly more dependent on your benchmark environment than any difference between them.
- antifa 4y agoAccording to that, solid won in the majority of metrics. And what about build size?
- aquaductape 4y agoSvelte has largest component size compared to other frameworks such as Vue, React and Solid, so it quickly grows, even on a small webapp. Because Inferno is VDOM, I'm assuming it has a smaller component size compared to Solid.
- ulizzle 4y agoYeah, it does have significant performance improvements, because diffing the Virtual Dom adds heavily to computation costs if you aren't being extra careful or as the application grows to real-world size, especially in mobile. No VDom is always faster than having a VDom. But I do agree with your point 100% that it should tell you right away about it on the README what that means, and the significance behind the claim.
- dmitriid 4y agoNo, it's not always faster. IIRC in a recent stream the author of Solid showed that it's hard to beat a proper VDOM implementation when you have 1000s of elements. And most naive non-VDOM implementations will probably lose to a good VDOM implementation.
- jakelazaroff 4y agoThat’s true, but you can say the same thing about reactivity: not having it is always faster than having it. These are not zero-cost abstractions; we use them because the alternative tends to be less performant at scale, but technically you can always beat them by going in and manually updating the DOM yourself.
- password11 4y ago> because diffing the Virtual DOM adds heavily to computation costs if you aren't being extra careful or as the application grows to real-world size, especially in mobile. Is there some recent study showing evidence or analysis of this? You're saying the main root cause of poor performance is the diff burning up CPUs? I always assumed applications run slowly because people are overusing global (redux) state and every state change is subscribed to by like 10 different components. And people making 5 network calls before their component meaningfully renders.
- HereBeBeasties 4y agoAs ever, it depends on your use case. If you're rendering 20 TODO items then who cares? If you're rendering thousands of items on an SVG data visualisation, sure it matters. You can tell it matters because otherwise React wouldn't have implemented escape valves to improve performance, like shouldComponentUpdate. You can get around this by using persistent data structures with lenses, which is how Elm works. Then it's just reference equality checks as you go down the tree, which is inherently faster.
- synergy20 4y agoHow is it different from svlete and solidjs? both are no-VDom approaches.
- fabiospampinato 4y agoThings like Solid (https://www.solidjs.com/ https://www.solidjs.com/) also have no virtual DOM, and the improvements are in higher ceiling for performance, lower memory usage, simpler DX (components are not re-executed, there aren't any dependency arrays anywhere), easy high performance (no useRef this and useRef that to make things fast, no useCallback, no React.memo, these things are just obsolete).