Jarrod Overson - Developing Web Components: UI from jQuery to Polymer

• 2015-02-06: First Release

Web development has not stopped evolving since I stumbled into the field over 13 years ago. If anything, the rate at which it is evolving is increasing. If you take a look at the investment that Google has made in Polymer and web components, it is probably safe to bet that web components will play a large role in web development in the near future as browsers implement more support for them. There are still some issues that need to be addressed, such as search engine optimization (SEO) concerns, but I do not think web components are going away, and I dont think this is bad. The introduction of web components (or a similar standard for extending, packaging, encapsulating, and importing discrete UI components) is long overdue in web development. Even if you do not put all your stock in web componentsfor example, lifting back the curtain and seeing how the Great Oz accomplishes his UI wizardry, making an element draggablethey can be very useful.

Glenn Vanderburg said, Developers should always understand one layer of abstraction below their everyday work. I agree with this statement, and I would argue that widget libraries, jQuery plugins, and even jQuery are the levels of abstraction at which most frontend engineers operate on a daily basis. The level just below that consists of the DOM manipulations these libraries perform, and the DOM and its native APIs. Understanding precisely what these libraries are doing will enable you to write more efficient code on a daily basis and prepare you for the great awakening.

Inevitably, there will come a time when one of these libraries does not fit nicely into the use case with which your product manager or information architect has gifted youat which point, you either sink or swim. I for one would have preferred to have some swimming lessons before my day arrived, but I was not that fortunate.

I was tasked with making a fixed-width portal product fluid-width, and all of the portlets resizable. Sounds easy, right? I was informed that this had been attempted more than once before, and that previous developers had failed and said it was impossible. Well, that was encouraging. On top of this, Internet Explorer 9 had just hit the market, and due to technical debt we were running three different versions of jQuery and two different versions of jQuery UI, none of which worked well with IE9. So, before I could even start the resizing work I had to move to a single version of jQuery and jQuery UI that played nicely with IE9. You might think that moving to a single version of each library would be a simple process, but I quickly realized why we had accumulated the massive technical debt. We were running a myriad of jQuery plugins ranging from bad to awful in quality and old to ancient in web time. In addition to breaking our code, the upgrade broke the majority of these plugins. This required upgrading and patching several plugins, and replacing others. This in turn involved an intimate knowledge of the DOM, which I did not have. I console logged, reverse engineered, and consumed Stack Overflow until I had solved every problem. This was all before I could even get started on the column resizing and portlet changes.

Next, I got some ridiculous requirement that the portlet column resizing had to look precisely like a mock that had already been approved. It also had to behave just as the approved specification described. There was not a plugin in existence that would meet these requirements. Marvelous. I got to write my own.

Once I had that spaghetti code written, I had to make all the portlets and every widget resizable. All of these events had to be timed properly, and nothing could spill out of containers while resizing. setTimeout and I began a love affair that still continues to this day.

If you can relate to this story, then you likely have your own. If so, like me, you probably hacked something together that was a hodgepodge of Stack Overflow responses and miscellaneous jQuery plugins held together by some glue code you wrote that have 100 different branches to account for all the anomalies that occurred due to your lack of understanding. I have been there, and it is not fun. This experience is why I wrote this book.

In addition to not drowning, there are some other benefits to understanding how the lower-level parts of UI components function:

• It allows you to define an API that makes sense to youjQuery plugins are not everyones cup of tea.

• It gives you full control over the entire stack, which makes debugging easier and allows you to decide at what layer a change should occur.

• It allows you to decide which features are important and to limit your footprint in cases where file size is of great concern (e.g., mobile applications).

• It allows you to make optimizations that fit your applications and use cases.

Lastly, I think that it is every frontend engineers job to understand the DOM and vanilla JavaScript. This understanding, and the ability to design solutions, is what sets frontend engineers apart from frontend developers.