Getting unstuck in webcomponents

Between evaluating a technology as useful and learning how to use that technology to actually solve problems can add up to a long time span. Especially when a technology is against your carefully arranged biases on how to craft websites.

Martin Muzatko Written by Martin Muzatko


A couple of years ago, I found a great article by Rob Dodson about webcomponents. He also wrote another brilliant article for CSS-Tricks. Unfortunately, it took me a while to truly get into webcomponents. A lot of existing frameworks/libraries aren't really encouraging to get into them.

"This technology looks like it solves the problems of everyone and I'm just sitting here and wonder if I could ever learn that."

I used to be a copy&paste&adapt developer and I could have embraced all the awesome technologies earlier to be more productive and get rid of all the cognitive load of solving problems over and over again. As I write this, there are still many CPA frontend-developers out there, reluctant to learn about things that could make their dev-life a lot easier.

Let's fix that

Currently HTML5 is making its move to encourage creating and using webcomponents - reusable configurable blocks of HTML/CSS/JS. How does it look so far? Not so well.

What are our options? Polymer, X-Tag and similar frameworks or UI-libraries.

Learning new frameworks and libraries consumes a lot of your precious time to make your life a bit easier afterwards. This sucks. Because even then, you still need additional time to fix your problems with new technology. There are several other drawbacks like performance, relying on Javascript, but nothing is as big as the roadblock, that you have to invest quite some energy, to save you from frustration later on. If you are like I was, as soon as you find even tiny problems that are caused by the new thing you learn, you tend to give up since nobody is there to help you getting unstuck.

How often did you look for more reasons to give up than to continue?

I used to look at new technologies like they have to prove to me that they are worth the time spent. Before we can have less cognitive load about our earlier problems, we need to learn, use and embrace technology that helps us getting rid of the unneccessary cognitive load.

Exponential Knowledge

The more advanced you get in something, the better you are at getting better. Learning how to learn something more efficiently. So the learning experience should be exponential (IF there wouldn't be these emotional problems about something being so hard or so impossible to learn). Soon after you grasped the basics of HTML and CSS, you are going to understand more complex HTML better. This is for all parts of development. It may take you months to get from stone-age HTML to advanced CSS with special effects. But then, the more you learn, the faster you learn new complex topics. In the last few months I was able to skyrocket my knowledge. Now I'm here with reusable components, creating interactive webapps. But we can get stuck sometimes.

Identifying and facing Problems

Back to topic. Let's see what we already tend to reuse and what we refuse to reuse and write from scratch over and over again.

HTML - Most of the HTML I wrote, was from scratch, I do have some patterns in my brains that tell me which elements belong where. Writing HTML with Emmet is fast anyway. So basically I reuse almost nothing other than the basic setup - the head part mostly.

[[bar progress="2" color="#f16529"]]

CSS - Since Pre-Processors, I have been reusing a few low-level things like variables (some colors, degrees for creating slanted gradients and fonts) or some mixins that make using animations or transitions easier, but nothing really that great.

[[bar progress="8" color="#369bd6"]]

JavaScript - With jQuery and other tools, I was reusing a few common solutions I created. For pure JS; maybe a few numeric methods like random, chance, range, etc.

[[bar progress="25" color="#f0db4f"]]

Tackling the Problems of Reusability

We do have some components we use. Bootstrap, Foundation,. etc.. You still have to write a lot of markup everytime you want to implement, say a bootstrap carousel.

<div id="carousel-example-generic" class="carousel slide" data-ride="carousel">
  <!-- Indicators -->
  <ol class="carousel-indicators">
    <li data-target="#carousel-example-generic" data-slide-to="0" class="active"></li>
    <li data-target="#carousel-example-generic" data-slide-to="1"></li>
    <li data-target="#carousel-example-generic" data-slide-to="2"></li>

  <!-- Wrapper for slides -->
  <div class="carousel-inner" role="listbox">
    <div class="item active">
      <img src="..." alt="...">
      <div class="carousel-caption">
    <div class="item">
      <img src="..." alt="...">
      <div class="carousel-caption">

  <!-- Controls -->
  <a class="left carousel-control" href="#carousel-example-generic" role="button" data-slide="prev">
    <span class="glyphicon glyphicon-chevron-left" aria-hidden="true"></span>
    <span class="sr-only">Previous</span>
  <a class="right carousel-control" href="#carousel-example-generic" role="button" data-slide="next">
    <span class="glyphicon glyphicon-chevron-right" aria-hidden="true"></span>
    <span class="sr-only">Next</span>

Urgh! So much HTML for just two slides. There is way more markup than actual content!

If we have to go even further and customize the carousel, say we want custom icons for the indicator-dots, we are going to have a lot of mess in short time. So either you have great memory, or you have a decent editor with refactoring tools, or you copy one alternative and reuse that. Even with all three of the above and with less than three components to manage, we are most likely doomed to mess up. That's humans nature. But we can do better than copy&paste&adapt. We are not obligated to copy.

Let's see how this would look like in the webcomponent-world.

<carousel indicators indicator-icons="globe map-o" controls class="slide">
    <carousel-item background="2.jpg" caption="Item 1">
    <carousel-item background="1.jpg" caption="Item 2">

You would have to define the options/settings of the component only once. Then you can just call it with the items you need - done. Data-attributes were only the first step to configurable custom elements. We should focus on creating reusable components instead of copypasting boilerplate over and over again. But how?

It's time for a Riot

A few months ago, I found Riot via Being as skeptical as always, I was looking at their page and even though they didn't have that much demos or examples, it immediately spoke to me. Riot - against what? Against the current trend of boilerplate and unneeded complexity. Yes that's me!

They are also against slow learning and against reinventing the wheel.

We think that a small, powerful API and concise syntax are extremely important things on a client-side library.

Since then, I did my best to implement Riot in several webapplications in production.

Riot - Riot certainly encourages to create reusable components - a layout combined with logic and interchangable data already makes a component. Since exploring Riot, I created about a dozen reusable UI components I can use in any project. Modals, Picker, Autocomplete, Filter, Pagination, Sortable etc..

[[bar progress="75" color="#ff0044"]]

You can do so much with the HTML and CSS you already know. There is almost no JS involved with creating reusable HTML/CSS components. But it has everything you need, in case you want to level your JS skills.

  • Riot requires you to invest almost no time to see results
  • There is not that much to learn to create interactive components and/or apps
  • There are a few helpers to easily create customizable components
  • Riot, as of version 2.3.0 needs only 18kb of space (compared to jQuery: 83kb)

Here is how Riot compares to existing frameworks and libraries:

You can start exploring it on the official website or tuning in on the quick tutorials that I wrote for you here on Happy-CSS.

What are the benefits?

You can productize your web-offers using components. You can let go of wasting time on adapting your existing HTML boilerplate to fit the needs of you or your client. You could make your living from reusing what you already have built. Every component becomes a brick that is already there to be used to build your wall. And then, when you have your walls that you don't have to construct from bottom up for every new project. It is easy to use these as the building blocks for entire projects. More than that, we can stop worrying over how we achieve certain things, without pulling an all-nighter



I did this transition only a couple of months ago. Within a few months, I moved from repetitive tasks to interaction-designer level tasks. Without having to care about fundamental HTML and CSS stuff anymore over and over again. I learned to adapt the mindset of fixing something once and then reusing it. It takes time to create a mindset, where a world of "fixed it once, fixed it forever" is possible.

Further Reads

Give it five minutes

A Dao of Web Design

Riot Lessons

What are your thoughts about embracing new technology? Have you experienced problems getting to know new technologies/frameworks/libraries? Let me know in the comments.

How do you build re-usable interactive webcomponents without wasting your precious time bending the DOM to your needs? Get my latest content about building front-end web-apps delivered directly to your inbox and get free code samples for all the components I create.

See other articles

How to group together filter inputs to obtain and combine their values


When you want to filter a set of products or other lists, you usually run into many issues when wiring together the variety of filters. I show you how you can retrieve the data and combine the values to filter your items in real-time.

Becoming a zombie


Do you find yourself losing track of time again? Without really knowing, a year passed. As day for day you continue your work, you had some random bursts of motivation, but you know that these kind of motivation spikes won't get you anywhere in the long term.

Updating the riot cheatsheet


It has been roughly a year since I created the riot cheatsheet. With the knowledge acquired by now, it is time to start from scratch. #news 4 #riot 12 #nodejs 2 #webpack 3

About being part of the community


Hello there! A few months ago, I decided that I have to be more active in the community of web developers. Since then, I wanted to give talks about my favorite tools.

See all Articles