Stencil: I Think I Found My Frontend Home

Getting Real

I've just started exploring stencil and am already nursing a crush.

I will be the first to admit that I don't particularly enjoy building frontends. It's the reason my own personal website is, well, sad. It's been incomplete and neglected since the day I forced it out in the open, and largely untouched from that pathetic, half-finished state. This means it does not reflect any recent work I have to show off, at all, or accurately demonstrate what I'm capable of in any significant way. Useful, right? Why even have one, at this point.

I built that website as a side-effect of a DIY static site generator exploratory project in Rust. The fun part of that project for me was building the static site generator and web server. To see if it all worked I needed some test stuff to feed it so I figured I may as well build a personal website. Poor thing never stood a chance - talk about falling short of even the bare minimum.

One of my goals for 2020 is to completely rebuild it into something that isn't embarrassing, and hopefully hone a useful skill and learn more about the domain along the way.

Runners Up

Choosing a stack in the JavaScript world is daunting, especially when you don't actually know what you're doing. Before settling on stencil I considered the following options:

• HTML/CSS

My "aesthetic" for tooling choices is barebones and simple. I prefer to build my own abstractions, at least when I'm learning a domain, before trying to choose someone else's, and also think that for this website even vanilla JS is probably overkill, everything I want to present can be presented statically and simply. All I really need is HTML and CSS. I decided not to go this route because I do want to open myself up to more flexible growth paths in the future, and this is the most labor-intensive route if I go beyond the absolute basics. I also find it extremely boring to do, which means I'd be less likely to finish.

• Gatsby

The framework I've spent the most time with is React, so Gatsby was a natural choice for the next level of organization. I liked it a lot, and developed a healthy appreciation for GraphQL, but ultimately found it was like "React+" - you're really on your own in terms of ecosystem, and there is a ton of complexity going on to achieve what (for me) is a simple end goal, even after I got my head around the basic model (both React itself and then Gatsby over it). I still think highly of Gatsby in general and would revisit for a larger, more complicated project.

• Svelte/Sapper

I finally looked at Svelte, because I like the idea of an AOT compiler handling this complexity rather than a bunch of complex runtime logic. I didn't spend a lot of time with it, though, because it looked like a whole new set of stuff to learn, as well designed as it is, and that's precisely what I want to avoid. The Sapper repo looks a little dead, too, but that's not always a valid indicator. I'm keeping my eye on this as well, though.

Why Stencil Wins

I want to be crystal clear: I am not saying that stencil "wins". I am only saying it wins for me, for this project. I know I have a tendency to prod at controversial questions on DEV to see what happens, but this is not one of those posts.

Stencil is (mostly) just "Web". It's actually not a "framework" at all. Instead, it's a generator and compiler for Web Components, with some extra niceness built-in to streamline the process.

The Web is an inherently complicated platform, and frontend is not my primary target domain, so I do want some help taming that complexity. What I don't want is for that help to consist of a whole new set of specifics to learn which may or may not apply to anything else, and which has no guarantee of lasting relevance. That's been my experience with JQuery, Knockout, Ember, Meteor, React, Vue, Svelte, whatever else I've touched - even just listing stuff I've test driven makes my head spin and it's all new layers on top of an already complicated topic.

Now, it's a valid point that Web Components may very well represent yet another step along this chain. There's a phenomenal discussion here:

Why I don't use web components

Rich Harris ・ Jun 20 '19 ・ 7 min read

#html #webcomponents

My favorite quote from that discussion came from @josepot, who noted that "web-components are just leaky abstractions built on top of other leaky abstractions". That's hard to argue with. Still, though, what isn't?

I like how Stencil is focused first and foremost on compliance with existing standards. To write my app, I need to learn TypeScript, not some specific other tool. I also love how easy it's made it for me to piece together my app. The stencil generate tool can generate just your TSX or include a CSS stylesheet, a Jest component.spec.ts file, and a Puppeteer component.e2e.ts file. I'm forcing myself to use all of these for every component as an educational exercise, E2E testing in specific is something I've never experimented with, but it's great that it's all opt-in and you could keep it straightforward as long as you want.

Within minutes of loading up the template app I had added a new component and hooked it up to a new route with the handy built-in stencil-router component, purely based on what I already knew about HTML templates going in and the example provided. Sold!

Example Component

For a simple example, here's a component I put together to display a United States postal address:

import { Component, Prop, h } from '@stencil/core';
import { Address } from '../../cvdata';

@Component({
  tag: 'app-cv-address',
  styleUrl: 'cv-address.css',
  shadow: true
})
export class CvAddress {
  @Prop() address: Address;

  render() {
    if (this.address) {
      return (
        <p itemscope itemtype="https://schema.org/PostalAddress" id="address">
          <span itemprop="streetAddress">{this.address.street}</span><br />
          <span itemprop="addressLocality">{this.address.locality.name}</span>, <abbr title={this.address.locality.state.fullName} itemprop="addressRegion">{this.address.locality.state.abbreviation}</abbr> <span itemprop="postalCode">{this.address.locality.postalCode}</span><br />
          <span itemprop="addressCountry">{this.address.locality.state.country}</span>
        </p>
      );
    }
  }
}

It's just TypeScript, or an ES6 class, with some metadata stored in a decorator. JSX is a polarizing tool, but I think it's a good fit for the problem it solves. I've never used Angular but I think the "metadata-in-a-decorator" pattern is not entirely dissimilar.

This is the over-engineered Address TS interface I defined to pass in as a prop:

interface AddressRegion {
  fullName: string,
  abbreviation: string,
  country: string,
}

interface Locality {
  name: string,
  state: AddressRegion,
  postalCode: string,
}

export interface Address {
  street: string,
  locality: Locality
}

This is precisely why I like using TypeScript over JavaScript - familiarity. I'm used to tools that let me define the shape of my data up front, and get frustrated when debugging problems in vanilla JS that would have been caught by a typechecker. By setting this up before implementing, it's easy for me to dig through the object passed in as a prop. I know it's not technically any different than doing so without a defined interface, but I like it, dammit. Having my editor know what I'm doing is a huge help - I like my red squigglies showing me when I'm being stupid. Typechecked props by default is just awesome.

This was easy to pop in the larger context:

render() {
    return (
      <div>
        {/* other stuff... */}
        <app-cv-address address={this.data.address}></app-cv-address>
      </div>
    );
  }

No need to import anything, just use your new component! It couldn't be easier, and I'm off to the races.

Beyond the perceived technical merits of this tool, beginning to build this simple application with stencil is pretty much the only time I've ever actually enjoyed the process of writing a frontend application. I thought Gatsby was incredibly cool tech, and Svelte was a solid implementation of an elegant idea, but "fun" is a little more elusive for me in this space.

Why exactly this tool got me there when so many relatively similar others haven't is tricky for me to pinpoint, but I'm not fighting it. It's simple to get started with, based around core Web technologies that I know will continue to be relevant, and will allow complexity to grow as needed as opposed to including it up-front in a massive convoluted "starter app" template. I'm hoping this tool stays around for a long time and see no reason to hop around, at least for personal use, for the foreseeable future.

Photo by Karim MANJRA on Unsplash

Comments

[Ryan Smith]

I also landed on Stencil after trying all of the other big frameworks and built my site with it. It just feels right. It seems like other front-end libraries are "hacking" the web to get it to do their bidding, while Stencil embraces it and provides the same convenience as those frameworks. It is hard to justify the investment of learning a front-end framework that is not compatible with anything else and may eventually be replaced by the next big thing in 3-5 years. My only complaint so far is using JSX with it, I think I would prefer a template approach instead, but everything else has worked well.

[David Dal Busco]

My first impression was the same as yours, I would have rather like to use template, but now? I would like to use TSX everywhere 🤣

Cherry on top, I think, it could help developers with prior React experience to easily step in Stencil and likewise, for developers without React experience, it could help to step in React.

[Ben Lovy]

template approach

How tricky would this be to make work work with the tools as-is? I know the stencil tool does operate on a set of assumptions but at a glance this seems like the sort of thing you could do.

[Ryan Smith]

I think it can be done. I set up lit-html in Stencil and it seemed to work, but was kind of weird because I had to create a dummy element to attach lit-html to and call render() { render( document.querySelector("element") ) }. I'm sure that probably negated any compiler optimizations in Stencil. There might be a better way to do it, but I haven't explored it too much.

[Gabe Kangas]

It's nice to hear of somebody else who doesn't particularly enjoy building frontends. It seems sometimes that everyone is so passionate about web frontend development. I think building web frontends is a mess and no fun, but because it's 2020 I can't get away from it. It makes me feel like I'm the only one that feels that way! Good to know I'm not alone!

[Ben Lovy]

I think some of that might be perceived bias - DEV in particular is pretty frontend focused but it really is just a subset of all the engineering going on - thankfully so!

[David Dal Busco]

Great article Ben, thx for the share 👍

If I understand correctly what the Stencil team is currently cooking and also understand correctly that you like Rust, I might not be wrong saying that you might even gonna love more Stencil soon 😉

Check out this recent tweet from @adamdbradley 👉 twitter.com/adamdbradley/status/12...

[Ben Lovy]

You just made my month.

[Ghost]

I've noticed that you have written some Rust articles, I know Rust/wasm is not production ready yet (that is of course always debatable), but did you take a look on that?, how far from ready is it?,

I'm working in a personal project with Actix-web and soon I'll start dealing with the client side, I haven't started a heavy research on the client side yet but from what I've heard I'm considering: Svelte, Stencil or something in Rust, maybe Seed or Percy, but there seems to be very uncertain yet.

Did you considered some wasp alternative?, any interesting discovery on that front? or is too new/experimental yet?

[Ben Lovy]

Yep - My old site is in actix-web, and I plan to continue writing servers in hyper. Part of my goal here is to get more familiar with a more mainstream tech, so TypeScript was a primary driver.

As far as frontends go, I've tried both Yew and hand-rolling with web-sys - I wrote a quick write-up of the latter here:

Reactive Canvas with Rust/WebAssembly and web-sys

Ben Lovy ・ Jun 14 '19 ・ 11 min read

#rust #webassembly #beginners #tutorial

I think "uncertain" is exactly the word. Not a lot of "1.0" level crates, so you have to expect breaking API changes. I think this should be revisited after everything has had more time to bake, but is an exciting tech to watch.

For simple frontend sites, though, Rust is overkill. JS/TS is the right tool for a lot of cases. If you're doing all your work server-side, then it's a little more robust. I really like hyper.

For frontends, I've wanted to try seed for a while, would be curious to hear how it goes if you do. For rust web servers, I'm most excited about tide but again, we're a little early for it to be ready for use.

As for whether Rust is "production-ready" in a general sense, I think there are domains where it absolutely is, but the big thing that needs to happen is a larger set of "1.0"-stable crates.

[Ghost]

I guess we'll have to wait and see on the client side, in the server side I'm really happy so far with Actix-web, it was kinda hard for me at the start but once you start to get in the groove you even start to enjoy the API docs :D

PS: If you find yourself in the curious mode, take a look to SQLx (is a Rust SQL toolkit fully async with async-std and has forbidden non-safe code 8-o ) I just found it and look very promising, far from 1.0, but looks great.

[Ben Lovy]

I was also thrilled with actix-web 0.7, but the 1.0 breaking change threw me for a lurch and I haven't spent the time to sit down and learn the new API - I really should.

I saw a reddit post about that - looks very cool. The Rust ecosystem is full of cool stuff. Today I'm playing with cxx, a safer way to interface C++<->Rust than bindgen. It's like getting cool new toys every day.

[Esteban Hernández]

I liked Stencil at first but found event dispatching and handling to be unreliable and buggy. Haven't given it a second try in a while. Did you find handling events simple and reliable?

[David Dal Busco]

I use many events and handlers and never had trouble related to Stencil, even the contrary, I found easy to implement and reliable. Events are a core mechanism of our editor.

Only difficulty I once had was with the selection API but that's not related to Stencil but rather with the platforms and the compatibility of such API with Shadow Dom.

[Ben Lovy]

Interesting - that's good to know. So far in this app I've only handled onLoad and onClick and haven't needed to dispatch anything myself, so it's way too early to tell. How long ago did you try it?

[Esteban Hernández]

I think around August. A lot of the event handlers would fire only once or not at all.

[Ben Lovy]

Yikes. Will definitely be on the lookout for that, but so far so good.

[Sid]

I've had a great experience so far in building apps with svelte and sapper and ability to include web components and output web components . It seems like a good move to bet on web components but the way to create them is extremely verbose . I have a broader solution workspace when building in svelte , it's so close to html, CSS and plain js that the barrier of entry is low . For the new web app projects , I recommend to have a setup where the solution can accommodate web / vanilla js components with a server side framework that does a lot of heavy lifting . We cannot future proof everything , but atleast be prepared for it when someone comes along with a game changing idea

[Ben Lovy]

I've definitely still had my eye on this, next time I'm looking to set up a more interactive page I'd like to dive in.

[Raghav Misra]

Angular is pretty similar syntactically to Stencil, for what I have seen. Also, Angular has a way to create web components called Angular Elements. I haven't looked in to it much, but it's seems cool