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.
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