Web Component Thoughts….

The past 1.5 years I’ve been working exclusively with Web Components and specifically Polymer. The more I use this technology the more convinced I am that this is the technology I should be using. Now, I’m not saying that Web Components and Polymer are hammers and every problem/project is a nail. However it’s quite refreshing that Polymer’s goal is to make itself irrelevant. What does that mean, Polymer is there temporarily until the browsers decide upon common standards and implement those standards. Which, they’re doing. The Custom Elements 1.0 spec has been released.

As far as complimentary technology goes, I’m still a little on the fence about which technologies are the best fit with Polymer and Web Components. Redux for managing state seems to be bubbling to the top of the heap in regards to managing the state of an application. Also, service workers are core to just about all web technologies these days, especially for push notifications, client side caching and adding our web apps to a device’s home screen. Service workers do provide their own issues especially when you have to make a decision about when to surface dynamic data from the cache as opposed to from the network.

I would like to add more thought around my opening statement of why I think Web Components are the future of web development. If you think about it, web components have been around since html came about. We define a div, span, a, label, etc. to the markup and the browser just knows what to do with it. These are web components (specifically an HTMLElement or extension of HTMLElement). They are just natively incorporated into all the browsers in some form or other. With that, then why wouldn’t we create our own elements that extend HTMLElement and then we get to define our own API and markup for that element? This gets us as close to the browser platform as possible. It also allows easy integration with other APIs built directly into the browser. It’s for this reason alone that I feel that this is the technology I should be working with.

In practice I’m able to rapidly develop solutions and get them in front of a customer using elements produced in previous projects. For every element you create that addresses a problem specific to a customer, the faster you can develop solutions for that customer. Sure there are things that every customer will need, so we develop elements to meet those needs also. Fairly large element portfolios certainly help increase productivity. Also, I’m able to produce very polished applications because I put a lot of thought into what styles should be configurable inside an element and actively use themes and standard variable names for all the different colors that an application needs to look nice and be branded to each customer. Another plus is I now produce very few things that aren’t reusable. Sure, some applications have specific needs that aren’t really found elsewhere which results in a very specific element to solve a very specific problem. But we still at least attempt to make it re-usable.

So am I saying go out and re-write all your apps using Web Components? No, that would be unrealistic and pretty ludicrous. But maybe if you have a small project in the pipeline, that might be a prime target for at least trying them. I bet you’ll at least get a better understanding of what they are and where they fit into the current technology soup of 101 different frameworks and libraries.

Until next time…. Happy Coding.

Share This: