Why use Polymer?

I had a chance to watch the Google I/O keynote with the infamous Adams, and while the majority of the presentation was centered on hardware (Google in your car, Google on your body), what really caught my fancy was Material Design and Polymer. I’ll leave the niceties of Material Design to my creative counterparts, but basically it's an “evolutionary” set of principles and design patterns meant to be intuitive, mimic real-life interfaces, and focus on crisp lines, high-contrast, and visual depth.There is a lot of material (pun intended) on the web about how to use Polymer, but not too much on the “why” behind its implementation. Why is it so important, and how is it actually changing the web for the better? Well, I’m hoping to put a little context behind Polymer and prove it’s not just another framework or plugin you could maybe use.

A Brief History

Before we get into Polymer, let’s delve into the (arguably) boring history behind the idea. Back in the day, the web was ridiculously repetitive. Every time you wanted red text, you had to define the font properties with an identical font tag for every instance of your red text. When the boss points out that you used the wrong red, you’ve got to go back and change every single one of those font tags. If you were dealing with multiple pages or files, it killed productivity and forward motion.CSS helped with this issue by allowing developers to define the style once and implement across multiple instances. That allowed developers to focus a bit more on code and interaction. We then, of course, had the same problem with JavaScript; we had to write the same code over and over again. The idea of the plugin quickly emerged, allowing us to write specific, portable pieces of code that could be used on multiple pages, multiple sites, and even across multiple industries.

So what's the issue?

Now that we’re writing highly reusable pieces of code, the issue is conflicts. We’ve matured to the point that we’re no longer writing plugins with conflict-ridden names like “Button” or “MapPlugin,” or using global variables named “timer” or “img," but what we face now is inheritance issues. Our browser is getting smarter every day and is getting creepily good at trying guess what we, as developers, mean when applying styles and adding functionality.

As we get more efficient and modular, what we really need now is a way to separate our components and have them operate pretty independently of other components. It's got to be extensible enough for us to efficiently integrate the component into the most complex of designs and concepts without losing functionality, breaking other components on the page, or destroying important styling.

I’ve touched on some paradigm shifts in CSS and JavaScript, but in order to get fully modular in the web, we have to go back to the beginning and rethink how we use HTML. HTML4 and HTML 5 have been doing wonders with creating new tags for us to use, but how crazy would it be if instead of coding a couple nested divs with a list, a bunch of list items, and a bunch of links, you could just use a menu tag? Some JavaScript frameworks like Angular have been playing with this concept for a while, but still have conflict and scoping issues.

Polymer, you say?

Enter Polymer, a library that allows developers to write and implement near-standalone web components. And it's a game changer. I recommend doing some research and incorporating it into your suite of tools. It'll make you better, and make the web better!Their website is super helpful and explains how to put it into action, but if you've got any questions, comment below! I'm on standby.