3 ms·

None of the frameworks you have mentioned support proper sandboxing of component internals. They are leaky [1] and incompatible with each other abstractions. We

None of the frameworks you have mentioned support proper sandboxing of component internals. They are leaky [1] and incompatible with each other abstractions. We need at least some basic native shadow DOM support in order to hide implementation details and avoid naming clashes. [1] https://en.wikipedia.org/wiki/Leaky_abstraction https://en.wikipedia.org/wiki/Leaky_abstraction

EdSharkey 11y ago
Agreed, most libraries and frameworks have nasty leaky abstractions; that is part of the cost of choosing to add those packages in your architecture. And heck, the browser itself is a clown car full of leaky abstractions, we deal with the problem everywhere. I think successful open source projects have a pretty good track record managing leaky abstractions since they have so many users. JQuery did a good job in this area over time, papering over many of the leaky abstractions present in the DOM across browsers. Looking at the bug tracker for React, I think they are doing okay too after a rocky start. Haven't really tracked Angular, but I hear Ember is a pretty well run project too. Shadow DOM does sound pretty good, but not essential to componentization if you're managing your ID's carefully. Honestly, I don't care if a framework or the browser manages my component scopes, I just want it taken care of. I always thought scoped stylesheets would be more important to non-leaky UI component development, but it seems like that is yet another dead-end experiment that didn't catch on. http://caniuse.com/#feat=style-scoped http://caniuse.com/#feat=style-scoped So we fall back to tooling again, and get something like SASS to manage and build our monolithic stylesheets. I prefer linking to Joel Spolsky's blog when describing Leaky Abstractions since he coined the term: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
- jarek-foksa 11y ago
  ID prefixing won't prevent component internals from leaking to event listeners, querySelector results, TreeWalkers/NodeIterators, innerHTML, and many other APIs. Native shadow DOM allows me to write components with strict encapsulation on pair with the built-ins such as <button> or <input>, neither framework comes even close to that. Styles defined inside shadow DOM are always scoped to the local shadow tree, so there is really no need for style[scoped]. Chrome and Opera (and maybe Firefox) support CSS encapsulation inside shadow DOM making the CSS preprocessors less needed.
  - EdSharkey 11y ago
    Shadow DOM does sound pretty cool, I wish its design allowed it to fit in better with existing DOM. I think react components give you pretty good isolation. You don't spend any time querying by selector or innerHtml, you just update your model, it re-renders the component tree, and then a diff of the DOM yields the mutations it will do on your behalf. Event binding is similarly abstracted. It's a different paradigm than what you're describing, and I think it works well for a lot more use cases than just "componentize the DOM". I'd love to be able to combine shadow DOM and react somehow (assuming wide browser support emerges). I bet a lot of performance optimizations could be derived in the browser from native Shadow DOM.

EdSharkey 11y ago

Agreed, most libraries and frameworks have nasty leaky abstractions; that is part of the cost of choosing to add those packages in your architecture. And heck, the browser itself is a clown car full of leaky abstractions, we deal with the problem everywhere. I think successful open source projects have a pretty good track record managing leaky abstractions since they have so many users. JQuery did a good job in this area over time, papering over many of the leaky abstractions present in the DOM across browsers. Looking at the bug tracker for React, I think they are doing okay too after a rocky start. Haven't really tracked Angular, but I hear Ember is a pretty well run project too. Shadow DOM does sound pretty good, but not essential to componentization if you're managing your ID's carefully. Honestly, I don't care if a framework or the browser manages my component scopes, I just want it taken care of. I always thought scoped stylesheets would be more important to non-leaky UI component development, but it seems like that is yet another dead-end experiment that didn't catch on. http://caniuse.com/#feat=style-scoped http://caniuse.com/#feat=style-scoped So we fall back to tooling again, and get something like SASS to manage and build our monolithic stylesheets. I prefer linking to Joel Spolsky's blog when describing Leaky Abstractions since he coined the term: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

jarek-foksa 11y ago
ID prefixing won't prevent component internals from leaking to event listeners, querySelector results, TreeWalkers/NodeIterators, innerHTML, and many other APIs. Native shadow DOM allows me to write components with strict encapsulation on pair with the built-ins such as <button> or <input>, neither framework comes even close to that. Styles defined inside shadow DOM are always scoped to the local shadow tree, so there is really no need for style[scoped]. Chrome and Opera (and maybe Firefox) support CSS encapsulation inside shadow DOM making the CSS preprocessors less needed.
- EdSharkey 11y ago
  Shadow DOM does sound pretty cool, I wish its design allowed it to fit in better with existing DOM. I think react components give you pretty good isolation. You don't spend any time querying by selector or innerHtml, you just update your model, it re-renders the component tree, and then a diff of the DOM yields the mutations it will do on your behalf. Event binding is similarly abstracted. It's a different paradigm than what you're describing, and I think it works well for a lot more use cases than just "componentize the DOM". I'd love to be able to combine shadow DOM and react somehow (assuming wide browser support emerges). I bet a lot of performance optimizations could be derived in the browser from native Shadow DOM.