Introducing Shadow DOM API
webkit.org
webkit.org
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". ;)
Before they were deprecated for iframes?
They're simple to me: basically just isolated tree of DOM attached to the document. The only slight complexity comes from projection, which really is just a way to plug in a child element into the shadow. Projection is absolutely necessary for composable widgets, you couldn't create containers without them.
Just earlier today I had an issue where I was trying to read this article [1] and the page, after loading for around 3 minutes (I was on mobile and on the free plan of my ISP, which gives only 64kbps, but unlimited), had all the content, but neither JS nor CSS.
There are already many websites which I can’t use at all anymore because they make everything invisible until JS and CSS are loaded. Flash of unstyled content is not an issue for me, it’s the whole reason I am able to read pages.
[1] http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two...
With the caveat that I only sorta understand this stuff -- if it emerges this way after the politics & process, you should be able to use the 'deep combinator' >>> to apply styles even across shadow DOM boundaries.
Also, it breaks about every existing userstyle, ever.
And there should be a more general solution that also handles the shadow DOM of browser-internal elements like the <input type="file">
Beyond that, the Web Components spec seems geared for coarse-grained components - like a widget or a panel. I could be wrong about this, I admit, my experiments a year ago with Web Components were short lived when I saw how much got polyfilled on Firefox. Anyhow, React is a javascript library exercise rather than a retool-the-DOM exercise to me, and that's a big reason I appreciate it. It offers data binding, rendering, templating, and true-componentization all in one package - and it supports legacy systems. I think there's an answer in Web Components for all of those things, including legacy support up to a point with polyfills, but it wasn't cohesive nor easy to roll things.
I think with lots of tool support, perhaps a compiled language targeting the Web Components spec, it could be just as easy to roll Web Components as React Components.
It was so nice to finally get inline SVG, instead of confined inside Adobe's plug-in. Crazy days.
> The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components.
Web components have pretty much the same levels of composability as React, but have promise for even more. The main reason I say this is that the components specs attempt to formalize a surface area for all web webcomponents libraries to interoperate with each other - though we're not to that point yet.
Many of the Polymer core components are a great example of composed elements (sometimes overzealously so). Shadow DOM and insertion points (<content> or <slot>) do wonders for this. (Yes, Polymer 1.0+ backs off from this a little bit)
React really only composes well with elements written in React. It can talk out to native components (and custom elements), but it's awkward enough that you tend to build wrappers to expose a more React-y interface (value, onChange, etc).
---
> I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;)
Assuming that you want these inline frames on a per component basis, we're talking about a ton of overhead per component:
* A new JS VM context (for the sandboxed global and security mechanisms)
* A new render layer (and the the synchronized painting you mention)
* All the other browser bits that would need to be built up
---
DOM is a problem, but it's not the biggest problem, and performance-wise, there have been tremendous improvements in the last few years (Try running your benchmarks again).
However, imagine a world where all elements are defined with a set of public APIs like web components. No more crazy special cased properties, magic methods, etc. Imagine how much cruft the browser vendors could remove from the DOM. Imagine how much faster things would be.
Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.
I didn't know about this, any guidance on why?
TL;DR: Shady DOM provides an API that is similar to shadow DOM, but without all the crazy overhead when polyfilling it. The downside is that it's not quite transparent to someone outside of a Polymer element
> Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.
It would be interesting to see if that's even remotely feasible with the current "limitations" of Shadow CSS and/or how Shadow CSS would have to be extended to support this.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
I believe iframes can be very costly for the browser to manage, but I don't understand all the reasons why that would be - perhaps something to deal with the cross-domain security concerns.
It'd just be nice to have a stripped-down same-domain version of iframe that could layout nicely as a rectangle into the parent page, but not inherit styles nor Javascript namespace from the parent page.
The idea of having multiple threads contributing to the DOM that builds the page really intrigues me.
There's a proposed thing for HTML5+ called CanvasProxy, for example. The idea would be that you could detach a Canvas from the DOM thread and give it to a Web Worker. It could get a Canvas context in the worker from the proxy, and all draw commands would execute against the Canvas' pixel buffer in the worker. Meanwhile, back in the DOM thread, the actual canvas tag still lives on, just in detached mode, but you can still set CSS styles on that tag. You just can't get access to the Canvas context.
It sounds rad, and would make a big difference to canvases that represent heavy computations or frequent draws. No browser vendor has attempted to implement CanvasProxy however, it sounds like it is a challenge to keep it actually performant, and/or there are GPU threading issues?
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.
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.
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.
- What's wrong with vulcanize (combines all your components into one single html file)?
- Polymer now offers Shared styles, so that you don't have to duplicate your css. And you can use BEM or what ever you like.
- Get ready for HTTP2 in a few years.
Most of the issues I ran into were relating to inconsistent pathing. It was difficult to get every type of thing that could use a path (image tags, css, html inclusions, etc) working in a way that worked at both the path of the component and the newly created path when combined. Perhaps this has changed since the last I used Vulcanize but it was very painful at the time.
I also had a hell of a time getting the google maps, and a few other google components, to Vulcanize with the rest of my components but I honestly can't remember the issues now.
> Polymer now offers Shared styles, so that you don't have to duplicate your css
That's Polymer specific though; is there a way to do that with native web components? I could be missing something but it looks specific to Polymer. Regardless I'm glad this is being addressed to a degree but the solution seemed somewhat unintuitive as it's not using CSS semantics for driving the style.
Essentially the majority of projects I work on have developers and designers on them. The designers are usually pretty good with CSS, Illustrator and Photoshop so anything outside of CSS requires quite a bit of learning for them so that's a hill I have to battle with techniques such as these.
> Get ready for HTTP2 in a few years.
Just like I'm not going to be able to use ES6 for many years I'm not holding my breath here :)
Maybe? I'm not sure. The vast majority of issues I had with Vulcanize stemmed from pathing changes.
So say you're working on a component that exists at /components/mycomponent/mycomponent.html
When you're referencing JavaScript, images, CSS, etc you typically assume you're at / but it doesn't work like that for everything. So you either have to setup a configurations so you have a universal prefix to use for everything or do everything relative to root (which at least in the environments I deployed into not really doable as the root could change). So the vulcanizer needs to understand and reroute everything within your component and since there is no way to override the way the browser fetches content you're left with trying to figure out everything to include and doing it via ajax (if you wanted to be automated about it).
I'm not saying it's impossible but it seems difficult to do to the point where I don't know that that's the best path for web development to go down.
I honestly can't remember some of the other issues I've run into. Mostly JavaScript errors from third party components and even other Polymer components but it's been about 6 months or so since I've used it. I'm sure Vulcanize has gotten better by now and I know Polymer has.
Instead use a normal JavaScript module loader to load components and concat them the usual way. Don't use imports.
[1] https://hacks.mozilla.org/2015/06/the-state-of-web-component... (see: HTML Imports)
I expect that when the ES6 modules loader spec is finalized it will be fully compatible with the underlying semantics of HTML imports, and they will work quite nicely together.
Just say no to web components. Say yes to upgrading HTML specs directly.
If you want to see balkanized UI frameworks, there it is.
Because they shouldn't be. HTML should not be responsible for providing every possible UI element. In fact, I would argue that provides _far_ too many UI elements, and should instead provide low level user input APIs that can be used to build interactive elements.
Thanks but no thanks.
HTML should provide a rich, declarative UI API by default. We shouldn't have to hunt down separate components to get that.
If you have to load Javascript, you have already lost.
This is commonly known as the web browser.
lol @ browser vendors deploying UI components via Javascript, when they could just as easily deploy them in the web browser itself as part of upgraded HTML specs.
We used to write web specs speculatively, without having feedback from real-world use, and it was a disaster. Take a look at the list of W3C standards:
https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan...
How many of them do you actually use? Remember when everything was XML, XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?
That's nice in theory, but what's happening in reality is that no component is going to be standardized, and HTML remains stagnant for another 15 years.
There's pretty ample evidence that common webdeveloper behavior does make it into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS transitions & animations, long-polling => websockets, common layouts => <header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary> elements, the addition of date/datetime/color/number/range/tel input types, etc. If you're still coding HTML like you did in 2000, you are now very obsolete.
Shadow DOM's style scoping is very intentional, and brings sanity to styling. Cross-scope styling is possible via CSS custom properties in a much more principled way than letting styles leak all over the entire document.
CSS selectors allow for a pretty wide breadth of targets -- they can be as narrowly specific or as broadly general ("leaky") as the author likes.
What's the exact problem that another layer/mechanism of scoping solves that being thoughtful about your selectors doesn't?
You can kind of fake it with build steps and some luck, but it will always have holes and problems with dynamically updated DOM.
Faking lower bounds also keeps the browser from knowing that it doesn't have to invalidate the isolated scopes when properties above them changes.
vs
One-thousand `regular` DOM Elements with 1000 CSS selectors.
It's a simple math. 10 times faster.
Shadowdom allows for specific targeting within a component; is that necessary faster than a query using another element / class name for targeting a component in "regular" usage? I'm curious on the numbers here as I don't know that you're necessary right or wrong here.
Or maybe the correct way of using web components would be to create component "rollups" on server side, to reduce the latency effect of the extra requests. Or the browser might start caching common components between page requests.
Maybe the current web component spec is just the first step to get the reusable web started...
They don't add any additional TCP connection latency, sure. I think it's a bit unrealistic to claim there won't be any congestion of the multiplexed stream which causes additional latency.
>I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away.
I may be misremembering, but I thought that was just for request headers?
That's correct: https://http2.github.io/http2-spec/compression.html.
Web Components are just a set of APIs and capabilities in the browser. They don't imply anything about the number and type of files that are used to create your app.
Putting it another way - whats the advantage of HTML imports over server side imports?
Server side imports may increase the initial payload, but that will still be quicker compared to extra fetch requests for the web component.
@nostrademons is right that http2 will level the playing field for this battle... so definitely keeping an eye out for it!
You can inline your custom element definition just like you can inline anything else.
Every componentization system will require concatting to get good performance on today's web (http2 push is close but quite here yet).
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.
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?)
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.
Web Components to the rescue!
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?
Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.
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...
Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production.
With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside.
What's your hesitation?
The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into.
I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers.
Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started.
You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on.
And "no observed downside" is not strictly true if you consider the cost of added complexity.
For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
I like Babel too and the bulk of my new development is in ES6, but ubiquity is a really nice feature for development tools, probably the nicest of all.
I personally hate bindings now, apart for using them with forms, but React offers a mixin for that. What I am interested is if Polymer is worth it or not.
React (with a flux-like control flow library, such as Redux) has a higher cognitive load to start. Where it shines is as additional features are added, there is very little additional complexity. Where with Polymer (or Angular) your application as will see a curve of additional complexity as features are added.
I started a pretty basic setup for React + Webpack with hot reloading[1]. I'm going to add in Redux next, then Router... At which point I'm planning on adding in material-ui[2]. From there, I'll try to keep it updated or forked to use as a base application.
I started it off by following te SurviveJS book[3], but my direction is a bit different. I'd also recommend reading the full stack redux tutorial[4].
[0]: https://facebook.github.io/react/docs/tooling-integration.ht...
Another classic approach I've seen is to create an "<x-app>" element which contains the entire site, which also handles the various application state and binding tasks. The Polymer Starter Kit[1] follows this approach, and it also includes tools for building/minification using Vulcanize[2] and gulp[3].
[1] https://github.com/polymerelements/polymer-starter-kit
I've waited a looong time for that.
It does seem like we're getting close to being able to work on the web like I did on my Mac in 1990!
What are the actual software engineering principles Polymer enables developers to apply?
It's just a library, so it won't do magic but it's a big improvement.
Similarly for CSS selectors and class names - I mean, BEM and SMACCS and stuff are cool and all, but it's also nice to know that my CSS styles won't leak outside the component, so I can just do div class="main" or something and not worry about how other developers name their classes on other branches of the DOM.
Here is a question I asked back then: http://stackoverflow.com/questions/25856324/iterating-throug...
You'll see in the answer the complexity around dealing with children that come and go (vs in React you'd actually write it declaratively once and be down with it -- kind of interesting that Polymer has so much "templaty" stuff and is ultimately less declarative than the pure JS approach React).
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.
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.
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>;
- 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?
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.ht...
Edit: This article[1] has details on performance and styling options.
[1] https://hacks.mozilla.org/2015/06/the-state-of-web-component...
[1] - https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meetin...
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.
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?)
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.
Where is Microsoft in this adoption cycle?
And are there any incompatibility across the existing implementations, namely, Chrome, FF and now Webkit?
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.
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.
http://html5doctor.com/the-scoped-attribute/
http://caniuse.com/#feat=style-scoped
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.
New API, new implementation, or both?
The answer to CSS scoping is much simpler: CSS Modules https://github.com/css-modules/css-modules
This is true, CSS performance is better in native Shadow DOM.
Fortunately there are already polyfills for that: http://webcomponents.org/
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
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).
That's not a big deal for any one web app, but a huge deal across web development in general.
Except, it won't. They've explicitly stated they have no interest in conforming to or adapting the web components standard.
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-component... [2a]: https://dev.modern.ie/platform/status/templateelement/ [2b]: https://blogs.windows.com/msedgedev/2015/07/15/microsoft-edg... [3]: https://hacks.mozilla.org/2014/12/mozilla-and-web-components...
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.
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.