Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

171–180 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#171

Post by tyingq »

I'm somewhat surprised that React won out versus Angular or something similar. Because React isn't opinionated about the supporting things around it, there seems to be wide variations in a React stack and approach from team to team.

More so than I would typically see in any other ecosystem. But nobody seems to care. Is is that it makes for a sort of meritocracy where people that keep up with the fast changing landscape get the best opportunities? Basically, I can't figure out why JS developers aren't overwhelmed and frustrated with all the choices.

Re: Virtual DOM is pure overhead (2018)

#172

Post by madeofpalk »

recursive wrote: post #156
madeofpalk wrote: post #61

Earlier quoted context omitted.

Is it possible to just not think about it? Or is that easier said than done?

Usually it just works. But, even following the "Rules of Hooks" ( https://reactjs.org/docs/hooks-rules.html ), I managed to write some code where the state that belonged to one component ended up in its adjacent sibling. When that happened, I really wasn't sure what to do other than go on a deep react dive. It's not clear how to debug stuff like that. I came to realize that I had confused the reconciler. The fix is b…

How did this happen? I've never seen this in practice if you weren't doing something "obviously" wrong.

Re: Virtual DOM is pure overhead (2018)

#173

Post by daok »

tyingq wrote: post #171

I'm somewhat surprised that React won out versus Angular or something similar. Because React isn't opinionated about the supporting things around it, there seems to be wide variations in a React stack and approach from team to team. More so than I would typically see in any other ecosystem. But nobody seems to care. Is is that it makes for a sort of meritocracy where people that keep up with the fast changing landsca…

One reason React won over Angular is it relies on JavaScript instead of custom templating syntax. E.g. You loop with a forEach, not some ng-...

Re: Virtual DOM is pure overhead (2018)

#174

Post by kujino »

jchw wrote: post #41

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compile…

Svelte hasn't taken over because React is way too popular already. If you want a job you have to learn React (the same way Java is still one of the top lang to get a job but it's for legacy rather than technical reasons).

Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more readable.

Svelte is the only framework you can grasp in 10min by just looking at a few examples. To get started, you don't even have to read a tutorial or documentation, the code is self-explanatory.

React is a complex beast and, in my opinion, all this is an overkill / overengineered environment for expressing UIs.

I find Svelte to be the only framework that "make sense". Ultimately UI is not that complex, it's a store -> derived variables -> UI where each step is a reactive function of the previous one. A framework should let you express this very concisely and take care of everything else for you.

If x = y + z then I want to write x = y + z, end of the story. Like in a Excel sheet, just write the formulas and that's it. No useStates, hooks, componentShouldUpdate(), and other wierd stuff.

Svelte is to React what Pluto is to Jupyter Notebooks, less popular because of legacy, but, in my opinion, obviously more elegant & cleaner

Re: Virtual DOM is pure overhead (2018)

#175

Post by dstick »

recursivedoubts wrote: post #76
avidphantasm wrote: post #63

I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the…

You might want to take a look at the HAT stack: https://htmx.org - server interactions in HTML https://alpinejs.dev - small front end tweaks in your HTML https://tailwindcss.com - styling in your HTML This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free. full disclosure: I am the author of htmx [1] - https://htmx.org/e…

> This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free.

Not to be "that" guy but what you're describing is a .vue file. And with a Vue single file component you have 1 dependency: Vue. With HAT you have 3. Or am I missing something?

Re: Virtual DOM is pure overhead (2018)

#176

Post by dstick »

holtalanm wrote: post #64
ferdowsi wrote: post #33

I feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what? In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering mi…

> In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures. Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client. Ended up needing to freeze the state as I…

Would you mind elaborating a bit on _how_ you implemented this? In my experience with Vuex and large datasets with dozens of stores, the devil is in the detail and how you change stuff matters a lot.

For example, you can't just create and keep a copy of a dataset / variable. It will remain reactive. You need to clone it. Failing to do so will indeed quickly clog up... everything :D

Re: Virtual DOM is pure overhead (2018)

#177

Post by eagsalazar2 »

macspoofing wrote: post #97
protonimitate wrote: post #74

Earlier quoted context omitted.

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to se…

>Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale. What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here. That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

>> That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. As an incumbent it has staying power because there is benefit in sticking with the herd, it remains a pretty nice developer experience, and because it has essential features other frameworks don't really provide yet (React Native being the biggest one although I do realize other frameworks are working on this now too).

Svelt isn't popular because to disrupt a solid incumbent you need something that is dramatically better at solving problems devs actually care about (not corner case performance benchmarks when React is "good enough" 99% of the time). Svelt has failed to do that, plain and simple.

Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community, maybe is a clue as to why Svelt has failed to be sufficiently introspective in either accepting it is a niche framework (which maybe it is great for) or that it needs to change if it wants to be more mainstream.

Re: Virtual DOM is pure overhead (2018)

#178

Post by slver »

jchw wrote: post #41

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compile…

> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.

Modern software commonly goes through multiple transformation (compilation stages) and it's increasingly common for some of them to be AOT, and some to be JIT, and neither AOT or JIT is overhead, even in combination. They have different pros/cons and in fact together you get the best of both worlds.

This doesn't negate your main point, but I wish you didn't end with an example of "irony" that actually is incorrect.

Re: Virtual DOM is pure overhead (2018)

#179

Post by arenaninja »

datavirtue wrote: post #90
arenaninja wrote: post #72

Earlier quoted context omitted.

I used React for 3 years and I'm using Angular for 2 years now; Angular is super heavy handed and gets in your way

I have professional experience in Angular and it is simply a framework for building applications. It hits that out of the park. I genuinely tried React and had to ditch it. Way too much drama just to manage state. It is clearly for building components, not applications. I don't think comparing the two is relevant. Angular gets in your way if you are just building components but it unleashes a deluge of productivity i…

To me scaling this Angular codebase has been more challenging than it was to scale React codebases for collaboration across multiple projects and teams. Going through NgModule instead of using plain node packages is my main gripe here; coincidentally this is also what gets in your way if you're trying to build reusable dumb components in Angular

I almost like ngrx because it reduces boilerplate, but I don't understand why their createAction helper doesn't follow Flux Standard Action; I can't be convinced this isn't a design flaw

Re: Virtual DOM is pure overhead (2018)

#180

Post by dsego »

daok wrote: post #173
tyingq wrote: post #171

I'm somewhat surprised that React won out versus Angular or something similar. Because React isn't opinionated about the supporting things around it, there seems to be wide variations in a React stack and approach from team to team. More so than I would typically see in any other ecosystem. But nobody seems to care. Is is that it makes for a sort of meritocracy where people that keep up with the fast changing landsca…

One reason React won over Angular is it relies on JavaScript instead of custom templating syntax. E.g. You loop with a forEach, not some ng-...

forEach in react/jsx, are you sure?
Post reply on HN