wondering aloud... perhaps we need something like WASM, but for HTML... in other words, a way for a server to ship pre-compiled DOM (not an html string) directly to the layout engine, bypassing the HTML parser -- same way WASM bypasses the JS parser with pre-compiled byte code.
-
Show this thread
-
Wasm doesn’t parse faster than JS IIRC
1 reply 0 retweets 1 like -
Replying to @saambarati @getify
Sure, but Kyle wants to circumvent parse altogether
1 reply 0 retweets 2 likes -
Replying to @rwaldron @saambarati
specifically, I musing about circumventing stupid wasted work where SSR builds a DOM in memory on the server, serializes that DOM back down to a string of HTML (costly), transfers the string of HTML over the wire, then has to re-parse that string of HTML back into the same DOM.
2 replies 0 retweets 1 like -
also... whether WASM "is faster" than JS is less the point and more that WASM was, in fact, despite some attempts (like this one) to re-author history, sold as cutting out a lot of "JS parse overhead", such as this post.pic.twitter.com/VnRLgXIFQi
1 reply 0 retweets 1 like -
It's both amusing and frustrating that some people seem to think that we can't remember from just 2-3 years ago that this -- cutting down/out JS parse times -- was absolutely one of the main selling points for WASM. Just google search to find dozens/hundreds of such mentions.
4 replies 0 retweets 3 likes -
I’m not sure why history is even relevant. You’re musing about a new feature to avoid JS parse cost. Multiple implementers are telling you that in 2019, this is not the dominating cost anymore. Parse cost is just not a problem in need of a solution.
2 replies 0 retweets 6 likes -
Are you still talking about HTML? Kyle's original post was about avoiding parse of "giant string of HTML". Don't get stuck on parsing JS, that was a side note
1 reply 0 retweets 1 like -
Mathias Bynens Retweeted getify
That’s not what https://twitter.com/getify/status/1125124825905807360 … says

Mathias Bynens added,
getify @getifyReplying to @getify @rwaldron @saambaratialso... whether WASM "is faster" than JS is less the point and more that WASM was, in fact, despite some attempts (like this one) to re-author history, sold as cutting out a lot of "JS parse overhead", such as this post. pic.twitter.com/VnRLgXIFQi2 replies 0 retweets 0 likes -
seriously, what are you even talking about? you and others were retconning the situation, saying that WASM had nothing to do with JS parse times. It did. It may not now, but it did. I was establishing that fact. but it's all a rather unrelated rabbit trail from my OP.
2 replies 0 retweets 1 like
Mathias Bynens Retweeted getify
Retconning? I was specifically responding tohttps://twitter.com/getify/status/1125008258668875776 …
Mathias Bynens added,
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.