This post starts with a brief archeological retrospective on the component systems of the past 11 years to provide some perspective of where we are now, and what’s possible with modern web technologies compared to the recent past. The post starts in the pre-iPhone era of 2005 which I’ll dub 2005-BI (Before iPhone).
2005 (BI – Before iPhone)
When I started building websites back around the 2005 time frame, there were a few cutting-edge technologies that made it possible to create user interface widgets that could be created once and then dropped into any website to enhance the functionality. At the time, this collection of technologies consisted of Flash, Java Applets, and Silverlight. In 2005 these technologies were great. They closed the gap between what was possible in the browser natively, and what we as developers wanted to deliver to our end users on the web. Common use cases included things like video players or file upload controls. These technologies worked by providing a plugin model, where users would install an application on their PC (for example Adobe Flash), which would then plug into the browser. You could then create applications that ran within this sandboxed environment, where the creators of the plugin systems could establish APIs that filled the gaps that were missing in what the browser provided. To summarize, these technologies helped solve two problems:
- Encapsulation: By the nature of the plugin model widgets created in these technologies were encapsulated from the rest of the page, meaning that styles and behavior from the rest of the page didn’t leak into the controls. This made it easy to drop a control created for one site into another and have it “just-work”.
- Bridging the feature gap: Whilst it’s easy to forget in this day and age, back in the 2005-BI era there were things that you just couldn’t do with native browser technologies period. These technologies solved this problem by adding the features that were not supported by native browser APIs.
2007 – Now (AI – After iPhone)
Whilst these technologies were essential at the time, events have transpired between then and now that have made them just as extinct as the dinosaurs. Two key events leading to this include:
- The advent of the smart phones and tablets (primarily the iPhone) which refused to enable plugins. This meant that an increasing segment of users couldn’t be reached using these technologies.
- Browser technologies got better, much better. Among the changes we got ES2015+ and HTML5, which allowed us to build the kind of rich components in our web applications that previously were impossible with the browser APIs alone.
The wild west of web development
Whilst browser technologies have come along way over the past 15 years and helped solve the feature gap problem we had back in the 2007 (BI) era, up until quite recently we didn’t have a way of standard way of building encapsulated controls. Many libraries began to emerge at this point to solve big parts of the problem space. This led to more and more applications being built in pure web technologies. But until recently, if I wrote a control that I wanted to share with your website, without you making any changes to my control or your side, we’d have had a difficult time doing it.
Enter web components
Recently a new collection of technologies have evolved to help solve the problem of creating encapsulated components for the web. These technologies consist of four web specifications designed with the aim of making it easy to build encapsulated user interface blocks that you can write once, and drop into other websites, without modifying either the component block or the destination site.
These specifications are in the process of being implemented by the various browser vendors as APIs. The four specifications are as follows:
- HTML Imports which allow you to load HTML documents into other HTML documents
- The Shadow DOM which provides encapsulation of styles and markup. This is the key to creating components that you can seamlessly drop into any website. You can achieve some of the same benefits with IFrames, but while IFrames are targeted at loading external pages into your website and coincidentally provide encapsulation, the Shadow DOM is designed with encapsulation in mind, and as such has features targeted at this purpose.
- HTML Templates which provide a way of including snippets of markup within a page which are not executed when the page loads. This means for example that if you include an image tag within an
- Custom Elements provide the building blocks to create custom DOM elements that behave just like the DOM elements you use on a day to day basis in your web development projects. For example you could create an
<info-card> </info-card>custom element with child nodes, styling, and custom events, that would behave just like an out of the box element like the
- PolymerJS was created by Google as a means of sanding down some of the rough edges of the current web component implementation. It’s light weight and provides some much needed syntactic sugar to the web component APIs. I think Polymer is a great choice for creating stand alone components that you need to be able to share between a potentially diverse set of websites. It adds features such as data-binding, and easy event management, creating a far smoother developer experience than you would see using the web component APIs directly. Google recently announced that they’ve re-built YouTube on PolymerJS, which if nothing else shows that a) it’s possible to build fantastic websites on web components with PolymerJS, and b) Google is invested in this project for the long term.
- Aurelia is a single page application framework designed make it easy to build modern web applications. One of the things that continues to attract me to Aurelia is its interaction and support of the web component APIs. Aurelia applications use HTML templates, and HTML imports under the hood to implement some of the core frameworks features such as views, and template loading. Further, you can use the ShadowDOM in your Aurelia views to create components that feel like native DOM elements. Like most other modern frameworks such as Angular2, React, and VueJS you can also use polymer components within an Aurelia application. What differentiates Aurelia from Polymer is that whilst Aurelia supports the web components, it is also a fully fledged SPA framework, with features like routing, and layout management, pub-sub, and dependency injection which make it great for architecting larger scale applications.
This brings us through to the modern era, today, where we have an emerging web component specification and a set of APIs which browser vendors improve support for day by day. My prediction at this point in time is that web development frameworks with converge in some senses, adopting better support for the web component standards. I also expect that we’ll continue to see the same great amount of diversity in web frameworks that we see today where different development styles in each framework appeal to different developers. Some frameworks such as React have already started to diverge in more functional programming direction, where Aurelia and VueJS appeal to developers with an eye for simplicity. In the next post in this series, we’ll take a deeper look at how Aurelia leverages the web component APIs, and how you can use these APIs within an Aurelia project.
If you’re interested in learning more about Aurelia, check out the book.