I’ve seen the future, it’s full of HTML.

Mikeal Rogers
4 min readSep 28, 2017

--

WebComponents are more than standards.

Developer trends are driven by innovations in distribution. Languages, platforms, frameworks, all of them offer new and, hopefully, improved way to package the value you create and share it with others.

In open source ecosystems distribution is the key differentiator. Node.js’ popularity, and the size of its ecosystem, are due in large part to a small set of compatibility patterns and a terrific package manager.

Web development has been completely re-shaped by tools like babel and webpack which have enabled next generation frameworks like React. These projects leverage Node.js’ distribution tools, giving them a key advantage in ecosystem and speed of development.

But along the way, as we adopted all these new tools, we lost something.

Web development used to be a lot simpler. If I wanted to test a library or hack together a quick demo, I could just <script src=”some-library”>.

I could reload the page instead of re-compiling a bundle. I could load a static page instead of running a development server.

Our default workflow has been complicated by the needs of large web applications. These applications are important but they aren’t representative of everything we do on the web, and as we complicate these workflows we also complicate educating and on-boarding new web developers.

As good as Node.js is at providing a platform for distributed JavaScript it has never had a great story for packaging re-usable HTML and CSS. The entry point for most “resusable” components in this space require that you have already setup one of the popular frameworks like React.

HTML Returns

What if there was a way to have our cake and eat it too :)

What if we could leverage all the code in npm and allow people to use our libraries with as little effort as a <script> include?

What if we could distribute re-usable framework independent components with just npm?

I think we can. After a few months using raw WebComponents, I think there is a way for us to build isolated functionality as new HTML elements that are developed and distributed with npm and Node.js.

Here’s a few examples I’ve cooked up in the past few weeks.

WebTorrent Element

<web-torrent src="MAGNETURL"></web-torrent>

Just give it a magnet URL and the content contained in the torrent will load into the element. This is all un-styled, so you can add your own CSS to the page to do whatever you like.

Markdown Element

<mark-down>
## h2

* test
* test2

```javascript
let x = 'asdf'

class Text {
constructor() {

}
}
```
</mark-down>

I was so sick of adding compile steps just to get some markdown rendering. Now I just hit ctrl-r and it re-renders like magic, just like back in 1999:)

Roll Call

<roll-call call="CALLID"></roll-call>

I’ve been working on Roll Call for over a year.

I’ve gone through a couple attempts at re-factoring to make it more pluggable but none of them worked until I went deep into WebComponents.

Now it’s as easy as adding an element to your page and you get multi-user audio calls with podcast recording and p2p file transfers. It’s also a lot easier to work on the code as isolating each elements styling forces proper modularization.

No Framework Required

In these projects, I didn’t pick between ease of bundling the component over ease of use without a bundler. All of these components can be installed with npm and you can bundle them with your favorite bundler into your own app.

I’m not trying to be anti-framework, frameworks have their place, but the only way to be compatible with any framework is to not rely on one for re-usable components.

npm as CDN

Before every npm publish, a small script runs that builds a standalone version of the libraries with a WebComponents polyfill loader.

Combine this with jsdelivr and the assets are already on a CDN ready for people to <script> include.

This means we don’t need a separate release process for the standalone assets or any new fancy push to a CDN.

I had a great chat with Alex Russell, one of the earliest advocates for WebComponent standards, to talk about the reality of using them today. Check it out if you’re interested in hearing more.

--

--

Mikeal Rogers

Accurate predictions about things that already happened.