Entries with tag polymer .

Do we still need web frameworks?

The past, present, and future of component-based development on the web

In my previous two posts, I’ve compared Polymer and Angular on performance and developer experience. In this final post of the series, I want to take a step back and look at how we ended up in a situation where Google has two models for building components for the web, what that means for developers today, and what the future might bring. 

A brief look at history

Polymer and Angular are perhaps more similar than you realize. For starters, both are Google projects. Both also take a component-based approach to building apps.

The Polymer project got started in late 2013 as a library and browser polyfill to help developers get started using the Web Components standards that had been introduced two years earlier. Work on Angular 2 began about a year after Polymer, in late 2014. Among the goals for Angular 2 were improved performance and a more scalable, component-based development model. Initially, the Angular team was planning to base the component model on standard components.

Angular 2 plays nicely with web components built using other libraries (Polymer, X-Tag, and others), allowing you to pass data into them as easily as if they were written in Angular. Angular components use web standards (such as shadow DOM and the HTML5 template tag) in browsers that support them., March 2015.

The Angular team later changed their position and built their own component model that is very similar to Web Components, just not tied to the Web Platform. They did this to not be dependent on the DOM. For performance reasons, they wanted to offload some of the browser work to a Web Worker, do pre-rendering on the server and support platforms other than the Web. The downside of this was added complexity — both runtime and development time.

While both Polymer and Angular have a relatively similar take on what the role of a component is, they differ significantly in how prescriptive they are. Polymer is a small library that builds on top of Web standards. Its component model scales from the use of a single Web Component on a static page to building entire applications. It includes helpers for data binding, routing, and localization, but they are all optional. There are some emerging best practices for how to structure applications, but Polymer doesn’t force any of them on the developer.

Angular is the enterprise Java of front-end frameworks

Angular, on the other hand, is much more opinionated. It’s also more than just a framework; it’s a platform of its own. Angular is the enterprise Java of front-end frameworks. It provides enterprise developers the tools and patterns they are used to when building complex apps. It has support for routing, dependency injection, localization, pre-rendering and testing. It gives developers a well-defined way of structuring their apps and dealing with data flow, removing a lot of the uncertainty from building an app.

Why is Google building both Polymer and Angular?

Why is it then that Google has these two separate projects for building component-based Web applications? Wouldn’t it make more sense for Angular to use Web Components as it’s component model? After all, that’s what the Angular 2 team tried to do at first, right?

I think that Google’s end goal is to make the Web as attractive as it can be for app developers. The Web is after all where they make their money. 

One of the obstacles they identified was that the Web needed a component model to support the building of more complex applications. They needed a quick solution, so Angular 2 was created with its own component model. 

Meanwhile, Google worked with the W3C and other browser vendors to pass standards for adding a component model to the Web platform itself. The standardization process is slow, so they created browser polyfills and the Polymer library to help developers get started using the upcoming features.

By having both Angular and Polymer, Google can offer a way of building component-based Web apps in the short term while working on a more elegant solution for the long term. It wouldn’t surprise me if future versions of Angular moved over to use (or at least support) Web Components when browser support is universal.

Community engagement

When it comes to community size and engagement, there’s no question about which one is more popular among developers. Angular has become one of the most popular web frameworks over the last five years, while Polymer and Web Components have remained a very niche technology.

Google Trends for Angular (blue) and Polymer (red) over the last five years.

Polymer is mostly aimed at component developers. The fact is that Web Components alone are a too low-level construct in most cases when building complex apps. Developers want more structure and help, which means that they are looking for frameworks when building larger applications.

Angular’s popularity also means that there is much more community-generated documentation, courses and other learning material available. You are also more likely to find answers to your Angular questions on Stack Overflow and similar sites. For developers looking for a well-established tool for their next project, especially if they need to get buy-in from their management, Angular looks more appealing at the moment.

Paving the way for the next generation of Web frameworks

Looking at the developer adoption of Polymer and Angular makes it fairly evident that developers want to use frameworks when building apps. The way I see it, Angular represents the current generation of Web frameworks while Polymer is paving the way for the next generation.  

Building on Web Components, future Web frameworks can be built leaner and faster as they no longer need to build and run their own component models in the browser. The shared component model also means that frameworks can be made more modular. Some projects only need a router; others may additionally need dependency injection, localization or a testing library. Being able to choose only the parts you need will make development easier and the end user experience faster.

While Web Components are a very powerful concept, I think their biggest impact for most developers is that they are paving the way for a new generation of faster, more light-weight frameworks and tools — a future where every new framework doesn’t need to build its own component set.

Comparing Polymer and Angular from a developer’s perspective

In my previous post, I showed that Polymer has a significant performance advantage over Angular. If you are trying to make your app fast (you should be), you are probably wondering if it would make sense to build it with Polymer.

The potential problem with building an app with Polymer is that Polymer was not initially designed for building applications. It’s a library to help developers work with Web Component APIs (think jQuery for the Web Components APIs). 

Fortunately, the component-based development model offered by Web Components is flexible enough that you can build complex applications using the browser as your framework. But while it’s possible to create complex apps with Polymer, it’s still missing the structure and guidance a framework gives you.

In this post, I will compare the development experiences in building the same application in both Angular and Polymer.

Tools and languages

Both Angular and Polymer come with command-line (CLI) tools that help developers set up and build projects. The CLI tools hide much of the complexity of the build process: taking care of things like transpilation, optimizing and bundling code for production. The Angular CLI additionally (and optionally) performs an Ahead-of-Time (AOT) compilation step to reduce the amount of JavaScript processing that is needed in the browser. 


Since Polymer is based on Web standards, components are built with HTML and JavaScript. In Polymer 2 and later, the default language level is ES6, which will get transpiled down to ES5 by the CLI to support older browsers. 

A simple Polymer component.

Polymer is still fairly limited when it comes to IDE support. The Polymer team is working on improving that through the Polymer IDE plugin that can be used with editors like VS Code and Atom. The Polymer IDE plugin helps developers avoid common mistakes, and offers some autocomplete help. Because Polymer uses plain ES6, there are no type checks.


Angular supports development in TypeScript, JavaScript, and Dart. Most documentation and examples that are available online are using TypeScript, which is the de-facto language for building Angular apps. TypeScript is a superset of JavaScript that adds type checking. Type checking gives developers an added layer of checks on the code and can be helpful to ensure APIs are used correctly, especially when working in bigger teams or when using third party libraries. 

A simple Angular component. 

The use of TypeScript in Angular also makes it easier for IDEs to offer development time help and checks. Visual Studio Code and WebStorm both have good support for TypeScript, the latter even helping the developer with including imports, making Angular development in an IDE fast despite the amount of boilerplate.


Debugging Polymer applications is straightforward. You can use the browser developer tools to set breakpoints and inspect the running code just like you would with any other front-end technology. 

Most often, debugging the Angular app boiled down to a series of console.log statements

Angular is much more complex to debug due to the build steps between your code and the code that is running in the browser. The Angular CLI build creates source maps that should allow you to debug the TypeScript code in the browser. In practice, this didn’t work well as the source maps didn’t match the running code and breakpoints didn’t work. There is also a Chrome plugin for debugging Angular apps called Augury that allows you to inspect the hierarchy and status of your components. I did not find the plugin to be very useful in pinpointing issues. Most often, debugging the Angular app boiled down to a series of console.log statements. Error messages in the browser console were cryptic, and stack traces rarely include identifiable code, only Angular internal calls. 

Application structure and routing

Since both Angular and Polymer are component-based, the general application structure is similar. The UI is constructed out of components that get combined into successively more complex components, which are nested until an app emerges. In Angular, you can additionally bundle related components into modules that are used to scope dependencies, and that can be loaded lazily when needed.

Larger applications are organized into views. The views are typically bound to URLs so that users can link to different parts of the application and use browser navigation buttons to move back and forth. This mapping between view components and URLs is handled by a router. 

Angular ships with a somewhat complex but feature-rich router that supports arbitrarily deeply nested routes. It helps the developer keep the application’s JavaScript size manageable by lazily loading code for modules that aren’t needed until later. It further allows routes to be equipped with Guards, code that is run before or after a view gets activated, to conditionally prevent navigation. The router is configured in a TypeScript file through nested objects.

Polymer ships an optional router that can be used to map between URLs and components. Using the router requires several steps and a lot of repetitive code. You need to add an app-location and anapp-route element to your app to listen for URL changes. Using this information, you can decide what components to show, and optionally (manually) hook up lazy loading of those components. 

By default, Polymer components are only lazily loaded into the DOM, but not removed. This leads to the DOM growing over time in large applications which may result in performance issues, especially on devices with limited memory. 

The lack of a good router is the single biggest factor making it difficult to build large applications in Polymer

The Polymer router also supports nested routes. In practice, however, using nested routes gets very complicated as the router doesn’t know which view is active so sub-routes will get triggered on all views regardless if they are visible. The router does not either hook up to the build tools, so you need to separately configure views for lazy loading. 

Based on my experience, I feel that the lack of a good router is the single biggest factor making it difficult to build large applications in Polymer. 

Working with data

Data binding and data flow are important aspects of building apps. One of the functionalities that Polymer provides on top of the Web Components standards is a simple data binding system that supports both one-way and two-way binding of data. One-way data binding is preferred over two-way binding to make it easier to integrate the components with other frameworks and to enable uni-directional data flow patterns like Redux.

Angular also comes with support for both one-way and two-way data binding. In addition to data binding, it also comes with a Dependency Injection (DI) system that makes it easier to hook up services, especially when testing. Angular builds heavily on RxJS and Observables for handling data, especially for asynchronous HTTP communication. The reactive programming model will take some getting used to if you don’t have experience from before, but enables you to build elegant UI code. 

Editing data in forms is somewhat different in Polymer and Angular. Polymer has a form element that extends the HTML form. All validation is handled by the form elements themselves, which is a bit limiting at times. In Angular, the validation is handled by the framework which makes it easier to combine different components but still have consistent validation.

Making it look nice

When it comes to customizing the look and feel of your app, Angular is much easier to work with than Polymer. Angular works together with existing CSS libraries like Bootstrap or Semantic UI and you can easily write global CSS to give your app a cohesive look. 

Polymer is harder to customize in terms of look and feel because Web Components are designed to encapsulate their implementations, which means that you need to declare CSS variables and mixins that you import in your components. This means that you cannot use something like Boostrap easily and that it’s hard to get third party components fit your applications look and feel. 

Angular also makes working with dynamic styles easier than polymer, as the template syntax includes a helper for setting style names based on a condition. In Polymer, you need to rely on basic data binding and custom methods which adds a lot of boilerplate.

Mobile support: Progressive Web Apps, native apps, or both?

Angular and Polymer have different approaches when it comes to mobile support. Angular is more focused on today’s needs, so it includes support for building both Web applications and native applications (although native support requires you to write a separate implementation of the view). They also added support for creating Progressive Web Applications (PWA) recently. 

For Polymer, PWA is the only mobile strategy. This is in line with Polymer’s goal of building on Web standards to expand what you can do on the Web. 

Maintainability and stability 

Angular and Polymer both have a less than stellar track record when it comes to API stability. Polymer had a very rough transition period leading from version 0.5 until 1.0. Likewise, Angular 2 went through an extended period of API changes during development, lasting throughout the release candidates. There have even been some smaller breaking changes within the “stable” 2.x version. 

The good news is that both teams have taken note and are planning for smoother upgrade paths in the future. Polymer 2, currently in release candidate, includes support for legacy components so you can migrate applications piece by piece. The Angular team has also promised that breaking changes in Angular 2+ will be easier to migrate, and have hinted several times at a migration tool to streamline the changes.

While it’s hard to predict the future, I think that Polymer and the W3C standards it builds on will provide a more stable foundation for apps that need to be maintained for longer periods. 

Choosing development comfort over performance

We know that Polymer allows us to create fast web apps. But it turns out that Polymer by itself is too low-level to easily build big applications. There is clearly still a reason developers are selecting a framework like Angular instead of Polymer. Frameworks help developers structure applications and take care of things like routing, dependency injection, localization and other things you need to deal with when building a large application. Unfortunately, this developer convenience comes at a runtime performance cost to the end user. 

A good first step towards making Web Components suitable for building bigger and more performant apps would be an improved router. It would both help to give structure to apps and make it easier to create apps with tens or hundreds of views.  

In the last post of this series, I’ll take a look at why Google is working on two competing component-based tools for building web apps and what it might mean for the future of Web frameworks. 

Stay tuned.

Reinventing the Data Grid

A Data Grid is one of the most commonly used components in business apps. It must also be one of the most complex components to implement. There are many aspects that you need to get right – customizability, performance, usability, cross-platform support, just to name a few.

Vaadin has years of experience in building components like data tables and grids for business apps, and specifically, the Vaadin Elements team has been developing and maintaining Polymer-based Web Components like <vaadin-grid> for about two years now.

A year ago, I was looking into <iron-list> – a powerful list component built by the Polymer team, which helped me realize how expressive and user-friendly HTML templates can be in Web Components for defining customized, repeating structures like lists. Using declarative HTML is a natural way for any web developer to define contents of tables as well. So, I started to think if templates could be used to build a data grid element.

At the end of January 2016, I started experimenting and building prototypes around <iron-list>. The main goal was to validate two things: what is the user’s preference in using templates over the existing patterns and how could the column templates be technically implemented so that people would be able to style and access the contents of the cells while keeping the internal structure of the table encapsulated inside a shadow root.

As a result of the experiments, <iron-data-table> was produced. During the following months, it quickly gained many of the features you usually expect to find in a data grid. As the template approach kept gathering positive feedback, I wanted to introduce the idea to my colleagues at Vaadin.

After discussing our options, we decided to implement the <vaadin-grid>2.0 based on templates.

.     .    .

Today, with the lessons learned from <iron-data-table> and with the help of the whole Vaadin Elements team, we are really moving forwards in getting <vaadin-grid> 2.0 ready for release.

Almost a year after the first experiments with the templates, we are really excited to release the first alpha version of <vaadin-grid> 2.0.

Feature-wise the alpha is in most parts already more advanced than its predecessor, but there are still some missing pieces we will implement before entering the beta stage early next year.

Here are the highlights of some of the most important features — you can take a look at the release notes and live demos for more details on v2.0.0-alpha1.


Extensive Customizability


Templates allow you to declaratively define how property values are displayed, to have dynamic content based on data, edit values using two-way binding and add event listeners to any element inside the cell.

More specifically, the templates in <vaadin-grid> allow you to change the selection state of items, display item details, and edit data items easily.


See the live templating examples for more details.


In addition to having full control over the contents of the cells and their styles, you can also use a variety of different CSS mixins to apply custom styles to the cells to make the grid fit in nicely with the design of your app.

There are different mixins targeted for the header, body and footer cells and also, there are mixins for the body cells having different states like selected or active.

Here are some examples to give you an idea of how versatile the mixins are:

Material Design


Dark Theme

.     .    .

See the live styling examples for more details.


Powerful Data Rendering

As <vaadin-grid> is based on <iron-list>, it uses a similar virtual DOM structure to render and reuse row and cell elements. In practice, the number of elements in the DOM is not increased by the number of items bound to the grid.

We’ve paid extra attention to making sure the scrolling experience is silky smooth in all major browsers and mobile devices and continue working on improving it.

The rendering engine has been extended to also support lazy loading by introducing the function dataSource, which you might already be familiar with from the first generation of<vaadin-grid>. The function data source allows you to feed items from a remote service, asynchronously, or for example from a generator function.

One unique feature of the improved rendering and scrolling engine is the fact that there in practice is no upper limit for the number of items.



Empowering Helper Elements

Although the templates are powerful and allow you to do virtually anything inside the cells, there are some commonly used patterns that can be quite complex to implement. We recommend encapsulating any repeating pattern into a reusable custom element.

We are currently shipping <vaadin-grid> with helper elements for providing multi-selection, filtering, and sorting.


.     .    .

See the live filtering and sorting examples for more details.


What’s next?

The focus at the beginning of 2017 will be on adding missing features like keyboard navigation, accessibility support, column reordering and resizing.

The current plan is to release the 2.0 stable as a Polymer 1.x element, but a Polymer 2.0 compatible element will also be released later.

We are also going to publish articles about the interesting things we have learned and will learn while building Vaadin Elements — topics including at least Polymer’s Templatizer, custom overlays, accessibility and testing.

As always, all feedback is highly appreciated – the fastest ways to get in touch with us are through Gitter or GitHub. You can also follow our progress in our Waffle board.


Originally published in

— 3 Items per Page
Showing 1 - 3 of 6 results.