In this article series, we will understand-
You can easily get started with progressive web app polymers by understanding all the above concepts clearly.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 are based on four main specifications that introduces you to progressive web app polymers.
The Custom Elements specification lays the foundation for designing and using new types of DOM elements.
The shadow DOM specification defines how to use encapsulated style and markup in web components.
The HTML imports specification defines the inclusion and reuse of HTML documents in other HTML documents.
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
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.