1.5 Years with Polymer Web Components

For about the last 6 to 8 months I’ve been doing a lot of development using Polymer Web Components. I started with the 0.5 developer release version. My experience so far has been a little bitter sweet.  Using version 0.5 I had to jump quite a few hoops to get things working, but once I figured out the patterns all was well with the world.

In the Beginning

I had chosen to use Backbone Marionette for the MVC architecture for my apps. I already knew Marionette so I felt the logical choice was to stay productive and just use what I already knew and use the web components in my templates. If I needed a custom component, so be it, I created it. But I tried not to create too many, but still quite a few were created. This was especially the case when version 0.8 came out which was the first breaking change and a pre-cursor to the future. By using Marionette I felt like it worked pretty well. I really couldn’t take advantage of Polymer’s data binding, but I had a Backbone Model for that anyway.

I was able to create some really cool applications and our customers were thrilled with the outcomes (delight your users). Everything worked as it should, it even looked and behaved great on a mobile device. These apps actually looked and felt like they were designed for mobile.

Then Came Version 1.0

Then version 1.0 came out production ready. I had already figured it would be a breaking upgrade after version 0.8 so it really wasn’t a shock, just a nuisance. Nothing from 0.5 worked with version 1.0 so I had to convert my custom components to work with 1.0 and I had to revisit all the apps I had created. While this experience was certainly on the bitter side, it gave me a chance to learn more about Polymer and how things worked.  That learning curve wasn’t as steep as the initial intro into Polymer was, but it really revealed any bad decisions I had made in the previous version.

I started using Polymer everywhere and started creating more and more custom components. I was still using these components with Backbone Marionette and just learned the limitations, what I could and couldn’t do because of the way that Marionette handles regions and View (The Backbone kind, not Notes kind) elements. If these “rules” I had discovered weren’t followed, weirdness ensued with the Polymer components. Things like having to wait for animations to finish, or render a View and then transition to a page. So a lot of setTimeout commands started showing up in the code. Sometimes it was only a 1ms wait, but still it presented complications. Also, a lot of CSS hacks had to be incorporated when weirdness was involved, again it was centered around the way Marionette handles putting HTML templates into the DOM.

Since some hacks were starting to appear in the CSS and JavaScript, performance started to suffer. We also started encountering a lot of browser compatibility issues. Surprisingly IE 10 & 11 handled Polymer much better than Safari, but they still had their issues. Firefox was also becoming a pain and really started to cement my thoughts around maybe we’re approaching this wrong.

Some spare time appears

While I was waiting for some backend and design changes I ended up with some spare time. With this spare time I decided to start implementing our portal as a totally all Polymer application as a pure learning experience and was totally meant to be an experiment. What I found was that a LOT of weirdness just disappeared, even tho I copied the existing HTML templates and logic I then just replaced the relevant bits. It was still very pleasurable to see that weirdness just go away. I also found that the browser incompatibility issues just disappeared. Sure, there were some CSS (mainly what I had written) that IE didn’t like, all the other browsers looked and behaved great.

I also found that the speed at which everything was coming together was greatly faster than using Marionette. When using Marionette there are a LOT of moving parts. You’ve got to manage the order modules are fired up, need to ensure require.js is working properly, need to create the router, router controller, app and ensure that is all working before you write a single line of code. A page rendered by Marionette also required at least 4 files. A controller, view, HTML template and model. Depending on what was being rendered you may also have had to create a collection and item views. So a lot of logic was required to get everything working and this all takes time and planning.

The outcome so far

So that was about a month ago since I’ve been working on this “experiment” in my off time and usually 1 day a week. I’ve put in about 80 to 90 hours of development time. In our current version we’re doing dynamic forms, views, a new user profile and person cards. This requires us to toss out a lot of older work to incorporate these new things. Since I was replacing these things anyway, the goal this past week has been to catch up the Polymer only site to include everything that isn’t going to be tossed out. I’ve pretty much been able to do that, plus on top of that, we’re freeing up one person on my team from doing weirdness control and browser compatibility work.

As far as infrastructure, I was able to cut down the number of network requests by more than 60%. Polymer’s data binding makes this possible, why fetch something when you’ve already got it. In the build version, I’m now delivering one file to the browser instead of many. The initial page load is doing half the number of requests as the Marionette version. It’s also blazingly fast when compared to the Marionette version, so much so that you can feel the difference. Usually with performance gains you really can’t feel the difference, but with these you certainly can.

The amount of code to maintain has also drastically been reduced. For example, in the Marionette version the sidebar was around 1400 lines of code spread across about 12 different files and was it’s own module. In the Polymer version we’re well under 1000 lines of code spread across 3 different components and the majority of the code is HTML and CSS, not JavaScript. Also, maintainability has increased as it’s now fairly obvious where the logic for something lives since it’s all contained within custom components. For example, the sidebar, there is the sidebar-list component, sidebar-item component and sidebar-avatar component.

On the device front, the site behaves great on a desktop browser including Safari, IE and Firefox. On a mobile device, it looks and behaves great, just as you would expect it to. The performance is noticeably better and no animation weirdness, for the most part (IE runs the animations slower, but they aren’t broken). Not to mention a quote from someone previewing the work so far, “The Animations just make me happy”. We were able to get rid of all the setTimeout commands and all the CSS hacks. With Polymer’s custom CSS features there’s even minimal CSS where in the Marionette version the CSS was HUGE.

Looking to the future

Since the switch to Polymer only, we can now look at enabling the offline capabilities of a Polymer app. While most would say this isn’t such a big deal, with old notes apps sometimes it is a deal breaker. Also enabling offline, performance should increase substantially, with things being delivered from the cache if possible instead of the network on subsequent network requests. The Polymer team is making great strides in getting things into the W3C specs for CSS Variables, templates and the HTML spec. The work being done in Polymer is also being used in Angular2 and vice versa. There is also a growing open source community around making custom web components. There are some absolutely beautiful date pickers being created, along with very robust components like the vaadin-combo-box, vaadin-data-grid and others that are totally re-usable and capable of just being dropped into your project.

When creating custom components, we can now use the tools made available by the Polymer team just for this purpose. No more hacking the build process to get it to work with Marionette. The Polymer Starter Kit comes with it’s own build process that just works. You may have to change it a little to get your code to the Domino server, but other than that, it’s good to go.

There is also a lot of work being done by the Angular2 team and Microsoft to get TypeScript functionality included. The ability to use TypeScript makes writing JavaScript a lot more object oriented and closes the gap of transitioning from Java to JavaScript.

Conclusion

My experience so far I feel has been a pretty positive one. A year ago this was bleeding edge technology and it felt like it. Today, this has moved back to cutting edge technology with improvements being made by leap and strides instead of creeping. The Polymer team has announced that breaking changes will be announced by major version number revisions. Version 1.x.x should always be compatible with version 1.x.x however version 2.x.x may include breaking changes, which actually makes perfect sense.

I’m really looking forward to working with this technology and adding new features and functionality to our software just got a lot easier. Sometimes new features cause a feeling of dread and anxiety when I might have to touch something that was fragile to begin with. As long as I create stable components, nothing should end up being fragile, and that’s a good thing.

Share This: