I don't think VDOM as it's most commonly implemented is a very good model to add. It doesn't make a distinction between static and dynamic.
-
-
Replying to @justinfagnani @_developit and
What Ryosuke proposes in https://github.com/whatwg/html/issues/2254 … would make it easier to create large DOM trees and directly address the dynamic parts.
5 replies 5 retweets 21 likes -
Replying to @justinfagnani @_developit and
This largely ignores how developers use JSX and tagged templates, <template /> improvements isnt what lib authors want... imo of course
4 replies 0 retweets 9 likes -
Replying to @tbranyen @_developit and
I'm a lib author, and it's what I want. <template> improvements would make a fast and small lit-html even faster and smaller.
3 replies 1 retweet 7 likes -
Replying to @justinfagnani @tbranyen and
And I don't think it ignores anything. One of the critical jobs of any template system is creating DOM trees and addressing parts of them.
2 replies 0 retweets 4 likes -
Replying to @justinfagnani @tbranyen and
Right now that typically involves creating a large number of JS wrappers + DOM traversal...
2 replies 0 retweets 2 likes -
Replying to @justinfagnani @tbranyen and
...the template extension proposal offers a way to do do that much more efficiently, with less code.
1 reply 0 retweets 3 likes -
Replying to @justinfagnani @tbranyen and
that can be used as infrastructure for any number of different layers above it.
1 reply 0 retweets 3 likes -
Replying to @justinfagnani @tbranyen and
Also, can we just talk about vdom overhead for a minute? I'm grateful the marketing dreck about it being "faster" quietly exited stage left
4 replies 4 retweets 15 likes -
Replying to @slightlylate @justinfagnani and
But we need to all admit that doubling up your data structures & doing work O(num-elements) when changes are smaller is *not fast*
8 replies 8 retweets 32 likes
Best case, vdom helps avoid scheduling issues, but what I see in traces is *huge* per-element overhead
-
-
Replying to @slightlylate @justinfagnani and
The way FWs attempt to efficiently update DOM are not exactly without overhead either, though. Wouldn't a native DOM-morph API help?
2 replies 0 retweets 4 likes -
Replying to @HenrikJoreteg @slightlylate and
Adding a native v-dom, incremental-dom or what-have-you-dom would currently be the biggest win across the board for platform IMO
1 reply 0 retweets 5 likes - 9 more replies
New conversation -
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.