ebidel

Yes and no. In some cases (3rd party content that you don't control), there's no way to know what script/iframe is going to do/use. For example, ads script that uses `document.write()` and kills perf.

Turning on certain policies can also help you be certain quality/standards are being met across your site. For example, the creative team forgets to optimize images and you end up shipping many more MBs of images than actually needed. The `image-compression` feature policy could be used as a gut check to make sure that never happens.

full example of screenshoting a DOM element:

https://github.com/GoogleChrome/puppeteer/issues/306#issueco...

Make sure you're using Chrome 59. If you don't have that yet, try Chrome Canary.

It's just a bug :) https://news.ycombinator.com/item?id=14240460

As noted, you'll need the --disable-gpu flag for now. Hopefully that will go away around ~Chrome 60.

See

- https://bugs.chromium.org/p/chromium/issues/detail?id=546953...

- https://bugs.chromium.org/p/chromium/issues/detail?id=695212

FWIW, we created the Github issue tracker b/c it's a bit more approachable for everyone. Github is also a much better place for discussions.

Windows support is coming. You can follow along at https://bugs.chromium.org/p/chromium/issues/detail?id=686608

If your app uses a huge amount of code, then yes. But that's really the fault of the app developer. Not the library.

What developers often do is pull in a ton of components from the web components catalog and not realize that every component comes with a cost. It's no different than working with libraries. Know the tradeoffs.

There are plenty of examples of fast rendering apps that written with Polymer. Check out https://shop.polymer-project.org/ and https://www.chromestatus.com/features, to name two.

https://ebidel.github.io/polymer-experiments/polymersummit/f... is another example that shows how to utilize the "upgrade" feature [1] of the custom elements API. IOW, the browser can render markup without JS ever running. Unfortunately, this is not something that Polymer leverages very much. It requires more work and is less friendly to new developers.

[1]: https://developers.google.com/web/fundamentals/getting-start...

Also relevant: "Cache-Aware Server Push (Client Side)" https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mv...

The Chrome team is hashing out potential solutions to the server push <-> browser cache problem.

In using shadow DOM, one thing that's become clear is that it is a developer productivity tool (built in the browser).

With React, you have to use inline styles (https://facebook.github.io/react/tips/inline-styles.html) or a build tool to modularize/prefix CSS selectors (e.g. CSS Modules). Inline styles can muck with specificity and tons of inline styles can actually force the browser to do more context switching than necessary (HTML parser <-> CSS parser). Mind you, the latter is unlikely to actually be a perf issue in a real app.

In shadow dom, you just write CSS. Write simple selectors in a `<style>` or a stylesheet, the browser automagically scopes the selectors to the component, no tools required. Shadow roots also prevent outer styles from cross the boundary and leaking in. That one is particularly tricky without help from the browser.

As for perf...

In theory, the browser can optimize work (style recalcs, layout, paint) in shadow trees b/c the DOM is local.

However, generally there's a lot of low hanging fruit still to look at. Browser engines have been optimized for global css so those paths are super fast right now. https://bugs.chromium.org/p/chromium/issues/detail?id=314303 is a good example of the work that can be done (now fixed in Blink):

> Being inside a ShadowRoot disables lots of optimizations we have for the normal document. Authors also use ShadowRoots differently than the main document (ex. hundreds of tiny identical sheets in each Shadow instead of one really big one in the document) so we should consider those use cases and how we can handle them better.

> We should be able to get much faster. This bug tracks the many efforts to make recalcStyle faster in ShadowRoot (and by extension Web Components)

Another thing Blink does is optimize `<style>`s so they're shared/cached across instances of a component (as long as their `.textContent` is the same). That was a pretty big speed up in Blink.

Non-comprehensive list of Google properties and Chrome-team efforts using: https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%...

Obviously doesn't include stuff in the works :)

Polymer itself is 47KB. If you add the web component polyfills (16KB), that's 63KB minified and gzipped. I tend not to consider the polyfills because they're not Polymer and are a stop-gap that goes away over time.

Perspective is important :) Putting 1000 material design inputs on a page isn't something a sane web app would do. The same is true for a native app.

Re. "bloat" of components. I think it's important to remember everything something like paper-input is doing for _you_. As a developer, I no longer have to think about: validation, animations, a11y, keyboard, knowing all the MD spec configurations, labels, underlines, colors, fonts, typography, margins, composability, x-browser interop,... Sure, if you were implementing your own input, you could cut corners and/or leave out what you didn't need. However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.

MS: https://dev.modern.ie/platform/status/shadowdom/ "we intend to begin development soon"

FF: https://bugzilla.mozilla.org/show_bug.cgi?id=1205323

Yep, service worker is amazingly powerful!

FWIW, Chrome has a bug where SW doesn't intercept URLs changed using history.pushState(). If you're using the web app in Chrome 40, turning off wifi and navigating the site will show "blank pages". However, refreshing the page you land on does will work as expected while offline.

Good news is that it has been fixed in Chrome 41...coming soon! https://code.google.com/p/chromium/issues/detail?id=429972

It's still behind the web components flag in FF nightly. The master bug for web components is: https://bugzilla.mozilla.org/show_bug.cgi?id=811542

Beers!

It's 100% bizarre to think about elements that don't render UI. Honestly, I'm still wrapping my head around it.

If you think about it though, there are plenty examples today that don't render UI (directly) but serve a specific purpose: <script>, <meta>, <html>, <style>, <head>, <title>, <link>, ....

Search for "display: none": http://src.chromium.org/viewvc/blink/trunk/Source/core/css/h...

Interesting times indeed.

These are legitimate concerns to have. There are many new technologies at play in this space and a lot of new concepts.

> What really remains to be seen is whether this reduces or increases complexity.

One word: scoping

This is an important concept in software development that we've severely lacked on the web. We're used to creating global documents of HTML, CSS, and JS and hoping it doesn't explode. Frankly it's a mess. I'm surprised we've put up with it for so long! The technologies behind web components (Shadow DOM and Custom elements in particular) empower us web devs to be good developers. That is, we can take advantage of patterns like OOP: compartmentalize and scope functionality to a particular problem space.

CSS/DOM encapsulation is an added benefit to tell this story. As a developer, I no longer have to hunt down what CSS is effecting my page. I just look at the element's definition.

The hope with all of this stuff is that there's less re-inventing the wheel and more productivity. Scoping takes us to this happy place. Unlike most new web platform APIs, the web component APIs are purely about developer ergonomics. It's about your productivity. That makes me super happy...both as a web dev and someone who teaches web devs.

> Like Addy points out ("not a silver bullet") performance, security,...

Nothing in web development is a silver bullet :) A best practice today may be an anti-pattern tomorrow. However, with components, we have the opportunity to bake in more for free. For example, accessibility is low on people's radar. If a component set takes care of the details for me, I'm a happy camper.

Nothing changes in regards to security. In fact, the API specs leave it out entirely. When people hear "encapsulation", they automatically think security. IMO, it's better to think about components as "scopes".

> ...one of Polymer's example components was an Ajax call, which I suppose you can fire from the script. Is that really better than putting the ajax parameters in the code?

Web components allow us to rethink what HTML can be; what it can do. We have to unlearn years (possibly) decades of assuming that HTML can provide no useful API. When given a declarative vs imperative API, I suspect 9/10 developers will go the declarative route. It's unquestionably easier.

`<polymer-ajax>` is a good example of providing an a hybrid. It defines an imperative API on its DOM interface and a declarative one by configuring it through attributes and listening for events. Is the declarative route better? Perhaps. The point is that it encapsulates the details of using XHR. I'm excited to never NEVER write that boilerplate XHR code again.

Ajax is also a trivial example. The cognitive load of being a web developer is oftentimes too high. You can imagine more complex APIs and libraries (webrtc, webgl, etc) being offered as declarative custom elements. A declarative option makes those underlying technologies more convenient/approachable to others.

> Does it encourage "globals"-like behavior, where hidden dependencies crop up?

Components encourage the opposite. When used correctly, HTML Imports provides the necessary dependency management. If an element requires script x and element y, those deps can be included/bundled as an Import for the component.

> Are there life-cycle behaviors to the Ajax component that might trigger the request at surprising or frustrating times?

There's nothing stopping component authors from shooting themselves (or their users) in the foot. It's my hope that well-written components will surface to the top of the stack. If a component is naughty, no one will use it.

Can you explain why it feels heavy? I would love to know more.

Polymer's entire stack is a la carte:

* platform.js - polyfills if you just want to use vanilla web component apis, today

* polymer.js - build declarative custom elements that use data-binding, touch, property observation, inheritance

* elements (ui/non-ui) - if you don't want to write any code at all :)

Sugaring libraries like Brick and Polymer that sit on top of the native web component APIs will, of course, be opinionated and do things a bit differently. However, the workflow for consuming components will be similar across the board. Something like `bower install brick-carousel polymer-tabs`. Then use the elements in your pages.

It's a common misconception that Shadow DOM is required to create a "web component". What it brings to the table is style and dom encapsulation. Not using it means components won't have those benefit (by default), but there's nothing stopping people from creating custom elements that are not encapsulated.

An analogy can be made to requestAnimation. raF isn't required to create animations, but it's highly useful in that context. raF can also be used for other use cases outside of animations (scroll effects, etc). Shadow DOM is the same IMO. It's a useful standalone technology, but when used in the context of web components, it really shines.

Adding powerful new APIs to the web platform benefits more than just Angular, no? The set of evolving standards-based technologies behind "web components" (templates, Shadow DOM, HTMLImports, custom elements) can be utilized by any framework. More tools in our toolbox.

The Custom Elements[1] and Shadow DOM[2] specifications have little to do with each other. The former is useful for defining new elements in HTML, along with properties and methods. The latter can be used to encapsulate the style/dom of that element's internals. So each technology is useful by itself and can be used standalone. When used together, that's when magic happens :)

[1]: http://w3c.github.io/webcomponents/spec/custom/ [2]: http://w3c.github.io/webcomponents/spec/shadow/

See my post [1] on SO on "Polymer elements (e.g. web components) vs. Angular directives". Essentially, Angular directives allow you to create new elements in HTML. That's done through JavaScript because the proper API primitives haven't existed in the web platform to create components. Now they're getting built in via Custom Elements, Shadow DOM, etc. Frameworks also win because they can leverage these new APIs.

[1]: http://stackoverflow.com/questions/18089075/what-is-the-diff...

Thanks for the heads up. Fixed through the magic of PRs! https://github.com/Polymer/docs/commit/1b9f0c361f84ce0157a13...

The foundational layer goes away over time. Everyone's app gets better/stronger/fast :) The opinionated sugaring layer on top of Web Components (the Polymer layer) won't go away.

That said, one goal is to have a continuous feedback loop with standards bodies to get things spec'd out if it makes sense to add them to the web platform. Similar to how querySelector landed after jQuery made it "a thing".

Correct. In that example, the value attribute is bound to the element's age property. Basically, anything in {{}}.

> <input value="{{firstName}} {{lastName}}">

This will work as you expect (http://jsbin.com/ecejiy/6/edit). Plus, if either of those property values change, the input.value will be updated accordingly.

By the way, you can also add/define your own syntax for MDV bindings: https://github.com/Polymer/mdv/blob/master/docs/syntax.md

Dart's Web UI is built on top of Web Components. At least in the case of Polymer and Dart, Web Components are the "framework" :)

Data binding happens at the property level. For example, you can remove the id/for attributs from those elements and things still work correctly:

http://jsbin.com/ecejiy/2/edit