
Ask HN: Why not create DOM Tree / CSSDOM in back end before sending to browser? - techsin101
When browser gets html and css, it goes through trouble of parsing it. Constructing DOM, then parse CSS and create CSSOM.<p>Sum this across millions of users and all of them are doing the same thing over and over again.<p>What if you could do this once in backend and deliver constructed CSSOM&#x2F;DOM in binary format.<p>Wouldn&#x27;t that be more efficient?<p>This can easily be integrated into current system.<p>Browser make http request tells backend it supports a new type i.e.: html&#x2F;binary or something<p>Framework in backend automatically parse and construct whole tree and caches it then send it to frontend.<p>There could be even partially constructed trees for dynamic content ex: user profile<p>to me it&#x27;s like getting pizza delivered vs getting ingredients for pizza delivered.
======
lobster_johnson
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.

~~~
techsin101
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

~~~
mr_toad
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.

