3 ms·

The beauty of the virtual DOM is that it relies on pure view functions: given this props+state input, this is how the DOM looks like. Generating DOM fragments o

The beauty of the virtual DOM is that it relies on pure view functions: given this props+state input, this is how the DOM looks like. Generating DOM fragments on update is possible, but naively done it will quickly get out of sync with the DOM view function. Curious about 'really cool work' in this space!

vosper 5y ago
> Generating DOM fragments on update is possible, but naively done it will quickly get out of sync with the DOM view function. Curious about 'really cool work' in this space! This is what Svelte's doing, as I understand it: letting you think like you're writing React ("when in this state, the world should look like this") but avoiding the (greatly overstated, IMO) overhead of the virtual DOM by translating the changes into direct DOM updates in a complilation step.
- bookofsand 5y ago
  Ah, I see. The programming model is similar, but the execution of the virtual DOM shifts from runtime to compile time. Cool!
- jchw 5y ago
  Virtual DOM overhead is only overstated in that it usually isn’t really compared to any reasonable baseline when discussed. Many will acknowledge that React was faster than many of its contemporaries—and I’m sure it remains competitive—but still express concern over the unnecessary overhead of the virtual DOM. I think I blame part of this on the language we use. These days a huge buzzword of sorts is the “zero-cost abstraction.” It means zero runtime cost, but a lot of us internalize it as completely free, failing to account for the fact that it often entails increased complexity and build times. Granted, often this is a worthwhile tradeoff, but in order to know you need a more nuanced comparison. That virtual DOM is “pure overhead” isn’t objective fact - pure overhead is an error of coding that can be fixed in a pull request. No, this is more like ideology. The problem with this ideology isn’t that it’s bad, it’s just incomplete. It usually explains away why the world hasn’t simply adopted their worldview by appealing to ignorance or even stupidity, while ignoring potentially serious issues. Like yeah, if I want to make a desktop application in 2021, I have to consider Electron because simply put, there’s a lot broken in modern native UI. And sometimes people are still right. There’s always a possibility Svelte will win out, or eventually be proven right even if it doesn’t. Maybe. But it’s 2021, and the year of the Linux desktop is still around the corner. If something hasn’t happened yet, at least humor some reasons why that might be the case. (Personally, in my experience, even update-intense apps wind up having bigger fish to fry than VDOM, so I can’t say I’m holding my breath.)
  - csande17 5y ago
    In practice, React users often end up running all their app code through a big slow compiler anyway. Usually Babel (to convert JSX to createElement calls) or TypeScript. Svelte doesn't increase the overall complexity of your build process, it just uses that compile step to do something to your code that's actually useful.
    - bayesian_horse 5y ago
      Type checking and Browser compatibility are somewhat useful to some people...
    - jchw 5y ago
      Adding more compilation steps is not free, though. You have to convince people to want this. It's not necessarily an easy sell. Even though JSX is pretty React-specific, it still has managed to make its way into other frameworks and many compilers because it's fairly general at its core and because it is a fairly non-invasive process. So for example, you can compile JSX using babel, but also TypeScript, esbuild, and more. (And those are all independent implementations!) I can't claim to know what the build process looks like for Svelte, but I have a suspicion it is far less general than the source code transformations that we have so far that provide type checking and newer ES functionality in older engines. (Which, by the way, you appear to be insinuating are not "actually useful.") Angular has a similar thing going on and it is not terribly well received.
  - bayesian_horse 5y ago
    Virtual DOM overhead is totally overstated. It's just that it offends some people's idea of efficiency to build a data structure to throw most of it away anyway. But in reality, the virtual DOM allows you to avoid manipulating the actual DOM, which is both slow and error-prone. The browser necessarily attaches all sorts of memory objects and state to components in the DOM, which his why unnecessary mutating has to be avoided at almost all cost. Svelte may go a step further by automating DOM manipulation. But it doesn't have the same following yet. And usually, if there is no explosive growth in such a technology, it's not just because of evil overlords preventing its justful rise...
eyelidlessness 5y ago
Like I did in another subthread I’d suggest looking at SolidJS. It’s philosophically similar to React for rendering, uses JSX, and at least as “pure”. It has reactive APIs similar in use to React hooks (neither of which are pure), but compiles to DOM.

vosper 5y ago

> Generating DOM fragments on update is possible, but naively done it will quickly get out of sync with the DOM view function. Curious about 'really cool work' in this space! This is what Svelte's doing, as I understand it: letting you think like you're writing React ("when in this state, the world should look like this") but avoiding the (greatly overstated, IMO) overhead of the virtual DOM by translating the changes into direct DOM updates in a complilation step.

bookofsand 5y ago
Ah, I see. The programming model is similar, but the execution of the virtual DOM shifts from runtime to compile time. Cool!
jchw 5y ago
Virtual DOM overhead is only overstated in that it usually isn’t really compared to any reasonable baseline when discussed. Many will acknowledge that React was faster than many of its contemporaries—and I’m sure it remains competitive—but still express concern over the unnecessary overhead of the virtual DOM. I think I blame part of this on the language we use. These days a huge buzzword of sorts is the “zero-cost abstraction.” It means zero runtime cost, but a lot of us internalize it as completely free, failing to account for the fact that it often entails increased complexity and build times. Granted, often this is a worthwhile tradeoff, but in order to know you need a more nuanced comparison. That virtual DOM is “pure overhead” isn’t objective fact - pure overhead is an error of coding that can be fixed in a pull request. No, this is more like ideology. The problem with this ideology isn’t that it’s bad, it’s just incomplete. It usually explains away why the world hasn’t simply adopted their worldview by appealing to ignorance or even stupidity, while ignoring potentially serious issues. Like yeah, if I want to make a desktop application in 2021, I have to consider Electron because simply put, there’s a lot broken in modern native UI. And sometimes people are still right. There’s always a possibility Svelte will win out, or eventually be proven right even if it doesn’t. Maybe. But it’s 2021, and the year of the Linux desktop is still around the corner. If something hasn’t happened yet, at least humor some reasons why that might be the case. (Personally, in my experience, even update-intense apps wind up having bigger fish to fry than VDOM, so I can’t say I’m holding my breath.)
- csande17 5y ago
  In practice, React users often end up running all their app code through a big slow compiler anyway. Usually Babel (to convert JSX to createElement calls) or TypeScript. Svelte doesn't increase the overall complexity of your build process, it just uses that compile step to do something to your code that's actually useful.
  - bayesian_horse 5y ago
    Type checking and Browser compatibility are somewhat useful to some people...
  - jchw 5y ago
    Adding more compilation steps is not free, though. You have to convince people to want this. It's not necessarily an easy sell. Even though JSX is pretty React-specific, it still has managed to make its way into other frameworks and many compilers because it's fairly general at its core and because it is a fairly non-invasive process. So for example, you can compile JSX using babel, but also TypeScript, esbuild, and more. (And those are all independent implementations!) I can't claim to know what the build process looks like for Svelte, but I have a suspicion it is far less general than the source code transformations that we have so far that provide type checking and newer ES functionality in older engines. (Which, by the way, you appear to be insinuating are not "actually useful.") Angular has a similar thing going on and it is not terribly well received.
- bayesian_horse 5y ago
  Virtual DOM overhead is totally overstated. It's just that it offends some people's idea of efficiency to build a data structure to throw most of it away anyway. But in reality, the virtual DOM allows you to avoid manipulating the actual DOM, which is both slow and error-prone. The browser necessarily attaches all sorts of memory objects and state to components in the DOM, which his why unnecessary mutating has to be avoided at almost all cost. Svelte may go a step further by automating DOM manipulation. But it doesn't have the same following yet. And usually, if there is no explosive growth in such a technology, it's not just because of evil overlords preventing its justful rise...

eyelidlessness 5y ago

Like I did in another subthread I’d suggest looking at SolidJS. It’s philosophically similar to React for rendering, uses JSX, and at least as “pure”. It has reactive APIs similar in use to React hooks (neither of which are pure), but compiles to DOM.