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 344 posts

Re: Virtual DOM is pure overhead (2018)

#241

Post by e12e »

DonHopkins wrote: post #178
fauigerzigerk wrote: post #174

Earlier quoted context omitted.

is-odd doesn't have any tests for handling zero. What would they be anyway? What is-odd does is to throw an exception if you pass anything that isn't a safe integer or a string representation of a safe integer. Otherwise it just returns n % 2 === 1 (after converting string to int if necessary)

You don't want to start a religious war between the people who believe zero is special, and the ones who believe it should throw an error if you pass a string, and the people who believe it should attempt to convert the string to an integer, and the people who believe you should either round or truncate when the parameter is a floating point number, and the people who disagree about which direction to round, and the…

> should either round or truncate when the parameter is a floating point number

Isn't the parameter always floating point in Javascript? (which does mean a package like isOdd will have to incorporate some level of mysticism...)

Re: Virtual DOM is pure overhead (2018)

#242

Post by ljm »

oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

I love how many people there are in this thread that somehow avoided the jQuery hell a lot of us battled against.

I was involved in that, mostly from when my paycheque involved throwing together websites in Drupal 6. Holding that architecture together was trouble enough without having to also care about the frontend, we were only scripting it. The idea of the HTML being considered an 'app' was utterly alien to me and my colleagues at that time.

I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

Ten years later and I find closures more intuitive than half the stuff we've concocted in OOP land.

More than that, jQuery was a means to an end and to shove low-effort animation and UI into an app to make it look snazzy and 'Web 2.0' like (glass effect banners, drop shadows and all). If it wasn't jQuery it was script.aculo.us.

Then we got Backbone and Coffeescript at around the same time, by which time I was a Ruby dev. Backbone contributed to a fundamental shift in how we build a frontend, and we had Knockout, Sencha, ExtJS, etc. following along. And then the concept of 'comet' (keeping an HTTP connection alive for long polling) and MeteorJS.

The impact of React and its concept of the VDOM has been phenomenal. It may be overhead as the Svelte authors say, but the experience of working with React, and any similar library in the ecosystem, is a boon to anyone who wants to do serious work in the browser. Without being hyperbolic this feels like the legacy of smalltalk: programming in a dynamic environment, only you're not actually aware that you are.

There has to be a fantastic retrospective on the progression of JS since that initial ten-day genesis.

[0] https://medium.com/dailyjs/i-never-understood-javascript-clo...

Re: Virtual DOM is pure overhead (2018)

#243

Post by PudgePacket »

ru999gol wrote: post #233
reilly3000 wrote: post #42

Has anybody here migrated a UI from React to Svelte? How did it go?

of course not, this is just opinionated rubbish, in the real world people use react dom/native

> Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

https://news.ycombinator.com/newsguidelines.html

https://mobile.twitter.com/sveltejs/status/10885005396404183...

Re: Virtual DOM is pure overhead (2018)

#244

Post by computerex »

azangru wrote: post #29
computerex wrote: post #20

What a strange post. Yes, virtual DOM is overhead, much like JIT compilation is an "overhead". But this overhead ultimately translates to better performance because many virtual DOM transformations can be buffered into 1 transformation of the real DOM.

> ultimately translates to better performance Better compared to what? For a library like React, which re-renders the DOM tree every time component’s props or state change, virtual DOM with diffing and patching is indeed a better approach as compared to naive re-rendering of the whole DOM. But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based…

> Better compared to what?

Better than, presumably the old way of doing things, doing DOM transformations manually in handwritten code.

I haven't seen these talks by Rich Harris but they sound very interesting and I'd be very interested to see the performance.

Re: Virtual DOM is pure overhead (2018)

#245

Post by madhadron »

somerando7 wrote: post #51
jordache wrote: post #27

Earlier quoted context omitted.

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

Vanilla JS with a good understanding of MVC serves quite nicely in most cases. I wrote a few introductory programs to clarify it (https://github.com/madhadron/mvc_for_the_web).

Re: Virtual DOM is pure overhead (2018)

#246

Post by peterangular »

spankalee wrote: post #95
somerando7 wrote: post #51

Earlier quoted context omitted.

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

Check out web components with LitElement and lit-html. You get a very React-like experience with components and functional templates in JS, but it's all standard JS, and there's no framework, just standard web components. The lock-in and risk is very low for enterprises.

Went down this rabbit hole yesterday and played with LitElement/lit-html for the first time... great experience for folks who don't want much "ceremony". Was also SUPER impressed with AppRun.

The more that I depart from my "bare metal" web tooling the riskier/dumber things get. I always want to see a path back to a basic HTML5 shell, driven by almost-pure JS (w/tiny helper libs), and basic CSS. Just like basic UNIX tooling - basic web tooling just works!

To those thinking about trying lit-html; it IS as simple as the example on the GitHub project page. I was able to build it into a semi-complex application within a couple of hours and it had massive performance payoff w/o compromising how I want to build things. It definitely gets my "KISS" approval stamp.

Re: Virtual DOM is pure overhead (2018)

#247

Post by ben509 »

hn_throwaway_99 wrote: post #91
oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

> This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail. I disagree with this. I think the major key insight and innovation with React, which this article fully acknowledges, is that it is much easier to think about declarative UI as solely a function of the current state without having to think about the transitions to arrive at that st…

Svelte is a compiler, so I think it's figuring out the possible state changes as part of compilation. Contrast with React where any component can return any elements at any time.

Re: Virtual DOM is pure overhead (2018)

#248

Post by jeremyjh »

nailer wrote: post #162
QuadrupleA wrote: post #32

So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a ca…

> compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). > Can't speak to the svelte approach due to inexperience with it Heya! I'm been using Svelte for the last week for a new project - knowing React has the lion's share of community right now, but feeling like Svelte is where things are going to be. Regarding: "compared to a well written app…

Svelte definitely is compelling, but one thing I really like about using React or Vue.js are the very mature communities and in particular the full-featured styled widget libraries. Projects like Semantic UI React[1] or Buefy[2] (Bulma/Vue.js) give you so many basic components that would be major time sink to create yourself in every project. Does Svelte have anything like this?

[1] https://react.semantic-ui.com

[2] https://buefy.org/documentation

Re: Virtual DOM is pure overhead (2018)

#249

Post by weberc2 »

barrkel wrote: post #222
WA wrote: post #185

Earlier quoted context omitted.

If you’ve ever written a video game, I think it’s quite obvious as well. Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear. Of course, your game can run entirely "in memory" without a render function, which is basically what the game server does. So I guess, many people have figured…

Before anybody runs away and thinks there's a fundamental insight here, I have to say that all that's really changing is who owns the retained model: application or UI library. I mean retained by contrast with immediate, as in the early DirectX jargon. By retained model, I mean the source of truth as to the current state of the UI. Games normally use an immediate mode API, but they still render the UI from a model; i…

How are these other state concerns you mention (e.g., focus) handles in immediate mode GUIs? Do the components retain those states or do you keep a separate model for those states that needs to interact with the application model? If so, how is that interaction wired up?

Re: Virtual DOM is pure overhead (2018)

#250

Post by edem »

oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

React has nothing to do with this. They just took an idea as old as Windows 1.0 and applied it to web development.
Post reply on HN