Building efficient web components

Jump to repository / Jump to demo / Read on Github

Sometimes it feels like we go in circles…

I went on a journey to find the best tool for building reusable components for Web applications.

In the beginning I would like to talk about efficiency. As engineers we often being asked to find the best solution to a problem. In software engineering it usually means to generate more value in our products as cheaply as possible.

efficiency = value / cost

When we develop a new feature for a Web application we can consider factors like.

| Values        | Costs             | 
| --------------|-------------------|
| Accessibility | A lot to learn    | 
| Performance   | More to code      | 
| Usability     | Hard to debug     | 
| Security      | High maintenance  |
| Etc...        | Etc...            |

It shouldn’t suck. Seems obvious but we often forget what it means to be an engineer.

Approach

Let’s build something meaningful. The task is to build an application that can utilize several reusable components and represents something we commonly use. Like forms and tables with data.

Requirements

Form component

• Displays 3 fields with configurable values.
• Has two actions to show data and to change data.
• Calls the table component and passes fields values.

Table component

• Accepts parameters from the form component.
• Calls an external API to get the data.
• Displays received data in tabular form.

Cell component

• Calls an external API to get text to display.
• Uses attributes as parameters.

Support all modern browsers and IE11 :)

Fair play rules

Solution should include at least 2 files app.js or app.html and index.html.

• Not minified.
• Use similar HTML structure.
• Use similar coding styles with comments.

All solutions include common files:

• common.js with configurations, APIs and analytics.
• minified bootstrap CSS and style.css with basic styles for metrics will be loaded later and excluded from metrics.

Solution can use unlimited external libraries.

• External libraries can be minified.
• Don’t use CDNs. All solution files should be served from the same place.

Avoid table rendering optimizations.

• Display cells row by row, column by column.
• We don’t want to repeat JS framework benchmark
• And we can always use similar optimizations for every solution here.

Checkout a demo page with solutions and tests.

Results

I tested native JS, JQuery, X-Tag, Polymer, and bBlocks. My metrics include critical rendering path, display speed and change speed for 1500 items. I can run as many iterations as needed. Results are stored in the locale storage and you can see average values for each solution. It becomes very flexible this way. And you can try different browsers and modes.

Chrome (no-cache mode).

IE11 (no-cache mode).

Chrome (with cache).

Chrome (no-cache, Good 3G throttling mode).

Solution code size

Dependencies size (minified)

Opinions

First of all I would like to say how thankful I am to creators of libraries we use everyday in our apps. Pioneers explore new ways of developing for Web. It often comes with extra costs. But at the same time I think our building blocks need to be as efficient as possible.

Native Javascript

• This could be a base to compare other solutions.
• I didn’t use any new Browser APIs like Custom Elements.
• I used mutation observer to detect attribute changes for the cell component.
• It showed the best performance with 1KB of extra dependencies.
• Controversially, this solutions was not fastest for me in IE11 :¯\_(ツ)_/¯.
• As expected, native Javascript requires more code to write which increases the costs.
• But it will not increase learning curve.

jQuery

• An old friend and a strong contender.
• Slowest solution because of an overhead when using jquery methods instead of native.
• Stable, easy to learn, rich ecosystem.
• Latest slim version is relatively small in size 68KB.
• Could be a winner if it is already a part of the app. Which could be true for ~70% of the Web. This way it doesn’t bring extra costs.

Polymer

• I used a micro package of Polymer v1.
• Speed wise it is getting closer to native Javascript. But heavier due to polyfills and library size.
• Polymer suggests to use all new APIs like Custom Elements, HTML Imports, Shadow DOM, Templates. Each has several caveats.
• It brings some extra ambiguity when you use many unstable technologies. You end up paying higher costs by spending more time and including heavier polyfills and libraries.

X-Tag

• Smaller library built on top of Custom Elements API.
• Provides DOM helpers and APIs to define properties and observe attributes. Just what we need.
• Heavier than it could be mostly because of extra polyfills.
• Showed better performance and smaller solution size compared to Polymer.

bBlocks

• Can we do better? I tried to create the most efficient one.
• Lightweight. Only 4KB minified. Extremely modular and flexible. Only 2 major APIs to create components and features that I can keep consistent forever.
• I was able to achieve better results with less to code and minimum to learn.
• It requires only several lightweight polyfills for IE11 and the best Custom Elements polyfill. Only 14KB in dependencies.
• It doesn’t require transpiling and it could work with Classes or Prototypes.
• I created a module with DOM helpers. An example how we can make our solutions compact.

Agree or disagree all opinions are welcome! ✌️

Jump to repository / Jump to demo / Read on Github