Future-Proof Web-Components

Can you remember JQuery? That was a revolution back in 2006. We could run JS code in all browsers seamlessly. Even though it's being updated and reached v3, it's part of history for web-developers. Browsers evolved and VanillaJS came out. Well, the developers community realized that was cooler to write native instead of JQuery. No more pain with plugins version and incompatibilies.

By then HTML5, CSS3 came out and web-components were slightly evolving in browsers. Some approaches like importing HTML pages were great but did not meet the required adoption to become a standard. In 2020 you can't mention web-component without thinking about libraries such as React or Vue. Some other libraries such as Preact, Pureact, Vue, Riot, Svelte, Lightdom, Hyperapp… also came out.

If you're looking for a large community, reading a book about your lib or working for the next couple of years on an app, those will be the best solutions. However, if you need a tool that you get your hands into, fix, debug, improve and add functionalities to in 2030, forget about them. Their 2020 version will be obsolete and impossible to update without full-rewrite.

The need of Future-Proof

Application sometimes need to last for years. I mean 5, 10 years or more. A client had an application written in 2006 and asked for a small update here or there. The code was written with a technology is not used anymore and we couldn't get our hands into it. We had to rewrite to app entirely. The demand was explicitly to build something that could run and be maintained again in the future. We're talking about 2034, an era for the Web world! We had to see that much forehead, in an unpredictable environment.

When working in a company that builds a product, the big players such as Vue and React can be first-class choices. A team can maintain the source, upgrade the dependencies, debug issues as they come. However when working for long-term apps with no dedicated team, maintaining an app and its dependencies for years is not an option. In which case you must use long-term tools; future-proof libraries.

When talking about future-proof the best choice for a lib is no-lib. A project can be written from scratch and eventually use native webcomponents. We had experimented these approaches with a decent level of satisfaction. That was indeed satisfying enough to give it a future. Plus, it was pleasant to code and easier to debug. However, it could become tricky to get some basic functionalities such as reactiveness and components communication.

We therefore used Riot for the long-living app. It was writing native-like components with the missing parts. All great. But… it was a little buggy with some unexpected behaviors and digging into the source code was a pain, and unresolvable. We needed a new tool that would be more robust and future-proof. Riot 4 came out since, solving some bug and bringing some new ones.

Defining Future-Proof

A future-proof approach has essential ingredients:

• the documentation should not be necessary
• source code must be easy to read and patch
• it should be fully sitting on top of standards
• it must be easy to debug with native tools
• there should be not third-party dependency
• compilation is a dependency, therefore no compilation required

Looking at the libraries above you can eventually tick a box or 2. You can forget 2030, if you eventually can guess what was happening in the code and hoping it is still running, the documentation to get your hands into it will be outdated and you won't even be able to update the app and install the compilation tool.

A Native Web-Component Solution

For the past couple of years - while being grumpy with Riot - I've been working in parallel on a tool so simple that the source could be readable with no pain and work out of the box. Brick (https://github.com/polight/brick) and Lego (https://lego.js.org) then came out.

Brick is a native class that extends HTMLElement in less than 100 lines of code. It also adds reactiveness to native web-components. It's very similar to Hyperapp, but native. It's fast, easy to debug and raw. Above all, it fits the list of future-proofness.

Lego is a way of writing native HTML elements in HTML. It is pretty close to HTML Module import spec. Under the hood it builds Bricks components, so it's native HTML elements written in an HTML Module way. While HTML Modules are (eventually) on their way, the web-component ecosystem is in bloom with anything and everything. There is a need of something stable enough to be game for the next year with no hype and future-proofness in mind.

What are your needs for building apps for long-term? What is it that you look for when adopting a tool? Answers will vary with your environment and I'd be curious to collect feedbacks of apps you build over 3 years ago.