The DOM can be used both very effective and very ineffective. The same is true for the virtual DOM, but libraries like react make it a bit easier for less experienced developers to use it effectively - and that's a good thing.
However, we had handcrafted DOM manipulations more than a decade ago that were easily faster than react - because they only made the necessary changes and reused instantiated nodes without any intensive reconciliation.
Libraries like Svelte and SolidJS help to have almost the same performance without the hassle and easily surpass react and other virtual DOM libraries in terms of performance.
I agree with a lot of these points in this statement - but I think you are generalizing here. While manually writing direct, imperative DOM manipulations is always going to be faster than any library you use out there, that's not really how we do web development today in real production use cases. React was created to make webdev paradigms delarative, and inventing the virtual DOM is just a means to an end.
I actually checked out SolidJS the other day, I found the concept very intruiging and the beta of SolidJS actually inspired me to create something like this in the first place. I loved how they optimized their own architecture, so I took some of the broad design principles and applied it to my own project.
However, I partially disagree with your generalization that Svelte and SolidJS is better for development experience and always has better performance. Development experience is subjective, it's difficult to objectively define whether something is "worth the hassle" or not. While React may be overall slower that Svelte and SolidJS, using React is a scapegoat in itself. MillionJS, compared to React's internal Virtual DOM engine is very different, but suffers from the same concequences as all Virtual DOM does. This is why MillionJS has several compiler-aware optimizations, so that in the future, Svelte + React mixes can be created.
…that's not really how we do web development today in real production use cases.
If performance is your highest priority and the page is rather simple, it is still a sensible choice to develop exactly like this – and I actually did that ~ 3 years ago. Unfortunately, we had a priority shift in the meantime, so I cannot show you the result anymore, but it easily outperformed anything we could have done with react.
However, I partially disagree with your generalization that Svelte and SolidJS is better for development experience…
I would partially disagree, too, because I made no such statement. I merely remarked that they save you the hassle of hand-optimizing DOM manipulations while allowing for similar performance.
React is a compromise – and as I already said, that can be a good thing, too, depending on what you intend to do.
I see, personally I would prefer the best performance, but to each their own. I'd like to see the example if you ever get to find it!
I think I misinterpreted your statement there, I thought you were talking about React when you remarked about the "hassle" part.
It can also be noted that using any technology is a comprimise - for example, using DOM nodes generally constrains you to imperative programming, and Svelte constrains you to it's own syntax, while providing extreme performance. I think a better phrasing could be "a means to an end" to provide declarative programming.
Every library and even using no library is a compromise between time, performance and features (maintenance costs time, so a library that makes it easier will save time).
I'm currently using react at work and it's a rather good compromise, because we work with 4 teams of varying experience on a very complex application.
But back to the original point: a virtual DOM is not a necessity, but merely one way to solve a certain set of problems – and in some (but not all) cases, other solutions might be a better fit.
That's a good way to put it, I just rephrased the title of the article so it's a bit more vague, but no longer claims that it's a necessity. Thank you!
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.
The DOM can be used both very effective and very ineffective. The same is true for the virtual DOM, but libraries like react make it a bit easier for less experienced developers to use it effectively - and that's a good thing.
However, we had handcrafted DOM manipulations more than a decade ago that were easily faster than react - because they only made the necessary changes and reused instantiated nodes without any intensive reconciliation.
Libraries like Svelte and SolidJS help to have almost the same performance without the hassle and easily surpass react and other virtual DOM libraries in terms of performance.
I agree with a lot of these points in this statement - but I think you are generalizing here. While manually writing direct, imperative DOM manipulations is always going to be faster than any library you use out there, that's not really how we do web development today in real production use cases. React was created to make webdev paradigms delarative, and inventing the virtual DOM is just a means to an end.
I actually checked out SolidJS the other day, I found the concept very intruiging and the beta of SolidJS actually inspired me to create something like this in the first place. I loved how they optimized their own architecture, so I took some of the broad design principles and applied it to my own project.
However, I partially disagree with your generalization that Svelte and SolidJS is better for development experience and always has better performance. Development experience is subjective, it's difficult to objectively define whether something is "worth the hassle" or not. While React may be overall slower that Svelte and SolidJS, using React is a scapegoat in itself. MillionJS, compared to React's internal Virtual DOM engine is very different, but suffers from the same concequences as all Virtual DOM does. This is why MillionJS has several compiler-aware optimizations, so that in the future, Svelte + React mixes can be created.
If performance is your highest priority and the page is rather simple, it is still a sensible choice to develop exactly like this – and I actually did that ~ 3 years ago. Unfortunately, we had a priority shift in the meantime, so I cannot show you the result anymore, but it easily outperformed anything we could have done with react.
I would partially disagree, too, because I made no such statement. I merely remarked that they save you the hassle of hand-optimizing DOM manipulations while allowing for similar performance.
React is a compromise – and as I already said, that can be a good thing, too, depending on what you intend to do.
I see, personally I would prefer the best performance, but to each their own. I'd like to see the example if you ever get to find it!
I think I misinterpreted your statement there, I thought you were talking about React when you remarked about the "hassle" part.
It can also be noted that using any technology is a comprimise - for example, using DOM nodes generally constrains you to imperative programming, and Svelte constrains you to it's own syntax, while providing extreme performance. I think a better phrasing could be "a means to an end" to provide declarative programming.
You're right.
Every library and even using no library is a compromise between time, performance and features (maintenance costs time, so a library that makes it easier will save time).
I'm currently using react at work and it's a rather good compromise, because we work with 4 teams of varying experience on a very complex application.
But back to the original point: a virtual DOM is not a necessity, but merely one way to solve a certain set of problems – and in some (but not all) cases, other solutions might be a better fit.
That's a good way to put it, I just rephrased the title of the article so it's a bit more vague, but no longer claims that it's a necessity. Thank you!