larlet-fr-david-cache/cache/2021/0f1f65d09181752916216e892bb192d8/index.md

title: Using the platform
url: https://elisehe.in/2021/08/22/using-the-platform
hash_url: 0f1f65d09181752916216e892bb192d8

<p>I recently came across a series of articles by Daniel Kehoe where he introduces <a href="https://tutorials.yax.com/articles/build-websites-the-yax-way/quicktakes/what-is-the-yax-way.html"><em>The Stackless Way</em></a>, an optimistic take on web development that proposes we “use the platform” (modern features built into the language) instead of frameworks and build tools that keep getting replaced every few years.</p>

<p>It was good timing. While I’m a front-end developer at heart, I’ve rarely had the luxury of focusing on it full time. I’ve been dipping in and out of JavaScript, never fully caught up, always trying to navigate the ecosystem all over again each time a project came up. And framework fatigue is real!</p>

<p>So, instead of finally getting into Rollup to replace an ancient Browserify build on an old codebase (which could also really use that upgrade from Polymer to LitElement…), I decided to go “stackless”. I took a long-time idea for a motion design project and built it using nothing but features native to the browser: vanilla JS, ES6 modules and web components.</p>

<p>Working on a codebase with no dependencies has been a way of rediscovering exactly what I get for free in 2021, and what value I’m adding by bringing frameworks, transpilers and bundlers to the mix. I’d like to share what I learned (and what I needed to unlearn) in the process.</p>

<h3 id="the-project">The project</h3>
<p>The project itself, <a href="https://schematics.elisehe.in"><em>Schematics: A Love Story</em></a>, is a collection of animated diagrams from a visual poetry book by the same name. The animations dotted throughout this write-up are examples from the project: SVG created programmatically with modular, vanilla JavaScript, encapsulated in a web component, sitting inside a framework-free codebase.</p>

<figure class="image">
	<picture>
		<source srcset="https://d33wubrfki0l68.cloudfront.net/0d2f110a4e442af3495fdc556c2dbd92accc9255/5a69e/assets/post-assets/stackless/fig14-desktop.gif" media="(min-width: 750px)"></source>
    <img src="https://d33wubrfki0l68.cloudfront.net/d20fa5f0b97d59400afd9bae5611ceb9b1437c93/ed6db/assets/post-assets/stackless/fig14-mobile.gif" alt="Figure 14: A line spiralling upwards along a the time axis in a 3-dimensional coordinate system.">
	</picture>
  <figcaption>
		A diagram reproduced from <a href="https://julianhibbard.com">Julian Hibbard’s</a> <em>Schematics: A Love Story</em>, handcrafted with modern JavaScript.<br><a href="https://schematics.elisehe.in">See full collection</a>
  </figcaption>
</figure>

<h2 id="the-stackless-way">The Stackless Way</h2>

<p>Daniel Kehoe is not alone in his push-back on the complexity of the modern web. Frank Chimero’s <a href="https://frankchimero.com/blog/2018/everything-easy/"><em>Everything Easy is Hard Again</em></a> gets to me every time, and, more recently, I  enjoyed <a href="https://medium.com/codex/youre-missing-out-on-vanilla-js-91aceec917d6">this lighthearted rant</a> about the lack of appreciation for vanilla JS.</p>

<p>Appeals for external JS dependencies to be added with thoughtful intent have become common, but some schools of thought question the concept of single-page apps as a whole: server-side rendering is still a thing, after all. Pages can also be pre-built into a fully static site and served from a CDN (see <a href="https://jamstack.org/what-is-jamstack/">Jamstack</a>). These approaches recognise that we can move some of the complexity currently managed by front-end frameworks elsewhere on the stack.</p>

<p>But Kehoe’s series of articles on going stackless feels a little different. It’s not just about JavaScript — it’s a wholehearted devotion to the native features of the web as a platform (Routing? Just make sure every URL matches a .html file!)</p>

<p>There are limits to this kind of purism, of course. The Stackless Way, to me, is less of a realistic approach to building production web apps and more of a learning and introspection tool, a way to take a step back and fall in love with the platform again.</p>

<p>Being all about motion design, my own project relied on many a <code class="language-plaintext highlighter-rouge">setTimeout</code> and page transitions — a single-page app, really… just handcrafted. The two main technologies that made it possible are ES6 modules and web components, which, along with module CDNs, form the pillars of The Stackless Way.</p>

<h2 id="es6-modules">ES6 modules</h2>
<p>If you’ve been developing for the web for some time, you might remember doing this:</p>

<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">&lt;head&gt;</span>
  <span class="nt">&lt;script </span><span class="na">src=</span><span class="s">"/js/vendor/jquery.min.js"</span><span class="nt">&gt;&lt;/script&gt;</span>
  <span class="nt">&lt;script </span><span class="na">src=</span><span class="s">"/js/main.js"</span><span class="nt">&gt;&lt;/script&gt;</span>
  <span class="nt">&lt;script </span><span class="na">src=</span><span class="s">"/js/subscribe.js"</span><span class="nt">&gt;&lt;/script&gt;</span>
  <span class="nt">&lt;script </span><span class="na">src=</span><span class="s">"/js/gallery.js"</span><span class="nt">&gt;&lt;/script&gt;</span>
  <span class="c">&lt;!-- Many more script tags whose specific ordering was a source of bugs and frustration --&gt;</span>
<span class="nt">&lt;/head&gt;</span>
</code></pre></div></div>

<p>Listing all required scripts separately in the document <code class="language-plaintext highlighter-rouge">&lt;head&gt;</code> was all we could do given the lack of support for a native import/export mechanism in JavaScript. This was, of course, suboptimal:</p>

<ul>
  <li>each script tag initiates a HTTP request;</li>
  <li>there is no namespacing (all scripts exist in the global scope);</li>
  <li>the order of execution is linear, and maps directly onto the ordering of the script tags.</li>
</ul>

<p>To combat this, approaches to modularity in JavaScript have proliferated over the years (AMD, UMD, CommonJS), and along with them, build tools and bundlers to convert the modular code into something that the browser understands.</p>

<p>ECMAScript Modules (also referred to as ESM or ES6 Modules) is the first <em>native</em> standard for modules in JavaScript. I emphasise <em>native</em> here because that means we can ditch the build tools and bundlers in favour of <code class="language-plaintext highlighter-rouge">&lt;script type=“module”&gt;</code> in HTML and <code class="language-plaintext highlighter-rouge">import</code>/<code class="language-plaintext highlighter-rouge">export</code> in JS:</p>

<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">&lt;head&gt;</span>
  <span class="c">&lt;!-- Single entry point for a dependency graph of any depth --&gt;</span>
  <span class="nt">&lt;script </span><span class="na">type=</span><span class="s">"module"</span> <span class="na">src=</span><span class="s">"main.js"</span><span class="nt">&gt;&lt;/script&gt;</span>
<span class="nt">&lt;/head&gt;</span>
</code></pre></div></div>

<div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c1">// main.js</span>
<span class="k">import</span> <span class="nx">Gallery</span> <span class="k">from</span> <span class="dl">"</span><span class="s2">./Gallery.js</span><span class="dl">"</span><span class="p">;</span>
<span class="k">import</span> <span class="nx">SubscriptionForm</span> <span class="k">from</span> <span class="dl">"</span><span class="s2">./SubscriptionForm.js</span><span class="dl">"</span><span class="p">;</span>

<span class="c1">// Gallery.js</span>
<span class="k">import</span> <span class="nx">Swipe</span> <span class="k">from</span> <span class="dl">"</span><span class="s2">./helpers/gestures.js</span><span class="dl">"</span><span class="p">;</span>

<span class="k">export</span> <span class="k">default</span> <span class="kd">class</span> <span class="nx">Gallery</span> <span class="p">{}</span>
</code></pre></div></div>

<p><strong>Native support for modularity is the most important step towards a build-free codebase</strong>. If I had access to only one <a href="http://es6-features.org/">ES6 feature</a> for the rest of my life, I’m confident that modules would take me most of the way there when it comes to well-structured native JavaScript.</p>

<p>And not having to build your JS app is magical. Setting up the directory structure for <em>Schematics</em>, I was giddy with excitement skipping <code class="language-plaintext highlighter-rouge">npm run build</code> and seeing my source files mirrored — as is! — in the browser. It reminded me of when I first began building websites and double-clicking <code class="language-plaintext highlighter-rouge">index.html</code> was enough to see your work in the browser.</p>

<p>You do need a local server if you’re using ES6 modules (so double-clicking an HTML file might be a thing of the past for good). But there’s no lag between editing your code and seeing changes in the browser, and the source code you see in the inspector is exactly what you typed into your editor (no sourcemaps!).</p>

<p>Nevermind the faster edit-compile-debug cycle — this speaks directly to Chimero’s concern about the <a href="https://frankchimero.com/blog/2018/everything-easy/">lack of legibility in today’s codebases as an obstacle to learning the craft</a>:</p>

<blockquote>
  <p>Before, the websites could explain themselves; now, someone needs to walk you through it. Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. […] the best way to help someone <em>write</em> markup is to make sure they can <em>read</em> markup. (<a href="https://frankchimero.com/blog/2018/everything-easy/">Frank Chimero</a>)</p>
</blockquote>

<figure class="image">
	<picture>
		<source srcset="https://d33wubrfki0l68.cloudfront.net/5d8af1fbafa273e967948ac4fef631cb65230ef8/c1472/assets/post-assets/stackless/fig18-desktop.gif" media="(min-width: 750px)"></source>
    <img src="https://d33wubrfki0l68.cloudfront.net/17fab52ccc9fc287c87cb7cd801de4d371344419/e0067/assets/post-assets/stackless/fig18-mobile.gif" alt="Figure 18: A flow diagram for love. Good? Yes. More? Yes. Do it.">
	</picture>
  <figcaption>
		A diagram reproduced from <a href="https://julianhibbard.com">Julian Hibbard’s</a> <em>Schematics: A Love Story</em>, handcrafted with modern JavaScript.<br><a href="https://schematics.elisehe.in">See full collection</a>
  </figcaption>
</figure>

<p>I recommend reading Kehoe’s <a href="https://tutorials.yax.com/articles/javascript/import/index.html"><em>Javascript import explained</em></a> or Ayodeji’s <a href="https://medium.com/backticks-tildes/introduction-to-es6-modules-49956f580da"><em>Introduction to ES6 modules</em></a> for a historic overview of approaches to modularity, how we got to ESM, and how to write your own modules.</p>

<h3 id="the-future-of-app-bundles">The future of app bundles</h3>

<p>Just because you don’t strictly need a build tool to <em>run</em> your code, doesn’t mean you shouldn’t use one for production builds to optimise performance. I’m referring here not to transpilation, but to minification, mangling, tree-shaking, etc.</p>

<p>I’ve been bundling JavaScript into a single <code class="language-plaintext highlighter-rouge">app.js</code> file for such a long time that my first instinct was to concatenate everything into a single script on <em>Schematics</em>, too. This, of course, will not work with ES6 modules — the concept of files is what creates boundaries between different modules, and there is no way to specify more than one module per file.</p>

<p>Luckily, you don’t need to bundle your ES6 modules into a single file to improve performance. Let me repeat: <strong>you don’t need to bundle your ES6 modules into a single file to improve performance</strong>.</p>

<p>Here’s why:</p>

<ol>
  <li><code class="language-plaintext highlighter-rouge">&lt;script type=“module"&gt;</code> requests are deferred by default: they won’t block document parsing.</li>
  <li>Serving all modules from separate source files is great for caching, as the modules unaffected by some change can continue being retrieved from the cache. When you serve a single bundle, any one change will invalidate the whole bundle.</li>
  <li>You can lazy load parts of your code by making use of <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#dynamic_imports">dynamic imports</a> — importing modules during runtime at the point where you actually need them.</li>
  <li>You can preload critical modules with <a href="https://developers.google.com/web/updates/2017/12/modulepreload"><code class="language-plaintext highlighter-rouge">modulepreload</code></a>. This starts parsing and compiling the linked modules immediately, off the main thread.</li>
  <li>Finally, HTTP2 may in the future allow us to resolve the entire dependency graph from the first <code class="language-plaintext highlighter-rouge">&lt;script type=“module”&gt;</code> request, and send all required files back in a single response. For the time being, this requires bespoke logic written on the server side.</li>
</ol>

<p>And don’t forget about bundle size:</p>

<blockquote>
  <p>If you inspect the output code generated by most popular bundlers, you’ll find a lot of boilerplate whose only purpose is to dynamically load other code and manage dependencies, but none of that would be needed if we just used modules with import and export statements! (<a href="https://philipwalton.com/articles/using-native-javascript-modules-in-production-today">Philip Walton</a>)</p>
</blockquote>

<p>I still have some work to do to go against my first instinct to bundle. It’s not uncommon for a SPA to have hundreds of JavaScript files, and the prospect of serving them all separately seems counterintuitive. Even having read up on all the reasons why I don’t need to bundle my modules, I occasionally hesitated before separating some logic into its own file to avoid the extra request.</p>

<figure class="image">
	<picture>
		<source srcset="https://d33wubrfki0l68.cloudfront.net/ea47b365638fd85ec7952a63fafb1997530db2b2/b2b8c/assets/post-assets/stackless/fig20-desktop.gif" media="(min-width: 750px)"></source>
    <img src="https://d33wubrfki0l68.cloudfront.net/3835a734f4f22ce2dddee7654ebd561f17e23042/cceca/assets/post-assets/stackless/fig20-mobile.gif" alt="Figure 20: An illustration of the propagation of sound waves across arrays of vertical lines.">
	</picture>
  <figcaption>
		A diagram reproduced from <a href="https://julianhibbard.com">Julian Hibbard’s</a> <em>Schematics: A Love Story</em>, handcrafted with modern JavaScript.<br><a href="https://schematics.elisehe.in">See full collection</a>
  </figcaption>
</figure>

<p>For more details and interesting discussion around ES6 module load performance and app bundles, see <a href="https://esdiscuss.org/topic/fwd-are-es6-modules-in-browsers-going-to-get-loaded-level-by-level">this thread on the ECMAScript Discussion Archives</a>. The spec is not set in stone yet, and there are plenty of ideas floating around, some more daring than others (my personal favourite is the proposal to serve the entire module dependency graph as a .zip file).</p>

<blockquote>
  <p>There’s plenty of ongoing module work happening in Chrome, though, so we’re getting closer to giving bundlers their well-earned rest! (<a href="https://developers.google.com/web/updates/2017/12/modulepreload">Sérgio Gomes</a>)</p>
</blockquote>

<p>I also recommend reading <a href="https://philipwalton.com/articles/using-native-javascript-modules-in-production-today"><em>Using Native JavaScript Modules in Production Today</em></a> by Philip Walton. It explains how to serve optimised module files alongside a standard fallback single-file bundle for older browsers.</p>

<p>Finally, if you’re looking for an alternative to webpack that supports native modules, check out <a href="https://vitejs.dev">Vite</a> or <a href="https://rollupjs.org/">Rollup</a>.</p>

<h2 id="web-components">Web components</h2>

<p><a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components">Web Components</a> is an umbrella term for several native technologies (Custom Elements, Shadow DOM and HTML templates) that let us bundle the markup and dynamic behaviour of an element into a reusable piece of code, on a high level no different to the React or Vue component. As of May 2021, <a href="https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/"><em>All the Ways to Make a Web Component</em></a> lists 55 variants of a hypothetical <code class="language-plaintext highlighter-rouge">&lt;my-counter&gt;</code> component for comparison across bundle size, coding style and performance. Native web components, of course, stand out because they have no external dependencies (and, consequently, an unmatched tiny bundle size).</p>



<p>Here are some of my own impressions of web components as compared to external frameworks when it comes to DX and architecture.</p>

<h3 id="shadow-dom-and-template">Shadow DOM and <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code></h3>

<p>The shadow DOM, a way of keeping the internals of a component inaccessible to the main document, is a neat feature in theory, but a natural use case for it didn’t really arise when working on <em>Schematics</em>. I’ve played around with the shadow DOM in the past as part of a Polymer (now LitElement) project, and I mostly remember it creating more problems than it solved, especially when it came to styling. I can see the shadow DOM being useful in cases where a component is reused across many sites and in unpredictable contexts (such as elements in a UI library); for your standard <code class="language-plaintext highlighter-rouge">&lt;site-specific-header-dropdown&gt;</code>, it doesn’t add much value.</p>

<p>The <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code> and <code class="language-plaintext highlighter-rouge">&lt;slot&gt;</code> elements (the latter only useful if you’re using the shadow DOM) are presented as a means of adding hidden markup inside JS, but they feel clunky if you’re used to something like JSX. Additionally, the <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code> tag <a href="https://stackoverflow.com/a/53317973">seems counter-inuitive if the aim is to create portable components</a> that can be included in an app with a single import. When declared in the HTML, any JavaScript making use of the <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code> makes assumptions about what’s available to it in the main document. Indeed, at times the <code class="language-plaintext highlighter-rouge">index.html</code> in Schematics felt like a dumping ground for various <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code>s, rather than a neat overview of the page structure.</p>

<p><a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components/HTML_Imports">HTML Imports</a> was a proposal that might have allowed us to package JS and HTML together into a single bundle, making <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code> the star of the show. Unfortunately, the feature never took off.</p>

<p>Another <a href="https://github.com/whatwg/html/issues/2254">proposed feature</a> is a means to add variables, simple statements and event handlers to nodes in a <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code> tag. The gist of it is similar to what you’d currently see in front-end frameworks:</p>

<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">&lt;template</span> <span class="na">id=</span><span class="s">"card"</span><span class="nt">&gt;</span>
  <span class="nt">&lt;card&gt;</span>
    <span class="nt">&lt;h2&gt;</span>{{title}}<span class="nt">&lt;/h2&gt;</span>
    <span class="nt">&lt;div&gt;</span>{{description}}<span class="nt">&lt;/div&gt;</span>
    <span class="nt">&lt;a</span> <span class="na">href=</span><span class="s">"/card/{{id}}"</span><span class="nt">&gt;</span>Read more<span class="nt">&lt;/a&gt;</span>
    <span class="nt">&lt;button</span> <span class="na">handler=</span><span class="s">"onEdit"</span><span class="nt">&gt;</span>Edit<span class="nt">&lt;/button&gt;</span>
  <span class="nt">&lt;/card&gt;</span>
<span class="nt">&lt;/temlate&gt;</span>
</code></pre></div></div>

<p>Being accustomed to built-in data-binding in frameworks, until the variables above are automatically updated, the feature feels half-baked. As it stands, it’s difficult to gauge the full, declarative markup of a component in one place, as update logic is scattered throughout the class with query selectors, <code class="language-plaintext highlighter-rouge">innerHTML</code>, document fragments and the like.</p>

<p>If you’d like variable and event handler support in <code class="language-plaintext highlighter-rouge">&lt;template&gt;</code> now, GitHub, who <a href="https://github.blog/2021-05-04-how-we-use-web-components-at-github/">use vanilla web components internally</a>, provide <a href="https://github.com/github/template-parts">a polyfill</a> for the minimum viable bits of the proposal. As for data binding, Danny Moerkerke describes one approach to implementing it yourself: <a href="https://medium.com/swlh/https-medium-com-drmoerkerke-data-binding-for-web-components-in-just-a-few-lines-of-code-33f0a46943b3"><em>Data binding for Web Components in just a few lines of code</em></a>.</p>

<figure class="image">
	<picture>
		<source srcset="https://d33wubrfki0l68.cloudfront.net/d85e81c35756d05361c49b19e45743d3f40f6567/75587/assets/post-assets/stackless/fig36-desktop.gif" media="(min-width: 750px)"></source>
    <img src="https://d33wubrfki0l68.cloudfront.net/d0c8e2853dbe0b9a57cdfc78906026bff470b269/dd0d7/assets/post-assets/stackless/fig36-mobile.gif" alt="Figure 36: A swinging pendulum.">
	</picture>
  <figcaption>
		A diagram reproduced from <a href="https://julianhibbard.com">Julian Hibbard’s</a> <em>Schematics: A Love Story</em>, handcrafted with modern JavaScript.<br><a href="https://schematics.elisehe.in">See full collection</a>
  </figcaption>
</figure>

<h3 id="extending-native-elements">Extending native elements</h3>

<p>The web components feature I was most excited about, and one that a third-party framework inherently cannot provide, is <a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements#customized_built-in_elements">the ability to extend native HTML elements</a>. This allows you to inherit any built-in behaviour for that element in your component, including accessibility-specific properties. Unfortunatley, <a href="https://dev.to/lkraav/comment/ad06">Apple have decided not to support customizable elements in Safari</a>.</p>

<p>This is disappointing. Using front-end frameworks, we often implement our own, more snazzy versions of native HTML elements. Input elements especially, such as dropdowns and radio buttons, are tricky to style using CSS and often end up reproduced with JS. But reproducing the required ARIA attributes, keyboard navigation and the like requires extra effort — something we would get for free with customizable elements.</p>

<h3 id="components-all-the-way-down">Components all the way down?</h3>

<p>While ES modules sparked excitement for the future, I was left underwhelmed by the prospect of native web components replacing traditional front-end frameworks. In hindsight, weighing up web components against JS frameworks was missing the point of the exercise. It’s not about making more of your JavaScript vanilla; it’s spotting opportunities to forego JavaScript in the first place.</p>

<p>Being a React user, attaching my <code class="language-plaintext highlighter-rouge">App.js</code> root component to a <code class="language-plaintext highlighter-rouge">&lt;div id=“app”&gt;</code> root node and working down the tree, in smaller components, is how I’m used to thinking about SPAs. Though you <em>can</em> attach your component onto individual DOM nodes (and you could easily mix and match frameworks, too), the more standard approach is to let the framework drive the whole page.</p>

<p>This will quickly fall apart when using web components. At the level of the atomic UI element, they shine; for the business logic and user flows, you should defer to a different part of your stack. As for static content — why render it with JavaScript if raw markup does the job perfectly?</p>

<p>And so, I caught my mindset shifting from an app that’s just one big component to <em>not</em> using components by default, breaking the link between component and framework in the process.</p>

<p>In the case of <em>Schematics</em>, I ended up with just a couple of main custom elements sitting neatly in the middle of native HTML tags. A simplified illustration of the idea:</p>

<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">&lt;body&gt;</span>
  <span class="nt">&lt;header&gt;&lt;/header&gt;</span>
  <span class="nt">&lt;aside&gt;&lt;/aside&gt;</span>
  <span class="nt">&lt;main&gt;</span>
    <span class="nt">&lt;schematics-figure&gt;&lt;/schematics-figure&gt;</span>
    <span class="nt">&lt;schematics-figure-toolbar&gt;&lt;/schematics-figure-toolbar&gt;</span>
  <span class="nt">&lt;/main&gt;</span>
  <span class="nt">&lt;footer&gt;&lt;/footer&gt;</span>
<span class="nt">&lt;/body&gt;</span>
</code></pre></div></div>

<p>It seems obvious in hindsight that a component on a website should encapsulate the behaviour and appearance of some bit of UI. But, as <a href="https://dev.to/redbar0n/what-happened-to-components-being-just-a-visual-thing-22hc">this article nicely puts it</a>, with the proliferation of JS frameworks, “we’ve landed over in the ditch on the other side of the road: putting all sorts of behaviour into the same JSX-denoted structure as Components”.</p>

<blockquote>
  <p>“React renders your UI and responds to events” was <a href="https://youtu.be/x7cQ3mrcKaY?t=79">how it was introduced</a>. Not: “React is a way to transform and execute all your logic in a hierarchy of declarative markup”, as it has devolved into in many cases. (<a href="https://dev.to/redbar0n/what-happened-to-components-being-just-a-visual-thing-22hc">Magne</a>)</p>
</blockquote>

<figure class="image">
	<picture>
		<source srcset="https://d33wubrfki0l68.cloudfront.net/6d77f50ef261b769e44844c897ce310990d23906/7d632/assets/post-assets/stackless/fig43-desktop.gif" media="(min-width: 750px)"></source>
    <img src="https://d33wubrfki0l68.cloudfront.net/f544521286fe6c3c943b2adea827785c25f4ba91/21968/assets/post-assets/stackless/fig43-mobile.gif" alt="Figure 43: A 3D cube erratically rotating and changing size.">
	</picture>
  <figcaption>
		A diagram reproduced from <a href="https://julianhibbard.com">Julian Hibbard’s</a> <em>Schematics: A Love Story</em>, handcrafted with modern JavaScript.<br><a href="https://schematics.elisehe.in">See full collection</a>
  </figcaption>
</figure>

<hr>

<p>The above thoughts are mostly based on first impressions. If you’re interested in a more detailed review of the state of the web components spec, I recommend <a href="https://webreflection.medium.com/about-web-components-cc3e8b4035b0">this excellent article by Andrea Giammarchi</a> which takes a more critical look of the feature in the context of the 30-year history of the web.</p>

<h2 id="the-future-of-stackless">The future of stackless</h2>

<p><em>Schematics</em> was a simple project as far as architecture goes, and web components and ES6 modules took me most of the way there. I can’t see myself building a complex app without a framework. Fully static sites, too, are simpler to build using a generator like Jekyll: something like markup reuse across pages is impossible when you only have the browser and text editor to work with (the humble <code class="language-plaintext highlighter-rouge">&lt;iframe&gt;</code> might disagree with me here…).</p>

<p>Technical limitations aside, an issue I became aware of during this exercise was a lack of standards in vanilla JavaScript. Because we’re so used to the framework dictating how to structure our codebase, there aren’t many established guidelines should you decide to handcraft your JavaScript. Never mind the high-level architecture — even the way you define a class, use static variables, or implement composition all have a range of approaches to them. Web components fill in the gap when it comes to the UI; perhaps if more developers dared to go framework-free (when appropriate!) discussions around best practices would be more productive.</p>

<h2 id="know-the-platform">Know the platform</h2>

<p>Developing web apps without frameworks or build tools is not an end goal in and of itself. As Daniel Kehoe put it in the stackless newsletter:</p>

<blockquote>
  <p>I don’t think we’ll be talking about “stackless” in a few years. It’s just going to be part of any web developer’s professional bag of tricks.</p>
</blockquote>

<p>I’d love to see that happen. I have a special disdain for beginner JavaScript tutorials that have you run <code class="language-plaintext highlighter-rouge">create-react-app</code> as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.</p>

<hr>

<h3 id="postscriptum-stackless-stylesheets">Postscriptum: Stackless stylesheets?</h3>

<p>I’m so used to writing LESS or SCSS, or, more recently, setting up a set of PostCSS plugins, that <em>not</em> having a preprocessor didn’t cross my mind at first.</p>

<p>Indeed, Kehoe encourages the use of CSS frameworks and/or preprocessors <a href="https://tutorials.yax.com/articles/the-yax-way/2.html">“until libraries of custom UI elements are more broadly available”</a>.</p>

<p>But such a big part of the appeal of stackless for me was running <em>all</em> source code in the browser as is — having a preprocessing step for CSS would ruin that. So, in the spirit of the exercise I limited myself to vanilla CSS.</p>

<p>I persisted with this right up until the first media query came along, and things began to look nasty. Yes, modern CSS does get you 90% there; custom properties are a real workhorse (don’t forget, no preprocessor can give you properties that update during runtime, or that you can set/get via JavaScript). But the lack of native support for nested selectors (along with the parent selector) I cannot live without, and that extra 10% makes a world’s difference.</p>

<p>Stackless CSS isn’t there yet. Use a preprocessor.</p>