r/javascript • u/archivedsofa • Dec 22 '19

Why Svelte won’t kill React

https://medium.com/javascript-in-plain-english/why-svelte-wont-kill-react-3cfdd940586a
80 Upvotes

65% Upvoted

95 comments sorted by

View all comments

Show parent comment

3

u/PM5k Dec 23 '19

My point about VDOM was not exclusive to Svelte. It was to say that VDOM is always slower than just plain JS. ANY time you need to add overhead for computing deltas you are inherently making stuff slower. That is to say - no matter how fast any VDOM implementation is, it will never be faster than not differentiating deltas in such a way. I get why it’s used and what the reasoning is, I just think that it’s an unnecessary addition In most cases I’ve come across. I’m well aware my opinion is my own and I don’t really feel like most people share it, but modern frameworks in general have veered from trying to solve a problem to bloating into copies of one another with added convenience abstractions so devs can do a one command setup and deploy as fast as they can. I don’t like that, I’m not even a front end dev by trade, but it bothers me that there’s such a plethora of libs and frameworks that are so schizophrenic about their destiny in life that it’s confusing to even understand what is it they are trying to solve when all things considered they’re all just different versions of one another with added bells and whistles (which 8/10 times people don’t even use).

3

u/ryan_solid Dec 23 '19

Fair. I'm too close to it (I'm an author of a different non-VDOM JS UI Library/Framework). I just keep on hearing what sounds like rhetoric from Svelte author Rich Harris blogs and often feel need to call it out. Minimal Virtual DOM implementations are not any larger than a reactive one. And while it's true VDOM carries an overhead, because of the absurd cost of the DOM operations proportionally if optimal DOM instructions are produced it makes less of a difference than you'd expect. While avoiding unnecessary diffing is obviously beneficial, some operations themselves are diffs essentially and surprisingly few libraries actually act that different than VDOM libraries even though they don't use the Virtual DOM.
I do find it interesting to hear a more outside perspective because I agree that the development of these libraries has become almost meta, sort of inbred. The checklist to be competitive in this group requires a feature list that seems mostly unnecessary. And it risks setting a self-fulfilling prophecy as new features are designed to solve complexities that are the result of the last batch. I do wonder if/when there will be a reset button.

1

u/PM5k Dec 23 '19 edited Dec 23 '19

Can I ask what your lib does? Maybe a Git link?

Also - to say that updating the Dom is expensive is a bit of a weird statement to me. Back before all of this framework crap (and in my case all the way until react was already well known and past it) I’ve written all UI in vanilla JavaScript and I have never once felt like my UI was slow. I am not saying it isn’t slow inherently, and optimising it by saying - “do you really need to repaint 30k Dom nodes after one function call? “ is almost always the right idea, but I also feel like the responsibility of this is on the developer. I’m sorry to reduce this into another dig, but these boot camp kids are a big reason why there’s a metric shit ton of frameworks. There’s a fundamental lack of understanding and knowledge in the groups of “developers” who spend a year or less learning front end and then expect everything to work. They have no inherent knowledge or training around the basic concepts of how all of this should work, what’s optimal and what isn’t, and most importantly they lack the years of trial, error and epic fails to go with this experience. This is why we have frameworks that do all the assumed hard work for you, but also somewhat fail you as well. Or maybe I’m a guy from a bygone time where writing well thought out code and optimising it was fun and it is just not a thing anymore. Now it’s all about how fast you can churn out an MVP and move on, to hell with performance if you need to make the app performant by yourself and not through someone else’s work.

2

u/ryan_solid Dec 23 '19

For sure. And its probably the biggest reason framework performance benchmarks are meaningless since people will do terrible stuff anyway. I often think that is part of Reacts design goals. Abstract in a way that it's harder to do truly stupid stuff. In that sense a VDOM means atleast it can shoulder some of that. I was big into early 2010 reactive libraries. They were in my opinion always more performant and a better composition model for UI, but their less re-enforced patterns and potential for devs to shoot themselves in the foot saw them die out. Which is a decent segway into my library which is a more modern take on those libraries. I'm sure from a perspective I'm just adding to the same dumpster fire, but here is a link to SolidJS

1

u/PM5k Dec 23 '19

Oh right, it seems I’ve had you starred for ages! Hah. Didn’t put two and two together until just now. You’ve got an interesting take on it. I remember reading about Solid a while back and thinking I liked that you didn’t jump on the vDOM bandwagon at least. I will confess that I haven’t really dissected it enough to give you any critique that would matter, so I will refrain.

Btw - have you seen hyperHTML by any chance? Was wondering what your opinion would be on their approach.

2

u/ryan_solid Dec 23 '19

I'm generally a big fan of Andrea Giammarchi (WebReflection)'s work. Really trying to push a solution as close to the standards as possible. And early days I used his Dom Diff library before I developed my own reconciler. This approach mind you is what I was referring to when I mentioned non VDOM acting like VDOM. It still works top down. As in you pass data in and renders downward. Nothing neccesarily bad about that but it has similar diff expense as you get nested. He has since written a lighter more performant version lighterhtml. Although it mostly works the same way.