In this post I will try to summarize my highlights and takeaways from this summit. There are also a couple of links that go into deeper details for the various topics, and I will be exploring some of those topics more closely in the future, which will most likely result in more articles.
Polymer 3.0
Definitely the big announcement of this summit was the Early Access for Polymer 3.0. While not having any significant API changes, there are some major changes when it comes to getting and using (Polymer) web components:
- Instead of (the deprecated) Bower, web components and the Polymer library will be distributed via npm in the future, using yarn as package manager for a flat dependency tree with version conflict resolution.
- Instead of using HTML imports, web components will be JS modules to follow the agreed upon standards. The biggest drawback of this approach is that instead of defining your template as HTML you will need to put it into a property as a string. But this approach also enables a lot more flexibility for defining and mixing your templates as detailed below in the paragraph about template literals.
- Since there are no breaking API changes in the library itself, upgrading from Polymer 2.0 to 3.0 is really easy, just changing the way that elements are imported and moving the template to a property. And... there's a tool for that - polymer-modulizer
Template Literals
While having all your HTML in a string might seem weird at first, it actually offers a lot more flexibility than "static" HTML templates defined declaratively.
If you want to extend an element you can for example refer to
super.template and either wrap the content or insert data into the template.lit-html takes template literals to a totally different level, by offering efficient rendering and re-rendering for property changes, and a whole box of goodies like automatically waiting for Promises to resolve and updating the template accordingly. Still in development but already very promising.Links: lit-html
State Management
When it comes to building full apps with web components, managing the state across those components can be solved in a variety of ways. A simple mediator pattern, setting the properties of children in a parent element and listening for events coming from the children works in simple apps but can add a lot of overhead once you have to pass state from the root all the way down to children that can be several layers deep in the nested web component tree, and then wait for events to be passed back again.
A suggested alternative to this approach is to have a global mediator that has control over all the children directly and listens to events from all of them. This global state can for example be implemented using Redux. For Polymer there's also a Mixin that makes hooking up properties to a Redux store very easy.
Links: Redux / polymer-redux
Polymer in Production
For me personally the talks by third parties like EA, USA Today and Netflix were the most inspiring since those companies had to deal with a lot of the problems and challenges I'm facing in my daily business. Seeing how they handle their component libraries with efficiency, testability and re-usability in mind, gave me a lot of ideas how to improve our internal workflows.
Best practices
There are several things to consider when creating and using web components to make sure they play nicely with different frameworks, like how attributes and properties should be handled. Many of those best practices are already included if you are using Polymer to create your web components, but it's still a good idea to take a look at the best practices list in the new section about custom elements in Web Fundamentals.
Links: Custom Elements Best Practices / Building Components / Custom Elements Everywhere
Server-Side Rendering
While Google's search bot already is able to handle JavaScript and therefore get content from your site even if it's built using web components that need to be rendered first, several other bots and snippet fetchers will look at a rather empty page when just fetching your HTML.
One approach is to use a server-side rendering service that uses a browser engine to render the page and returns a static HTML page that can be served to bots. Rendertron uses headless Chrome to achieve just that.
skatejs takes a different approach by producing static HTML that can be read by bots, but (optionally) adding a script that will turn the static HTML back to a dynamic version for clients that support it.
Links: Rendertron / skatejs/ssr
Random collection of links
Playlist of all the talksWebPagetest - Measuring the time to until your web app becomes interactive on real devices
webcomponents.org - Almost all the custom elements you will ever need
prpl-server-node - A node server with all the features necessary for hosting PRPL apps.
youtube.com/new - Test the new Polymer-powered YouTube UI
polymer-webpack-loader - Using webpack with Polymer
wizzywid - UI prototyping tool for HTML, web components, and Polymer.
XD-MVC - Polymer elements for cross-device apps.
A-Frame - Custom elements for building VR experiences.
My photos of day 1
My photos of day 2
