3 ms·
> The problem with vanilla JS is not APIs, API is the easy thing. Then the problem is really the API, if one needs to write tons of helpers just to make that t
by aikah 7y ago
> The problem with vanilla JS is not APIs, API is the easy thing.
Then the problem is really the API, if one needs to write tons of helpers just to make that thing bearable. Never had to write a framework on top of QT or WPF just to develop apps on these platforms. Web Components tries to make things a bit easier by allowing people to write their own widgets that know how to clean up themselves when removed, but it's not there yet apparently.
IMHO what the DOM needs is a good DOM diff API directly included in the browser. Right now it's either modifying DOM nodes themselves manually or just innerHTML string trickery, when wanting to update an entire tree of DOM nodes.
events are already a solved problem thanks to event delegation. It's DOM modification that is still painful.
This list of recipes doesn't solve the large front-end app at scale problem.
So personally right now, all I need IS a DOM-diff library. Using external widgets is a bit trickier, but with event handlers I can do required instantiation and clean-up provided the third party widget has the necessary event hooks.
- cies 7y ago> Then the problem is really the API I think the problem of JS is not the APIs, it's the language itself. > IMHO what the DOM needs is a good DOM diff API directly included in the browser. Here you go, part of WebComponents: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM https://developer.mozilla.org/en-US/docs/Web/Web_Components/... > Web Components tries to make things a bit easier by allowing people to write their own widgets that know how to clean up themselves when removed, but it's not there yet apparently. WCs aims to replace a lot of what is now React. As is "just the view and some encapsulation. With a the litElements lib (or some other) you also get some life cycle callbacks. > This list of recipes doesn't solve the large front-end app at scale problem. It did not claim to either. My 2 cents: that problem is prolly going to be fixed by writing code that compiles to JS (or WASM). JS was the problem all along for big codebases; too quirky, too little safety, very easy to make mistakes.
- vince14 7y ago> part of WebComponents WebComponents do not have DOM diff APIs whatsoever.
- mosdl 7y agoDiffing isn't really needed - usually you either replace a subtree completely or change a few attributes, which isn't hard to write code for. Diffing will always be expensive memory wise.
- aikah 7y ago> Diffing isn't really needed - usually you either replace a subtree completely or change a few attributes, which isn't hard to write code for. Replacing the entire page on model change doesn't work for interactive forms and I don't want to micro-manage every attribute. My model drives the view automatically so diffing is necessary. The memory cost isn't that big if the diff algorithm is implemented efficiently.