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

61–70 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#61

Post by CharlieDigital »

randomdata wrote: post #29
traverseda wrote: post #7

Earlier quoted context omitted.

Serious answer? SEO and accessibility. HTML lets search engines crawl pages and screen readers read pages (which can often be a legal requirement). If we're rethinking the web stack I'd advocate for htmx with wasm-based web components for more complicated stuff like if you needed to polyfil in some new image format, or run a terminal emulator, or do webrtc calls with your own fancy custom noise reduction algorithm. Y…

> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?

Short answer: yes.

Crawlers are based on consuming text.

HTML is text. Sites that optimize for SEO also use JavaScript to provide SEO context. The specific standard is called JSON+LD; pretty much any site that you use where SEO matters has JSON+LD, RDF-a, or Microdata embedded in the HTML.

You can see these structures if you use the Schema.org validator: https://validator.schema.org/

Try plugging in a URL like Reddit.com and see for yourself. On e-commerce websites, it's a *must have*. For example, try this Amazon page: https://www.amazon.com/dp/B09V3GZD32.

TL;DR: crawlers are parsing RDF-a and Microdata in the HTML or JSON+LD embedded in `` tags.

You can learn more about it here: https://developers.google.com/search/docs/appearance/structu...

Re: Virtual DOM is pure overhead (2018)

#62

Post by overgard »

thomasikzelf wrote: post #55
afavour wrote: post #40

Earlier quoted context omitted.

Agreed, I'd love to see HTMLElement.beginTransaction() or something similar.

Document fragments are like transactions for the DOM. Alternatively you could just learn which Dom operations force a layout shift and batch those.

You are correct, but if you think about it, you're talking about parsing and tokenizing before the operation can even occur. That's really heavy. I think it could be better than reading .innerHTML

Re: Virtual DOM is pure overhead (2018)

#63

Post by TurningCanadian »

afavour wrote: post #36
harel wrote: post #11

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…

> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…

> React also needs to hydrate every element even when it isn't ever going to change

That is no longer true with Server Components https://beta.nextjs.org/docs/rendering/server-and-client-com...

Re: Virtual DOM is pure overhead (2018)

#64

Post by asveikau »

miohtama wrote: post #25
_Algernon_ wrote: post #12

All abstractions are pure overhead. Let's code everything by hand by flipping bits in memory using a tiny magnetic needle.

This is not correct. Zero cost abstractions are not overhead. Some abstractions are zero cost abstractions. Thus, not all abstractions are pure overhead. More on zero cost abstractions here: https://stackoverflow.com/a/69178445/315168

The Stroustrup quote in that thread is better than what you linked to.

The concept was popularized by C++ templates. The idea is that the templated code would be just as good as if you hand wrote it without generics. There's no extra function pointers or virtual calls, extra indirection by pointing to some user data, etc.; the tree node or whatever and data struct are declared as a single entity, there's no runtime callbacks, etc.

Re: Virtual DOM is pure overhead (2018)

#65

Post by spankalee »

dmix wrote: post #44
spankalee wrote: post #17

The key observation about HTML templates is that usually large portions of them don't change with new data. There is static content, and even with lots of dynamic bindings they're tied together in a static structure. So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static c…

> The key observation about HTML templates is that usually large portions of them don't change with new data. Isn't this a core idea underneath the https://fresh.deno.dev/ "islands" and I believe the https://astro.build/ framework when they confronted issues around hydration/SSR? https://www.patterns.dev/posts/islands-architecture/ Clearly there's some overhead via the vDOM and simply using React-like templates when…

vdom is overhead server-side too. When rendering HTML on the server you really want to stream longer pre-allocated strings as much as possible. The serialization overhead of converting many small objects to individual HTML tags shows up in profiles. And when you want low latency and the ability to handle high loads, it matters.

Re: Virtual DOM is pure overhead (2018)

#66

Post by SigmundA »

c-smile wrote: post #30

Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…

Just have a suspendLayout resumeLayout / beginUpdate endUpdate method like Winforms surprised doesn't exist after all these years

Re: Virtual DOM is pure overhead (2018)

#67

Post by afavour »

TurningCanadian wrote: post #63
afavour wrote: post #36

Earlier quoted context omitted.

> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…

> React also needs to hydrate every element even when it isn't ever going to change That is no longer true with Server Components https://beta.nextjs.org/docs/rendering/server-and-client-com...

...which are a whole damn thing.

Don't get me wrong I'm glad the React team is tackling the problem but it's telling that the answer requires an entire server side solution when other JS frameworks are able to solve this in the client or at build time. And just looking at those docs screams "patching over a fundamental issue" to me.

Re: Virtual DOM is pure overhead (2018)

#68

Post by boomlinde »

overgard wrote: post #32

Sadly, it seems like nobody is considering the best optimization: make DOM operations fast. I think if you could batch DOM operations together you could avoid a lot of wasted relayout and duplicate calculations.

> Sadly, it seems like nobody is considering the best optimization: make DOM operations fast.

On the contrary, there is evidence that quite a few people are considering that.

Re: Virtual DOM is pure overhead (2018)

#69

Post by overgard »

c-smile wrote: post #49
overgard wrote: post #32

Sadly, it seems like nobody is considering the best optimization: make DOM operations fast. I think if you could batch DOM operations together you could avoid a lot of wasted relayout and duplicate calculations.

I was thinking of how to improve DOM updates. One of ideas is to add Element.update() method: Element.update(function(updateCtx) { updateCtx.setInnerText(this, "new text"); updateCtx.setAttribute(this, "title", "new title"); ... }); This has two benefits: 1) transactional update, 2) for contenteditable scenarios it can group DOM mutations in atomic undo-able action. But I've discarded that in lieu of Element.patch(vD…

I actually think the former example is more clear. It's a bit verbose but every part is simple. The second example is very "magic", it takes a lot of thought to understand

Re: Virtual DOM is pure overhead (2018)

#70

Post by randomdata »

CharlieDigital wrote: post #61
randomdata wrote: post #29

Earlier quoted context omitted.

> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?

Short answer: yes. Crawlers are based on consuming text. HTML is text. Sites that optimize for SEO also use JavaScript to provide SEO context. The specific standard is called JSON+LD; pretty much any site that you use where SEO matters has JSON+LD, RDF-a, or Microdata embedded in the HTML. You can see these structures if you use the Schema.org validator: https://validator.schema.org/ Try plugging in a URL like Reddit…

Here's an excerpt of some Javascript found on the Amazon link:

    window.ue_ihb = (window.ue_ihb || window.ueinit || 0) + 1;
        if (window.ue_ihb === 1) {

            var ue_csm = window,
                ue_hob = +new Date();
            (function(d) {
                var e = d.ue = d.ue || {},
                    f = Date.now || function() {
                        return +new Date
                    };
                e.d = function(b) {
                    return f() - (b ? 0 : d.ue_t0)
                };
                e.stub = function(b, a) {
Feel free to visit it to find the entire script. It is much too large to post here. What is a crawler learning from that program that would be lost if the equivalent code was bundled as WASM instead? Why couldn't its WASM parser pull out the same information? The JS/WASM runtime in the browser has to produce the same result regardless of which encoding is chosen, so everything will be encoded in there somehow.
Post reply on HN