17 ms·
Introducing Shadow DOM API
- hxn 11y agoThe template element looks very useful. Basic support in old browsers should be possible by simply setting it to display:none.
- Zikes 11y agoThere are some key features of template that hiding it would not accomplish, namely that the contents like scripts are guaranteed not to execute until they've been cloned/stamped. Fortunately there are already polyfills for that: http://webcomponents.org/ http://webcomponents.org/
- Zikes 11y agoI'm pretty excited about what this will do for web components development. Polyfills have come very close, but deeply nested components can become a tangled mess in no time. If anyone is interested in getting started with web components, I recommend taking a look at Google's Polymer[1] library. It's a fairly opinionated approach, but has a relatively small learning curve. [1] https://www.polymer-project.org/1.0/ https://www.polymer-project.org/1.0/
- IshKebab 11y agoYeah Google Play music is extremely slow in Firefox and I'm pretty sure it is because of their insane Web Components polyfill.
- spankalee 11y agoPlay Music is using an old prerelease version of Polymer. When they update to the latest production Polymer it should be much, much faster.
- ashark 11y agoAre they using it for Inbox, too? The memory use on that page. Yikes. To think I used to browse the web on 64MB of RAM without ever feeling memory-constrained. Sometimes with my e-mail client also open!
- kuschku 11y agoI’ve seen cases where I’ve opened Inbox on web on android and all apps in background crashed... The memory usage is insane.
- ashark 11y agoI just checked. My Inbox is has no mail in it (in the part I have open anyway, which is the... inbox). It is using 1.01GB of memory, 858.4MB compressed. Double-u. Tee. Eff. Docs.google.com, with a spreadsheet open? 617/585MB. Still entirely unacceptable, but lower than an empty Inbox. The difference between the two should be more than enough to run both, even with a comically generous bloat allowance. (I'd written then deleted something snarky about Google notoriously rigorous hiring practices really shines when we look at software that results, but seriously, all those smart people and this is what comes out? All their web software is embarrassingly bloated. Chrome's battery drain versus Safari? Android, which seems to take Do the Worst Thing that could Possibly Work as its guiding principle? What is going on in there? Is it some sort of organizational problem?)
- kuschku 11y agoThis is exactly the issue. The products have gotten bloated, slow, unusable on older devices, and the quality of the actual service has gotten worse, too. This is just... impossible to use. Google already is the new Microsoft, and Chrome the new IE. With this, they’re also losing any other reputation they had left. Google products once used to be about the tiniest and fastest solution, working everywhere, and using the least possible resources, without any bullshit features.
- spankalee 11y agoInbox does not use Polymer
- david-given 11y agoI rejigged my personal website using Polymer and was thoroughly impressed. It's pretty heavyweight, mostly because I'm too cheap to precompile and minify my Javascript, but the modular approach means that I can now, finally, apply actual software engineering principles to building websites. The documentation could be better, and you pretty much have to like Material Design, and there could be a richer set of standard widgets available, and it desperately needs a CDN, but other than that I found it really pleasant to use. What I haven't tried is building any kind of reactive interface. It's got some support for binding elements to data, but I didn't explore that much. Anyone care to comment?
- seivan 11y agoDid you try React before switching over? How did you enjoy data-bindings after working setState() ?
- david-given 11y agoNo, I've never touched React (mostly because it seems to require precompilation). I've been meaning to check it out at some point but the barrier of having to set up a Javascript toolchain has, so far, been too high to be worth it. Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.
- mbrock 11y agoFYI, React doesn't require any precompilation. You only need to include a JavaScript file. The JSX stuff is entirely optional, although almost everyone uses it. I share your fear and loathing of JavaScript compilation toolchains, and I successfully avoided all of them on a medium-sized React project. After we had a good working prototype, we started using some more tooling, but we kept it extremely simple to start with. 1. JSX tags simply compile to calls like React.createElement("a", { href: url }, ["content"]) and if you just create a short alias for that function, you don't need JSX at all. 2. If you're anything like me, things like Flux scare you by being weirdly ideological and requiring unnecessary boilerplate. You can ignore it and just use a single object to store all your state, according to the "keep it simple, stupid" philosophy. That said, I would recommend that you look at the Redux library, which is a simple and rational approach to the nebulous "Flux" concept. Redux is simple—it's just a certain design pattern that makes sense in the React context. 3. I find React.addons.update to be the most obvious and simple way of doing immutable updates to nested structures—which is what most React programs are doing all the time. People have come up with various libraries for more sophisticated immutable data structures, but you're unlikely to need them, and React.addons.update gives you 90% of the bang. Next time I have a bit of non-stressed free time, I'd like to make a repository with an example React application that's extremely simple, requiring no tooling and as much as possible avoiding "lockin" to various newfangled libraries and paradigms...
- eob 11y agoI've been using Polymer for a few months now after following the WebComponent spec for quite a while, and I'm really liking what I'm seeing. While it can admittedly lend itself to a very Java Swing-feeling development flow, that's a breath of fresh air compared to the traditional mess of web code I usually end up with. WebComponents in general (and Polymer as a particular library on top of them) I feel are going to be a 10x force multiplier for web development.
- wichert 11y agoIt might also be interested in taking a look at Aurelia (http://aurelia.io http://aurelia.io). That is a fairly new framework (still in active development, it hasn't hit 1.0 yet) which is heavily influenced by web components and seems to implement them quite well. When using their bundling gulp task I can have a full components using app that only requires a couple of HTTP requests to load.
- cletusw 11y agoI'm sure Chrome/Opera and Firefox will tweak their implementations to match the updated spec soon, then all that's left will be Edge, and they've expressed intent to implement!! https://dev.modern.ie/platform/status/shadowdom https://dev.modern.ie/platform/status/shadowdom
- pjmlp 11y agoOne step closer to XAML...
- meesles 11y agoIsn't this React??? Shadow DOM, in particular, provides a lightweight encapsulation for DOM trees by allowing a creation of a parallel tree on an element called a “shadow tree” that replaces the rendering of the element without modifying the underlying DOM tree.
- deleted 11y ago[deleted]
- gravity13 11y agoReact does not use Shadow Dom. And React is not related to CSS first-hand, though people are trying apply the same modularization principles of DOM encapsulation to the CSSOM. Not only that - there's a lot of implication that come with Shadow Dom that will make it impossible to just plug and play with React. Namely, the fact that is stops the cascading effect of Cascading Style Sheets. Whereever you are stylizing large swathes of your app with common css code, you'll need to rethink by either treating css as a module and importing at the new shadow root, or by rewriting your css to be more redundant. These tradeoffs require considerable buy-in, which leads me to suspect React will continue to be agnostic towards shadow dom.
- deleted 11y ago[deleted]
- chc 11y agoIt's similar in some ways, but not exactly the same. This allows an element on a page to contain a whole tree of elements while still appearing as a single element from the outside (i.e. for the purposes of DOM methods, CSS, etc.).
- morgante 11y agoNo, the virtual DOM and the Shadow DOM are distinct concepts. The virtual DOM is a parallel representation of the DOM which is used to diff against—it's only used for "logic" rather than display. The Shadow DOM is actually almost the opposite: it replaces the visual/interactive presentation of the tree without changing the exposure of the underlying elements to the rest of the page. That being said, they bother offer mechanisms for writing modularized frontend code effectively.
- thegayngler 11y agoI'm extremely excited about this. I have been playing with stock Web Components for the last year and a half or so. Polymer I have been hot and cold for. I prefer to learn the standard to start. Overall I am very happy with this development.
- tdumitrescu 11y agoAgreed. While Polymer is a neat project, I honestly think it's kind of hurt the adoption of web components. I'm sure I'm not the only one who's tried to learn about web components according to the standards, only to run into a ton of Polymer stuff on the web and get turned off by the heavy, opinionated, framework-like nature of it. The underlying web components APIs are much less off-putting to me, once you can dredge them up through the SEO swamp.
- marknutter 11y agoPolymer is really not that opinionated. All they do is provide sugar that you would eventually write yourself after you get comfortable with web components and start to notice where the boilerplate lives.
- deleted 11y ago[deleted]
- Ideabile 11y agoWhat gonna happen to all those engines/framework with Shadow DOM Views technologies? In short is the end of React?
- quest88 11y agoWhy do you think it'd be the end of React?
- JDDunn9 11y agoEventually yes, web components will likely kill off the usefulness of most front end frameworks.
- mbrock 11y agoGeneral note to people engaging in technological conversations: When posting strong statements, please consider including explanations, arguments, and maybe some definitions. This helps other people understand your claims, and is a big part of what makes "reason" such a powerful thing. More information here: https://en.wikipedia.org/wiki/Reason https://en.wikipedia.org/wiki/Reason
- bsimpson 11y agoReact's virtual DOM is an implementation detail - its real power is in how easy it makes it to write composable components. If Web Components are ever a faster render target than the DOM, you can trust that ReactDOM will be upgraded to comply (in the same way that Ember aped React's virtual DOM as Glimmer). That said, I have a feeling Web Components add complexity (and weight) to the render path. I doubt they will be faster than DOM diffing in the near term (although with any new web tech, there's always the possibility that they'll make available performance optimizations that can't be supported in the traditional DOM).
- eob 11y agoI agree there will probably be a performance lag for a while, but long-term I think the WC model wins out because it brings encapsulation and reuse into the formal suite of W3C specs. That's not a big deal for any one web app, but a huge deal across web development in general.
- Someone 11y agoCan anybody tell how this relates to http://trac.webkit.org/changeset/164131 http://trac.webkit.org/changeset/164131 (discussed in https://news.ycombinator.com/item?id=7243122 https://news.ycombinator.com/item?id=7243122)? New API, new implementation, or both?
- cletusw 11y agoNew API and new implementation. https://lists.webkit.org/pipermail/webkit-dev/2015-September/027661.html https://lists.webkit.org/pipermail/webkit-dev/2015-September...
- gravity13 11y agoThe things I'm curious about with Shadow Dom: - How does it affect performance, if say, a large application is composed of many shadow dom elements, each containing a large amount of redundant CSS? - Will there be a way to let certain css styles "leak" through while encapsulating others? Or is any type of native inheritance gone?
- Zikes 11y agoBecause a template would define the styles once, but be stamped multiple times, there should be minimal redundant copies of the styles themselves. How this performs will remain to be seen, as it would be up to the browsers to implement the spec optimally. You can "pierce" the shadow DOM with the ">>>" combinator (previously /deep/), allowing you to style elements from outside of the shadow DOM. This is discouraged in the case of web components, however, as a component is supposed to operate as a black box entity. Instead, a component can expose APIs for styling, such as with CSS variables: https://www.polymer-project.org/1.0/docs/devguide/styling.html#xscope-styling-details https://www.polymer-project.org/1.0/docs/devguide/styling.ht... Edit: This article[1] has details on performance and styling options. [1] https://hacks.mozilla.org/2015/06/the-state-of-web-components/ https://hacks.mozilla.org/2015/06/the-state-of-web-component...
- arota 11y agoThe last I had read[1], the intention is to deprecate shadow piercing combinators altogether. [1] - https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meetin...
- Zikes 11y agoI guess that would make it discouraged in all cases, then.
- spankalee 11y agoPerformance will be better with Shadow DOM. The styles are deduplicated (in Chrome at least, and I believe Firefox too), and the style boundary adds opportunities for optimization. There will be ways for styles to leak. The Polymer team has added a polyfill for CSS Custom Properties and CSS Mixins (the @apply rule [1]). Custom Properties cross shadow boundaries, and @apply lets you define properties sets that are applied later down the cascade. This lets components define very targets sets of custom properties that they apply to specific elements within their shadow root. [1]: http://tabatkins.github.io/specs/css-apply-rule/ http://tabatkins.github.io/specs/css-apply-rule/
- pornel 11y agoI, for one, am not excited about this. It's a "oh, that's neat" feature visible only to developers, but it is not enabling anything groundbreaking for the end users, so it isn't making webapps more competitive with native. We still need iframes for 3rd party embeddable components, and for 1st party components we have good enough solutions, and the tendency seems to be abstracting the DOM away. Web Components keep taking a lot of spec and implementation effort that could be spent on something with a bigger impact (ServiceWorkers in iOS? Transactional DOM that doesn't jank/layout-trash? Activities/Intents/Scopes for native-like sharing?)
- hugozap 11y agoA solid platform gets better gradually, it may not excite you but it's an important step in the right direction. Indirectly it does impact the users, because polyfills for browsers that do not support shadow dom have performance issues, not counting the time developers spend maintaining them.
- TeeWEE 11y agoI really like webcomponents, but they still statefully update the UIX, just like most native ui frameworks. React solves this by giving a declarative functional approach to webdevelopment. Would it be possible to combine both react with webcomponents? If so, are there any demo"s out there? I couldnt find anything.
- Zikes 11y agoSO has some discussion on React & Web Components: http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer http://programmers.stackexchange.com/questions/225400/pros-a...
- mbrock 11y agoThat depends on what you are doing inside of your web components. You can load any JavaScript you want in there, you know. If you want to use React, that's fine. Web Components is just a set of extensions to the DOM standards to allow encapsulated custom elements.
- bsimpson 11y agoI was wondering about that when I read this post this morning. The interface of a React component is very small: it's effectively just a render function with some lifecycle hooks and an internal setState method. Depending on your data management philosophy, you can even scrap state altogether and leave just the render function: var View = (props) => <div>{ props.content } </div>; You could probably write a Polymer-esque library that let you create Web Components with a similar API. I haven't looked into the implementation details of react-{dom, canvas, -native}, but I imagine that's effectively what they do - bridge from that API to the platform's native one. I expect that if Web Components are ever faster or otherwise better than the legacy DOM, such a shim will emerge to make WC as easy to write as React components.
- deleted 11y ago[deleted]
- hugozap 11y agoI've working with Polymer and it's been a great experience. This is great news as it will make polyfills less needed.
- idibidiart 11y agoWithout Microsoft adopting this too it remains in a "sort of kind of useful but not really" status. Where is Microsoft in this adoption cycle? And are there any incompatibility across the existing implementations, namely, Chrome, FF and now Webkit?
- rictic 11y agoMicrosoft has publicly announced that they're implementing Shadow Dom for Edge. Chrome is implementing Shadow Dom v1 now, an experimental version is in Canary I believe. The currently shipping version has a different model for distributed children, but we're actively moving to the newly agreed upon spec now.
- ebidel 11y agoMS: https://dev.modern.ie/platform/status/shadowdom/ https://dev.modern.ie/platform/status/shadowdom/ "we intend to begin development soon" FF: https://bugzilla.mozilla.org/show_bug.cgi?id=1205323 https://bugzilla.mozilla.org/show_bug.cgi?id=1205323
- octref 11y agoReally like this as a React dev. Recently there is a trend to use inline CSS to do CSS modularization in React, but I feel it's not really a clean approach. With Shadow DOM you can mount the whole React App onto a Shadow root and have perfect CSS encapsulation. Hopefully we can see Shadow DOM supported by major vendors' stable channel soon.
- jlongster 11y agoShadow DOM is not the solution for CSS isolation for components. You'd have to mount every single component into its own shadow DOM which seems unnecessarily complex (and most likely has significant perf implications). The answer to CSS scoping is much simpler: CSS Modules https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
- spankalee 11y ago> and most likely has significant perf implications This is true, CSS performance is better in native Shadow DOM.
- octref 11y agoNo I wouldn't mount each component into a Shadow DOM. For example if I have a React App with 2 major parts developed by 2 teams, I would just mount them onto 2 Shadow DOMs so each team don't need to worry about CSS classes collisions or whatever else that's on the webpage.
- BinaryIdiot 11y agoAt first I was gung ho about web components. I was so excited I used Mozilla's X-Tag for one project and Polymer in another project. I am now no longer in favor of using them and it makes me sad, actually. Web components are simply too heavy. They add latency to download (yeah you can combine them but I've never found tooling (including Vulcanize) that worked very well). Also the shadow dom's separation makes styling more difficult across multiple components requiring awkward shadow dom hacks in the CSS and / or duplicating / adding more CSS to components themselves. Same with using JavaScript and third party libraries not expecting to use the ShadowDom though this isn't so bad. When I'm working on something that needs to be optimized for low bandwidth / high latency I go as lightweight as possible and I concat as much stuff together as I can. I want web components to work so badly but they're way too slow for me to use anytime soon.
- mbrock 11y ago"Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"? That's a weaker claim, and leads to the question of what they might be good for right now. I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources. But I've only looked a little at the W3 specs and haven't tried using them in reality.
- BinaryIdiot 11y ago> "Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"? Current implementations yes but when browsers have 100% integration? I want to say yes but would love to say no. My biggest issues (latency, trying to concat and minify down and duplicative CSS) are not really addressed anywhere but until all browsers have the full implementation I can't say for sure I'll admit. > I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources. That seems like a great use case. I'd prefer, and probably most others, to host my own components versus externally referencing them but in some cases where you can't really get around it (I'm not familiar with Stripe's payment widget but Google Maps is certainly like this) I could see that being a good use case. Honestly that in and of itself may justify its existence but I'm just not convinced of its use fullness outside of that just yet.
- elcritch 11y agoThey're fantastic for a lot of purposes. I've been experimenting with web-components for a couple of months now. It's not really "prime-time" ready, IMHO, but it's cool to see how quickly it's progressing now that Mozilla is more on board [1] and Microsoft's Edge is implementing core features [2a] and supporting WC's generally [2b]. (PS Vote on the MS's Edge website for implementing WC features! Seems they actually look at the votes some to determine features). One of the biggest hangups for my team has been Firefox/Mozilla opting not to enable HTML imports (it's implemented) which causes quite a bit of annoyance when developing and using piece-meal web-components. They list there reasons [3] but their perspective seems to be driven from a "Javascript" first mentality with HTML being second class. My code is all driven by web-compoents though. The difficulty comes from getting the WC polyfills to load before Firefox tries to load your dom-modules (in Polymer terms). I want to separate out my HTML into modules and not require loading polyfills before I can include static HTML pages that might not even have Javascript in them. There will probably be a lot of resistance, or rather, misuse of web-components for a while unless web-developers start switching to a "data first" mentality which is gaining traction from React and ClojureScript. It also feels pretty very heavy-weight if you're using Polymer currently. BTW, anyone know how the shadow DOM affects performance of the entire browser window? Mainly, I'd be curious to know if updates to a shadow-DOM is isolated from causing Light DOM updates (e.g. updates to the shadow DOM could be isolated to generally not affect the parent window, or could be batched). This would yield much of the benefits of React's Virtual DOM. Just not sure where to look in the Webkit docs to find where this would be documented. [1]: https://hacks.mozilla.org/2015/06/the-state-of-web-components/ https://hacks.mozilla.org/2015/06/the-state-of-web-component... [2a]: https://dev.modern.ie/platform/status/templateelement/ https://dev.modern.ie/platform/status/templateelement/ [2b]: https://blogs.windows.com/msedgedev/2015/07/15/microsoft-edge-and-web-components/ https://blogs.windows.com/msedgedev/2015/07/15/microsoft-edg... [3]: https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ https://hacks.mozilla.org/2014/12/mozilla-and-web-components...
- sslnx 11y agoI have always been skeptical about Shadow DOM. It tries to solve different problems under one solution. Say you want a static page without scripts but with CSS encapsulation. You cannot achieve that. Instead you have to use Shadow DOM and get it in package with other unneeded things. CSS encapsulation could be solved with special attribute, new HTML tag or even with new CSS rule, and it would have been more flexible than Shadow DOM is.
- nostrademons 11y agoYou're looking for "<style scoped>", which is in Firefox, used to be in Chrome, but was eventually removed in favor of Shadow DOM. http://html5doctor.com/the-scoped-attribute/ http://html5doctor.com/the-scoped-attribute/ http://caniuse.com/#feat=style-scoped http://caniuse.com/#feat=style-scoped https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/scoped/blink-dev/R1x18ZLS5qQ/Bjuh_cENhlQJ https://groups.google.com/a/chromium.org/forum/#!searchin/bl... I think the main reason webcomponents won out over scoped styles is because usually once you need to scope your styles, you find you also need to scope your querySelector calls, and your DOM traversals, and your IDs....and pretty soon you have shadow DOM. It's unlikely that you need style namespacing if you're just a single dev working on a static page, and it's unlikely that you won't need JS & DOM scoping if your product grows beyond that.
- avodonosov 11y agoGreat to see such a progress. I hope within a decade or two HTML will finally allow us to create convenient reusable building blocks.
- EdSharkey 11y agoDOM is such a crufty old API/data structure to work with and with CSS, computationally it's a pig. Anything we can do to isolate bits and bobs on the page from one another and make DOM easier for the browser to render and emit events for, the better. I just think the Shadow DOM and Web Components are too complex to work with as designed. The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components. All I would want/need is a lightweight version of iframe whereby it functions like a javascript security and css styles sandbox, call it a subwindow. A subwindow could load html/css/js independently from the parent page like a Web Worker does, or it could borrow from assets the parent page has loaded and its HTML could be inlined as innerHTML statically/dynamically from the parent page (at creation time.) A subwindow would have an independent global/window object from the parent window. And, you could postMessage/onMessage communicate with the parent window if you needed. It could be constructed with its own dedicated DOM thread, or it could schedule on the parent's thread if you didn't want another thread spawned. Paints would have to be synchronized between the DOM threads, which could be a bummer. I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;)
- hayksaakian 11y agoIsn't that how normal frames used to work? Before they were deprecated for iframes?
- rco8786 11y agomy thoughts exactly. what's old is new again
- seabee 11y agoFrames like frameset? It sounds more like Netscape 4 layers.
- EdSharkey 11y agoI don't want to partition the page the way frames/frameset did, I want to sandbox code and content the way iframe does, just in a more lightweight fashion. If I could couple that sandboxing with a component factory library like React, that could really be something else.
- williamle8300 11y agoThis is a nod to ReactJS
- JeremyBanks 11y agoThe ShadowDOM spec has been in development since at least a couple of years before React was announced.
- michaelwww 11y ago"Stop writing frameworks" by Joe Gregorio [OSCON 2015] is a nice intro to html imports, shadowdom and other aspects of web components, although his knock on frameworks goes too far for me, especially since some frameworks can use web components as well. https://www.youtube.com/watch?v=GMWAHzXQnNM https://www.youtube.com/watch?v=GMWAHzXQnNM
- datashovel 11y agoCompose all the things! It's definitely reassuring to see that this is the attitude of the people who are building the standards for the future of the web.
- wampler 11y agoSo when can we use it?