React vs. Polymer

Choosing a JavaScript Library

The age of monolithic javascript frameworks is beginning to end. The age of libraries and web standards is here to stay.

The monolithic framework is dead because it locks you into one way of developing your application. This one way does not leave room for new and better ways of development in the future. Both React and Polymer are libraries that can be dropped into any code base, no matter what framework is being used, and almost immediately enhance the developers workflow.  While both effective, these two libraries take two vastly different approaches to component development.

How React's and Polymer's websites explain what each is about:

React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.
Unlock the Power of Web Components. Polymer is a JavaScript library that helps you create custom reusable HTML elements, and use them to build performant, maintainable apps.

Each of these libraries has its own advantages and disadvantages.  Lets dive into what makes these libraries tick:

Reacts has two major selling points, its Virtual  DOM (Document Object Model) and its one-way binding. One-way binding only allows data to flow in one direction. For example if a user enters their name in a form field react will fire a change event. React provides an API to then run a function when that event is fired. That function can then update the state of the component which in turn can update the value of the field.

Virtual DOM
React was one of the first libraries to include a virtual DOM.  What this gives react is the ability to do a diff on what is currently rendered and selectively update only the specific elements that have changed since the last render. This ends up producing a much more performant render cycle which gives the user of the application much quicker feedback loop.

One Way Binding
This point may fly in the face of what most front end frameworks laud as their key feature, but one way binding produces predictable components and therefore produces a simpler application to maintain. More traditional two-way binding will also slow render times.


Polymer is at its core a group of polyfills that enable browsers to understand Web Components.    

Web components are a set of web platform APIs that allow you to create new, custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML. 

The polymer library gives some syntactic sugar over the web apis making it easer to create and maintain web components. What is great about web components is that once built, they are truly independent of any other elements or components and highly transportable between applications.


Each of these libraries have downsides. Some can be overlooked, but others may be  deal breakers, depending on your preferences. Whenever looking at using a library, it is wise to truly understand how these downsides will affect the longevity of the project.


React seems to either be loved or hated because of three things. First we have JSX. JSX is what looks like html but that html gets compiled into javascript. A simple React jsx file might look like this:

class HelloMessage extends React.Component {
  render() {
    return <div>Hello {}</div>;

That html-looking syntax is jsx. It allows the developer to freely write what is more familiar rather than writing that same thing out in pure javascript:

class HelloMessage extends React.Component {
  render() {
    return React.createElement(
      "Hello ",

The second thing that tends to be a big turn off for developers is that react best practices are to have all the component code in the same file. That means the javascript, html (JSX), and css.  Writing everything in one file goes against what web developers have been working with for the last 5 years, where commonly held best practice is that every piece of code is separated into its own file, thus making it easier to maintain and update.

The last gripe with React is the weight of the code that needs to be shipped with your application. What that means is that without writing a single line of code, the application will weigh 43kb. In this day and age where most website views come from mobile devices, the entire page weight is important for not slowing down the web experience.


Polymer has a few downfalls of its own. These might seem to be exactly what its trying to solve, but in the end, the developer will have to decide if the extra work and trade offs are actually worth it.

First, we have the problem that the polymer in the end is producing DOM, which sounds great, but in practice ends up as a step backwards. This is because you end up having to do any interactions or DOM manipulation in basic javascript, which adds a more boiler plate code akin to what single page applications looked like before React and other such libraries came about.

The next thing that makes developers reluctant to use Polymer is that in order to pass data to a Polymer component it needs to be passed via attributes on the component. Because the component is a regular DOM element means you have to pass data to it in string form. When applications get larger and more complex this can create performance problems because you are converting your data to a string just to convert it back into an object when the component uses that same data. Polymer has come up with work-arounds for this issue by creating placeholders for variables in strings. But by using these placeholders, you have tied your application explicitly to Polymer because the placeholder is not in the Web Component spec. 

Real World Application - Which one is better?

Up to this point, I have tried to stay as objective as I can to give you true pros and cons of the either library. I am now going to dive into my opinion.

I believe that React is the library that takes the win here for a few reasons.

First, because at the end of the day, all react components get compiled down to javascript, the learning curve is substantially less than it is for polymer and for large projects that have a lot of developers, React makes it easy for teams to scale well.

React also has one-way binding that creates a repeatable structure that makes debugging applications less time consuming. This one-way binding gives the developers some affordances when making assumptions about data flow in the application I won’t get into, but see Redux .

The last and possibly best reason to use React over polymer is pure performance. Reacts virtual DOM keeps re-renders, the most time intensive process, to a minimum thus producing a snappier user experience.

Final Thoughts

All in all, I think that React is the better direction for applications, but if there are components that get reused across your organization, Polymer may be a good fit for you. That being said, there is no reason why you couldn’t use the two together; polymer is creating plain html which react can then manipulate.  Which is the beauty of these two libraries.