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

321–330 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#321

Post by rhinoceraptor »

somerando7 wrote: post #97
jacobsenscott wrote: post #73

Earlier quoted context omitted.

Why don't they allow react? One reason I can think of is they have a server side side rendered architecture and they want people to continue to use that. They don't want new devs to use company time to buff their resume with unmaintainable learning front end code. At least that's why I generally shoot down attempts at using FE js frameworks over here. We have some really awful react 0.11 pages that are years old that…

Legal reasons.

The patents issues was FUD, but now it's completely irrelevant, the patent clause was removed a while ago.

Re: Virtual DOM is pure overhead (2018)

#322

Post by ousta »

radicalbyte wrote: post #152
jasonkester wrote: post #119

Earlier quoted context omitted.

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You hav…

That's just a symptom of Javascript being the entry-level language. You can be sort of productive without ever understanding how anything works. Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.

I hear everyday components but JSF was components, ASP.NET was components , Knockout was components. Explain to me what is the difference?

Re: Virtual DOM is pure overhead (2018)

#323

Post by dirkg »

namelosw wrote: post #61
Lowkeyloki wrote: post #11

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…

It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them. It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript. For example, a framework Foo does not have the concept '…

Anything with a DSL is evil. That's why I never liked Vue and don't understand its huge popularity - you get none of the functional benefits of React, you might get a minor speed increase, and you DO get to write code the old style with custom DSL and no clear components.

Re: Virtual DOM is pure overhead (2018)

#324

Post by Sawamara »

kevingadd wrote: post #278
Sawamara wrote: post #139

Earlier quoted context omitted.

Ew, not really. Even the getters can be performance-heavy in DOM-land. If you store your data in JS-land, and only diff against that, you never need to touch the dom for anything, except the endpoint insertions. At worst , it is matched evenly by any sort of custom vanillaJS+Dom manipulation tool (which needs to be perfectly well written, and hand-crafted to match what you are currently working on). At best, its seve…

You overestimate the cost of modern DOM operations. It's a battle between your virtual DOM (to optimize DOM operations without lots of diffing overhead) and the native DOM (which is frequently a bunch of JS that can get inlined and avoid duplicate work)

No I do not. You will have to work very hard to back up the claim that modern DOM operations are not costly. Plenty of lookups can cause repaint or reflow.

Scenario A: (Vdom-like approach) - Render x with dimensions x,y,z,w. - Store the reference to the created DOM elements. - Store dimensions it was created with

If you do not go towards this way, and actually query DOM-land to get the dimensions you need to check against, you will run into issues. By storing your state alongside the endpoint, you will only have to diff against the stored state and props, not the endpoints themselves.

That COMPLETELY bypasses DOM access, and only updates the changed elements.

Show me how bypassing this and just using dom alone is superior. Or how adding layers of layers of js-land checks is not approaching the solution that vdom and differs already arrived at.

Re: Virtual DOM is pure overhead (2018)

#325

Post by dirkg »

brobdingnagians wrote: post #55
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?

I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as we…

Vue's 'separation' is a myth.

I don't know why people keep believing that separating templates and js is a good thig. Pete Hunt addressed this in the React into videos he did -

you want 'separation of concerns', not 'separation of technologies'.

React does the former. Vue/any other templating engine does the latter.

Re: Virtual DOM is pure overhead (2018)

#326

Post by ozten »

vaibhavkul wrote: post #309
beders wrote: post #164

It is simply mind-boggling how much effort the JS community has put into working around the performance properties of a document layout engine to make it 'interactive' and 'responsive'. With only 3 major rendering engines left standing, where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines? Back to Svelte vs. React vs. Reagent vs. Vue.JS vs. Angular v…

This is why I find the flutter approach interesting: it has its own rendering engine. I would guess it is optimized for this sort of thing (dynamically rendering UI elements) without depending on an external entity (DOM). Maybe there is a future where flutter style renderers become standard, have a container like a browser (to avoid the entire runtime baggage when it's deployed), and people target it instead of the D…

Does Flutter bridge accessibility APIs?

Re: Virtual DOM is pure overhead (2018)

#328

Post by rxgx »

floatboth wrote: post #175
concerned_user wrote: post #163

Earlier quoted context omitted.

I hear the tale of "soon native Web Components" for years and still none in sight yet. As far as I remember there are some attempts from Chrome and Mozilla but not sure I saw a real cross-platform spec out, so I stopped tracking the news around it really. Can you provide some references maybe?

https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=shadowdomv1 v1 shipped with Chrome 53, Safari 10 and Firefox 63. (And there's a polyfill.) It's not "soon", it's very much "been in production for a while". A base class like LitElement https://lit-element.polymer-project.org is all you need to achieve a sort of "react-like" development style (components with unidirectional data flow) WITHOUT build…

Anyone else get a little excited about that Edge v75?!

Re: Virtual DOM is pure overhead (2018)

#329

Post by spankalee »

nsonha wrote: post #301
floatboth wrote: post #182

Earlier quoted context omitted.

And lit works without any build tools!

the main reason templates are bad is not that it needs a build step, it's more about being non-standard (a problem lit-html doesn't have), and not statically analyzable (think typescript's jsx), which lit-html doesn't solve.

lit-html does solve the static analyzable problem, see https://marketplace.visualstudio.com/items?itemName=runem.li...

Re: Virtual DOM is pure overhead (2018)

#330

Post by JMTQp8lwXL »

brylie wrote: post #214
JMTQp8lwXL wrote: post #117

Earlier quoted context omitted.

I've never understood how people view the separation of template, styles, and business logic into separate files as simpler. Now, to work on a single component, I need to open three files in my editor, instead of one.

The "separate files" argument is a red herring. It is really about separate "mindsets" or "modes of thinking". In effect, JavaScript logic tends to be procedural/imperative, while templates allow declarative semantics, and styles are nearly a 2.5D constraint language. "Separation of concerns" here means only having to think in a particular mode, rather than blending all of those modes of thought into a single eyespan…

I don't see how separate files forces you to think differently. It might aid in that effort, but it likely doesn't force it.
Post reply on HN