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

241–250 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#241

Post by Marazan »

macspoofing wrote: post #182
eagsalazar2 wrote: post #177

Earlier quoted context omitted.

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

>This is complete and utter nonsense. Were you programming seriously before React? Indeed I was. >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. I'm not saying React isn't a good framework, it is perfectly nice, though I th…

Angular was a hot mess and I found it a nightmare to program with.

It basically embodied the bad side of JS frameworks pre-React.

It managed to take alllll the wrong lessons from Flex.

Re: Virtual DOM is pure overhead (2018)

#242

Post by 8note »

tarkin2 wrote: post #117

Browsers have improved to the point where VirtualDOM is basically unneeded.

I'd imagine that over time, depending on browser makers focus, either virtual doms or non virtual doms will be faster than the other.

It'd be handy to have it as a flippable switch

Re: Virtual DOM is pure overhead (2018)

#243

Post by hajile »

mumblemumble wrote: post #92
progx wrote: post #70

Earlier quoted context omitted.

Performance is not a problem for the most developers, as long as the app runs smooth. React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React. React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code...…

> Performance is not a problem for the most developers, as long as the app runs smooth. On their machines. That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resour…

Most devs using React work in development mode which is several times slower than production. I used to test with a chromebook and production builds were often faster than dev builds on my macbook.

Re: Virtual DOM is pure overhead (2018)

#244

Post by recursivedoubts »

arduinomancer wrote: post #234
recursivedoubts wrote: post #76

Earlier quoted context omitted.

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…

My impression of reading [1] is that its just moving the "spooky action at a distance" to a different place. If I see this: Click Me My immediate question is * What actually executes when I click the button? * How can I debug the code that sends the GET request? * How can I customize the GET request and add stuff like custom headers? In the jQuery example all of that is obvious on first glance. I feel like complexity…

Do you feel that way when you see an href on a link? Do you feel the need to debug that? If so, how do you do it?

There is an hx-headers attribute to modify headers, or you can plug into the events system if need be.

htmx is extending HTML as a hypermedia and, therefore, is a very different model than most javascript-based apps today.

I am not sure if complexity can be destroyed (I'd need to have a solid definition of complexity to discuss that) but it can certainly be managed in different ways, some of which are more effective than others for certain problems. We don't do web programming in assembly for a reason.

Re: Virtual DOM is pure overhead (2018)

#245

Post by cuddlecake »

rendall wrote: post #230
cuddlecake wrote: post #228

Earlier quoted context omitted.

Eh, I'd say it's a valid use case as any. Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc. What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people an…

I dunno. Maybe. How about the practice of removing a test that fails? Literally, test fails, remove it, problem solved. Ship it. Sure there are build warnings, but CI isn't complaining, so..? Is that a valid use case? If your team member did that, you'd be cool-and-the-gang, easy-like-sunday-morning, shaming-is-the-real-shame?

You're trying to reframe my argument in a bad way.

I'm talking about people deciding to use a certain technology with tradeoffs.

You're talking about people going against quality standards of a development team. And that's where I end the conversation, you bore me.

Re: Virtual DOM is pure overhead (2018)

#246

Post by alserio »

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 does two things very well: it's easy to integrate with other vanilla and not js technologies and opens up the space of your solutions. You don't have to have full buy in in it. You are not forced to do things how the framework want you to think about them. That's alone is a big win against React in my book, where you are not doing web dev, you are doing React dev, and sometimes that is way too constrained. That's is also a reason why Svelte is not irrelevant. It doesn't need to become React to be useful.

Re: Virtual DOM is pure overhead (2018)

#247

Post by zozbot234 »

mumblemumble wrote: post #124
macspoofing wrote: post #89

Earlier quoted context omitted.

>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. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because…

> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you'…

> But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations

"Swapping out entire chunks of the tree" is in fact a very sensible choice given that the browser rendering pipeline is highly optimized and can run in parallel, whereas any v-diffing step has to be done in single-threaded, non-native JS. You also save on the overhead of storing the vDOM itself, which will be quite significant.

Re: Virtual DOM is pure overhead (2018)

#248

Post by alserio »

vinnymac wrote: post #81
jchw wrote: post #71

Earlier quoted context omitted.

That’s the weird part. I agree with you, but then at the end, they say the important part: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understand…

Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed. At the end of the day, I've never spok…

Hooks are a big shift towards a more fine grained reactive programming in terms of API. However even vdom vs reactivity systems is not an obvious choice, since they have their tradeoffs. The same conflict is much more visible in vue. Thankfully, there are a lot of alternatives that explore this problem space

Re: Virtual DOM is pure overhead (2018)

#249

Post by holtalanm »

dstick wrote: post #176
holtalanm wrote: post #64

Earlier quoted context omitted.

> 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

you don't have to clone it. cloning the object and putting it in Vuex will still result in it being reactive.

`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.

well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.

Re: Virtual DOM is pure overhead (2018)

#250

Post by arcturus17 »

davidwparker wrote: post #208
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…

I'd say that the NY Times is pretty good for "at scale".

Doesn’t the NYT do a lot of React too? From what I read in other comments Svelte was an experiment.

I think what people mean when they say “at scale” is they want to see a large codebase, with a large team working on it, where Svelte is the primary front-end choice.

Post reply on HN