While I agree with you that Virtual DOM isn't necessary for most use cases - my original intention was to phrase it as "Why is the Virtual DOM necessary in most cases." The argument that the .innerHTML is just a scapegoat and "nobody uses it anymore" is false, take jQuery users for example. I don't even want to point out the transgressions made with $(el).html(). However, that shouldn't be the discussion here, rather the example posed in the article is just that, it's not an argument point but rather an example to demostrate why the Virtual DOM was created in the first place.
Just claiming "Svelte is faster than React" is naive. Personally, I use Svelte more than React, which was why I created Million in the first place - to allow the compiler to generate as much static content as possible while minimizing runtime. This allows for significantly less size (as you're just generating a data structure) vs basically imperative code, as well as pretty good performance overall.
While I agree with many of your points, I think you could consider doing some research into this field - there's a ton of interesting complexity and context to discover and learn.
It's very difficult to compare Million to Svelte, as Million is a VDOM engine, and Svelte is a JavaScript framework. It's like comparing apples to oranges.
but you wouldn't need MillionJS if you used a framework like Svelte. So what advantages do runtime-based frameworks (like VDOM frameworks) have over compile-time frameworks (like Svelte)?
I understand that, but by VDOM i meant virtual-dom frameworks like React and Vue. There are also frameworks like Angular which don't use virtual dom but are still runtime frameworks.
The reason why I asked is because it looks like MillionJS is an engine that people can use to build more virtual-dom frameworks. But if compile-time frameworks like Svelte are the future, why would one want to build another runtime framework?
It's very difficult to broadly claim that Svelte is the future, but I 100% agree that compile-time frameworks are the future. Million.js is like the intersection between VDOM + compile-time, as it can be further optimized through compile time and is aware of the compiler. Virtual DOM is super, super powerful in terms of declarative programming, and combining the two can achieve the best of both worlds.
well I guess the way I see it, virtual doms wont be needed when we move to compile time frameworks. The name "virtual dom" comes from the fact that it's an in-memory representation of the DOM. But this just adds unnecessary overhead, since compile-time frameworks compile the code such that operations are done on the DOM directly.
Ultimately, the new mindset is that the programmer writes their declarative code, and the framework/compiler decides everything between the code and the output. If direct DOM manipulations are optimal, the framework will do that. If a virtual dom is optimal, then the framework will output a virtual dom. Right now MillionJS feels like it's working with outdated technology. I think if MillionJS wants to be ready for the future, it needs to provide a more general framework for static analysis.
Generating straight imperative code has many downsides. For example, there would be an increase in the generated to source ratio, increasing bundle size, vs. just generating a data structure which would save a lot on bundle size. Even then, Million proves than in the benchmarks, it's able to match up against imperative DOM manipulations, thanks for shortcutting. Virtual DOM is here to stay, but it needs to evolve to mesh with the new paradigms.
Static analysis is great, but there are already so, so many SSG/SSR frameworks/integrations out there, namely 11ty, Astro, etc. These libraries have found it's very hard to achieve zero runtime (unless your page literally has zero interactivity). Million.js attempts to address this outdated technology and shift the VDOM paradigm to the modern age.
Svelte has already calculated the inflection point where the bundle size becomes larger than react, and it's much larger than most applications will reach, see here. Even so, as I said a smart static analysis framework would be able to generate a virtual dom if it were optimal (but I guess Svelte is not there yet).
but for now, I think virtual doms are starting to fall out of use. They may prove useful again in the future but right now it seems like frameworks like Svelte are just all-around better than virtual dom frameworks (aside from the maturity of React and Vue I guess). Though I am curious to see the benchmarks of Svelte vs MillionJS in some real life application.
Also note that SSR and SSG are not really static analysis technologies. They don't analyze the code, they just runs the code and generate the initial DOM tree. Static program analysis is in pretty early stages for web dev and Svelte is the first framework to utilize it and take off, at least from what I've seen (though I guess bundlers like Webpack sort of count as well, though the analysis is not as complex as Svelte's)
Anyways, I don't mean to disparage your work, I think it's an impressive and interesting project (otherwise I wouldn't have looked into it). I just think it has a few directions it needs to go if it wants to keep pace with modern developments.
The inflection point project you referenced looks really interesting - but it only compares React 16 and Svelte, which could differ from application to application. I could be misinterpreting the readme, but in my opinion I am doubtful of the results when applied to different scenarios, as there is just so much variablity possible that could change the inflection point(s).
It's very difficult to claim that Virtual DOM is falling out of use. While some popular + successful libraries like Svelte/Solid have outright rejected the Virtual DOM, a significant portion of libraries and newly created libraries will continue to use Virtual DOM. It's just so difficult to compare libraries because of subjectivity, and claiming that certain libraries are "all around better" than others is an overgeneralization in my opinion. I think a MillionJS and Svelte benchmark could be interesting, but they are so different that it would only be accurate for an indirect comparison (through a compiler library built to optimize for Million).
I think SSR and SSG do some static analysis. For example, astro removes any unnecessary code, some SSR/SSG do static prop, component and vnode hoisting (might be bundlers, I'm not sure), but I agree it's not to the extent of the application of static analysis in other programming langs. I think a possibile difficulty Svelte devs might be facing is just that flow analysis is hard (e.g. prepack), and it'll take time for this technology to develop.
a lot of the stuff you mentioned is either runtime optimizations or bundling (which is static analysis, but it's really just tracing import statements to find which code is used and which isn't). And SSR just runs the code to generate a DOM tree, it's not analyzing the code or generating code . Real static analysis is difficult, as you pointed out. But that's why Svelte is making such big waves. And prepack looks to be going that direction too. It's a huge field with a lot of opportunity.
But yeah ultimately it seems we disagree on what role VDOMs will have in the future, I guess we'll just have to see :)
What exactly is "most cases" because if you want to argue as you did in the comment (which makes more sense than the article)?
Virtual dom is better than inner html. Jquery users use innerHTML but... that's not a problem unless they also replicate a react-like state management which would need to track a certain number of changes that makes that impractical.
But then a better choice is to use Virtual DOM. But Virtual DOM is an pute angular concept, so you're saying that React is necessary.
Saying that virtual DOM is necessary in most cases means that there's really no other way to achieve said cases without it. Which is technically not true.
I rephrased the article title to be "Why Virtual DOM"
Honestly, I'm not sure I completely understand what you're saying here, so I'll try my best to answer. While writing straight performant jQuery will be faster, it doesn't provide a declarative experience developers use React for in the first place. Additionally, Virtual DOM is not a pure Angular concept? I think you misunderstand.
Most of your concerns should be addressed with the new article title.
Perhaps I gave a bit the wrong impression. I don't quite expect 'adjustments', merely a discussion on options available for a given goal.
What I'm saying is that there are different options available, which by default means that Virtual DOM will never be the "necessary" option. Something becomes the necessary way when there's either no alternative or the alternatives are so bad they're not worth considering.
As a side note, certainly jQuery's dev experience will never be a match to pretty much anything else out there today, but that's a different kind of concern.
What I'm saying is that Virtual DOM is but one way (and also that Virtual DOM is not a Angular concept, it's a React one).
What are the ways?
Virtual DOM (which is what React does), basically a per component 'map' of a component's tree as it would be rendered, changes are performed against it at runtime and eventually applied.
Change Detection (not sure Angular gave an actual name, but they called it their own change detection tree): which overall serves a similar function as Virtual DOM but its implementation is significantly different and they go at great pains to underline it's different than Virtual DOM (at least since v6 onwards). Theoretically it should also be more efficient (which is why it's a shame to dismiss Angular's change detection tree as just "a" VDOM).
Compile-time change optimisation: what Svelte does, maps and tracks at compile time state change pathways, but applies them "live" at runtime. I guess it could be said it's like using targeted direct changes as you would use jQuery but taking away the decision path on performing the actual change away from developer.
So Virtual DOM is just one of at least three efficient options on managing DOM changes, so "why use Virtual DOM" could reasonably be expected to argue why Virtual DOM is a better option that any of jQuery's way (which is only as efficient to the extent that a developer is a master or algorithms), Angular's way or Svelte's way.
Thanks, this explaination is much more clear. I agree with pretty much all your points, but I think you are approaching this the wrong way. I think you are segregating the options into their own categories, and comparing them just like that. This is a valid comparison, but not how Million approaches it. Million allows for more fluiditiy between the categories, as it takes the "compiler-time" optimization you mentioned + Virtual DOM together, bringing the benefit of both worlds.
I hope this brings more context
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I agree with you that Virtual DOM isn't necessary for most use cases - my original intention was to phrase it as "Why is the Virtual DOM necessary in most cases." The argument that the .innerHTML is just a scapegoat and "nobody uses it anymore" is false, take jQuery users for example. I don't even want to point out the transgressions made with $(el).html(). However, that shouldn't be the discussion here, rather the example posed in the article is just that, it's not an argument point but rather an example to demostrate why the Virtual DOM was created in the first place.
Just claiming "Svelte is faster than React" is naive. Personally, I use Svelte more than React, which was why I created Million in the first place - to allow the compiler to generate as much static content as possible while minimizing runtime. This allows for significantly less size (as you're just generating a data structure) vs basically imperative code, as well as pretty good performance overall.
While I agree with many of your points, I think you could consider doing some research into this field - there's a ton of interesting complexity and context to discover and learn.
what advantage does MillionJS bring over Svelte? Svelte is both declarative and fast, which seem to be your main concerns
It's very difficult to compare Million to Svelte, as Million is a VDOM engine, and Svelte is a JavaScript framework. It's like comparing apples to oranges.
but you wouldn't need MillionJS if you used a framework like Svelte. So what advantages do runtime-based frameworks (like VDOM frameworks) have over compile-time frameworks (like Svelte)?
VDOM is not a framework. Generally speaking VDOM is not used by the average user, rather it's a engine to build frameworks off of.
I understand that, but by VDOM i meant virtual-dom frameworks like React and Vue. There are also frameworks like Angular which don't use virtual dom but are still runtime frameworks.
The reason why I asked is because it looks like MillionJS is an engine that people can use to build more virtual-dom frameworks. But if compile-time frameworks like Svelte are the future, why would one want to build another runtime framework?
It's very difficult to broadly claim that Svelte is the future, but I 100% agree that compile-time frameworks are the future. Million.js is like the intersection between VDOM + compile-time, as it can be further optimized through compile time and is aware of the compiler. Virtual DOM is super, super powerful in terms of declarative programming, and combining the two can achieve the best of both worlds.
well I guess the way I see it, virtual doms wont be needed when we move to compile time frameworks. The name "virtual dom" comes from the fact that it's an in-memory representation of the DOM. But this just adds unnecessary overhead, since compile-time frameworks compile the code such that operations are done on the DOM directly.
Ultimately, the new mindset is that the programmer writes their declarative code, and the framework/compiler decides everything between the code and the output. If direct DOM manipulations are optimal, the framework will do that. If a virtual dom is optimal, then the framework will output a virtual dom. Right now MillionJS feels like it's working with outdated technology. I think if MillionJS wants to be ready for the future, it needs to provide a more general framework for static analysis.
Generating straight imperative code has many downsides. For example, there would be an increase in the generated to source ratio, increasing bundle size, vs. just generating a data structure which would save a lot on bundle size. Even then, Million proves than in the benchmarks, it's able to match up against imperative DOM manipulations, thanks for shortcutting. Virtual DOM is here to stay, but it needs to evolve to mesh with the new paradigms.
Static analysis is great, but there are already so, so many SSG/SSR frameworks/integrations out there, namely 11ty, Astro, etc. These libraries have found it's very hard to achieve zero runtime (unless your page literally has zero interactivity). Million.js attempts to address this outdated technology and shift the VDOM paradigm to the modern age.
Svelte has already calculated the inflection point where the bundle size becomes larger than react, and it's much larger than most applications will reach, see here. Even so, as I said a smart static analysis framework would be able to generate a virtual dom if it were optimal (but I guess Svelte is not there yet).
but for now, I think virtual doms are starting to fall out of use. They may prove useful again in the future but right now it seems like frameworks like Svelte are just all-around better than virtual dom frameworks (aside from the maturity of React and Vue I guess). Though I am curious to see the benchmarks of Svelte vs MillionJS in some real life application.
Also note that SSR and SSG are not really static analysis technologies. They don't analyze the code, they just runs the code and generate the initial DOM tree. Static program analysis is in pretty early stages for web dev and Svelte is the first framework to utilize it and take off, at least from what I've seen (though I guess bundlers like Webpack sort of count as well, though the analysis is not as complex as Svelte's)
Anyways, I don't mean to disparage your work, I think it's an impressive and interesting project (otherwise I wouldn't have looked into it). I just think it has a few directions it needs to go if it wants to keep pace with modern developments.
The inflection point project you referenced looks really interesting - but it only compares React 16 and Svelte, which could differ from application to application. I could be misinterpreting the readme, but in my opinion I am doubtful of the results when applied to different scenarios, as there is just so much variablity possible that could change the inflection point(s).
It's very difficult to claim that Virtual DOM is falling out of use. While some popular + successful libraries like Svelte/Solid have outright rejected the Virtual DOM, a significant portion of libraries and newly created libraries will continue to use Virtual DOM. It's just so difficult to compare libraries because of subjectivity, and claiming that certain libraries are "all around better" than others is an overgeneralization in my opinion. I think a MillionJS and Svelte benchmark could be interesting, but they are so different that it would only be accurate for an indirect comparison (through a compiler library built to optimize for Million).
I think SSR and SSG do some static analysis. For example, astro removes any unnecessary code, some SSR/SSG do static prop, component and vnode hoisting (might be bundlers, I'm not sure), but I agree it's not to the extent of the application of static analysis in other programming langs. I think a possibile difficulty Svelte devs might be facing is just that flow analysis is hard (e.g. prepack), and it'll take time for this technology to develop.
a lot of the stuff you mentioned is either runtime optimizations or bundling (which is static analysis, but it's really just tracing import statements to find which code is used and which isn't). And SSR just runs the code to generate a DOM tree, it's not analyzing the code or generating code . Real static analysis is difficult, as you pointed out. But that's why Svelte is making such big waves. And prepack looks to be going that direction too. It's a huge field with a lot of opportunity.
But yeah ultimately it seems we disagree on what role VDOMs will have in the future, I guess we'll just have to see :)
Ah yeah, I was so hyped for the prepack project but I'm kinda bummed out facebook basically just dropped the project
What exactly is "most cases" because if you want to argue as you did in the comment (which makes more sense than the article)?
Virtual dom is better than inner html. Jquery users use innerHTML but... that's not a problem unless they also replicate a react-like state management which would need to track a certain number of changes that makes that impractical.
But then a better choice is to use Virtual DOM. But Virtual DOM is an pute angular concept, so you're saying that React is necessary.
Saying that virtual DOM is necessary in most cases means that there's really no other way to achieve said cases without it. Which is technically not true.
I rephrased the article title to be "Why Virtual DOM"
Honestly, I'm not sure I completely understand what you're saying here, so I'll try my best to answer. While writing straight performant jQuery will be faster, it doesn't provide a declarative experience developers use React for in the first place. Additionally, Virtual DOM is not a pure Angular concept? I think you misunderstand.
Most of your concerns should be addressed with the new article title.
Perhaps I gave a bit the wrong impression. I don't quite expect 'adjustments', merely a discussion on options available for a given goal.
What I'm saying is that there are different options available, which by default means that Virtual DOM will never be the "necessary" option. Something becomes the necessary way when there's either no alternative or the alternatives are so bad they're not worth considering.
As a side note, certainly jQuery's dev experience will never be a match to pretty much anything else out there today, but that's a different kind of concern.
What I'm saying is that Virtual DOM is but one way (and also that Virtual DOM is not a Angular concept, it's a React one).
What are the ways?
So Virtual DOM is just one of at least three efficient options on managing DOM changes, so "why use Virtual DOM" could reasonably be expected to argue why Virtual DOM is a better option that any of jQuery's way (which is only as efficient to the extent that a developer is a master or algorithms), Angular's way or Svelte's way.
Thanks, this explaination is much more clear. I agree with pretty much all your points, but I think you are approaching this the wrong way. I think you are segregating the options into their own categories, and comparing them just like that. This is a valid comparison, but not how Million approaches it. Million allows for more fluiditiy between the categories, as it takes the "compiler-time" optimization you mentioned + Virtual DOM together, bringing the benefit of both worlds.
I hope this brings more context