Polymer And PWA: Understanding The “Why” — Part 1

In this article series, we will understand-

• A brief history of the evolution of web
• The drawbacks of the current state of web platform?
• How web components proposes to solve those issues?
• How Polymer fairs as a web component library and a lightweight frontend framework?
• The out of the box support for PWA and other performance best practices polymer provides

You can easily get started with progressive web app polymers by understanding all the above concepts clearly.

The creation of HTML & JS

HTML was created to share documents over the network. It supports three features mainly, i.e. display text, images, and interlink with other HTML documents. Everything was pre-created and servers distributed only static HTML pages. Below is the image of a typical browser from the 1990s.


Then they wanted to programmatically control HTML and add behaviors to HTML and browser. Hence Javascript was created.

Evolution of browsers

Web servers started to serve dynamic content unlike the static contents before. This lead to HTML spec evolution. Browsers started sending data to servers via forms and then AJAX. 

Browsers got more powerful as Javascript spec progressed. We got to a stage called WEB 2.0 where we started doing complex business logic processing at frontend. Patterns for development emerged and grew into libraries and frameworks. This has emerged polymer as an important library for building a progressive web app from scratch.

Framework Wars

There were a lot of competing frameworks to enable the complex frontend apps. Each had their own set of philosophies and build tools. This was essentially the web performance race with every new framework/version improving upon its predecessors. But, creating progressive web apps with polymer supports modern enhanced web platform.

Where is the web platform today?

We are cluttered and fragmented with frameworks. Each one has a twisted philosophy of performance and has laborious (automated yes, but try tweaking them) build process. All of this is a workaround on how the platform is today.

What did we lose?

Interoperability: We can’t use components built in different frameworks together with ease. Imagine if you are a big organization and your departments would have a lot of similar looking UI with slight modifications. Now, each department would choose their own framework to build the UI. As an organization, we can’t leverage the work of other teams.

Simplicity: We are all aware of the term javascript fatigue. There is so much churn in the frontend world each day that we have to make ourselves familiar with so many things. Each framework enforces its own abstractions of concepts and architecture that your skills are not transferable. You need to be a seasoned engineer to switch between frameworks and write near-perfect code. Others would have a steep learning curve and might take time picking up best practices.

Things we didn’t anticipate

When the frameworks came out they were mainly run on desktops and laptops. No one thought about the mobile web. Most frameworks are too heavy to run on mobile. The parse, compile, execute and render would put a huge load on the mobile CPU. But the computational power on mobile is limited. They don’t have big heatsinks like desktops. Without a heatsink, there would be an upper limit on the processing power of a mobile CPU.

Mutation of HTML

                                                                       This is a screenshot of Youtube webpage HTML code

In the Image above we can see how a typical HTML looks like for any website today. I call that built with <div> soup.

                                                                                                          Div Soup

It is common to see code like <div class=”tree-control”> where the behavior of tree control is forced on to a scaffolding HTML element div.

                                                                                                   Forced Behavior

HTML moved away from original purpose and capabilities. HTML was not meant for Web Apps. All it was supposed to do was have the ability to display documents over the network and link to other documents (https://www.w3.org/History/1989/proposal.html). So the frameworks that exist today are a workaround on the way the platform evolved and trying to do things which were not supported by the original vision.

Time to redesign the HTML/Web

                                                                 This is a screenshot of YouTube written with web components

What if we create a element <tree-control> instead of writing <div class=”tree-control”>. That would be an easy and natural to understand. It puts the information where it belongs and preserves the semantics.


But <tree-control> is not a default HTML element. How would browser parse it? Well, web components are the answer to that question.

Web Components

Web components are based on four main specifications that introduces you to progressive web app polymers.

Custom Elements

The Custom Elements specification lays the foundation for designing and using new types of DOM elements.

Shadow DOM

The shadow DOM specification defines how to use encapsulated style and markup in web components.

HTML imports

The HTML imports specification defines the inclusion and reuse of HTML documents in other HTML documents.

HTML Template

The HTML template element specification defines how to declare fragments of markup that go unused at page load, but can be instantiated later on at runtime.

( Intro on web components borrowed from https://www.webcomponents.org/introduction )

In simple terms, web component allows you to define your own HTML tags, enables you to define blocks of markup with the ability to inject dynamic content, gives you the ability to scope/encapsulate markup and styles in a separate DOM tree and provides a way to include and reuse HTML documents in other HTML documents.

                                                        You might say, hey!! popular frameworks already do something like that!

You might say, hey!! popular frameworks already do something like that! So let me take a look at the diagram below to understand the difference


Your typical frameworks operate at the Javascript level, which means when you insert your template into the page it parses the HTML, identifies if a definition for <tree-control> is present. if so it takes control of it and handles its lifecycle and its DOM activities. All of this is not native. So there is only so much performance optimization it can give us.

Whereas when you use web components we tell the browser what to do when it encounters a <tree-control> tag. We describe its life cycle to the browser. The browser is informed of the DOM manipulations. So what happens here is that browser is in control. It runs on a native layer which means that it will be faster than what frameworks do. This gives your web pages a default win.
Hope this Progressive web app polymers tutorial helped you to understand the basics of Polymer and PWA.

In the next part of the article, we shall explore Polymer, a javascript library that helps you create custom reusable HTML web components and all benefits that come with it.