Ask HN: Why not create DOM Tree / CSSDOM in back end before sending to browser? | Hacker News Reader

Ask HN: Why not create DOM Tree / CSSDOM in back end before sending to browser?

3 pointstechsin1013 comments

When browser gets html and css, it goes through trouble of parsing it. Constructing DOM, then parse CSS and create CSSOM.

Sum this across millions of users and all of them are doing the same thing over and over again.

What if you could do this once in backend and deliver constructed CSSOM/DOM in binary format.

Wouldn't that be more efficient?

This can easily be integrated into current system.

Browser make http request tells backend it supports a new type i.e.: html/binary or something

Framework in backend automatically parse and construct whole tree and caches it then send it to frontend.

There could be even partially constructed trees for dynamic content ex: user profile

to me it's like getting pizza delivered vs getting ingredients for pizza delivered.

Sure, it might work. A binary format still has to be parsed, of course, but it would likely be a little more efficient.

One question is whether that efficiency gain would be worth the hassle of a binary format. Binary formats have generally not been a good fit for the web; DNS and HTTP/2 are the only widespread protocols I can remember off the top of my head that are binary. gRPC is binary, and look at the lack of mature toolchains to work with it -- while there are some tools now, the selection is minuscule compared to those available for HTML and CSS.

Binary formats are also trickier to extend and keep backwards-compatible.

think of it like webassembly for html/css

right now it's like this

get html -> read html -> read css -> build tree -> calculate styles -> apply styles to tree -> paint the tree

what I'm thinking is this...

get html/binary -> read it -> paint the tree

You still have to deserialise it, parse it, and build a DOM tree.

You can’t just overlay a series of bytes into browser memory like you can with executable code, because the in-memory representation of the DOM tree is browser specific, and in some cases proprietary and undocumented.

And I suspect that in many cases the possibility of causing buffer overflows and other unexpected side effects by being able to target browser memory direct is too great for browser manufacturers to take the risk.

Java has had the ability to do something like what you propose with object serialisation, and they are considering removing it because of the risks.

Reply on news.ycombinator.com