Top ten reasons to use Polymer LitElement

LitElement is the next version of Polymer 3.0. I was about to say next “evolution” but that would be wrong. Huh? It’s technically a “de-evolution”. In my opinion, the Polymer team took everything they learned about Polymer and stripped it down to it’s best parts, included some much needed expressiveness in the template model and threw away rest in favor of easier and faster.

When should I use LitElement vs another JavaScript framework?

LitElement is lightweight, simple and comes with a library of ready-made components. It allows you to use other frameworks on top of it. From a tech perspective, it’s hard to go wrong with LitElement.

What about Angular? Yes, Angular is great. It’s mature and proven. But Angular and Polymer are on two ends of the spectrum. Working in Angular reminds me of J2EE where there are all these rather complicated constructs baked into the platform. What’s good about these constructs is that in a large enterprise environment, these constructs can significantly help to keep projects moving forward.

As an example, we chose to use J2EE deployed on Wildfly for our middle-ware because it is slower moving (less code iteration cycles) making it more suitable for a stable back-end. Yet, for smaller auxiliary micro services, we used Go again, favoring the simpler / faster combo.

For our front-end, we chose LitElement because we wanted our front-end goals were completely opposite of our middle-ware goals: high code iteration, fast moving and just plain fast.

Enough of that — let’s get down to the top ten reasons why you should use LitElement in your next project.

Reason #1: It’s simple and straight-forward

LitElement stays as close as it can to standard JavaScript and HTML. On the HTML side, there are minimal proprietary attributes, tags, etc. so that your finished HTML looks… well, normal. On the JavaScript side, the components you build follow the syntax and format of standard ES6 modules. It’s no different than modules that you might write in Node.JS.

As an example, let’s say we need to iterate over an array for a list.

Angular2 way:

<ul>
 <li *ngFor=”let ticket of tickets”>
 {{ticket.Type}} ({{ticket.Status}}): {{ticket.Subject}}
 </li>
</ul>

Polymer3 way:

<ul>
  <template is=”dom-repeat” items=”[[tickets]]”>
    <li>
      [[item.Type]] ([[item.Status]]): [[item.Subject]]
    </li>
  </template>
</ul>

LitElement way:

<ul>
${this.tickets.map(
  (ticket) => {
    html`
    <li>
      ${ticket.Type} (${ticket.Status}): ${ticket.Subject}
    </li>`
})};
</ul>

At first glance Angular and Polymer has less lines of code and “seems” simpler. But is it really? In Angular, you would need to know what “*ngFor” is — and what it does. I’ll be the first to admit that till this day, I’m still not completely clear what *ngFor actually does in various situations!

Same for Polymer — what is: is=”dom-repeat” and what does it do? Indeed dom-repeat’s behavior is not clear under various circumstances. These conveniences often come with a high price tag when your application evolves beyond drop dead simple.

While the LitElement way has more lines of code, note that besides the ${}, there is no other proprietary syntax. All the html is just plain html and all of the JavaScript is just plain JavaScript. There is no extra knowledge required and nothing (sometimes nefariously) hidden happening.

Anyone who can read HTML and JavaScript can understand the LitElement snippet without any knowledge of Angular or Polymer.

Reason #2: It’s expressive

For me, it’s the expressiveness of LitElement that truly makes coding in the framework fun. Because LitElement basically uses standard JavaScript embedded into the template, it give the coder a great deal of latitude to just

“get it done right then and there”.

And to boot, it does it in a transparent and readable way.

Consider the previous example —suppose ticket.Subject is an array. Uh-oh — what will *ngFor render? Something like [object Object]. So will Polymer. The solution? In Angular you might use a PipeTransform class. A separate class in a separate file. Starting to remind you of J2EE? In Polymer you could at least call a function:

[[item.Type]] ([[item.Status]]): [[doSomething(item.Subject)]]

This is not a bad approach, but if doSomething is rather trivial and you had multiple cases of this, you end up a lot of helper functions resulting is a great loss of transparency.

With LitElement, it’s a simple and expressive one-liner.

${this.tickets.map(
  (ticket) => {
    var txtSubject = ticket.Subject.join(',');
    var disp = html`
    <li>
      ${ticket.Type} (${ticket.Status}): ${txtSubject}
    </li>
    return disp;
})};

And it’s a lot more readable and transparent than “doSomething”.

I know what you are thinking — is this a great recipe for spaghetti code? Maybe, but in my opinion, no framework will keep a spaghetti programmer from making spaghetti!

As an aside, I spent a lot of time in the J2EE world with strict methodologies and patterns and anti-patterns and well-defined bean life cycles, etc. and that never stopped the spaghetti.

If doSomething’s logic is substantial and needed to be reused, LitElement would not stop you from:

${this.doSomething(ticket.Subject}

Reason #3: It’s fast. Really, really fast

I’ll cut to the chase here — the rendering speed difference is noticeable. The difference between Polymer 3.0 and LitElement is akin to the difference between a Java Servlet vs a static html page a decade ago.

The reasons behind the performance is beyond the scope of this article, but if you are interested you can listen to the talk by Justin Fagnani.

The Virtue of Laziness: Leveraging Incrementality for Faster Web UI”

Reason #4: Interoperability

LitElement plays nicely with other frameworks because it is a standard es6 web component — no different than any other web component that you import via NPM. You can use React and LitElement, Vue and LitElement. Redux works great in LitElement.

LitElement components are just standard ES6 web components

Reason #5: Readily available pre-built web ui components

There is an extensive library of pre-built web components that you can use immediately via NPM. You can access many of them at www.webcomponents.org.

This allows you to get your app up and running quickly. Plus, you can always swap these out with your own custom ui components later.

Reason #6: The entire NPM respository at your disposal

Both Polymer 3.0 and LitElement now use NPM. Various pre-built utilities and libraries written in ES6 can now be used inside LitElement.

Reason #7: It *is* the framework of tomorrow’s browser

Web components are already here. Evergreen browsers are quickly implementing any missing features of the specifications. What fills the gap is the LitElement library. LitElement is the closest thing to writing in the web components standard. Polymer’s original motto was “use the platform”. As in leverage the web components standard that is being baked into browsers. In the meantime, Polymer would fill the “gap” with polyfills. As the web components support has advanced in modern browsers, the “gap” has been slimming.

Writing your code in LitElement means you are essentially writing in the to-be universally support web components standard.

Who doesn’t want their code to be future proof?

Reason #8: Think components

Components promotes code re-use and maintainability. Any component you write can be imported into other components — and even other frameworks, like React for example. Since a component encapsulates a specific set of code, it makes it easier to maintain. Once a component is written, it can be used declaratively like

<my-ticket-list status=”important”></my-ticket-list>

This makes things more readable and intuitive. Plus there is the shadowDOM, which scopes the component so things like styles do not leak out into the rest of the application. Components are advantageous in both enterprise and small projects.

In a nutshell, components are just a lot more productive

Reason #9: One-way data-binding

If you have used React , I don’t think I need to elaborate? Working with two-way data-binding in Polymer 3.0 was just confusing at times. And I was not alone, my browser seemed equally confused! Unidirectional data flow in LitElement made data flow more predictable and performs better. Two-way data flow is very convenient when the use case is simple. A simple CRUD component comes to mind. But once the application gets to a certain level of complexity, all the benefits of two-way data-binding were lost to catching the endless boundary conditions of an asynchronous system.

Reason #10: You’re in good company

Some of the world’s largest companies have adopted Polymer.

Youtube, Google, Coca-Cola, McDonald’s, USA Today, EA.com, Bloomberg, Comcast, Dominos Pizza, Victoria’s Secret, Salesforce to name a few.

Well, there you have it —my top ten as a developer / architect on why you should seriously consider LitElement in your next project.

Over the coming weeks, I’ll be writing a “Git It Done!” practical hands-on series for coding common patterns in LitElement.