It seems like the value-add of React, or Angular Components, etc (not the routing and "frameworky" things) can really be boiled down to: 1. Better ergonomics for updating DOM from JS values 2. Managing teardown related to lifecycle of DOM elements 3. Some eventing ergonomics ..
-
Show this thread
-
... there are definitely other things they add, but those are the biggest three things I can think of. What are current DOM-related efforts to just ship these things natively?
2 replies 1 retweet 4 likesShow this thread -
Just number 2 above is puzzling. Outside of a WeakMap, I can't think of a way to teardown a resource when a DOM element is removed. And that's not an ideal solution. Why isn't there an "onremove" event or something? I guess there are MutationObservers, which aren't ideal either.
6 replies 0 retweets 7 likesShow this thread -
It just seems like these are problems we could solve with native APIs *in the browser*. Even if they were only 70% as ergonomic as say, React, I'd still rather use them if it meant better performance.
2 replies 0 retweets 7 likesShow this thread -
Why don't we have something like "virtual DOM" or "compiled templates" in the browser? Just something to make bridging the gap from JS values to DOM require a lot less code. If we had that, would frameworks not be smaller?
5 replies 3 retweets 14 likesShow this thread
Would be cool if the Template Instantiation proposal got implemented. Believe this might be the exact answer you're looking for. As a browser framework author, this would definitely make my life easier! https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md …
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.