UI Roundup 2017: Polymer

Two years ago, Polymer looked like an equal competitor to AngularJS. At the time, it wasn’t clear which one would win the race. Truth to tell, it’s not clear today. The JavaScript world is incredibly volatile and capricious. But the numbers I collected clearly indicate Angular (nowadays without JS) is much more important. At the same time, they indicate that Polymer is here to stay.

It’s just a library!

They say Polymer is just a library. In other words, it’s much less intrusive (for want of a better word) than a full-blown framework like Angular or JSF. Angular cares about every aspect of your program. Polymer has a much more limited scope. It offers a couple of tools like components and functions. It’s up to you how you’re going to use them. Angular forces you to adopt a particular programming style. Polymer does not, they say.

Thing is, that doesn’t exactly match my first impression. Maybe the first example my co-worker showed me wasn’t a typical Polymer application. But my first impression is that Polymer nudges the programmer into a particular direction. Historically, Polymer started in 2013 as a polyfill for web components. So it’s no surprise everything Polymer offers has something to do with web components. No matter what you want to do, you have to use a component to achieve your goal. That’s fine as long as we’re talking about visual components like tables or input field, but it also applies to non-visual stuff like AJAX calls.

Polymer component library

There’s a catalog of web components build with and for Polymer. Some of these components are visual, others are not.

The visual components are more or less what you’d expect. There’s everything you need to write a business application: input fields, drop-down menus, and so on. All of these are based on Material Design. That’s nice in that it’s very easy to write attractive applications. It’s hard to do it wrong. That, in turn, was one of the design goals of Polymer. It’s meant to build bridges between designers and developers.

The layout components make this even simpler. Polymer offers predefined components for typical application layout elements, such as toolbars, menus, headers, and grids.

Excursion: comparison to Angular, JSF, or Swing

At that point, it may be interesting to compare Polymer to other frameworks like Angular, JSF, or Swing. After all, that’s precisely what the UI roundup series is about: comparing frameworks to each other. In a way, Polymer strongly reminds me of Swing. Like Swing, it focuses on components, and it tries to cover every aspect of programming with a component. But it doesn’t encourage you to write your own component. Of course, you can write your own component, and it’s much more simple than it used to be to write a Swing component. But by default, Polymer applications are not built around user-defined components. They are built using existing third-party components.

That’s an interesting difference to Angular. Angular applications are all about writing your own components. You can’t avoid it. And the Angular team managed to make writing components very simple. In a way, it’s funny I’ve missed precisely that feature in Polymer. I’ve never missed it in JSF, Swing or SWT. It’s just the way we always used to do it. The vast majority of programmers simply use pre-defined components, with only a small elite of advanced programmers writing components. There’s nothing wrong with this approach. It just shows that the Angular team did a great job making writing components more democratic. JSF tries to reach the same goal with the custom components. That’s a less powerful approach than Angular’s approach, but it very popular. Obviously, developers want to write components.

Non-visual components

Polymer is all about components. So it’s not surprising even behavior is implemented a component. For instance, there’s an AJAX component. Actually, there’s more than one, but let’s focus on the most popular component:

<iron-ajax
    auto
    url="https://www.googleapis.com/youtube/v3/search"
    params='{"part":"snippet", "q":"polymer", 
             "key": "YOUTUBE_API_KEY", "type": "video"}'
    handle-as="json"
    on-response="handleResponse"
    debounce-duration="300">
</iron-ajax>

In this example, the property ajax has been set. So the component triggers an AJAX event whenever its URL, params or body are changed. When the response arrives, the method handleResponse is called.

That’s a great component. It makes AJAX really simple. However, it requires a mind shift. I, for one, prefer to express the static aspects of my application in a declarative way, while expressing behavior in a programmatic way. There’s nothing wrong with the Polymer approach, but it reminds me of the old saying that everything looks like a nail if your only tool is a hammer. In the case of Polymer, the “only tool” is using a third-party web component.

Programming style

The first few Polymer applications I saw embedded HTML, CSS and JavaScript into a single file. This pretty much shows the philosophy of Polymer: the application is centered around the HTML code, and it’s augmented by CSS and JavaScript. It goes without saying that you can extract your CSS and JavaScript code into separate files. Just include them using <link rel="stylesheet" type="text/css" href="..."> and <script src="..."/>.

Again, that’s an interesting difference to Angular. Polymer is meant to be more light-weight than Angular. As a consequence, it follows the traditional programming style more closely. Angular, in turn, simply does it the other way round. Everything is centered around the TypeScript components, and the HTML code is included with the TypeScript component.

What about TypeScript?

Talking of which: what about TypeScript?

Well, I didn’t see any native support of TypeScript yet, but you can generate the JavaScript files imported by the Polymer application using TypeScript (or Babel, or whatever). That doesn’t sound like the plain vanilla solution working out of the box, but it should do the trick.

Integrating Polymer with Angular

Originally, I considered Angular and Polymer competitors. So I was pretty astonished to see that there’s a project on GitHub aiming to integrate both frameworks. Come to think of it, it shouldn’t be a surprise. Angular care about the structure of a program: How to organize a program into useful entities such as components, directives, pipe, modules, and so on. Polymer focuses on delivering components. That’s more or less orthogonal to Angular.

However, on second glance thing didn’t look quite as good. When I tried to use the Angular-Polymer, I was taken aback by the amount of configuration you need to use Polymer in an Angular application. The integration works, but it doesn’t look like a love match. Come to think of it, there are many sources of problems. In particular, the life cycle and the event handling of an Angular application are different from the life cycle and the events from the polymer application. Adding insult to injury, the Angular-Polymer project wasn’t compatible with the current version of the Angular CLI when I experimented with it. Chances are that the problem has been solved in the meantime.

If you’re interested, have a look at Angular-Polymer.

Responsive design

Do I really have to mention this feature in 2017? Like almost every other modern framework, Polymer is responsive. Polymer implements Material Design, and responsiveness is one of the core features of Material Design.

Wrapping it up

If I’m not mistaken, Polymer has roughly 10% percent of the market share of Angular. That’s not much, but it’s not little, either. My guess is that Polymer is here to stay. Plus, it’ll continue to give important ideas to the broad JavaScript community. Plus, it’s the reference implementation for Material Design, which makes using third-party integration such as Angular-Polymer even more interesting.

Leave a Reply

Your email address will not be published.