From Frameworks to Benchmarks pt. 1 Intro

React

I hopped on the JavaScript framework hype train feet first. I started to use React for everything. I rewrote my portfolio in React. I concocted personal projects with the express purpose of creating specific React components for them. State was everywhere; props were flying left and right; and I was the mad genius at the helm.

But my as my zeal wore off, I realized I had ended up leaning on React for jobs that really didn’t merit a full front end framework.

Let’s go back to my portfolio – the one I hastily rewrote with React during my honeymoon period with the framework. I stored portfolio items in JSON, and used React and its JSX syntax to dynamically generate HTML for them. But that wasn’t really getting the full mileage out of the 30.5 KB for React and React DOM together (minified and gzipped) framework I was loading on each page visit. There were little-to-no state updates, meaning the entirety of the Virtual DOM was being loaded with no real performance benefit. The entire DOM diffing algorithm was sitting there totally unused.

I soon realized that all I really needed for a portfolio was JSX. Upon acknowledging the performance hit I was taking and seeing the consequent interference with SEO, React was becoming a less and less attractive option.

Server Side Rendering

“But what about server side rendering!?”

Server side rendering is a shallow fix to the problem. Loading unnecessary code on the server is admittedly faster, but is only a marginally better solution than loading unnecessary code on the client in the first place.

I’m not looking to force React into a use case it wasn’t designed for, I’m looking for an alternative to the Virtual DOM itself.

So I started shopping around for alternatives. I began with the other big name front end frameworks – namely Vue and Angular. Angular was immediately ruled out for its whopping ~60 KB (minified and gzipped) size. Vue seemed like a potentially good candidate at 21 KB (minified and gzipped), but similarly to React, I had to import a whole suite of functionality, such as Vue’s own Virtual DOM, whether or not it was needed.

The Hunt Begins

I had to circle back around and reevaluate what I was really looking for. I came up with the following wish list:

1. HTML should be generated from, and tied to JavaScript state.
2. If the state and/or site is static, I should be able to opt out of loading any kind of DOM update utility (Virtual DOM or otherwise).
3. UX is king. In other words, the more performant and light the framework is, the better.
4. (Bonus) Uses native code that doesn’t require Webpack, Babel, Grunt, etc.

Now that I had defined my parameters, I just had to keep an eye out for something that would fit them….

Enter: Lit HTML

Recently, a friend of mine turned me on to Lit HTML, developed by Polymer Labs. Lit HTML aims to build on the same idea components (which Lit HTML refers to as “templates”) from front end frameworks like React.

Unlike existing frameworks, Lit HTML parses and renders components through native browser features, namely: JavaScript’s template literals and HTML’s template elements (I guess we can forgive them renaming components to “templates”). This means no Virtual DOM, no transpiling process, no esoteric hybrid languages (looking at you, JSX), and potentially microscopic overhead.

True to its promise, Lit HTML is significantly smaller than any of the major front end frameworks, coming in at 2 KB(minified and gzipped). That’s 5% the size of React. Even despite the small size, Lit HTML claims to have a much faster update cycle thanks in part to their choice of native web technologies over a Virtual DOM, JSX, or other third party solutions.

So far, so good.

However, Lit HTML is incredibly new, and has not yet hit version 1.0. Not a lot of information is out there, and the project is subject to pivot in its approach before it’s widely released or accepted. In late October of 2017 (a month before writing this post), Justin Fagnani closes his Chrome Dev Summit talk introducing Lit HTML in part by saying they need to “get some documentation written, finally.”

So, maybe not so good.

But remember, a major selling point of Lit HTML is that it marries two native browser features to replicate component-based front end frameworks.

Hmmm…

I have a browser. Couldn’t I just start using those features without a framework? A former professor of mine adamantly proclaims that the only way to get optimally performant code is to ditch the frameworks and libraries and write it yourself. Why couldn’t you just use these concepts devoid of a framework?

Spoiler alert: you totally can. And I’m going to tell you how.

The tools to do so? JavaScript’s template literals, and HTML5’s template elements.

For the sake of sanity and brevity, I’ll be dividing the juicy details into two posts: One on JavaScript’s template literals, and another on HTML5’s template elements.

Part 2: JavaScript Template Literals