19 ms·

Virtual DOM is pure overhead (2018)

• imvetri 5y ago
  For anyone who wants to know how svelte handles DOM CRUD look at this question I had asked in stackoverlow https://stackoverflow.com/questions/56215374/what-is-the-concept-behind-svelte-compilation https://stackoverflow.com/questions/56215374/what-is-the-con...
• vlovich123 5y ago
  The blog ends with > But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?
  • TedDoesntTalk 5y ago
    Yes, I too was hooked but disappointed there was no link to a follow-up article!
  • nailer 5y ago
    Svelte is: - smaller (because Svelte doesn't include Svelte in the binaries it outputs, but rather a dynamically generated static mapping between data and elements) - better organised (single function components, with the JS, HTML and CSS in a single file) - like Vue! - simpler (name = 'Joe' instead of const [getName, setName] = useState(null); setName('joe')). The last one isn't quite true as you can't use this in all circumstances - fruits.push('pear') won't update fruits, you have to run 'fruits = fruits' afterward to trigger the update (there are other ways too).
    • deleted 5y ago
      [deleted]
  • dsego 5y ago
    It compiles the code into vanilla JS that directly updates the DOM on state changes.
  • porpoisemonkey 5y ago
    There's a better explanation of the differences here: https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like that eat into your frame budget and tax the garbage collector. Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.
    • pas 5y ago
      Isn't this very similar to Angular's Ivy compiler?
  • bobbylarrybobby 5y ago
    They briefly touched on what makes Svelte different but for some reason didn’t highlight it as the main takeaway. When Svelte builds your app, it’s fully aware of what components will need to update when data changes, and so it can wire up those precise dependencies statically. Then when data changes at runtime, instead of needing to diff the new state against the old state, components are updated in the way that was prescribed at build time, which is maximally efficient (as long as Svelte’s compiler is reasonably smart).
• nailer 5y ago
  I thought most of the JS world know that virtual DOM is slow and ahead-of-time direct binding is the way forward at this point - why do something expensive inside your users browser when it should be done on the developer's machine? Svelte will either take over, or React will get patched to start doing this in a major new release. It could go either way at this point.
  • dragosmocrii 5y ago
    I doubt Svelte will take over. Although I really like Svelte, and worked with it before React, the tooling with React is simply superior. Besides, React already mentioned in one of their introduction tutorials that they are considering taking Svelte's approach at one point. Developers choose the tools that makes them productive and that are enjoyable, not the ones that are most efficient (otherwise we'd all be writing assembly code)
    • nailer 5y ago
      > Developers choose the tools that makes them productive and that are enjoyable That true, but that points more towards Svelte taking over.
• leeoniya 5y ago
  also read https://ryansolid.medium.com/components-are-pure-overhead-12358123bc2b https://ryansolid.medium.com/components-are-pure-overhead-12...
• mvanaltvorst 5y ago
  You could also say Python is pure overhead. You can write any Python programme in C, but more efficiently! C is faster, and therefore better. This article avoids the fact that declarative programming has proven to be more pleasant for most people. And React simply is fast enough for most use cases, even though it has a performance penalty compared to Svelte. The virtual DOM is an elegant optimisation that usually works well in the real world, and methods like `shouldComponentUpdate()` can be used in the 1% of cases where the default is not fast enough.
  • Ashanmaril 5y ago
    > This article avoids the fact that declarative programming has proven to be more pleasant for most people. No it doesn't. Second-to-last paragraph: "It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones."
    • mvanaltvorst 5y ago
      You're right! Seems like I skimmed over that part. My point still stands, though.
      • nailer 5y ago
        Ease of use is definitely important - but 9/10 programmers not familiar with either Svelte or React, learning either for the first time, would prefer Svelte. There's many good reasons to use React - mainly the React ecosystem - but simplicity is not one of them.
  • shp0ngle 5y ago
    This article is specifically attacking a claim that I have heard before - that React is fast, because it works on virtual DOM, therefore it is faster than real DOM operations. I have heard that claim myself before.
• akx 5y ago
  This article is from 2018. Plenty of water under the JS bridge since then.
• ankurpatel 5y ago
  I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality. I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimulus JS is good enough. Personally I do not see why everyone wants to build a Single Page App when 80% of your pages are static and can be server rendered and with SSR frameworks you can build something a lot faster than building a Frontend and Backend separately and fragmenting or hiring extra developers when it is not needed. DHH said your code reflect your org structure and I agree companies that use SPA and Backends micro service arch usually tend to require more developers rather than companies that use SSR monoliths which appeal to smaller 1-3 developer companies that are building out a POC before committing huge amount of venture capital or their own money behind an idea that may not succeed.
  • kfk 5y ago
    about the monolith, the way data is growing in companies it will be impossible for one team to manage apps running for all data business domains. Businesses are not monoliths, they are organized in departments. The Supply chain department is the best suited for building supply chain services. The monolith might make technological sense but it’s making less and less business sense, just look at how quickly monolith systems like SAP or Salesforce are becoming obsolete.
    • nesarkvechnep 5y ago
      Not quick enough, actually
  • hallway_monitor 5y ago
    The SPA movement has always seemed like a cargo cult to me. Yes, AJAX is handy and it was exciting when it came out. We used it to update search results when you changed a filter. For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.
• nextaccountic 5y ago
  Okay, but - why does Rust frontend libraries (like Yew and Seed) use vdom instead of doing whatever Svelte does? Actually, is anyone else doing it the Svelte way?
  • posnet 5y ago
    There are some VDom-less libraries popping up now. https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore
    • nextaccountic 5y ago
      This is very cool, thanks!
  • pcstl 5y ago
    Because VDOM is useful for writing declarative code. It's DX over UX - and most of the time it won't impact UX anyway.
  • the__alchemist 5y ago
    I created Seed. I didn't know any better at the time! I'm no longer a fan of the extra computations VDOM does. Svelte's approach sounds like a clever way to mix declarative code without running extraneous computation.
    • nextaccountic 5y ago
      I understand. Btw, what do you think about MoonZoon? (https://github.com/MoonZoon/MoonZoon https://github.com/MoonZoon/MoonZoon) In special, the decision to not use Elm architecture. I see it's created by the current Seed maintainer. It appears MoonZoon uses https://github.com/Pauan/rust-dominator https://github.com/Pauan/rust-dominator which, like Sycamore, is also a DOM library that doesn't use vdom.
      • the__alchemist 5y ago
        Looks like a cool concept. Martin started working on it some time after I moved on, so I don't have any insight on it. I'd considered incorporating Dominator instead of an original VDOM, but at the time, it wasn't obvious how you'd interface with it. Ie not much in the way of docs or examples.
• jeswin 5y ago
  For 95% of apps, Svelte's custom syntax is pure cognitive overhead making little difference to the performance of the app.
  • recursive 5y ago
    For me, trying to make sense of how React's reconciler matches hook invocations to component instances is pure cognitive overhead. Other people don't seem to have this problem. But trying to accomplish anything in React is arduous for me, particularly with function components and hooks. Class components seem a little more obvious.
    • madeofpalk 5y ago
      Is it possible to just not think about it? Or is that easier said than done?
      • millerm 5y ago
        Yes, it's completely possible and most people don't think about it, at all. It's not complicated.
      • scotty79 5y ago
        I think it's perfectly possible if you just don't place hooks in a loop or if, which you shouldn't do and are warned against.
      • recursive 5y ago
        Usually it just works. But, even following the "Rules of Hooks" (https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html), I managed to write some code where the state that belonged to one component ended up in its adjacent sibling. When that happened, I really wasn't sure what to do other than go on a deep react dive. It's not clear how to debug stuff like that. I came to realize that I had confused the reconciler. The fix is basically to just use the key= attribute everywhere, not just in arrays.
• slumdev 5y ago
  The most important line: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Declarative, state-driven UI development is a valuable abstraction. I really hope readers take this to heart, rather than the article title becoming a new meme.
  • recursive 5y ago
    Declarative state-driven UI is great, but personally, I really prefer the way e.g. knockout does it over react. It uses observables and publish/subscribe to issue updates to DOM elements directly where they're needed. You may not like knockout, but it shows how virtual DOM isn't a requirement for declarative state-driven UI.
  • WillDaSilva 5y ago
    They note right after that: > it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in The abstraction is valuable, but its cost need not be so high. I do wish they'd elaborate on what Svelte does differently though, or link to another post which elaborates.
    • slumdev 5y ago
      The front page of their website proclaims Svelte to be "Cybernetically enhanced web apps", whatever that means. The "Rethinking" post gives a little more detail: > Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics. https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity Seems like a great idea, if it can gain the critical mass required and build a community of people developing code for it.
  • wruza 5y ago
    Declarative, state-driven UI development is a valuable abstraction. Which browsers do not support natively for decades and entire markets of ecosystems grow to work around that stupidest fact. Browsers could detect, batch and “reconcile” (whatever that means) the changes to the js runtime with much less runtime and devtime overhead than it is done in js by manual state tracking and updates.
• dvdcxn 5y ago
  I think this 3 year old topic needs to be revisted considering the improvements that Concurrent mode will provide.
• AshleysBrain 5y ago
  This blog says what I've always thought - that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code - not just DOM calls. If your pure JS code already is designed to eliminate redundant calls, then you already get the minimal DOM calls from JavaScript too. That's the best case, and VDOM can only be slower as it adds diffing overhead on top. There might be other good reasons to use a VDOM (including cases like using the DOM in a web worker). But I don't think performance is one of them.
  • madeofpalk 5y ago
    > you need to eliminate all redundant calls and operations this is a no-brainer, right? The tricky part is how you identify redundant calls and eliminate them, knowing that some have more cost than others.
  • onion2k 5y ago
    that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code That will still only result in a performant, smooth 60fps application if you can do all the calls and ops that aren't redundant in less than 11ms (16.6ms per frame, but the browser needs about 5ms to update the screen). If you're trying to do more than you can calculate in 11ms then you have to start spreading things over multiple frames hopefully doing what's most important first. This is pretty much what React's concurrent rendering claims if can do for you. If it works well it really will make applications feel significantly better. As far as I know Svelte doesn't have a solution for that. It just hopes you can get everything done in that 11ms. To be fair, 11ms is quite a lot of time on a modern computer, so unless you're doing some heavy calculation work that you can't move off the main thread to a worker you should be fine.
• ElViajero 5y ago
  The web stack, from tunneling thru HTTP to the JavaScript language itself, is a very interesting case study. I think that many decisions, like creating a virtual DOM, make a lot of sense in isolation. But, if you look at the complete ecosystem, no sane human being would have ever designed anything like that. Maybe, the Virtual DOM is pure overhead if you look at the complete system, but: 1. It was reasonable at the time 2. Some other patch to the Web Ecosystem will fix this The more systems are interconnected, the more difficult is to change anything radically and only incremental changes are possible.
  • mumblemumble 5y ago
    What's interesting to me, as someone who is currently learning Web development mid-career, is that I can see that vanilla JS is actually a really good option nowadays, but not necessarily available to anyone who's more established. Because it doesn't seem to have gotten good until fairly recently, and, for the most part, everyone had already made the important technical decisions before that happened. So, even if it's not necessary now, there's not necessarily any escape. The problem with complex tech stacks is that, for a variety of technical and social reasons, it's much easier to add to them than it is to take away. You can't necessarily incrementally roll back any of the bits of an existing React-based site; such an effort is liable to spiral into a complete rewrite. It's relatively easy, though, to incrementally add new things in order to paper over whatever's bugging you at the moment. The social story is similar. Coming from a position of knowing very little, the effort for me to learn the vanilla JS way of doing things is roughly similar to the effort to learn the React way of doing things. But, if I were already invested in the React ecosystem, that wouldn't be the case. I wouldn't just have to learn new tooling, I'd also have to re-learn my entire way of thinking about how to architect a webpage. Realistically, you can't, all else being equal, justify a radical re-tooling in order to achieve an incremental benefit like that.
    • jacob019 5y ago
      Vanilla JS gets messy as your app scales. You will end up building a framework.
• btown 5y ago
  While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html https://reactjs.org/docs/concurrent-mode-intro.html
  • agumonkey 5y ago
    Man I've been waiting for this for so long.
  • TeMPOraL 5y ago
    > React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames That's just cheating though, isn't it? And not in a good way. If you smear your DOM update over consecutive frames, you can maybe cram in 2-4x more operations in there before the user starts noticing. Past this point, a smeared update starts having design implications - things that should happen simultaneously now happen sequentially. Not to mention, application starts to feel heavy.
  • jiofih 5y ago
    The only reason you need that in the first place is because of how expensive updates in react are. It’s lack of true reactivity and user-controlled memoization lead to a ton of trashing. Svelte on the other hand is as optimized as possible - update the data, modify the corresponding DOM pieces directly. There is no realistic use case where you’d need to spread an update over multiple frames.
  • esprehn 5y ago
    React's concurrent mode doesn't split DOM updates across animation frames because that would cause visual tearing. It splits all the component "overhead" and the virtual DOM cost over multiple tasks though.
• mjw1007 5y ago
  Compare the design of Featherstitch [1], in contrast to BSD's soft updates. (I wonder what happened to Featherstitch.) [1]: https://lwn.net/Articles/354861/ https://lwn.net/Articles/354861/ It's a common pattern that you have a list of items of work to be done which in principle you could know ahead of time, but in practice it's better to track at runtime (even though it means the computer ends up repeating the same calculation again and again).
• KaoruAoiShiho 5y ago
  Svelte is so 2020, the new hotness is SolidJS. https://dev.to/ryansolid/solidjs-official-release-the-long-road-to-1-0-4ldd https://dev.to/ryansolid/solidjs-official-release-the-long-r...
  • croes 5y ago
    Any good comparison between Svelte and Solid.Js?
  • dgellow 5y ago
    SvelteKit is 2021 though :)
  • mncharity 5y ago
    This prompt to check on current Svelte and Solid-js alternatives, resulted in new posts on Marko[1], and OT, on Mini Apps.[2] Thanks! :) EDIT: Hmm, a few minutes later, the Marko post is blank, or not, depending on whether I'm logged it. That's... unexpected. Maybe a rate limit? The working url is https://dev.to/ryansolid/what-has-the-marko-team-been-doing-all-these-years-1cf6 https://dev.to/ryansolid/what-has-the-marko-team-been-doing-... . Too late to delete the post to leave the url clear for someone else to post. :/ [1] https://news.ycombinator.com/item?id=27676785 https://news.ycombinator.com/item?id=27676785 What Has the Marko Team Been Doing All These Years? Jun14 By Ryan Carniato of Solid, now on ebay's Marko. The interesting discussion at the end (including why Marko didn't catch on) turned up: [2] https://news.ycombinator.com/item?id=27676743 https://news.ycombinator.com/item?id=27676743 Mini apps: A web developer's exploration into mini apps — apps that are built with web technologies but that do not run in browsers.
  • jcuenod 5y ago
    Honestly, SolidJS is one of the most exciting options on the horizon. The creator wrote the vanillajs implementation for the frontend framework benchmarks so he really knows a lot about the performance implications of implementation details. The great thing about Solid is that it's a lot closer to react with hooks and jsx (I feel like Svelte is learning too much non-js stuff). The problem is that it also has its gotchas. It's much "smarter" than react about re-rendering, which means that it memoizes nodes all over the place and doesn't rerender the entire tree and diff all the time. Instead, it's only rerendering the node that changed (and not even the children of that node unless you set up the children correctly—gotcha). But look at the benchmarks... it's solid! I asked Rich Harris (author of Svelte) this: https://twitter.com/jamescuenod/status/1326747369480871941?s=20 https://twitter.com/jamescuenod/status/1326747369480871941?s... Ryan Carniato (author of Solid) makes some comparisons to Svelte here: https://dev.to/ryansolid/5-ways-solidjs-differs-from-other-js-frameworks-1g63 https://dev.to/ryansolid/5-ways-solidjs-differs-from-other-j... and also here: https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961c1125a6719a1cbd88b/documentation/comparison.md#svelte https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961...
• yuchi 5y ago
  @dang please add the (2018) suffix to this article.
  • rob 5y ago
    Apologies, given that I registered here in 2007 I should have known. Been away for a while!
• deleted 5y ago
  [deleted]
• ferdowsi 5y ago
  I feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what? In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering might be a problem is at Facebook SPA scale, and the vast majority of apps are not Facebook.
  • croes 5y ago
    It's not only performance, but cpu time and data volume.
    • dgellow 5y ago
      And battery life.
  • gregoriol 5y ago
    You are considering this from the side of one web app, but users generally will have dozens of tabs open. When you need a Core i7 with 16GB of RAM to handle your browser, because each developer didn't care about their individual performance, the web experience becomes a nightmare.
  • lamflam 5y ago
    For the applications I have worked on, rendering is basically the only reason for unresponsiveness. Loading from the network happens asynchronously and doesn't block the JS thread so any other interactivity or loading state/animation should work just fine. If loading over the network makes the application seem unresponsive, that's generally just bad UX implementation. I am currently working with low-latency audio and the latency requirements mean I have minimal buffering. While the VDOM render cycle is generally fast enough to be unnoticeable to the user, it stalls the audio buffering just enough to cause some stalling. There's a few heavier parts of the application where the rendering is expensive enough to briefly stall animations as well. While both of these issues are something we need to fix, it is specifically the rendering/vdom process that we need to work around to address these performance concerns, and we are definitely not at all Facebook.
• preommr 5y ago
  I've never really bought into this. The diffing is mostly an implementation deatil that is abstracted away. React could check to see if props.items changed instead of the nonsense it does. If it still does that in 2021. The thing is vue uses getters and setters that would trigger direct changes without needing to diff the entire tree. It could theoretically be really fast, but it still used a virtual dom, and it was around react speeds, give or take. I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte. I remember seeing a tweet by Evan You about vue3 being pretty much as fast svelte if not slightly faster. The point is that speed, when it comes to front-end frameworks, is a weird thing. There are other factors that are much more important like tooling, stability, code style, dealing with animations, etc. Things like svelte's compiler approach are much more interesting and unique selling points.
  • bmuon 5y ago
    > I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte Facebook has been working for a while on Ahead-Of-Time compilation for React. Interestingly, it looks like they thought the problem was too complicated and they gave up: > To address this challenge we initially experimented with one approach to ahead-of-time (AOT) optimization — Prepack — but ultimately that direction did not pan out. Specifically, we realized that many AOT optimizations don’t work because they either don’t have enough global knowledge or they have too little. For example, a component might be static in practice because it always receive a constant string from its parent, but the compiler can’t see that far and thinks the component is dynamic. Even when we could make optimizations work, we found that they were unpredictable to the developer. Without predictability it was hard for developers to rely on them. Instead they're now experimenting with moving the virtual DOM resolution to the server and avoiding sending all the "templating" code to the client, which achieves a similar result. See https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react....
• flowerlad 5y ago
  If you don't need Virtual DOM then Web Components are a great idea for building reusable components that work with all frameworks, including React. You can even use JSX to build Web Components: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
• jchw 5y ago
  Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead. Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here. In practice. So Svelte has a lot to prove to get people to try to move. And this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” (while simultaneously admitting that plenty of frameworks were slower at the time.) That’s not going to work. That’s going to classify you as “insane person” to many people. It reminds me of the claims G-WAN made: over-exaggerations in a smarmy tone based on micro-benchmark wins. I’m not saying there’s anything wrong with Svelte. But, this is not how you sell something. React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. It delivered exactly that. And yet: > the alternative is to do something no-one actually does Somehow this article manages to contradict itself in pursuit of unnecessary smarminess. I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion. The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.
  • madeofpalk 5y ago
    > this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.
    • 5y ago
• cwmma 5y ago
  the "strawman" of updating innerHTML on every change isn't that far from the truth of how a lot of backbone apps worked, you had a template that you'd render and set to innerHTML on input change, maybe the app would be broken down into different parts with their own template and the app would spend a bunch of logic tracking which changes updated which parts or trying to batch changes up, but that's not far off for a lot of backbone apps. One of the big selling points of react was you could basically write your app that way and it would fine.
• obphuscate 5y ago
  I read this long ago and I love Rich Harris and I think he is a super smart guy. But the problem as I see it is that he focuses on VDOM as just a performance hedge. As browsers improve (or rather as the market consolidates on WebKit variants as is happening now), then certain DOM operations that took substantially longer on average on IE or Edge vs. Chrome will no longer be as much of a problem, which is my view of what the VDOM was trying to solve. There are some operations that depending on the browser and how the internal mechanics of the layout engine work will take substantially longer on one browser vs another for instance. You are at the mercy of each layout engine's architecture. In this case, if you use a VDOM to calculate the simplest operation to be performed and just push the end results with the simplest operations manageable, you can elide away the differences between certain DOM operations taking longer than others across browsers. Setting innerHTML for example on IE (Trident), Edge (EdgeHTML), Safari (non-Blink WebKit), Firefox (Gecko) and Chrome/Chromium (Blink) is likely the best way to ensure consistent performance since it is one of the base operations you will need to do to manipulate HTML. I personally love the idea of the VDOM, because it liberates the content from being stuck to one document type: HyperText. While true when VDOM showed up on the scene, Facebook and others said the VDOM would help cure performance issues and that was the main selling point.. as we see now with things like ReactPixi, and Netflix using React for some of their apps - the VDOM is infinitely valuable for transcending the limits of HyperText and instead abstracting it away so that content may be projected by any sort of renderer using the same scaffolding as web pages. If you code to just the DOM - that is is where you will stay. Forever.
  • joppy 5y ago
    “ If you code to just the DOM - that is is where you will stay. Forever.” Svelte native exists… The VDOM which mirrors the document DOM is an implementation detail of React, as something sitting between the actual DOM, and the VDOM fragment returned by a React view. It’s true that if the document DOM gets fast enough, the mirroring VDOM could go away, but some diffing algorithm would still have to reconcile the document DOM with whatever fragment is returned from a view. I think one of the realisations of Svelte is that rather than returning arbitrary runtime generated DOM fragments from views, it is better to have the view implemented by a template that a compiler can understand and manipulate at compile-time. Here we trade off some expressivity (run-time generated DOM) for the ability to do much much more at compile time - I think this is the real point that should be being made in the article.
• EMRZ 5y ago
  For me, it's absolutely hilarious to see the frontend development discussion. They somehow figure the way to go full circle every 6 months.
• lkrubner 5y ago
  I need to sit down and write a long blog post on this subject, but the tl;dr would be "The modern Web environment, from programming to browsing, is a massive case of path dependence; if we were starting from scratch today, knowing all that we now know, we would not design anything like this." I have in my head a few dozen examples of what I mean, some small and some large. I won't even get into TCP/UDP which has already been argued over a thousand times. But I would point to RINA and other paradigms of remote execution: https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture https://en.wikipedia.org/wiki/Recursive_Internetwork_Archite... But that's the large scale stuff. We can also focus on very minor stuff where a different design decision might have lead to less trouble. Take, for instance, a mouseclick. Which element on a Web page should receive that mouseclick? Well, there is a well-established hierarchy that the browsers respect, walking up the DOM, checking each element to see if it has a handler registered. It can be a royal pain if your application needs you to break out of that hierarchy, and you can end up with something buggy because this is still an area where the different browsers have slight differences. But why should any hierarchy exist by default? We could have it such that there is no hierarchy by default, the only hierarchy is that which is defined by me, the programmer. I believe this original decision (of a default hierarchy) was made because there was an assumption, in the 1990s, that each page would be hand-coded, but nowadays we have frameworks that write much of our Javascript for us, so the possibility of assigning mouseclick handlers on the basis of classes, rather than the DOM, seems like a smart choice now, but probably didn't in the 1990s. I tried to write about some of this in essays like "The problem with HTML": http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html and also, "HTML is the failed GUI for TCP/IP": http://www.smashcompany.com/technology/html-is-the-failed-gui-for-tcpip http://www.smashcompany.com/technology/html-is-the-failed-gu... I'm not sure I really communicated myself very well previously, but perhaps if I focus on it, I can build the case that we've been following a path into a dark wood, and we've been so busy focusing on the path one step before us that we have perhaps not noticed that we've wandered into the lands where, in innocent days of yore, developers would have warned, "There be dragons, do not go."
• recursivedoubts 5y ago
  i don't know the Virtual DOM well enough to say for sure, but this appears to be yet further proof that, collectively, developers love complexity they say they dislike complexity but look at what they do not at what they say is it for fear of appearing insufficiently intelligent?
• mhoad 5y ago
  This is one of the reasons I am so into Lit (lit.dev). The web platform has changed so much the past few years, vDOM made a ton a sense back when React first launched and even for many years after that. It makes a lot less sense in 2021. I would even make the same argument for JSX itself. Once again JS now have template literals built into it. For anyone coming from a React background check out this code lab to see the difference: https://codelabs.developers.google.com/codelabs/lit-2-for-react-devs#0 https://codelabs.developers.google.com/codelabs/lit-2-for-re...
• selimnairb 5y ago
  I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the direction things are going?
  • arenaninja 5y ago
    I used React for 3 years and I'm using Angular for 2 years now; Angular is super heavy handed and gets in your way
    • datavirtue 5y ago
      I have professional experience in Angular and it is simply a framework for building applications. It hits that out of the park. I genuinely tried React and had to ditch it. Way too much drama just to manage state. It is clearly for building components, not applications. I don't think comparing the two is relevant. Angular gets in your way if you are just building components but it unleashes a deluge of productivity instantly if you need to build an application--especially for a team.
      • arenaninja 5y ago
        To me scaling this Angular codebase has been more challenging than it was to scale React codebases for collaboration across multiple projects and teams. Going through NgModule instead of using plain node packages is my main gripe here; coincidentally this is also what gets in your way if you're trying to build reusable dumb components in Angular I almost like ngrx because it reduces boilerplate, but I don't understand why their createAction helper doesn't follow Flux Standard Action; I can't be convinced this isn't a design flaw
  • recursivedoubts 5y ago
    You might want to take a look at the HAT stack: https://htmx.org https://htmx.org - server interactions in HTML https://alpinejs.dev https://alpinejs.dev - small front end tweaks in your HTML https://tailwindcss.com https://tailwindcss.com - styling in your HTML This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free. full disclosure: I am the author of htmx [1] - https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/
• FractalHQ 5y ago
  The most important part of Svelte, to me, is that it allows me to write web applications in the most elegant possible way. The compiler first approach means we get to choose whatever syntax we want to make the whole process as enjoyable as possible. The most brilliant part of Svelte was the decision to stay as close to JavaScript as possible, so anyone who knows JS, HTML, and CSS knows svelte. Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue. The unbeatable performance is just a plus for me. The DX is so good that building things is incredibly fun, intuitive, and headache free. I can’t emphasize enough how empowering it is. It’s so exciting seeing the community grow exponentially lately!!
  • KronisLV 5y ago
    > Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue. This makes me feel conflicted. With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech. With JS libraries it's the wild west once again and before you know it, your components will need 3 different mechanisms of being initialized, their internals will use different approaches, before long you'll have multiple versions of jQuery in there as well and it'll make you consider the downsides of that approach. But maybe I only have that outlook because I've witnessed many such situations of poorly integrated JS libraries and have therefore gotten used to walled gardens.
    • rendall 5y ago
      > With React/Angular/Vue you're given a stable base upon which to build new components and logic Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting that core concepts of the web are outdated because they came up in the Age of React. React/Vue/Angular will not protect you from bloated, poorly written apps. I would argue they encourage bad practices.
• incrudible 5y ago
  Ironically, the thing that supposedly no one does (setting innerHTML) in many cases is still much faster than using the finer grained DOM APIs the way React or Svelte would.
  • Yaina 5y ago
    I think it's hard to argue that these frameworks are out-of-the box faster than using the DOM APIs directly. What they do is provide abstractions that lets you scale HTML-interactivity up much faster. Plain-JS DOM manipulation code can become quite complex very fast, and I think that's what opens the door for inefficiency and also a lot of errors, because it's hard to keep track of possible DOM permutations.
• Yaina 5y ago
  As users of these web-frameworks it's not really noticeable if there is a V-DOM or not I think. The only thing that's really noticeable is the smaller bundle size (and maybe performance). But what I really, really like about Svelte is how refined the experience is. I think that's just a natural progression though. React got invented, then it got clear that some things have to be done again and again (boilerplate code) and some parts of it are too complex. Things you can only notice in hindsight. Then Vue came along and fixed a lot of these issues (making it beginner friendlier and simpler). And now we have svelte which takes the learnings and hindsight of Vue and what React did in the meantime and improves upon them. When projects grow, there is always this point where you have to start fighting the framework. The magic functions and implicit behaviour that makes them so easy to start with suddenly don't work for a use-case anymore and you have to almost hack a solution within the confines of the framework. Svelte on the other hand seems to be a lot more hands-off, a lot more vanilla javascript, where so far I didn't have the feeling I needed to fight it, even for ideas that were a lot more out of the box. I started using Vue when it was there where Svelte is now, so I'm fairly confident the tooling and larger community support will be a lot better in 1 to 2 years ^^
• px43 5y ago
  Maybe this is a dumb question from a JS muggle, but the thing that kills me about this whole movement to virtual/shadow DOM is that it's made the "ctrl+f" search useless on more and more websites. Is there a nice way to hook the search function to actually look inside elements that haven't been swapped in yet? If so, more people should be using it.
  • moritzwarhier 5y ago
    Never had this problem really (doesn't mean that it doesn not exist). Is shadow DOM a thing outside of SVGs? For sure it's not used by React, Vue etc. MDN is telling me that the upcoming Web component spec uses it though, so maybe libraries like LitElement use it too? Sites using React or Vue all seem to be searchable using standard CTRL-F for me.
    • recursive 5y ago
      I suspect this is a reference to the specific feature infinite/virtual scroll. The DOM nodes are only materialized when you scroll near them. CTRL-F is not able to find text that isn't currently in the DOM. If you scroll it into view, it suddenly starts working.
      • moritzwarhier 5y ago
        That's a very far stretch from purely the topic "Virtual DOM" though, no matter how few JS knowledge. I hate Infinite Scroll with a passion. FWIW Infinite Scroll can be and is often implemented as a jQuery plugin.
  • werm82 5y ago
    Virtual DOM is completely different from Shadow DOM. Shadow DOM is an isolated DOM of a web component, separate from the global DOM.
  • arcturus17 5y ago
    I’ve experienced this (Reddit comes to mind) but I’m pretty sure it’s because it aggressively mounts/dismounts things on/from the real DOM. In other words it virtualizes views (like when you have a 1000 row table and you only render rows 40-50), but this is not the same as DOM virtualization.
• sopooneo 5y ago
  For those who have worked on traditional desktop apps (rather than web), what underlying paradigm is used for UI updates there? I assume all these problems of fast partial updates must have been addressed there long ago. So apart from the specifics miasma of language and markup formats, how was it done? I ask in complete earnest, and if I should just be reading some particular Wikipedia article I'm grateful for any links.
  • christophilus 5y ago
    It's been a while, but when I developed Windows applications, I generally had a well-defined, observable central data structure. You made updates to it in systematic ways, and then each important section of your UI would handle updates and redraw intelligently. Sometimes, I'd make use of a component that did this itself, but yeah. At least back then, it was a lot of manual wiring. Maybe similar to backbonejs in some ways. The toy video games that I wrote were more React-like, in that you would simply update your models, and then a separate process would re-render 30-60 times per second. So, as a developer, you could really just think in terms of data transformations. Anyway, it's been 15 years since I've done either. I'm not sure how modern, native toolkits work. I assume there are decent React-like top-down-dataflow approaches these days.
  • iaml 5y ago
    From my limited experience with c#/xaml and swift apps, it's MVC/MVVM mostly, although apple is moving towards react-like swiftui.
• the__alchemist 5y ago
  When I learned frontend web work and React years ago, I fell for the same "VDOM is fast!" hype, and assumed there was non-JS magic under the hood. I eventually built a VDOM-based frontend WASM framework in Rust (Seed). I now built frontends in HTML and CS, with no frameworks, and minimal, targeted JS code to manipulate the DOM directly; it's liberating, and much faster than both React and WASM/Rust.
  • pwdisswordfish8 5y ago
    > Seed Sigh. https://wiki.gnome.org/Projects/Seed https://wiki.gnome.org/Projects/Seed (JavaScript-related, so not just any random name collision.)
  • ehnto 5y ago
    It's crazy how quickly frontend UI frameworks became the standard approach. They're not necessary in so many instances where they are used. I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget? Anyway, it's not that frontend UI frameworks are bad, it's more that pragmatism gets thrown out the window so quickly.
    • the__alchemist 5y ago
      It feels like we were coasting on a mentality of "Computation is cheap; We're in post-performance-scarcity era; Performance doesn't matter since computers are fast". -- Ignoring the reality that responsiveness is critical to user experience.
    • dsego 5y ago
      > I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget? A lot of new kids (we call them frontend engineers) haven't done the old school way. They just know SPAs, because that's what they've been taught in the last decade or so.
    • imbnwa 5y ago
      Yes, there's a lacking sense of measure in frontend and I work in a shop full of people that talk about what framework to use for a few buttons, a search form, and a result list. CSS is good enough that you can implement a lot of your UI state machine with classes as switches and scoped CSS variables available with `calc()` for threading particular derived values
• strangescript 5y ago
  Time and again it has been proven that the number one metric for success of a language or framework is developer experience. Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being. React has become that for frontend development. React is easier to use than Svelte. I got excited when I first learned of it, but its awkward to use at times and far more quirky than React. As others have pointed out, that bleeding edge performance is only as great as what you are building. If you don't need to update the DOM multiple times a second, then it barely matters.
  • throwaway894345 5y ago
    > Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being. JavaScript is the wrong example. It didn't succeed on merit, but because it was the sole language available for the web platform for the entire history of the web until recently and even now it enjoys significant "unfair" advantages (browsers only expose DOM APIs to JavaScript, the JS standard library is baked into the browser while other languages must ship their own over the network, etc).
    • SquareWheel 5y ago
      While never widely adopted, VBScript was able to be ran in script tags in Internet Explorer.
      • throwaway894345 5y ago
        I fully believe that JS is better than VBScript, but it's also possible that many other factors contributed to JS's triumph over VBScript. In whichever case, this is pretty weak evidence for the claim "JS won its popularity relative to other languages by merit" (presumably you weren't intending it to be strong evidence).
        • SquareWheel 5y ago
• tarkin2 5y ago
  Browsers have improved to the point where VirtualDOM is basically unneeded.
  • 8note 5y ago
    I'd imagine that over time, depending on browser makers focus, either virtual doms or non virtual doms will be faster than the other. It'd be handy to have it as a flippable switch
• Panther34543 5y ago
  I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework. I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing, and killed my newly gained enthusiasm for Svelte. Has anyone built full web apps without Svelte Kit (previously Sapper)?
  • arxpoetica 5y ago
    You absolutely 100% do not have to use Svelte Kit. Svelte Kit is just the equivalent of (an opinionated) Next.js, Gatsyby, or Nuxt.js framework. Those frameworks are also incredibly opinionated on purpose.
    • Panther34543 5y ago
      One of the things I came to enjoy regarding React was that the router was separate and kept the core React API small. I had hoped that something similar was the norm for Svelte, but it was quite clear that the official recommendation was to use SvelteKit. Have you built production apps with just Svelte? Is the tooling and feature set good enough to use Svelte alone in an actual app?
  • davidwparker 5y ago
    I built https://www.listenaddict.com/ https://www.listenaddict.com/ with Sapper. It was a good experience. That said, all of my other apps are using Kit, and I'm finding that experience even nicer. What did you find unappealing about Kit?
    • Panther34543 5y ago
      This post [0] sums up my general feeling toward SvelteKit. It seemed very opinionated and very restrictive, two qualities which seemed opposite the philosophy of core Svelte. [0]: https://www.reddit.com/r/sveltejs/comments/ni9g5d/svelte_vs_sveltekit/ https://www.reddit.com/r/sveltejs/comments/ni9g5d/svelte_vs_... Do you have concerns with using SvelteKit in production? It's still in Beta last I checked.
• tyingq 5y ago
  I'm somewhat surprised that React won out versus Angular or something similar. Because React isn't opinionated about the supporting things around it, there seems to be wide variations in a React stack and approach from team to team. More so than I would typically see in any other ecosystem. But nobody seems to care. Is is that it makes for a sort of meritocracy where people that keep up with the fast changing landscape get the best opportunities? Basically, I can't figure out why JS developers aren't overwhelmed and frustrated with all the choices.
  • daok 5y ago
    One reason React won over Angular is it relies on JavaScript instead of custom templating syntax. E.g. You loop with a forEach, not some ng-...
    • dsego 5y ago
      forEach in react/jsx, are you sure?
  • jlokier 5y ago
    I think it was: - The Angular dependency injection stuff seemed rather complicated compared with React pragmatism. Using React became heavier by the time Redux and other boilerplatish practices became widespread, but React had already gained adoption by then, and you could still get into it on tiny projects without fancy state management. - The VDOM had articles saying how much faster it was than everything else, so it gained a reputation for speed compared with the other client-side templating alternatives at the time. Angular 1 had a reputation for being slow due to scanning all state variables on every refresh. Really React wasn't fast at everything, but fast at enough things to get that reputation. People who really understood DOM differential updates already knew how to do it faster than VDOM, either by hand or with smarter differential template compilers, but implementations weren't common. Marko and Svelte came along later. - After years of being trained that separating HTML templates and code was the right thing to do for better engineering, preferably in separate files, it turns out that was annoying and lots of people really liked inlining the dynamic parts of HTML directly into code.
• thunderbong 5y ago
  I've commented on Svelte before [0]. Adding the same comment here - >> I've worked on multiple modern JS frameworks and Svelte is the closest I can get to mapping my mental model of how a web page works (HTML, CSS, JS) with the framework. Actually, I should correct myself - yes, the breakdown in terms of technology is HTML, CSS, JS but the underlying abstraction is actually - structure, presentation and functionality. This is where, imho, Svelte really shines. It helps you to map your mental model of structure, presentation and functionality to it's corresponding implementation of HTML, CSS, JS with a sprinkle of syntactic sugar. This goes way far in keeping the code easy to understand and maintainable in my opinion. [0]: https://news.ycombinator.com/item?id=26723214 https://news.ycombinator.com/item?id=26723214
• tonymet 5y ago
  Is there a good benchmark showing the number of dom nodes vs ui latency? React works well for few dom elements but suffers in messaging apps where dom count and dependency graph are large and complex
• kgr 5y ago
  When we designed to UI library for FOAM in 2011 at Google, we did extensive benchmarking, and discovered that DOM calls were very slow and that we could greatly improve performance by batching them. Yes, in the end, you still need to make DOM calls to update the DOM, but you were better off forming all of your DOM's html on the JS side and then just make one call to element.innerHTML = myHTML and then hookup listeners if necessary. The JS to C++ bridge was very slow, and so you were better off to make one large call and then have C++ parse your HTML and build all of the DOM itself than you were to make many small DOM calls adding each element and attribute value individually. However, I was recently writing a document on the performance advantages of FOAM's virtual DOM, but rather than just assert the fact without proof, I wrote some benchmarks to demonstrate... that it is in fact no longer faster. As a result, we're replacing FOAM's UI library, called U2, with a new non-virtual DOM library called U3.
  • madhadron 5y ago
    In my personal experiments, I ended up using document fragments. I wasn't doing FRP, just classic MVC, but a view (which was a JavaScript object) had a reference to the DOM elements it was responsible for. If it needed to replace them, it created a document fragment, did anything that needed to be done in there (including having children redraw) and then swapped out that fragment. This gave very nice performance.
  • lhorie 5y ago
    innerHTML has been slower than the DOM API for a few years. React had a big refactor at one point to rip out innerHTML logic precisely due to this. To make matters more interesting, the order of DOM API calls also mattered. In IE, building a DOM tree bottom up was significantly slower than building it top down (meaning, no large document fragments for you!). There are also a ton of other quirks: `.textContent = ''` being faster than removeChild, appendChild vs insertBefore vs replaceChild, childNodes random access, properties being faster than attributes (which is a rabbit hole of its own because SVG), cloneNode being faster but nigh unusable in a framework setting, orders of magnitude difference in performance due to data structure polymorphism... Squeezing performance out of DOM manipulation is really tricky because the performance profile of pretty much everything changes frequently without rhyme or reason.
• infogulch 5y ago
  macspoofing said elsewhere ITT: > DOM mutations are not the expensive thing, it's the final render. This is the crux of the issue: Updating the DOM will immediately rerender the page, even if there are additional changes that need to be made at the same time. So library/framework authors twist themselves into pretzels trying to work around the browser automatically doing all this unnecessary extra work that developers don't even want. Clearly it's a DOM api deficiency; there is no api to 'make these 15 changes scattered across the DOM all at once', instead each individual change causes a cascade of wasted effort repeated until the last change is applied OR developers take the nuclear option and just replace the whole damn page with a completely new DOM on every frame. Insanity. The solution seems obvious to me: Browsers should introduce a transactional DOM api that is only rendered after the transaction is 'committed'. It could be full-on transactions like a real DB or something simpler like a double-buffered frame swap. This would be relatively easy to retrofit into JS apps and frameworks and would enable them to effortlessly avoid a huge amount of wasted effort on the part of the browser.
• spankalee 5y ago
  I work on the Lit team at Google. A colleague there who went on to work on Flutter's VDOM-like system once said that React traded off CPU cycles for developer ergonomics and conceptual simplicity. A VDOM tree represents far more DOM states than a template will ever be put in, so materializing VDOM and diffing are absolutely pure overhead compared to the system knowing ahead of time what might change. With VDOM you repeatedly compare many nodes that will never show a diff, and that's just waste. VDOM brought three important things to the table, initially paid for by that overhead: * Template as values. JSX expressions produce JS values, and this is allows a functional programming approach to UI. * Expressions and control flow in JS. This shrunk the domain of the template DSL to just the component nodes, and reused knowledge and machinery of JS. Theoretically that leads to faster and smaller templating. * One-way data flow. This is a result of the first two items, but important on its own. Two way binding is nice sugar for some situations, but it makes it hard to reason about the state a template is in. Those are really great aspects of the VDOM approach (for a class of programmers, markup based templates are great for others). So the challenge to me had been to preserve those features, actually deliver on the smaller and faster part, and reduce the CPU overhead. That can be done with compiler-first systems like Svelte, but I think we get just as faster or faster, and as small or smaller with a pure runtime approach based on template literals, like we have with lit-html. Template literals let us describe the static and dynamic parts of a template separately, so there's no VDOM overhead. We don't compare the output of template expressions, we compare the inputs to the dynamic bindings. It's often an order-of-magnitude less diffing work, and approaches the point where the required DOM operations are the limiting factor. So we get low-CPU overhead, templates as expressions, logic in JS, and one-way-bindings, with no compiler. I really think this is the best of both conceptual simplicity and overhead - preserving much of the VDOM model, but doing it faster.
  • lhorie 5y ago
    > I really think this is the best of both I think this approach definitely has a lot of merit, but in terms of absolutes, it's still not quite there. Specifically, you're still going to be diffing as many bindings as a component has, be it one or one hundred, even if only one changed. Another more micro-level issue is that dynamically resolving which DOM properties to update is polymorphic, so you don't get nearly as much JIT optimization compared to a compiled approach that outputs monomorphic static property assignments. I quite like Solid.js' approach, which addresses both of these problems via a reactive data flow and aggressive compilation, while still providing a React-like experience.
• yawaworht1978 5y ago
  People often say things like "because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code" But what would be a minimal as possible example for this? I know a bit reactjs and it can get complicated as well with multiform s and various elements states depending on each other quickly too. A bad architecture can be "achieved" by either, I am curious about some examples showing me what people mean exactly by that.
• alsadi 5y ago
  I do agree. When I first see it I knew that. Comparing two sequences (actual dom and dom) to find diff is like O(n^2) and the assumption that dom ops is expensive is a lie (premature optimization). Dom ops on ids and classes and fragments is very fast. In most cases a slow dom is always a developer fault failing to use fragments.