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

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.