Hawk Ticehurst

Declarative signals

Mon, 30 Dec 2024 00:00:00 GMT

A year ago I published an article that talked about my experience using HTML Web Components, and at the end introduced a tiny framework called Stellar that makes the job of authoring reactive HTML web components a bit easier.

Since then, the project has largely sat untouched, acting more as a research exercise or a demonstration of the ideas I had been mulling over in 2023.

As 2024 comes to a close I've been working on an evolution to Stellar (my habit of mulling clearly hasn't changed). It's still a work in progress, but I've stumbled upon an idea that I think is worth sharing now.

What would happen if we had a way of defining signals directly in HTML?

Signals, in JavaScript

I'd wager that most who are reading this are at least a little bit familiar with signals.

At their most basic, signals are a method of defining and managing a small piece of state that can be used to update a user interface in a declarative/reactive way.

For even more information, see Corbin Crutchley's fantastic post: <a href="https://playfulprogramming.com/posts/what-are-signals">What are Signals?</a>.

Here's a small example of using signals in vanilla JavaScript.

<button>Count is <span id="count">0</span></button>

<script type="module">
	// The state function is used to create a signal
	import { state } from './signal.js';
	// The effect function is used to define what should happen
	// when the value of a signal changes
	import { effect } from './effect.js';

	// Get references to the button and span elements
	const button = document.querySelector('button');
	const span = document.querySelector('#count');

	// Initialize count signal
	const count = state(0);

	// Update the value of the count signal on each button click
	button.addEventListener('click', () => {
		count.value = count.value + 1;
	});

	// Update <span> with the current value of the count signal
	// This runs anytime the value of the count signal is updated
	effect(() => {
		span.textContent = `${count.value}`;
	});
</script>

I expect that last bit of effect code might look a tiny bit weird to folks who are used to using signals in a web framework. In most frameworks the code that is responsible for updating the DOM after a signal has been changed is hidden from (read: automatically generated for) you and I.

Removing the responsbility for developers to write this kind of DOM updating code is a fantastic idea and is one of the core selling points of a declarative UI programming model.

There is, however, a catch that I want to focus on today. Declarative signals, as they exist now, are always packaged in a larger web framework or component model. But what if you are working with a technology stack that doesn't natively support/provide signals?

You could adopt another framework into your stack that provides signals, but now you need to operate within the conventions of that framework. Or you could import a standalone signal library and write code similar to the example above, but now you're back to handling DOM updating logic.

While completely workable, I find both of these options to be a bit unsatisfying, which brings me to my final question:

Wouldn't it be great if there was an HTML element that handled reactive state management and rendering logic in a small package that could be used across any context and technology? What if we could write code that looked something like this?

<button>Count is <signal>0</signal></button>

<script>
	const button = document.querySelector('button');
	const count = document.querySelector('signal');
	button.addEventListener('click', () => {
		count.state = count.state + 1;
	});
</script>

Signals, as HTML

Obviously, there isn't a <signal> HTML element available today, but it doesn't mean we can't make one ourselves!

To jump straight in, we'll be building an <x-signal> custom element. Below is a very basic starter implementation of this custom element that will slowly be updated to include more features during the rest of this article.

import { Signal } from 'signal-polyfill';
import { effect } from './effect.js';

class SignalElement extends HTMLElement {
	constructor() {
		super();
		// Get initial value from the elements text content
		// Yes, this is weird -- I'll explain more in a bit
		const initial = this.textContent;
		// Create a new signal
		this.signal = new Signal.State(initial);
		// Everytime the signal value is updated rerender the element
		this.cleanup = effect(() => this.render());
	}
	connectedCallback() {
		// Render the element when it is first mounted to the DOM
		this.render();
	}
	disconnectedCallback() {
		// Run the effect cleanup when the element is destroyed
		this.cleanup();
	}
	render() {
		// Render the current value of the signal as the child
		// text content of the custom element
		this.textContent = this.signal.get();
	}
	// A getter method to access the current value of the signal
	get state() {
		return this.signal.get();
	}
	// A setter method to update the value of the signal
	set state(v) {
		this.signal.set(v);
	}
}

customElements.define('x-signal', SignalElement);

For the purposes of this demo we are using a polyfill of the JavaScript Signals proposal. The imported effect function is copied directly from the polyfill README.

The imported Signal class provides the core reactive primitive needed to make this all work and we are simply providing getter and setter methods named state to access and update the value of the signal.

For a great explainer on getters, setters, and signals see this <a href="https://www.youtube.com/watch?v=NR8L5m73dtE">video by Rich Harris</a>.

Finally, the rest of the custom element handles all of the rendering logic. For now the element can only handle strings, but even this basic implementation is enough to create one of the classic hello worlds of reactive UI programming.

<label for="input">Enter name:</label>
<input id="input" type="text" value="World" />
<p>Hello <x-signal>World</x-signal>!</p>

<script>
	const input = document.querySelector('input');
	const name = document.querySelector('x-signal');
	input.addEventListener('input', () => {
		name.state = input.value;
	});
</script>

<section class="render-container"> <div class="render-container-border"> <hello-world> <label for="input">Enter name:</label> <input id="input" type="text" value="World" /> Hello <x-signal>World</x-signal>! </hello-world> </div> </section>

HTML-based state

At this point, some of you may have already started to notice and question: How/where is the value of these signals being initialized? To answer that we need to quickly talk through a key idea from Stellar that I worked on last year.

Like many other web frameworks, the current version of Stellar ships a reactivity model that lets you declaratively define pieces of stateful UI.

Unlike other web frameworks, however, state is defined a little different than what you might have experienced when using tools like React, Svelte, or Vue. In most frameworks, state is defined in JavaScript and then passed into component markup using some type of templating syntax. In Stellar, this relationship is inversed. Reactive state is defined in HTML and then made accessible for manipulation in JavaScript.

I call it "HTML-based state."

In Stellar, this means a handful custom attributes called "directives" can be added to elements within a Stellar component to access the reactivity model.

A key part of all of this is that state is automatically initialized based on the existing text content, inner HTML, or property value of a stateful element.

As an example, the following Stellar code...

<p $state="text">Hello world!</p>

...should be interpreted in the following way:

The paragraph element is marked as stateful via the $state directive
The name of the state is "text" and can be accessed in JavaScript via this.text
The initial value of the state is the string "Hello world!"

While the syntax for x-signal looks a bit different (i.e. there are no directives), HTML-based state is also a key idea of <x-signal>.

<p><x-signal>Hello world<x-signal></p>

<script>
	const text = document.querySelector('x-signal');
	console.log(text.state); // Logs "Hello world"
</script>

You are literally encoding the initial value of your signal into HTML itself.

Let's do some coercion

Okay great, we can initialize a signal but we still have that pesky problem of text content being returned as a string in JavaScript.

In Stellar, all reactive state is coerced to the correct data type when being accessed in JavaScript. For example, if you were trying to define a count state initialized with the value 0 it will be coerced into type number. So let's just do the same for <x-signal>.

We'll also add the ability to set initial state via a state attribute which will be useful later when working with arrays and objects.

// NEW: Function for coercing a value to it's correct data type
function coerce(value) {
	if (!value) return;
	if (value === 'false' || value === 'true') {
		return value === 'true';
	}
	if (!isNaN(Number(value))) {
		return Number(value);
	}
	try {
		// Switch single quotes to double quotes, otherwise
		// JSON.parse will fail to parse what should be valid JSON
		const correctedValue = value.replace(/'/g, '"');
		const parsed = JSON.parse(correctedValue);
		if (Array.isArray(parsed)) return parsed;
		if (typeof parsed === 'object') return parsed;
	} catch (e) {
		// Not valid JSON, return the original value
	}
	return value;
}

class SignalElement extends HTMLElement {
	constructor() {
		super();
		// UPDATED: Coerce the text content of the element and
		// check for a state attribute
		const initial =
			coerce(this.getAttribute('state')) || coerce(this.textContent);
		this.signal = new Signal.State(initial);
		this.cleanup = effect(() => this.render());
	}
	render() {
		// UPDATED: Coerce signal to a string before rendering it
		this.textContent = `${this.signal.get()}`;
	}
	// ... other methods ...
}

And with those changes, we now can implement the next classic hello world of reactive UI programming.

<button>Count is <x-signal>0</x-signal></button>

<script>
	const button = document.querySelector('button');
	const count = document.querySelector('x-signal');
	button.addEventListener('click', () => {
		count.state = count.state + 1;
	});
</script>

<section class="render-container"> <div class="render-container-border"> <counter-button> <button>Count is <x-signal>0</x-signal></button> </counter-button> </div> </section>

Rendering HTML

Next on the list of useful features that are commonly needed for reactive UI programming is the ability to reactively update the inner HTML of an element instead of the text content.

class SignalElement extends HTMLElement {
	constructor() {
		super();
		// NEW: A flag for checking if the render attribute is set
		this.isHTML = this.getAttribute('render') === 'html';
		// UPDATED: Handle HTML rendering
		const initial = this.isHTML
			? coerce(this.getAttribute('state')) || this.innerHTML
			: coerce(this.getAttribute('state')) || coerce(this.textContent);
		// ... other code ...
	}
	render() {
		// UPDATED: Handle HTML rendering
		if (this.isHTML) {
			this.innerHTML = this.signal.get();
		} else {
			this.textContent = `${this.signal.get()}`;
		}
	}
	// ... other methods ...
}

And now we have the pieces needed to create a basic markdown editor/renderer with surprisingly little code.

<markdown-editor>
	<textarea># Hello markdown!</textarea>
	<x-signal render="html">
		<h1>Hello markdown!</h1>
	</x-signal>
</markdown-editor>

<script>
	import { marked } from 'https://unpkg.com/marked@9.0.3/lib/marked.esm.js';
	const editor = document.querySelector('textarea');
	const output = document.querySelector('x-signal');
	editor.addEventListener('input', () => {
		output.state = marked(editor.value);
	});
</script>

This example includes a second custom element (<code>markdown-editor</code>), but no JavaScript definition for that element. In this case, we've created a <a href="https://hawkticehurst.com/2024/11/css-web-components-for-marketing-sites/">CSS Web Component</a> to wrap the text area and signal for the purpose of adding styles.

<section class="render-container"> <div class="render-container-border"> <markdown-editor> <textarea># Hello markdown!</textarea> <x-signal render="html"> <h1>Hello markdown!</h1> </x-signal> </markdown-editor> </div> </section>

Rendering state in a custom way

So far we've seen examples of when the underlying state is perfectly reflected to the DOM. But what about when the underlying data/state is different than how that data/state is rendered?

We can add the ability to pass in a callback that will mutate how the data contained in a signal is rendered.

class SignalElement extends HTMLElement {
	constructor() {
		super();
		// UPDATED: Initialize mutation property and
		// add a default callback that does nothing
		this.mutation = (state) => state;
		// ... other code ...
	}
	render() {
		// UPDATED: Mutate state before rendering
		const value = this.mutation(this.signal.get());
		if (this.isHTML) {
			this.innerHTML = value;
		} else {
			this.textContent = `${value}`;
		}
	}
	// NEW: Add a method to set the custom mutation callback
	set customRenderer(callback) {
		this.mutation = callback;
		this.render();
	}
	// ... other methods ...
}

I personally don't like the property name <code>customRenderer</code>, but I couldn't think of something better. If you have better ideas please do suggest them!

Here's an example of rendering text content in a custom way based on the values in an array passed to the state attribute we implemented earlier.

<p>
	<x-signal id="numbers" state="[1,2,3,4]">1 + 2 + 3 + 4</x-signal> =
	<x-signal id="sum">10</x-signal>
</p>
<button>Add number</button>

<script>
	const button = document.querySelector('button');
	const numbers = document.querySelector('#numbers');
	const sum = document.querySelector('#sum');
	numbers.customRenderer = (state) => {
		return state.join(' + ');
	};
	button.addEventListener('click', () => {
		numbers.state = [...numbers.state, numbers.state.length + 1];
		sum.state = numbers.state.reduce((s, c) => s + c, 0);
	});
</script>

<section class="render-container"> <div class="render-container-border"> <add-numbers> <x-signal id="numbers" state="[1,2,3,4]">1 + 2 + 3 + 4</x-signal> = <x-signal id="sum">10</x-signal> <button>Add number</button> </add-numbers> </div> </section>

Here's an example of rendering inner HTML in a custom way to create a todo list.. or at least a partial implementation of one.

<label for="todo-input">Add todo:</label>
<div>
	<input id="todo-input" type="text" />
	<button>Add</button>
</div>
<x-signal state="['Get groceries']" render="html">
	<ul>
		<li>Get groceries</li>
	</ul>
</x-signal>

<script>
	const input = document.querySelector('input');
	const button = document.querySelector('button');
	const todos = document.querySelector('x-signal');
	todos.customRenderer = (state) => {
		return `<ul>
			${state.map((todo) => `<li>${todo}</li>`).join('')}
		</ul>`;
	};
	function addTodo() {
		if (input.value.length > 0) {
			todos.state = [...todos.state, input.value];
			input.value = '';
		}
	}
	input.addEventListener('keydown', (event) => {
		if (event.key === 'Enter') {
			addTodo();
		}
	});
	button.addEventListener('click', addTodo);
</script>

<section class="render-container"> <div class="render-container-border"> <todo-list> <label for="todo-input">Add todo:</label> <div class="todo-input-container"> <input id="todo-input" type="text" /> <button id="todo-btn">Add</button> </div> <x-signal id="todos" state="['Get groceries']" render="html"> <ul> <li>Get groceries</li> </ul> </x-signal> </todo-list> </div> </section>

Derived state

So far we've only covered a very basic usage of signals, but what about derived/computed state?

We can use Signal.Computed provided by the signal polyfill to create a computed property.

class SignalElement extends HTMLElement {
	// ... other methods ...
	set computed(callback) {
		// Clean up existing signal
		this.cleanup();
		// Reset existing signal with a computed signal
		this.signal = new Signal.Computed(callback);
		// Redefine effect code for this new computed signal
		this.cleanup = effect(() => this.render());
	}
}

And now we can pass a callback to that property that will correctly derive new state based on the value of existing state.

<button>Count is <x-signal id="count">0</x-signal></button>
<p>Doubled: <x-signal id="doubled">0</x-signal></p>

<script>
	const button = document.querySelector('button');
	const count = document.querySelector('#count');
	const doubled = document.querySelector('#doubled');
	button.addEventListener('click', () => {
		count.state = count.state + 1;
	});
	doubled.computed = () => count.state * 2;
</script>

<section class="render-container"> <div class="render-container-border"> <double-count> <button>Count is <x-signal id="count">0</x-signal></button> Doubled: <x-signal id="doubled">0</x-signal> </double-count> </div> </section>

And with that, we've completed an implementation of <x-signal>!

What did we miss?

There's certainly a fair few edge cases and questions that were missed in this article, but I'll cover two of them now.

Reactive properties

In Stellar and other reactive frameworks you have the ability to define reactive properties. For example, the value property on a slider/range element. While I haven't gotten around to implementing it, I believe it should be possible to wrap an HTML element with <x-signal> and reactively track a property of that element.

<x-signal track="value">
	<input type="range" value="1" />
<x-signal>

<script>
	const slider = document.querySelector("x-signal");
	console.log(slider.state) // Logs 1
	slider.state = 8;
	console.log(slider.state) // Logs 8
</script>

State that starts in the server

Another idea worth calling out is that while the examples in this article demonstrate handwriting state directly inside HTML elements, the real use case is to declare initial state in your server and pass the state into <x-signal> using the templating language of your server framework.

When used in a framework like Astro, initial element state can start in the server, be encoded directly into your HTML, and then be seamlessly hydrated on the client without any layout shift issues or flashes of new content once JavaScript is parsed and executed.

---
// Server data
const data = [1, 2, 3, 4];
---

<add-numbers>
	<p>
		<x-signal id="numbers" state={JSON.stringify(data)}>
			{data.join(' + ')}
		</x-signal> =
		<x-signal id="sum">
			{data.reduce((s, c) => s + c, 0)}
		</x-signal>
	</p>
	<button>Add number</button>
</add-numbers>

<script>
	import './signal-element.js';
	// Add numbers client code
</script>

<style>
	/* Styles */
</style>

Islets architecture

To close out, I'll end this article with one more thought.

As I've discussed a few times before, custom elements are the perfect technology for implementing the islands architecture. Each custom element becomes it's own island of interactivity within a larger sea of static HTML.

With <x-signal> I think we've stumbled upon an even lower level to this idea. An island that contains and reactively renders a single unit of data, such as a number, a string, an array, a snippet of HTML, and so on.

In a sea of static HTML and islands, we've discovered a tiny island... an islet.

If you want to see the full implementation of <x-signal> or try it for yourself, I've uploaded a self-contained implementation to the vnext branch of the Stellar repo. If you run into any questions or bugs feel free to open an issue or [at] me on Bluesky or Mastodon.

const todoInput = document.querySelector("#todo-input");
const todoBtn = document.querySelector("#todo-btn");
const todos = document.querySelector("#todos");
function addTodo() {
	if (todoInput.value.length > 0) {
		todos.state = [...todos.state, todoInput.value];
		todoInput.value = "";
	}
}
todos.customRenderer = (state) => {
	return `<ul>${state.map(todo => `<li>${todo}</li>`).join("")}</ul>`;
};
todoInput.addEventListener('keydown', (event) => {
	if (event.key === 'Enter') {
		addTodo();
	}
});
todoBtn.addEventListener("click", addTodo);

const counterBtn = document.querySelector('counter-button button');
const count = document.querySelector('counter-button button x-signal');
counterBtn.addEventListener('click', () => {
	count.state = count.state + 1;
});

const input = document.querySelector('hello-world input');
const name = document.querySelector('hello-world x-signal');
input.addEventListener('input', () => {
	name.state = input.value;
});

import { marked } from 'https://unpkg.com/marked@9.0.3/lib/marked.esm.js';
const editor = document.querySelector('markdown-editor textarea');
const output = document.querySelector('markdown-editor x-signal');
editor.addEventListener('input', () => {
	output.state = marked(editor.value);
});

const button = document.querySelector('add-numbers button');
const numbers = document.querySelector('add-numbers #numbers');
const sum = document.querySelector('add-numbers #sum');
numbers.customRenderer = (value) => {
	return value.join(' + ');
};
button.addEventListener('click', () => {
	numbers.state = [...numbers.state, numbers.state.length + 1];
	sum.state = numbers.state.reduce((s, c) => s + c, 0);
});

const doubleBtn = document.querySelector("double-count button");
const doubleCount = document.querySelector("double-count #count");
const doubled = document.querySelector("double-count #doubled");
doubleBtn.addEventListener("click", () => {
	doubleCount.state = doubleCount.state + 1;
});
doubled.computed = () => doubleCount.state * 2;

</script>

CSS Web Components for marketing sites

Mon, 04 Nov 2024 00:00:00 GMT

Hot take: I think "regular" web components (the ones with Shadow DOM and friends) are a terrible solution for marketing website design systems.

It has always left a bad taste in my mouth when I run across a web component for a swimlane, banner, card, and so on. Why? Because these are components that (unless you're doing something mighty fancy) should never require JavaScript as a dependency.

But, in the world of web components you are locked into JavaScript from the very start. To even register a web component with the browser you need JavaScript.

But what if... we didn't do that?

HTML Web Components

I've spent a good chunk of the last year focused on marketing site design systems at work. A regular topic of discussion is the need to build marketing sites that are accessible to folks with lower powered devices and poor internet connections. How do you achieve that? In short, use less JavaScript and ideally build UI with progressive enhancement in mind.

There are many ways to achieve these goals, but the method I've been focused on is how an HTML Web Component archictecture might be applied to implement a marketing site design system.

As a quick reminder/intro, HTML Web Components is a method of building web components where you write HTML as you would normally and then wrap the parts you want to be interactive using a custom element.

For example, if you wanted to create a counter button it would look like this:

<counter-button>
  <button>Count is <span>0</span></button>
</counter-button>

<style>
  counter-button button {
    /* Counter button styles */
  }
</style>

<script>
  class Counter extends HTMLElement {
    // Counter button behavior
  }
  customElements.define("counter-button", Counter);
</script>

The markup in an HTML web component is parsed, rendered, and styled as normal HTML. That HTML will then be seamlessly hydrated once the JavaScript associated with the custom element tag is executed.

In contrast, the markup of a "regular" web component (that uses Shadow DOM) is dynamically generated at runtime using JavaScript -- kind of like an SPA.

This component architecture is a really strong candidate for a marketing design system (and, as a bonus, avoids some of the big gotchas that come with regular web components).

It is a perfect implementation of progressively enhanced UI
It uses minimal and self-contained JavaScript -- HTML Web Components can be thought of as islands
You still get the power of custom element APIs to implement stuff like design system component variants
The component markup is fully SSR-able
The component markup can be styled like regular HTML
Common accessibility practices can be applied without issue

But for all these benefits we're still left with the original problem. HTML Web Components require JavaScript.

CSS Web Components

So here's the question: What would happen if we took the ideas of HTML Web Components and skipped all the JavaScript?

You get CSS Web Components.

Note: I've never seen anyone talk about or name this concept before, so I'm using "CSS Web Components" to describe the idea. But please let me know if someone has already written about and named this!

How do they work? The exact same as HTML Web Components but you just take advantage of the powers of CSS to implement key functionality.

As an example let's implement that swimlane component:

<swim-lane>
  <section>
    <h2>Creativity unleashed</h2>
    <p>A brand new way of illustrating for the web.</p>
    <a href="/product">Learn more</a>
  </section>
  <img src="product.jpg" alt="Product image" />
</swim-lane>

<style>
  swim-lane {
    display: flex;
    align-items: center;
    gap: 2rem;
    color: white;
    background: black;
    padding: 1rem;
    border-radius: 16px;
  }
  swim-lane h2 {
    /* Swimlane title styles */
  }
  swim-lane p {
    /* Swimlane description styles */
  }
  swim-lane a {
    /* Swimlane link styles */
  }
  @media (max-width: 650px) {
    /* Mobile responsive styles */
  }
</style>

<section class="render-container"> <div class="render-container-border"> <swim-lane> <section> <h2>Creativity unleashed</h2> A brand new way of illustrating for the web. <a href="#">Learn more</a> </section> <img src="/imgs/ephemeral-canvas.jpg" alt="Product image"> </swim-lane> </div> </section>

Okay great, we styled some HTML nested inside a custom element. There's nothing too novel about that. But what about adding some functionality? Say, a component variant that lets you reverse the layout of the swimlane?

It's possible using only CSS! Specifically, CSS attribute selectors.

<swim-lane layout="reverse">
  <section>
    <h2>Creativity unleashed</h2>
    <p>A brand new way of illustrating for the web.</p>
    <a href="/product">Learn more</a>
  </section>
  <img src="product.jpg" alt="Product image" />
</swim-lane>

<style>
  /* Other swimlane styles */
  swim-lane[layout="reverse"] {
    flex-direction: row-reverse;
  }
  @media (max-width: 650px) {
    swim-lane[layout="reverse"] {
      flex-direction: column-reverse;
    }
  }
</style>

<section class="render-container"> <div class="render-container-border"> <swim-lane layout="reverse"> <section> <h2>Creativity unleashed</h2> A brand new way of illustrating for the web. <a href="#">Learn more</a> </section> <img src="/imgs/ephemeral-canvas.jpg" alt="Product image"> </swim-lane> </div> </section>

Another really cool perk of this is that because you're defining an attribute on a custom element you don't have to worry about naming collisions with HTML attributes. No need to add data- to the beginning of attributes like you would/should on normal HTML elements.

How far does this go?

In theory, I believe this method of building design systems can go quite far. If you think about it, the vast majority of basic components you might need in a marketing design system are just vanilla HTML elements with specific style variations.

A marketing website button is just an anchor tag wrapped in a <link-button> custom element and styled using custom attribute selectors.

<link-button>
  <a href="">Learn more</a>
</link-button>
<link-button variant="secondary">
  <a href="">Learn more</a>
</link-button>
<link-button pill>
  <a href="">Learn more</a>
</link-button>
<link-button size="large">
  <a href="">Learn more</a>
</link-button>

<style>
  link-button a {
    /* Default link button styles */
  }
  link-button[variant="secondary"] a {
    background: transparent;
    color: white;
  }
  link-button[pill] a {
    border-radius: 50px;
  }
  link-button[size="large"] a {
    padding: 10px 20px;
    font-size: 1.25rem;
  }
</style>

<section class="render-container"> <div class="render-container-border"> <section class="button-container"> <link-button> <a href="#">Learn more</a> </link-button> <link-button variant="secondary"> <a href="#">Learn more</a> </link-button> <link-button pill> <a href="#">Learn more</a> </link-button> <link-button size="large"> <a href="#">Learn more</a> </link-button> </section> </div> </section>

From here, imagine incorporating all the other powers that CSS (and HTML) bring to the table:

Cascade layers for better control of how styles get applied
Container queries for conditional style variants based on a parent container
:has(), :is(), and :where() to simplify complex selectors
CSS variables for theming
@property rule for even more powerful CSS variables
light-dark() for system aware theming
Popover API for menus, toggletips, and dialogs without JS
Exclusive accordions for FAQ sections

The possibilities are quite large.

What do you think?

Bring your own base class

Mon, 20 May 2024 00:00:00 GMT

Last December I started a series of blog posts that introduced and explored the world of web components. Holiday obligations followed by several months of wedding planning, a move, and an upcoming grad school application meant the series has had to take a pause, but today we're finally back with the seventh installment!

You can thank Chris Coyier for this post. A discussion on Mastodon reminded me of the topic I wanted to talk about and so despite looming deadlines and better judgement I've been spurred to put pen to paper.

The basic idea of Chris's post is that web components stand out as a frontend technology that may finally break the curse of framework dependent componentry always eventually ending up in the proverbial tech junkyard. Aka, web components have the potential to last a life time. But there's one major caveat: you must write dependency-free web components (read: without a framework).

Many often lament creating dependency-free web components because, for lack of better words, it's a pain. in. the. butt.

But this doesn't have to be the case. Building dependency-free web components that last a life time does not have to mean a bad developer experience.

Today we're talking about web component base classes.

Web components are built on inheritance

Before we jump in we need to do some quick context setting.

When I say "base class" it's really just a casual (and slightly wrong) way of saying class inheritance and is used everywhere in the world of web components. Class inheritance is used to create layers of abstraction where new functionality can be built on top of existing functionality.

Every single web component framework today uses a base class to expose it's behavior. In fact, even vanilla web components use class inheritance.

class MyComponent extends HTMLElement {}
class MyComponent extends LitElement {}
class MyComponent extends FASTElement {}

In the above examples HTMLElement, LitElement, and FASTElement could all be casually referred to as web component base classes.

Note: If we're being precise, a base class is actually defined as a class that doesn't extend anything else. So in the above example <code>HTMLElement</code> itself is the only true "base class." Under the hood classes like <code>LitElement</code> and <code>FASTElement</code> all eventually extend <code>HTMLElement</code>.

It's common to see more mature web component frameworks using a few layers of class inheritance and a few thousand lines of code to implement their functionality. For example, Lit's inheritance chain currently looks like this: LitElement extends ReactiveElement extends HTMLElement.

While it's certainly daunting to look at a wall of code like that and think you have no choice but to use a web component framework to get a good component authoring experience I'm hear to say that is not at all the case.

Creating good dependency-free web component DX

Creating your own productive web component base class is actually pretty easy. Below are a few examples of how very little code can enable a desirable web component authoring experience.

Clean up the boilerplate!

The most basic example of the usefulness of a base class is to clean up all that boilerplate we try to avoid by using frameworks.

In under 20 lines of code we can abstract away some of the most annoying details of building web components –– namely configuring Shadow DOM and simplifying markup creation by enforcing the use a render method, similar to Lit.

class BaseElement extends HTMLElement {
	constructor() {
		super();
		this.shadow = this.attachShadow({ mode: 'open' });
	}
	connectedCallback() {
		this._render();
	}
	_render() {
		if (!this.render) {
			throw new Error(
				'Web components extending BaseElement must implement a `render` method.'
			);
		}
		const markup = this.render();
		const template = document.createElement('template');
		template.innerHTML = `${markup}`;
		this.shadow.appendChild(template.content.cloneNode(true));
	}
}

Here it is in action. Pretty nice right?

class MyComponent extends BaseElement {
	render() {
		return `<h1>Hello! I'm in the Shadow DOM!</h1>`;
	}
}

Make it pop

How about convenient styling? Several more lines of code adds the ability to use the Constructable Stylesheets Web API with some nice fallback functionality for browsers that don't support this API.

class BaseElement extends HTMLElement {
	constructor() {
		super();
		this.shadow = this.attachShadow({ mode: 'open' });
	}
	connectedCallback() {
		this._render();
	}
	_render() {
		if (!this.render) {
			throw new Error(
				'Web components extending BaseElement must implement a `render` method.'
			);
		}
		const markup = this.render();
		const styles = this.constructor.styles || '';
		const template = document.createElement('template');
		const useConstructableStyleSheets =
			this.shadow.adoptedStyleSheets !== undefined;
		if (styles.length > 0 && useConstructableStyleSheets) {
			const sheet = new CSSStyleSheet();
			sheet.replaceSync(styles);
			this.shadow.adoptedStyleSheets = [sheet];
		}
		template.innerHTML = `
      ${
				styles.length > 0 && !useConstructableStyleSheets
					? `<style>${styles}</style>`
					: ''
			}
      ${markup}
    `;
		this.shadow.appendChild(template.content.cloneNode(true));
	}
}

And now we have some easy to author component styles!

class MyComponent extends BaseElement {
	static styles = `
		h1 { 
			color: teal;
			font-family: cursive;
			font-size: 1.4rem;
		}
	`;
	render() {
		return `<h1>Hello! I'm in the Shadow DOM!</h1>`;
	}
}

Declarative interactivity

As a final example, we can use the NodeIterator Web API to add custom declarative event binding syntax (i.e. @click). It can handle native browser events and custom events.

class BaseElement extends HTMLElement {
	constructor() {
		super();
		this.shadow = this.attachShadow({ mode: 'open' });
		this._listeners = [];
	}
	connectedCallback() {
		this._render();
	}
	disonnectedCallback() {
		for (const { elem, event, callback } of this._listeners) {
			elem?.removeEventListener(event, callback);
		}
	}
	_render() {
		if (!this.render) {
			throw new Error(
				'Web components extending BaseElement must implement a `render` method.'
			);
		}
		const markup = this.render();
		const styles = this.constructor.styles || '';
		const template = document.createElement('template');
		const useConstructableStyleSheets =
			this.shadow.adoptedStyleSheets !== undefined;
		if (styles.length > 0 && useConstructableStyleSheets) {
			const sheet = new CSSStyleSheet();
			sheet.replaceSync(styles);
			this.shadow.adoptedStyleSheets = [sheet];
		}
		template.innerHTML = `
			${
				styles.length > 0 && !useConstructableStyleSheets
					? `<style>${styles}</style>`
					: ''
			}
      ${markup}
    `;
		this.shadow.appendChild(template.content.cloneNode(true));
		this._configureEventListeners(this.shadow);
	}
	_configureEventListeners(rootNode) {
		let node;
		const nestedCustomElements = [];
		// Create a node iterator to iterate through all elements in the shadow root
		const iterator = document.createNodeIterator(
			rootNode,
			NodeFilter.SHOW_ELEMENT,
			{
				// Function for filtering out nodes we can skip
				acceptNode: (node) => {
					// Reject any node that is not an HTML element
					if (!(node instanceof HTMLElement)) {
						return NodeFilter.FILTER_REJECT;
					}
					// Check if node is a nested custom element
					if (node.tagName.includes('-') && node.tagName !== this.tagName) {
						nestedCustomElements.push(node);
						return NodeFilter.FILTER_REJECT;
					}
					// Check if node is a child of a nested custom element
					for (const nested of nestedCustomElements) {
						if (nested.contains(node)) {
							return NodeFilter.FILTER_REJECT;
						}
					}
					return NodeFilter.FILTER_ACCEPT;
				},
			}
		);
		// Iterate through all nodes in the shadow root
		while ((node = iterator.nextNode())) {
			if (!node) return;
			for (const attr of node.attributes) {
				// Check for custom event listener attributes
				if (attr.name.startsWith('@')) {
					this._processEventHandler(attr);
				}
			}
		}
		for (const { elem, event, callback } of this._listeners) {
			elem?.addEventListener(event, callback);
		}
	}
	_processEventHandler(attr) {
		const elem = attr.ownerElement;
		// Extract the name and value of the attribute
		// Example: `@click="handleClick"` -> `click` event and `handleClick` method
		const { name: event, value: method } = attr;
		this._listeners.push({
			elem: elem,
			event: event.slice(1),
			callback: (e) => this[method](e),
		});
		// Remove (non-standard) attribute from element
		elem.removeAttributeNode(attr);
	}
}

And voila, declarative event binding!

class MyComponent extends BaseElement {
	static styles = `
		button { 
			color: white;
			background-color: rgb(95, 85, 236, 0.5);
			border: 2px solid rgb(95, 85, 236);
			border-radius: 8px;
			padding: 6px 10px;
		}
	`;
	render() {
		return `<button @click="helloMsg">Click me!</button>`;
	}
	helloMsg() {
		alert('Hello there!');
	}
}

So many possibilities

In less than 100 lines of code we've built a dependency-free web component base class that I'd argue gets us 80% of the way to a "proper" web component framework in terms of functionality and usability.

Obviously, the notable missing piece from this post is reactivity. It's not too much harder to implement once you learn some of the basic concepts, but I ran out of time to go over that today. I won't leave you hanging though, here's an example of a reactive HTML web components implementation in ~250 lines of code that I made last year.

Beyond that, however, there are so many possibilities for tweaking and adjusting the examples I gave above to suit your personal preferences. Perhaps you don't like render as a method name or you want to add more custom attribute syntax that enables new behavior using the NodeIterator API –– the possibilities are basically endless.

Go forth and build dependency-free components that are fun to write and last a life time.

I want a marketplace of base classes

To leave with a final thought, I have often dreamed about the idea of a marketplace of web component base classes.

Imagine an UnJS-like ecosystem of composable base classes that all have one tightly scoped purpose and can be freely mixed and matched to build up the ideal component authoring experience for each job.

To keep in the spirit of Chris's Mastodon post, all base classes would need to be built without any dependencies and would simply be copy-pasted into each project (à la shadcn/ui).

If there's any interest in this idea, I'd love to hear what the community thinks a base class contract/protocol should look like so anyone could hook into and build for this composable ecosystem. I'd like to write my thoughts on this one day (and perhaps even build some of it), but first I've got a wedding to get to 😁.

Until the next one!

Web components reading list

Mon, 18 Dec 2023 00:00:00 GMT

Welcome back to 7 Days of Web Components! A series of interactive blog posts that introduces and explores the world of web components.

This is the post for day six, if you missed the previous posts I encourage you to go back to day one and start there.

Today we're taking a breather to highlight the work and thoughts of others!

This reading list includes a smattering of some of my all time favorite web component blog posts and resources. It's organized in no particular order so feel free to skim and pick up one that looks interesting!

My web component reading list

In the next episode...

Thanks for stopping by! I hope you find an enjoyable read and/or something new!

Follow me on Mastodon for updates and see you in the next one!

Next post: Bring your own base class

Web components in VS Code

Sun, 17 Dec 2023 00:00:00 GMT

Welcome back to 7 Days of Web Components! A series of interactive blog posts that introduces and explores the world of web components.

This is the post for day five, if you missed the previous posts I encourage you to go back to day one and start there.

Today we're talking about an IRL (in real life) open-source component library built with web components. It also happens to be a component library that I built and maintain as part of my day job at Microsoft –– it's the Webview UI Toolkit for VS Code.

In this post, we're going to talk through some specific examples of how this library is built and some other thoughts and musings.

Please note: This blog post includes interactive code examples. If you're reading this from an RSS feed, I highly recommend you open the original post.

The toolkit

The Webview UI Toolkit is an open-source library of web components that implement the VS Code design system. These components are made available to VS Code extension authors to help them build user interfaces for their extensions (specifically webview-based extensions) that have the same look and feel as the rest of the code editor.

The library has been built and maintained since early 2021 and is now used in extensions like GitHub Copilot, GitKraken, Red Hat Java Language Support, Nx Console, Azure Bicep, and many other projects.

The components are built using a web component framework built by Microsoft called FAST. The toolkit specifically takes advantage of FAST Foundation which is a set of unstyled base components that the FAST team builds and maintains.

<section class="render-container"> <div class="render-container-border" style="gap: 10px;"> <vscode-button>Click me!</vscode-button> </div> </section>

Why web components?

In VS Code, webview extensions are a powerful way to add custom functionality beyond what the extension API supports. Under the hood, webviews are implemented using an iframe, which means a webview extension is effectively an isolated webpage inside of VS Code where extension authors can build whatever they want using any technology they desire.

Historically, this meant that the responsibility of developing UI which aligns with the VS Code design language and follows the webview guidelines fell to extension authors. A big goal of the toolkit was to shift some of this responsibility away from extension developers by providing a set of core components that make it easier to build higher-quality webview UIs in VS Code.

Additionally, since webviews operate as environments isolated from the usual resources and APIs available to VS Code, it means the native VS Code UI could not be used.

So translating that into a set of requirements, we're looking for a technology that can:

Render UI in a standalone composable fashion
Integrate with any technology stack that an extension author may want to use
Implement the VS Code design language with a high degree of control and isolation from extension developer code

Web components are a perfect candidate for this job. They are standalone and composable HTML elements that can be used with any* tech stack and when used with shadow DOM offer a very high degree of control and isolation from other code that may exist.

*React is the notable odd duck out here.. we'll talk about this later.

Theming

One of the most important and interesting early tasks of this component library was integrating with VS Code's theming system.

VS Code has a theme service that exposes somewhere around 500+ color tokens that correspond to different parts of the user interface. Themes are defined as huge JSON files that individually set color values for each token. Below is an example from the default dark theme in VS Code:

{
	"$schema": "vscode://schemas/color-theme",
	"type": "dark",
	"colors": {
		"button.background": "#0078d4",
		"button.foreground": "#ffffff",
		// ... other tokens ...
	},
	// ... other configurations ...
}

When a person switches to a new theme VS Code will, under the hood, update all the token values with the color values defined in the JSON file associated with the newly selected theme.

Native VS Code UI will use a system of internal TypeScript objects/variables to access these color tokens, but code inside a webview cannot do this since it is running in an iframe isolated from the usual APIs and resources available in VS Code.

Thankfully, VS Code also exposes all of its theme colors as CSS variables attached to the <html> element of each webview. When there's a theme change, every CSS variable will be updated with the new color values.

<html lang="en" style="--vscode-button-foreground: #ffffff; --vscode-button-background: #0078d4; ... many other tokens ...">

Listening for theme changes

While the simplest way to inherit these theme changes would be to directly use the exposed CSS variables in the toolkit components, FAST has first-class support for Design Tokens which provide a powerful and typesafe abstraction to represent values in a design system (like color, font, spacing, and so on). They also allow for the flexibility to handle some edge cases that show up later when correctly applying VS Code themes.

Since the toolkit uses these tokens, we need to find another way to listen for theme changes. We can accomplish this a MutationObserver.

A MutationObserver is a web API that allows you to watch for changes that happen to the DOM. Since we know that a bunch of CSS variables are added to the DOM and updated each time a theme change occurs we can use an observer to watch for that change.

Pulled directly from the toolkit source code, here's the function that will initialize a theme change listener for the toolkit components. As added context, this function is called one time when the toolkit is initially loaded onto the page (even more specifically, initialization happens when the first toolkit design token is created).

export function initThemeChangeListener(
	tokenMappings: Map<string, CSSDesignToken<T>>
) {
	// Wait until DOM loads to create observer
	window.addEventListener('load', () => {
		// Create new observer that will call the applyCurrentTheme 
		// function when a change occurs
		const observer = new MutationObserver(() => {
			applyCurrentTheme(tokenMappings);
		});
		// Configure observer to watch for changes on the class 
		// attribute of the <body> element
		observer.observe(document.body, {
			attributes: true,
			attributeFilter: ['class'],
		});
		// Apply themes for the first time since the DOM already exists 
		// and the observer code will not until the next theme change
		applyCurrentTheme(tokenMappings);
	});
}

We notably are listening for changes on the <body> class attribute instead of the <html> element because VS Code conveniently sets/resets a class name representing what type of theme has been applied when the theme changes.

<body class="vscode-dark empty" role="document" data-vscode-theme-kind="vscode-dark" data-vscode-theme-name="Dark Modern" data-vscode-theme-id="Default Dark Modern">

If we move onto the all-important applyCurrentTheme function, this is where all the values of each CSS variable set on the <html> element are applied to the design tokens created with FAST.

function applyCurrentTheme(tokenMappings: Map<string, CSSDesignToken<T>>) {
	// Get a reference to the body element
	const body = document.querySelector('body');
	// Get the computed styles of the body element
	const styles = getComputedStyle(body);

	if (body) {
		// Get the name of the theme type
		const themeKind = body.getAttribute('data-vscode-theme-kind');
		// For every VS Code design token...
		for (const [vscodeTokenName, toolkitToken] of tokenMappings) {
			// Get the value of a given VS Code theme CSS variable
			let value = styles.getPropertyValue(vscodeTokenName).toString();

			// Handle a couple of styling edge cases when a high contrast 
			// theme is applied
			if (themeKind === 'vscode-high-contrast') {
				// There are a handful of VS Code theme tokens that have no 
				// value when a high contrast theme is applied.
				//
				// This is an issue because when no value is set the toolkit 
				// tokens will fall back to their default color values (aka 
				// the VS Code dark theme color palette). This results in the 
				// backgrounds of a couple of components having default dark
				// theme colors––thus breaking the high contrast theme.
				//
				// The below code, catches these tokens which have no value 
				// and are also background tokens, then overrides their value 
				// to be transparent.
				if (
					value.length === 0 &&
					toolkitToken.name.includes('background')
				) {
					value = 'transparent';
				}
				// Set icon button hover to be transparent in high contrast 
				// themes
				if (toolkitToken.name === 'button-icon-hover-background') {
					value = 'transparent';
				}
			} else if (themeKind === 'vscode-high-contrast-light') {
				if (
					value.length === 0 &&
					toolkitToken.name.includes('background')
				) {
					// Set button variant hover backgrounds to correct values 
					// based on VS Code core source
					switch (toolkitToken.name) {
						case 'button-primary-hover-background':
							value = '#0F4A85';
							break;
						case 'button-secondary-hover-background':
							value = 'transparent';
							break;
						case 'button-icon-hover-background':
							value = 'transparent';
							break;
					}
				}
			} else {
				// Set contrast-active-border token to be transparent in 
				// non-high-contrast themes
				if (toolkitToken.name === 'contrast-active-border') {
					value = 'transparent';
				}
			}
			// Set a given toolkit token to contain the corresponding 
			// CSS value of the new theme
			toolkitToken.setValueFor(body, value);
		}
	}
}

Similar to the observer, we focus on the <body> element because all the CSS variables will be inherited from the <html> element and, more importantly, a custom data attribute exists that provides the name of the type of theme that is currently applied (i.e. vscode-dark, vscode-light, etc.). This information is used to correct a handful of styling edge cases and issues in different themes.

Pulling this all together, it means that we can create and use a single set of design tokens that automatically listen for and correctly apply theme changes in VS Code. The below code snippet shows a brief look at FAST's method of defining styles that is be passed into a component definition (in a different file) and automatically applied to the component shadow DOM.

import { css } from '@microsoft/fast-element';
import { buttonPrimaryBackground, buttonPrimaryForeground } from '../design-tokens.js';

const BaseButtonStyles = css`
	:host {
		color: ${buttonPrimaryForeground};
		background: ${buttonPrimaryBackground};
		/* ... other styles ... */
	}
`;

This was an admittedly quick breeze through the topic of handling theming in the Webview UI Toolkit that leaves out a tonnn of extra context and tiny details, so apologies for any potential confusion. If you're curious and want to know more, feel free to ask me questions on Mastodon and I'd be happy to answer and/or write a follow-up post at a later time.

I hope this did at least provide a general sense of what it looks like to solve a real-life problem in the context of a web component library.

Integrating with web frameworks

Another interesting task that I've spent a fair bit of time working on is making sure that the toolkit integrates well with web frameworks. It's very common to see webview extensions built using frontend web frameworks (especially of the single-page app variety) like React, Vue, and Svelte.

It's a choice that makes a lot of sense in this context. VS Code extensions are precompiled and downloaded by developers in the same way you might install an iOS or Android application. This means none of the usual web application concerns like initial load time and other network-based metrics apply here. Furthermore, creating multiple webviews to render different pages can be a huge pain, so a single-page app that can render multiple views within a single page is desirable.

In most web frameworks web components are natively supported and there isn't a whole lot of work to do except document any special configurations that are needed and provide good sample code for extension authors to reference.

One notable exception

React is the only remaining major web framework today that does not (as of writing this) natively support web components. The two big issues are:

React passes all data to custom elements in the form of HTML attributes. For primitive data this is fine, but this breaks down when passing rich data, like objects or arrays.
Since React implements its own synthetic event system, it cannot listen for DOM events coming from custom elements without a workaround.

Thankfully, there is a plan to natively support custom elements in React v19, but it means the toolkit has to do some extra work to grapple with the current reality.

A word of warning

When the toolkit was initially released as a public beta nothing was implemented yet to support React developers and we started getting a lot of requests and issue reports asking for guidance and support.

The usual workaround to use web components in React is to wrap those components in a React component and then manually handle cases when rich data is passed to the components or when a DOM event is dispatched. Tools like FAST provide a utility package for doing this automatically, so the initial recommendation was for developers to use that.

This proved to be cumbersome and error-prone for a variety of reasons, so there reached a point where the GitHub Next team (the team behind GitHub Copilot and a predominantly React-based team) graciously volunteered to contribute a pull request that would wrap and export the toolkit components as React components.

The effort was successful and well-received, but I have one huge regret when I look back.

When this was built I had recently learned about package exports and I thought it would be an elegant and cute solution if developers could install the React components within the same package, but just at a different export:

// Regular web component import
import { vsCodeButton } from '@vscode/webview-ui-toolkit';

// React component import
import { VSCodeButton } from '@vscode/webview-ui-toolkit/react';

This is what we did and while not a catastrophic decision it has led to many headaches during the past two years. By combining everything in the same package, it has:

Complicated the codebase in an unnecessary way
Made updates harder, more confusing, and more error-prone
Resulted in some annoying package manager warnings
Even resulted in some community confusion/mild frustration (i.e. "Why is React a peer dependency of a web component library?")

It's been a decision filled with a lot of wonderful (and at times a bit embarrassing) learning lessons and the next version of the toolkit will finally be separating these components into two separate packages.

But if I had to summarize these lessons in a shorter way, my parting words of wisdom to you are:

Never be cute. Always do the simple and straightforward thing. You'll thank yourself later.

In the next episode...

Thanks for stopping by! I hope this was an enjoyable (albeit brief) look at a web component library in the wild. Like I said above, if you have any questions feel free to reach out.

Follow me on Mastodon for updates and see you in the next one!

Next post: Web components reading list

const button = document.querySelector('vscode-button');
button.addEventListener('click', () => alert("Hi! I'm a VS Code button."))

</script>

Portable HTML web components

Sat, 16 Dec 2023 00:00:00 GMT

Welcome back to 7 Days of Web Components! A series of interactive blog posts that introduces and explores the world of web components.

This is the post for day four, if you missed the previous posts I encourage you to go back to day one and start there.

Today you get a two-for-one post! We start having some fun covering what I think is one of the most compelling benefits of using web components –– it pairs amazingly with markdown.

We will then identify and discuss yet another web component architecture that sits somewhere in the middle of HTML and JavaScript Web Components. This doesn't yet have a name, so I'm proposing "Portable HTML Web Components."

Tieing this all together we will also look at our first properly complex web component: an <audio-player>.

Please note: This blog post includes interactive code examples. If you're reading this from an RSS feed, I highly recommend you open the original post.

Browser-native MDX

MDX is a piece of technology that allows you to use interactive components inside your markdown. It is one of my favorite methods for building websites that I've come across.

It combines a seamless way to embed pockets of interactivity into your web pages with all the convenience of authoring content in markdown.

The one downside is that MDX is (more precisely) a way of using JSX inside of markdown. To be clear, I do not view JSX as the downside (for those who are unaware JSX is a historically polarizing technology due to its origins as a React/Meta project), but rather that it's a limiting technology to build on top of.

While you can author components in JSX using most modern frontend frameworks these days there are no guarantees that JSX (or even MDX for that matter) will be a well-supported method of embedding components into your markdown in the future. If and when that day comes I will have to re-author all of my content if I'm tied to MDX.

But you know what technology does have a very strong guarantee of sticking around long into the future? HTML. And you know what markdown conveniently supports natively? HTML. And (as we've established the last few days) do you remember what web components are, definitionally? Ding ding, HTML.

Said without all the Q&A, markdown and web components can be used as a browser-native MDX.

# Some example markdown

Author your content using normal markdown syntax.

But when you need a component...

<my-component></my-component>

...you literally just add it.

And remember, don't forget to add a script tag.

<script type="module" scr="/my-element.js"></script>

Voilà! You embedded an interactive component into your markdown. It's so simple, it's honestly why I didn't make this topic a full blog post.

With that said, I will leave you with a few tips/insights I've gathered along the way.

Component definitions right inside markdown

You can also author the component code right inside your markdown file if you desire.

# Markdown content

Blah blah blah...

<my-component></my-component>

<script type="module">
	class MyComponent extends HTMLElement {
		// ... component behavior ...
	}
	customElements.define('my-component', MyComponent);
</script>

HTML web components too!

Again, it's all HTML so markdown doesn't mind at all.

# More markdown content

Yada yada yada...

<my-component>
	<p>Some markup that will be hydrated.</p>
	<button>Click me!</button>
</my-component>

<script type="module">
	class MyComponent extends HTMLElement {
		// ... component behavior ...
	}
	customElements.define('my-component', MyComponent);
</script>

Or you can still link to an external file.

<script type="module" scr="/my-element.js"></script>

You can even define component styles!

<style>
	my-component p {
		/* ... styles ... */
	}
	my-component button {
		/* ... styles ... */
	}
</style>

Watch out for how markdown parsers handle script tags

Depending on the markdown parser you use to generate HTML, be wary of parsers that will escape your JavaScript code. In those cases, just default back to linking to an external JavaScript file as shown above.

An example and a segue

Markdown and web components are so flexible/enjoyable it's what I've been using to author this entire series! Here's an example of the actual HTML I'm writing inside my markdown files to render these posts.

This also introduces our component of the day, the <audio-player>.

<audio-player src="/audio/requiem-in-d-minor.mp3" title="Requiem in D Minor"></audio-player>

Portable HTML web components

At this point, I've discussed across multiple days what HTML and JavaScript web components are and how I like to think of them as living on a spectrum rather than as discrete entities. You can mix and match the browser APIs you use to build web components that find a balance between the capabilities you need while not taking on extra development complexity where you don't need it.

There's a really interesting grey zone that exists between these two that I want to talk about today that I've come to call "Portable HTML Web Components."

It's all a bunch of tradeoffs

At the two ends of this spectrum live a bunch of tradeoffs. With HTML web components you get web components that are very server-side rendering friendly, allow for flexible styling, are great for progressive enhancement, and avoid the pitfalls of shadow DOM. However, they come at the cost of portability, scoped styling, and template slots.

To use our <audio-player> component as an example, the markup when built as an HTML web component will look like this:

<audio-player src="/audio/requiem-in-d-minor.mp3" title="Requiem in D Minor">
	<audio></audio>
	<div class="left-container">
		<button id="play-btn" aria-label="Play song">
			<svg id="play-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" width="35" height="35" fill="currentColor" aria-hidden="true">
				<path d="M6.3 2.841A1.5 1.5 0 004 4.11V15.89a1.5 1.5 0 002.3 1.269l9.344-5.89a1.5 1.5 0 000-2.538L6.3 2.84z"></path>
			</svg>
			<svg id="pause-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 25 25" width="30" height="30" fill="currentColor" aria-hidden="true" style="display: none;">
				<path d="M6 19h4V5H6v14zm8-14v14h4V5h-4z"></path>
			</svg>
		</button>
	</div>
	<div class="right-container">
		<p id="song-title">Song title</p>
		<div class="audio-bar">
			<span id="current-time">00:00</span>
			<progress value="0" max="1"></progress>
			<span id="total-time">00:00</span>
		</div>
	</div>
</audio-player>

The markup of this component lives in the light DOM, so (as I said above) it's really easy to style and progressively enhance. What I really dislike about HTML web components, however, is that they are not portable at all. To use this <audio-player> I will need to copy and paste not only the custom element tag but all of the child elements that live inside it.

On the other end of the spectrum, JavaScript web components allow for fantastic portability, native scoped styling, and template slots, but come at the cost of poor server-side rendering capabilities*, are not easy to progressively enhance, and are a more complex development model to work with since more browser APIs are used.

*At the time of writing, Declarative shadow DOM is very close to having cross-browser support, so this reality will likely change soon.

As a JavaScript web component, our <audio-player> markup will instead look like this:

<audio-player src="/audio/requiem-in-d-minor.mp3" title="Requiem in D Minor"></audio-player>

Very portable!

A hybrid model

Browser APIs are flexible building blocks, however. There are no prescribed ways for how you need to use them, so what if we attempted to implement a sort of hybrid between the two models I described above?

I'm very interested in building an audio player that is focused on portability while still maintaining the simpler and more flexible development model of HTML web components. I want to be able to put as many audio players as I want across a project and just insert a simple script tag that points to a single JavaScript file like you would with a JavaScript web component.

<script type="module" src="/audio-player.js"></script>

This means I'll need to move my component markup out of my custom element tag and (in this case) into a JavaScript-defined template.

const template = document.createElement('template');
template.innerHTML = /* html */ `
	<audio></audio>
	<div class="left-container">
		<button id="play-btn" aria-label="Play song">
			<svg id="play-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" width="35" height="35" fill="currentColor" aria-hidden="true">
				<path d="M6.3 2.841A1.5 1.5 0 004 4.11V15.89a1.5 1.5 0 002.3 1.269l9.344-5.89a1.5 1.5 0 000-2.538L6.3 2.84z"></path>
			</svg>
			<svg id="pause-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 25 25" width="30" height="30" fill="currentColor" aria-hidden="true" style="display: none;">
				<path d="M6 19h4V5H6v14zm8-14v14h4V5h-4z"></path>
			</svg>
		</button>
	</div>
	<div class="right-container">
		<p id="song-title">Song title</p>
		<div class="audio-bar">
			<span id="current-time">00:00</span>
			<progress value="0" max="1"></progress>
			<span id="total-time">00:00</span>
		</div>
	</div>
`;

It will then be possible to add a custom element class in the same file that can reference, clone, and append the template as a direct child of the custom element tag.

class AudioPlayer extends HTMLElement {
	constructor() {
		super();
		this.appendChild(template.content.cloneNode(true));
	}
}

From there, all the other behavior to bring this audio player to life can be added. I won't go over it in detail in this post, but you can find the completed code in the collapsible view below.

One extremely important thing I want to call out, however. In this model, you need to clone the template content before most other component code! If you don't, getting references to DOM nodes and setting event listeners will fail.

<details> <summary>Completed audio player code</summary> <pre class="astro-code dark-plus" style="background-color:var(--code-block-background);color:var(--text-primary); overflow-x: auto;" tabindex="0"><code><audio-player src="/audio/requiem-in-d-minor.mp3" title="Requiem in D Minor"></audio-player> <script type="module"> const template = document.createElement('template'); template.innerHTML = /* html */ <audio></audio> <div class="left-container"> <button id="play-btn" aria-label="Play song"> <svg id="play-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" width="35" height="35" fill="currentColor" aria-hidden="true"> <path d="M6.3 2.841A1.5 1.5 0 004 4.11V15.89a1.5 1.5 0 002.3 1.269l9.344-5.89a1.5 1.5 0 000-2.538L6.3 2.84z"></path> </svg> <svg id="pause-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 25 25" width="30" height="30" fill="currentColor" aria-hidden="true" style="display: none;"> <path d="M6 19h4V5H6v14zm8-14v14h4V5h-4z"></path> </svg> </button> </div> <div class="right-container"> Song title <div class="audio-bar"> 00:00 <progress value="0" max="1"></progress> 00:00 </div> </div> ; /** * Custom element based on audio-tool by Kevin Logan * https://github.com/kevinlogan94/audio-tool/blob/master/src/audio-tool.js */ class AudioPlayer extends HTMLElement { static get observedAttributes() { return ['src', 'title', 'preload', 'auto-play']; } constructor() { super(); this.appendChild(template.content.cloneNode(true)); this.audio = this.querySelector('audio'); this.playIcon = this.querySelector('#play-icon'); this.pauseIcon = this.querySelector('#pause-icon'); this.playPauseButton = this.querySelector('#play-btn'); this.progressBar = this.querySelector('progress'); this.currentTime = this.querySelector('#current-time'); this.duration = this.querySelector('#total-time'); this.songTitle = this.querySelector('#song-title'); this.playing = false; } connectedCallback() { this.configureAudio(); this.checkFileTypeSupport(); this.setSongTitle(); this.setPlayPauseListener(); this.setProgressListener(); this.setTimeListener(); } attributeChangedCallback(name, oldValue, newValue) { switch (name) { case 'src': if (this.audio) { this.audio.removeEventListener('timeupdate', this.updateTimeHandler); this.audio.removeEventListener('loadedmetadata', this.metadataTimeHandler); } this.configureAudio(); this.checkFileTypeSupport(); if (this.audio && this.playIcon && this.pauseIcon && this.playPauseButton) { this.pauseIcon.style.display = 'none'; this.playIcon.style.display = 'block'; this.playPauseButton.setAttribute('aria-label', 'Play song'); this.audio.pause(); this.playing = false; this.dispatchEvent(new Event('audiopaused')); } if (this.progressBar) { this.progressBar.value = 0; } this.setTimeListener(); break; case 'title': this.setSongTitle(); break; default: break; } } configureAudio() { if (this.audio && this.hasAttribute('src')) { this.audio.src = this.getAttribute('src') || ''; } if (this.audio && this.hasAttribute('preload')) { const preload = this.getAttribute('preload'); if (preload === '' || preload === 'none' || preload === 'metadata' || preload === 'auto') { this.audio.preload = preload; } } if (this.audio && this.hasAttribute('auto-play')) { if (this.getAttribute('auto-play') === 'true') { this.audio.autoplay = true; this.audio.load(); } } } checkFileTypeSupport() { if (this.audio && this.audio.src) { const songFile = this.audio.src; const fileType = songFile.substring(songFile.lastIndexOf('.') + 1); // https://diveintohtml5.info/everything.html#audio-vorbis switch (fileType) { case 'mp3': if (!(this.audio.canPlayType && this.audio.canPlayType('audio/mpeg;').replace(/no/, ''))) { this.setUnsupportedMessage("This browser doesn't support MP3 audio files."); } break; case 'm4a': if (!(this.audio.canPlayType && this.audio.canPlayType('audio/mp4; codecs="mp4a.40.2"').replace(/no/, ''))) { this.setUnsupportedMessage("This browser doesn't support M4A audio files."); } break; case 'aac': if (!(this.audio.canPlayType && this.audio.canPlayType('audio/mp4; codecs="mp4a.40.2"').replace(/no/, ''))) { this.setUnsupportedMessage("This browser doesn't support AAC audio files."); } break; case 'wav': if (!(this.audio.canPlayType && this.audio.canPlayType('audio/wav; codecs="1"').replace(/no/, ''))) { this.setUnsupportedMessage("This browser doesn't support WAV audio files."); } break; case 'ogg': if (!(this.audio.canPlayType && this.audio.canPlayType('audio/ogg; codecs="vorbis"').replace(/no/, ''))) { this.setUnsupportedMessage("This browser doesn't support Vorbis audio files."); } break; default: if (!this.audio.canPlayType('audio/' + fileType)) { this.setUnsupportedMessage("This browser doesn't support this audio file"); } break; } } } setSongTitle() { if (this.songTitle && this.hasAttribute('title')) { this.songTitle.textContent = this.getAttribute('title'); } else if (this.songTitle && this.hasAttribute('src')) { this.songTitle.textContent = this.getAttribute('src'); } } setPlayPauseListener() { this.playPauseButton?.addEventListener('click', () => { if (this.pauseIcon && this.playIcon && this.playPauseButton && this.audio) { if (!this.playing) { this.pauseIcon.style.display = 'block'; this.playIcon.style.display = 'none'; this.playPauseButton.setAttribute('aria-label', 'Pause song'); this.audio.play(); this.playing = true; this.dispatchEvent(new Event('audioplaying')); } else { this.pauseIcon.style.display = 'none'; this.playIcon.style.display = 'block'; this.playPauseButton.setAttribute('aria-label', 'Play song'); this.audio.pause(); this.playing = false; this.dispatchEvent(new Event('audiopaused')); } } }); } setProgressListener() { this.progressBar?.addEventListener('click', (event) => { if (this.progressBar && this.audio) { let percent = event.offsetX / this.progressBar.offsetWidth; this.audio.currentTime = percent * this.audio.duration; this.progressBar.value = percent; } }); } playSong() { if (this.audio && this.playIcon && this.pauseIcon && this.playPauseButton) { this.pauseIcon.style.display = 'block'; this.playIcon.style.display = 'none'; this.playPauseButton.setAttribute('aria-label', 'Pause song'); this.audio.play(); this.playing = true; this.dispatchEvent(new Event('audioplaying')); } } setTimeListener() { this.audio?.addEventListener('loadedmetadata', () => { this.metadataTimeHandler(); }); } metadataTimeHandler() { if (this.audio && this.currentTime && this.duration) { this.currentTime.textContent = ${this.formatTime( this.audio.currentTime )}; this.duration.textContent = ${this.formatTime(this.audio.duration)}; this.audio.addEventListener('timeupdate', () => { this.updateTimeHandler(); }); } } updateTimeHandler() { if (this.audio && this.currentTime && this.duration && this.progressBar && this.playIcon && this.pauseIcon && this.playPauseButton) { if (!isNaN(this.audio.currentTime / this.audio.duration)) { this.progressBar.value = this.audio.currentTime / this.audio.duration; this.currentTime.textContent = ${this.formatTime( this.audio.currentTime )}; this.duration.textContent = ${this.formatTime(this.audio.duration)}; if (this.audio.currentTime === this.audio.duration) { this.audio.currentTime = 0; this.pauseIcon.style.display = 'none'; this.playIcon.style.display = 'block'; this.playPauseButton.setAttribute('aria-label', 'Play song'); this.playing = false; this.dispatchEvent(new Event('audiopaused')); this.dispatchEvent(new Event('audiofinished')); } } } } setUnsupportedMessage(message) { if (this.songTitle) { this.songTitle.textContent = message; } } formatTime(seconds) { const hours = Math.floor(seconds / 3600); const minutes = Math.floor((seconds % 3600) / 60); const remainingSeconds = Math.floor(seconds % 60); let formattedTime = ''; if (hours > 0) { const formattedHours = hours.toString().padStart(2, '0'); formattedTime = ${formattedHours}:${minutes .toString() .padStart(2, '0')}:${remainingSeconds.toString().padStart(2, '0')}; } else { formattedTime = ${minutes.toString().padStart(2, '0')}:${remainingSeconds .toString() .padStart(2, '0')}; } return formattedTime; } } customElements.define('audio-player', AudioPlayer); </script> <style> audio-player { display: grid; grid-template-columns: 15% 85%; justify-items: center; align-items: center; background-color: rgb(95, 85, 236, 0.5); border: 2px solid rgb(95, 85, 236); border-radius: 8px; padding: 0.5rem; width: 100%; } audio-player button { color: white; background-color: rgb(122 112 255); border: none; border-radius: 50%; cursor: pointer; width: 40px; height: 40px; padding: 0; line-height: 0; display: inline-flex; align-items: center; justify-content: center; } audio-player button:focus-visible { outline: solid 2px var(--focus-outline); outline-offset: 2px; } audio-player button svg { width: 20px; height: 20px; margin: 0; padding: 0; } audio-player #play-icon { margin-left: 2px; } audio-player .audio-bar { display: flex; align-items: center; justify-content: space-between; gap: 10px; } audio-player progress { grid-column: 3 / span 10; cursor: pointer; display: block; width: 100%; height: 6px; border: none; border-radius: 100px; background-color: rgb(190, 190, 190); } audio-player progress::-webkit-progress-bar { background-color: rgb(190, 190, 190); border-radius: 100px; height: 6px; } audio-player progress::-webkit-progress-value { background-color: rgb(122 112 255); border-radius: 100px; height: 6px; } audio-player progress::-moz-progress-bar { background-color: rgb(122 112 255); border-radius: 100px; height: 6px; } audio-player label { display: block; font-size: 1rem; } audio-player #song-title { font-size: 1rem; font-weight: 600; margin: 0; } audio-player .left-container { order: 1; height: auto; width: auto; } audio-player .right-container { order: 2; height: auto; width: 95%; } @media screen and (min-width: 48em) { audio-player #song-title { font-size: 1rem; } } </style></code></pre> </details>

There are no silver bullets

As a reminder, grey zones do not entail an absence of trade-offs so just like the other models, portable HTML web components come with their own tradeoffs. What I've gained in newfound portability, I've lost in the form of good SSR-ability and easy progressive enhancement.

But here's the thing, I think that's okay! There are no silver bullets in technology (or life for that matter). It's up to you to pick the correct tool for the task at hand. Portable HTML web components are now just another tool you can add to your toolbox to be used if/when you need it.

As a final thought, I leave you with this question: What other possible combinations of browser APIs and hybrid web component models live in this grey zone?

In the next episode...

Thanks for stopping by! In the next post, we're pivoting from theory and examples to look at a library of web components in production in the real world.

Follow me on Mastodon for updates and see you in the next one!

Next post: Web components in VS Code

Getting shady

Fri, 15 Dec 2023 00:00:00 GMT

Welcome back to 7 Days of Web Components! A series of interactive blog posts that introduces and explores the world of web components.

This is the post for day three, if you missed the previous posts I encourage you to go back to day one and start there.

Today will be our final post covering the basics of web components. It's time to talk about (the often dreaded and mischaracterized) Shadow DOM.

My goal with this post is to show that Shadow DOM is not nearly as scary or complex as web development discourse might have you think. It does indeed come with some new rules and conventions that are different from how you might usually think about web development, but I hope this post will help clearly articulate those rules and maybe even have you appreciating what shadow DOM brings to the table by the end.

Please note: This blog post is filled with interactive code examples. If you're reading this from an RSS feed, I highly recommend you open the original post.

A sneak peek

Here's what we're building today... a simple name tag. It'll also be our first JavaScript Web Component!

<section class="render-container"> <div class="render-container-border"> <name-tag>Poppy</name-tag> </div> </section>

P.S. for the curious, this is Poppy.

Shadow DOM is just another tool

Shadow DOM is usually described in precise (but slightly dense) technical terms as a "hidden" DOM tree that you can create and attach to HTML elements.

I, however, like to think about it as having the ability to add tiny little isolated web pages inside your document –– almost like a micro iframe that can hold fragments of HTML versus entire web pages.

Extreme isolation

One of the key traits of shadow DOM is that it is extremely isolated from the Light DOM (read: the rest of the page). Isolation in this case means it is hard or impossible to access/change the contents inside a shadow DOM such as styles, DOM and text nodes, and so on. It also means that, by default, things like styles in the shadow DOM do not affect the light DOM and vice versa.

This can often be a very frustrating experience for those just learning about Shadow DOM, but I want to point out that this isolation is an intentional feature! Shadow DOM is a standard way for developers to create highly isolated DOM trees that are modeled after the way browser vendors build native built-in HTML elements like <input>. Building native HTML elements requires extremely strong isolation –– you don't want developers to ever accidentally (or intentionally) start messing around with the internals of the web's building blocks.

There are thankfully ways to loosen and break through this isolation that we'll discuss below, but I hope this is starting to give a sense of the motivations and scenarios shadow DOM is built upon. Fundamentally, it is just another tool in the web development toolbelt, it's good for some things and not so good for others.

Shadow DOM modes

Shadow DOM exposes two "modes" –– open and closed.

A closed shadow DOM is totally, completely, and entirely locked down. This means there is no way to programmatically access or change the internals of these elements after the shadow DOM has been created.

I believe every built-in HTML element uses a closed shadow DOM (someone please fact-check me on this) and acts as a good example of what a closed shadow DOM might be used for.

As a fun aside, there's a way to see the internals of some built-in HTML elements via Chrome Dev Tools. Go to Settings > Preferences > Elements (section) and turn on the "Show user agent shadow DOM" setting. If you start poking around you should find some elements with user agent shadow roots. For example, here are the internals of an <input type="text"> pulled from yesterday's todo list component!

An open shadow DOM, on the other hand, does allow for programmatic access and manipulation after it has been created via an element.shadowRoot property. Open shadow DOMs are usually what you want to use when developing web components.

Creating shadow DOM

As I mentioned yesterday, "web component" APIs are browser APIs first and foremost so, just like templates, we can use shadow DOM with more than just web components.

In this case, the specific set of HTML elements we can use include <article>, <aside>, <blockquote>, <body>, <div>, <footer>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <header>, <main>, <nav>, , <section>, and . Other elements (such as a button) cannot host a shadow DOM.

As an easy starter example, we'll create an open shadow DOM and attach it to a div:

<div id="example"></div>

<script type="module">
	const div = document.querySelector('#example');
	div.attachShadow({ mode: 'open' });
</script>

From there you can use the shadowRoot property and regular DOM manipulation APIs to change and update the shadow DOM however you please. In this case, let's add some pink text to the shadow DOM.

div.shadowRoot.innerHTML = `
	<style>
		p {
			color: teal;
		}
	</style>
	<p>I'm teal text inside the shadow DOM!</p>
`;

Just like the image from earlier, if you inspect this element you'll find that it has a shadow root with a style and paragraph tag. These elements will be fully encapsulated within this shadow DOM –– the styles will not affect elements in the light DOM and vice versa.

<div id="example"></div>
<p>I'm a paragraph in the light DOM! I will not be pink.</p>

<section class="render-container"> <div class="render-container-border"> <div id="example2"></div> I'm a paragraph in the light DOM! I will not be pink. </div> </section>

Said a different way, shadow DOM is a browser-native way of creating UI with scoped styles!

Adding styles to shadow DOM programmatically

Thus far, we've demonstrated creating styles declaratively using a <style> tag, but it is also possible to create styles programmatically using something called "Constructable Stylesheets."

We actually won't have time to cover constructable stylesheets in this series, but you can read this great intro to constructable stylesheets on Google's web developer blog to learn more about them.

Overriding shadow DOM styles

When building a web component with shadow DOM, there are three primary ways that styles within the shadow DOM can be overridden. While this can feel limiting, it offers an interesting benefit –– you as a component developer can choose (with different levels of granularity) what styles can be overridden by those who may use your component.

1. `:host` styles

When defining your component styles you can use the :host psuedo-class to select the shadow DOM host. In the case of a custom element, the host will refer to the custom element tag you've defined (i.e. my-component).

<my-component></my-component>

<script type="module">
	class MyComponent extends HTMLElement {
		constructor() {
			super();
			this.attachShadow({ mode: 'open' });
		}
		connectedCallback() {
			this.shadowRoot.innerHTML = `
				<style>
					:host {
						background: tan; 
						padding: 1rem;
					}
					p {
						color: white; 
						background: teal;
						padding: 1rem;
					}
				</style>
				<p>A paragraph inside my-component.</p>
			`;
		}
	}
	customElements.define('my-component', MyComponent);
</script>

If you were to open dev tools and inspect <my-component> you'd see a style declaration that looks like this:

:host {
	background: tan;
	padding: 1rem;
}

It's possible to override these styles in the light DOM by creating a ruleset that selects my-component.

my-component {
	background: goldenrod;
}

An important note is that styles applied to my-component will not cascade into any elements within the shadow DOM. For example, changing the color will have no effect on the paragraph tag.

my-component {
	color: yellow; /* <-- This will have no affect on the shadow DOM */
}

2. `::part()` psuedo-element

But what if we did want to allow for changes on elements within the shadow DOM? Well for that you can look to the ::part() psuedo-element. With this, we can explicitly expose a part (get it?) of our shadow tree for developers to style.

It starts by adding a part attribute with some name value to the element that you want to be exposed for styling. As an example, we can update the paragraph in the shadow DOM from my-component.

this.shadowRoot.innerHTML = `
	<style>
		/* ... styles ... */
	</style>
	<p part="text">A paragraph inside my-component.</p>
`;

Back in the light DOM we can now use the ::part() psuedo-element along with the name we gave to the paragraph.

my-component::part(text) {
	color: yellow; /* <-- This WILL have an affect on the shadow DOM */
}

<section class="render-container"> <div class="render-container-border"> <style> my-component-with-part::part(text) { color: yellow; } </style> <my-component-with-part></my-component-with-part> </div> </section>

3. CSS variables

At the most granular level of control, we can allow individual CSS properties to be overridden using CSS variables.

One of the rules of shadow DOM is that CSS variables can "pierce through" the shadow boundary. Practically speaking this means if you define component styles in shadow DOM using a CSS variable, that variable can be changed in the light DOM and it will be reflected in your component.

Going back to our my-component example, if we remove the part so the paragraph tag can no longer be restyled and now add a border-radius property with a CSS variable as a value...

this.shadowRoot.innerHTML = `
	<style>
		/* ... other styles ... */
		p {
			color: white; 
			background: teal;
			padding: 1rem;
			border-radius: var(--rounded-corner);
		}
	</style>
	<p>A paragraph inside my-component.</p>
`;

...we can define a CSS variable in the light DOM that changes only that property and nothing else in the shadow DOM.

:root {
	--rounded-corner: 10px;
}

An API for your styles

One of the really interesting ways to think about this is that shadow DOM allows you to create an API for your styles.

With shadow DOM, you have fine-grained control over how your UI can be changed and adjusted. While this comes at the cost of flexibility, for some use cases like building a design system/component library, this level of control can be extremely desirable.

As I said earlier, shadow DOM is just another tool that is good for some things and not for others –– if fine-grained control of UI styles is something you're looking for, shadow DOM is an excellent tool for that job.

Templates and shadow DOM

It's time to start putting the pieces together to build our first JavaScript web component!

While I have thus far demonstrated using innerHTML to set the contents of shadow DOM, it is far more desirable to use templates instead. There are three ways that a template can be added to the shadow DOM.

1. Statically created templates

The first option is to statically define your template directly in HTML and get a reference to it in your custom element class. While this works perfectly well, it is often the least used method of creating a JavaScript web component because your component markup is now separated in a different place from your component behavior.

This example might look trivial, but in most real-world scenarios it's common to separate web component behavior into a separate JavaScript file.

<name-tag></name-tag>

<template id="name-tag-template">
	<style>
		section {
			border: 2px solid rgb(95, 85, 236);
			border-bottom: solid 12px rgb(95, 85, 236);
			border-radius: 6px;
			padding: 0;
			margin: 1rem 0 0 0;
		}
		p {
			color: white;
			background: rgb(95, 85, 236, 0.5);
			padding: 10px 40px;
			margin: 0;
			font-weight: 500;
			text-align: center;
		}
		#greeting {
			color: white;
			background: rgb(95, 85, 236);
			border-radius: 3px 3px 0 0;
			font-size: 1.1rem;
		}
		#name {
			font-weight: 700;
			font-size: 1.4rem;
			padding: 20px;
		}
	</style>
	<section>
		<p id="greeting">Hello, my name is:</p>
		<p id="name">Poppy</p>
	</section>
</template>

<script type="module">
	class NameTag extends HTMLElement {
		constructor() {
			super();
			this.attachShadow({mode: 'open'});
			this.tmpl = document.querySelector('#name-tag-template');
		}
		connectedCallback() {
			this.shadowRoot.appendChild(this.tmpl.content.cloneNode(true));
		}
	}
	customElements.define('name-tag', NameTag);
</script>

2. Dynamically created templates

Dynamically creating your template at runtime is by far the most common way to see JavaScript web components built. With this method, your component markup, styles, and behavior are all co-located in the same place.

<name-tag></name-tag>

<script type="module">
	const template = document.createElement('template');
	template.innerHTML = `
		<style>
			/* ... styles ... */
		</style>
		<section>
			<p id="greeting">Hello, my name is:</p>
			<p id="name">Poppy</p>
		</section>
	`;

	class NameTag extends HTMLElement {
		constructor() {
			super();
			this.attachShadow({mode: 'open'});
			this.tmpl = document.querySelector('#name-tag-template');
		}
		connectedCallback() {
			this.shadowRoot.appendChild(this.tmpl.content.cloneNode(true));
		}
	}
	customElements.define('name-tag', NameTag);
</script>

Quick development tip

When defining markup/styles in JavaScript you typically will do so using template literals (as I've shown above). This unfortunately means you lose out on code editor features like syntax highlighting and autocomplete. But this can be fixed!

In editors like VS Code, there are extensions such as es6-string-html that can provide syntax highlighting support for template literals. Once installed you just need to mark the strings you want to be syntax highlighted with a comment saying "html" or "css":

const template = /* html */ `
	<p>I will be syntax highlighted!</p>
`;

Unfortunately, I can't show you here in this blog post because the markdown rendered I use for my website doesn't support this functionality, but trust me it works 😉.

Another helpful setting to change in VS Code is the "Emmet: Include Languages" setting. It will enable Emmet abbreviations in languages that are not supported by default. For the sake of this discussion adding a mapping of {"javascript": "html"} will enable Emmet in JavaScript files!

3. Declarative shadow DOM

The final method of using templates and shadow DOM together is declarative shadow DOM and like the name suggests this is a fully declarative way to create a shadow DOM and attach it to a custom element –– aka no JavaScript required!

With that said declarative shadow DOM is only supported in Chrome and Safari at this moment. But fear not! Cross-browser support is genuinely and truly right around the corner.

<name-tag>
	<template shadowrootmode="open">
		<style>
			/* ... styles ... */
		</style>
		<section>
			<p id="greeting">Hello, my name is:</p>
			<p id="name">Poppy</p>
		</section>
	</template>
</name-tag>

Slots

Those with a keen eye may have noticed that the name tags in the above examples are hardcoded with the name "Poppy," but it would be great if we could pass in any name. We can with the <slot> element.

When used in tandem with templates and shadow DOM, slots act as a way to render children within a component template.

<template>
	<style>
		/* ... styles ... */
	</style>
	<section>
		<p id="greeting">Hello, my name is:</p>
		<p id="name"><slot></slot></p>
	</section>
</template>

We can now pass in any name we want to our name-tag component and it will be rendered within the  element.

<name-tag>Poppy</name-tag>
<name-tag>Hawk</name-tag>
<name-tag>Arthi</name-tag>

<section class="render-container"> <div class="render-container-border"> <name-tag>Poppy</name-tag> <name-tag>Hawk</name-tag> <name-tag>Arthi</name-tag> </div> </section>

Named slots

It is also possible to have more than one slot in your template using named slots. You can do this by adding a name attribute to slot elements and a slot attribute to the content you pass into your web component.

Note: There can only be one slot without a name attribute in your template. This is called the default slot.

<template>
	<style>
		/* ... styles ... */
	</style>
	<section>
		<p id="greeting">Hello, my name is:</p>
		<p id="name"><slot></slot></p>
	</section>
	<slot name="message"></slot>
</template>

<name-tag>
	Poppy
	<p slot="message">This is a message!</p>
</name-tag>

<section class="render-container"> <div class="render-container-border"> <name-tag> Poppy This is a message! </name-tag> </div> </section>

Styling slotted content

To wrap things up, I should also mention that you can style content that is passed into slots with the ::slotted() psuedo-element.

<template>
	<style>
		/* ... other styles ... */
		::slotted(p) {
			color: red;
		}
	</style>
	<!-- ... template markup ... -->
</template>

<section class="render-container"> <div class="render-container-border"> <name-tag> Poppy This is a message! </name-tag> </div> </section>

In the next episode...

Hopefully, I accomplished my mission and you (dear reader) have an increased clarity and appreciation for what shadow DOM is, how it works, and why it's special. If not, let me know what questions you still have and I'd love to try and answer them!

We've also officially concluded our intro to web components and now we get to have some more fun. In the next post, we're talking about what I think is one of the most compelling (and not usually talked about) use cases for web components –– markdown.

Follow me on Mastodon for updates and see you in the next one!

Next post: Portable HTML web components

<template id="name-tag-template"> <style> section { border: 2px solid rgb(95, 85, 236); border-bottom: solid 12px rgb(95, 85, 236); border-radius: 6px; padding: 0; margin: 1rem 0 0 0; } p { color: white; background: rgb(95, 85, 236, 0.5); padding: 10px 40px; margin: 0; font-weight: 500; text-align: center; } #greeting { color: white; background: rgb(95, 85, 236); border-radius: 3px 3px 0 0; font-size: 1.1rem; } #name { font-weight: 700; font-size: 1.4rem; padding: 20px; } ::slotted(p) { color: red; } </style> <section> Hello, my name is: <slot></slot> </section> <slot name="message"></slot> </template>

<template id="pink-template"> <style> p { color: teal; } </style> I'm teal text inside the shadow DOM! </template>

<template id="my-component-template"> <style> :host { background: tan; padding: 1rem; } p { color: white; background: teal; padding: 1rem; border-radius: var(--rounded-corner); } </style> A paragraph inside my-component. </template>

<template id="my-component-with-part-template"> <style> :host { background: tan; padding: 1rem; } p { color: white; background: teal; padding: 1rem; } </style> A paragraph inside my-component. </template>

Templates and todo lists

Thu, 14 Dec 2023 00:00:00 GMT

Welcome back to 7 Days of Web Components! A series of interactive blog posts that introduces and explores the world of web components.

This is the post for day two, if you missed day one I encourage you to go back and start there.

Today we're diving a bit deeper into the basics of web components and will be covering the <template> HTML element and its associated JavaScript API.

Please note: This blog post is filled with interactive code examples. If you're reading this from an RSS feed, I highly recommend you open the original post.

A sneak peek

Here's what we're building today. It's a tried and true classic –– the todo list.

<section class="render-container"> <div class="render-container-border"> <todo-list> <input type="text" placeholder="Add todo item"> <section class="todos"> <div class="todo"> <input id="pick-up-groceries" type="checkbox"> <label for="pick-up-groceries">Pick up groceries</label> </div> <div class="todo"> <input id="go-on-a-walk" type="checkbox"> <label for="go-on-a-walk">Go on a walk</label> </div> </section> 2 remaining <button>Clear completed</button> <template> <div class="todo"> <input type="checkbox"> <label></label> </div> </template> </todo-list> </div> </section>

Templates

You can think of <template> as a storage container for your markup. Any valid HTML fragments that you put inside of this container will not be rendered on the page until you explicitly attach them to the DOM (or Shadow DOM as we'll discuss tomorrow).

<p>I'm a regular paragraph. You can see me.</p>
<template>
	<p>I'm a paragraph in a template. You can't see me.</p>
</template>

You can use browser dev tools to inspect the below example. You'll find a <template> element right after the paragraph containing the HTML fragment shown above.

<section class="render-container"> <div class="render-container-border"> I'm a regular paragraph. You can see me. <template> I'm a paragraph in a template. You can't see me. </template> </div> </section>

Templates provide an easy HTML-based way of storing structured pieces of UI that need to be repeatedly used in a component or page.

These pieces of UI can be accessed via a read-only JavaScript property included on the HTMLTemplateElement interface called content.

const tmpl = document.querySelector('template');
const clone = tmpl.content.cloneNode(true);

There's two important things to call out here:

1. Use of cloneNode

When copying the content of a template it's extremely common to use the cloneNode method.

This is a method of the built-in Node interface that, as the name suggests, will return a duplicate of the node on which the method was called. Using cloneNode with a template ensures that you can change and manipulate each copy of a template without affecting others.

The passed-in boolean parameter also controls if any subtrees in the template content should be cloned (i.e. a deep clone). (The answer is usually yes.)

Be aware: Cloning a node copies all of its attributes and their values, including inline listeners. This is especially important for attributes like <code>id</code> which should not be duplicated in a document. If using an <code>id</code> you'll need to modify each template you clone to be unique.

2. tmpl.content returns an HTMLFragment

It's important to remember that tmpl.content (and tmpl.content.cloneNode) will return an HTMLFragment. This means if you ever want to access and/or manipulate the contents of a template before adding it to the DOM you'll need to do a bit of extra work.

The easiest thing you can do is use querySelector to find the specific element(s) you want and then directly manipulate them with JavaScript.

const paragraph = clone.querySelector('p');
paragraph.textContent = 'This paragraph has been changed!';

A quick example

To pull this all together, let's scaffold a tiny vanilla example: A button that, when clicked, will copy the contents of a template and add it to the DOM.

Also, notice that we haven't mentioned or used web components at all yet. This is one of the cool features of "web component" APIs –– they are browser APIs first and foremost, you are not restricted in how or where they can be used.

<button id="copy">Clone template content</button>
<section id="container"></section>
<template id="tmpl">
	<p>I'm a piece of UI!</p>
</template>

<script type="module">
	const button = document.querySelector('#copy');
	const container = document.querySelector('#container');
	const tmpl = document.querySelector('#tmpl');

	button.addEventListener('click', () => {
		const clone = tmpl.content.cloneNode(true);
		container.appendChild(clone);
	});
</script>

<section class="render-container"> <div class="render-container-border"> <section class="demo"> <button id="copy">Clone template content</button> <section id="container"></section> <template id="tmpl"> I'm a piece of UI! </template> </section> </div> </section>

Using templates in web components

In a web component context, templates are almost always demonstrated and used as a tool for creating the underlying markup of a JavaScript Web Component (note: if you don't know what a JavaScript Web Component is see the post from day one). This, however, requires Shadow DOM so we'll leave that conversation for tomorrow.

Instead, we're going to talk about how templates can be used along with HTML web components to help you avoid manually creating and configuring DOM nodes.

And yes.. for those paying attention, this does conflict with what I said yesterday about HTML web components "only using the custom elements API and [nothing else from] the 'web components' bucket, such as shadow DOM or templates."

As I said above, web component APIs can be mixed and matched as needed. The difference between HTML and JavaScript Web Components exists not so much as two discrete entities but rather as living along a spectrum.

A todo list (the hard way)

So let's build our todo list! To demonstrate the power of templates, I'll first show you what it looks like to do this without the <template> element. Each todo item will be manually created and configured using regular JavaScript DOM manipulation APIs.

Given the following starter HTML...

<todo-list>
	<input type="text" placeholder="Add todo item" />
	<section class="todos"></section>
</todo-list>

...we'll add a todo item anytime the Enter key is pressed in the text field.

class TodoList extends HTMLElement {
	constructor() {
		super();
		this.input = this.querySelector('input');
		this.todos = this.querySelector('.todos');
		this.input.addEventListener('keydown', this.addTodo);
	}
	addTodo = (event) => {
		if (event.key !== 'Enter') return;
		// Create elements required to make a todo item
		const todo = document.createElement('div');
		const label = document.createElement('label');
		const checkbox = document.createElement('input');
		// Configure elements
		const todoText = event.target.value;
		const uid = todoText.toLowerCase().replace(/\s+/g, '-');
		todo.classList.add('todo');
		checkbox.type = 'checkbox';
		checkbox.setAttribute('id', uid);
		label.setAttribute('for', uid);
		label.textContent = todoText;
		// Append checkbox and label inside todo item
		todo.appendChild(checkbox);
		todo.appendChild(label);
		// Add todo item to the todos container
		this.todos.appendChild(todo);
		// Clear text field
		event.target.value = '';
	};
}
customElements.define('todo-list', TodoList);

It's just come Classic Vanilla DOM Manipulation™. The only potentially fancy thing to note is that we create a unique identifier (uid) using the value we get from the text field.

const uid = todoText.toLowerCase().replace(/\s+/g, '-');

This will turn any space-separated string into a lowercase string separated by dashes. We need this uid to implement proper accessibility semantics by creating a unique association between the todo item checkbox and label.

checkbox.setAttribute('id', uid);
label.setAttribute('for', uid);

I'm sure there's an even smarter/better way to create this association dynamically, but that's what I came up with for today.

Unique identifiers aside, I hope you get the big idea. Creating UI using vanilla DOM manipulation is fairly straightforward but not at all fun to write.

A todo list (the template way)

Let's create a new todo list that instead includes a <template> tag as a child of our custom element.

<todo-list>
	<input type="text" placeholder="Add todo item" />
	<section class="todos"></section>
	<template>
		<div class="todo">
			<input type="checkbox" />
			<label></label>
		</div>
	</template>
</todo-list>

This template can then be referenced and cloned within our component class.

class TodoList extends HTMLElement {
	constructor() {
		super();
		this.input = this.querySelector('input');
		this.todos = this.querySelector('.todos');
		// New! Get reference to template
		this.template = this.querySelector('template');
		this.input.addEventListener('keydown', this.addTodo);
	}
	addTodo = (event) => {
		if (event.key !== 'Enter') return;
		// Clone template
		const tmpl = this.template.content.cloneNode(true);
		// Get references to checkbox and label inside template
		const checkbox = tmpl.querySelector('input');
		const label = tmpl.querySelector('label');
		// Insert data/content into template
		const todoText = event.target.value;
		const uid = todoText.toLowerCase().replace(/\s+/g, '-');
		checkbox.setAttribute('id', uid);
		label.setAttribute('for', uid);
		label.textContent = todoText;
		// Add todo to the todos container
		this.todos.appendChild(tmpl);
		// Clear text field
		event.target.value = '';
	};
}
customElements.define('todo-list', TodoList);

A solid improvement! With templates, we can avoid all of the manual DOM creation and configuration from earlier.

Admittedly, the above template code still isn't the most fun to write or look at though. It mainly comes down to the fact that there's some content (i.e. the todo item text and for/id attributes) that needs to be dynamically added when a todo item is created.

Browser-native templating syntax is what would complete this picture, but that doesn't exist... yet. A new browser API called DOM Parts is in the works that aims to provide a better mechanism for updating templates with dynamic content.

This might draw a common response I see to web components, however –– they're incomplete and browser support takes too long. Ugh.

So to close out I want to talk about how I've come to think about new web component features.

That also wraps up all the important parts of our todo list I wanted to talk about today. Below (in the collapsible view) you can find the code for a completed <todo-list> component.

<details> <summary>Completed todo list code</summary> <pre class="astro-code dark-plus" style="background-color:var(--code-block-background);color:var(--text-primary); overflow-x: auto;" tabindex="0"><code><todo-list> <input type="text" placeholder="Add todo item"> <section class="todos"> <div class="todo"> <input id="pick-up-groceries" type="checkbox"> <label for="pick-up-groceries">Pick up groceries</label> </div> <div class="todo"> <input id="go-on-a-walk" type="checkbox"> <label for="go-on-a-walk">Go on a walk</label> </div> </section> <p><span id="remaining">2</span> remaining</p> <button>Clear completed</button> <template> <div class="todo"> <input type="checkbox"> <label></label> </div> </template> </todo-list> <script type="module"> class TodoList extends HTMLElement { constructor() { super(); this.input = this.querySelector('input'); this.todos = this.querySelector('.todos'); this.button = this.querySelector('button'); this.template = this.querySelector('template'); this.remaining = this.querySelector('#remaining'); this.input.addEventListener('keydown', this.addTodo); this.todos.addEventListener('change', this.updateRemainder); this.button.addEventListener('click', this.clearTodos); } addTodo = (event) => { if (event.key !== "Enter") return; const todoText = event.target.value; const tmpl = this.template.content.cloneNode(true); const checkbox = tmpl.querySelector('input'); const label = tmpl.querySelector('label'); const uid = todoText.toLowerCase().replace(/\s+/g, '-'); checkbox.setAttribute("id", uid); label.setAttribute("for", uid); label.textContent = todoText; this.todos.appendChild(tmpl); event.target.value = ""; this.updateRemainder(); } clearTodos = () => { const completed = this.todos.querySelectorAll('input[type="checkbox"]:checked'); for (const todo of completed) { this.todos.removeChild(todo.parentNode); } this.updateRemainder(); } updateRemainder = () => { const unchecked = this.todos.querySelectorAll('input[type="checkbox"]:not(:checked)'); this.remaining.textContent = unchecked.length; } } customElements.define('todo-list', TodoList); </script> <style> todo-list button, todo-list input { font-family: inherit; font-size: inherit; font-weight: 500; color: white; background-color: rgb(95, 85, 236, 0.5); border: 2px solid rgb(95, 85, 236); border-radius: 8px; padding: 6px 10px; } todo-list button { font-size: 0.9rem; padding: 4px 10px; } todo-list button:hover, todo-list button:active { cursor: pointer; background-color: rgb(95, 85, 236, 0.7); } todo-list button:focus-visible, todo-list input:focus-visible { outline: solid 2px white; outline-offset: 2px; } todo-list input::placeholder { color: #999; } todo-list .todos { margin: 20px 0; display: flex; flex-direction: column; gap: 10px; margin-bottom: 0; } todo-list .todo { display: flex; align-items: center; gap: 6px; } todo-list label { user-select: none; cursor: pointer; } todo-list input[type='checkbox'] { --checkbox-size: 24px; -webkit-appearance: none; appearance: none; margin: 0; width: var(--checkbox-size); height: var(--checkbox-size); border: 2px solid rgb(95, 85, 236); border-radius: 6px; display: grid; place-content: center; cursor: pointer; } todo-list input[type='checkbox']::before { --checkmark-size: 12px; content: ''; box-shadow: inset var(--checkmark-size) var(--checkmark-size) white; background-color: CanvasText; width: var(--checkmark-size); height: var(--checkmark-size); clip-path: polygon( 12.08% 50.81%, 0.24% 67.73%, 42.23% 97.13%, 99.25% 15.68%, 81.01% 2.91%, 35.84% 67.44% ); transform: scale(0); transition: transform 100ms ease-in-out; } todo-list input[type='checkbox']:checked::before { transform: scale(1); } todo-list input[type='checkbox']:focus-visible { outline: none; border-color: white; } todo-list .todo:has(input[type="checkbox"]:checked) label { text-decoration: line-through; } </style></code></pre> </details>

How to think about new web component features

Just like any other browser API, new web component APIs (read: features) must go through their own standards process.

A combination of various community groups and browser vendor teams are continuously working together to propose new APIs, specify and standardize how they should work, and then get them implemented across browsers.

This. process. takes. time.

Historical context: This is, in large part, the reason that web components, despite being introduced back in the early 2010s, have taken so long to increase in adoption. It took almost a decade to get the first set of web component APIs standardized and implemented across all major browsers.

Lucky for us, this process is starting to move quicker nowadays. Efforts like Interop 2022 and Interop 2023 have seen all major browser vendors working together to solve browser compatibility issues and are to a larger extent hinting at a new state of the web where browser vendors are committing to be better about implementing new and existing APIs in a timely and consistent way.

Even with a quicker feedback loop, new web component features will (for all intents and purposes) almost always take longer to ship than new web framework features. This is a reality that is often frustrating to some people, but there's a really important tradeoff being made. The upfront cost of standards work means that any API added to browsers is committing to a contract of backward compatibility defined by the web –– that is to say, it’s here to stay.

As others have said before me, the idea is that web components APIs should outlast entire web frameworks.

In the next episode...

Thanks for stopping by! In the next post, we continue deeper into the basics of web components with Shadow DOM.

Follow me on Mastodon for updates and see you in the next one!

Next post: Getting shady

window.addEventListener('load', () => {
	const button = document.querySelector('#copy');
	const container = document.querySelector('#container');
	const tmpl = document.querySelector('#tmpl');
	button.addEventListener('click', () => {
		const clone = tmpl.content.cloneNode(true);
		container.appendChild(clone);
	});
});

class VanillaTodoList extends HTMLElement {
	constructor() {
		super();
		this.input = this.querySelector('input');
		this.todos = this.querySelector('.todos');
		this.input.addEventListener('keydown', this.addTodo);
	}
	addTodo = (event) => {
		if (event.key !== 'Enter') return;
		// Create elements required to make todo item
		const todo = document.createElement('div');
		const label = document.createElement('label');
		const checkbox = document.createElement('input');
		// Configure elements
		const todoText = event.target.value;
		const uid = todoText.toLowerCase().replace(/\s+/g, '-');
		todo.classList.add('todo');
		checkbox.type = 'checkbox';
		checkbox.setAttribute("id", uid);
		label.setAttribute("for", uid);
		label.textContent = todoText;
		// Append checkbox and label inside todo
		todo.appendChild(checkbox);
		todo.appendChild(label);
		// Add todo item to the todos container
		this.todos.appendChild(todo);
		event.target.value = '';
	};
}
customElements.define('vanilla-todo-list', VanillaTodoList);

class SlimTodoList extends HTMLElement {
	constructor() {
		super();
		this.input = this.querySelector('input');
		this.todos = this.querySelector('.todos');
		this.template = this.querySelector('template');
		this.input.addEventListener('keydown', this.addTodo);
	}
	addTodo = (event) => {
		if (event.key !== 'Enter') return;
		const tmpl = this.template.content.cloneNode(true);
		const checkbox = tmpl.querySelector('input');
		const label = tmpl.querySelector('label');
		const todoText = event.target.value;
		const uid = todoText.toLowerCase().replace(/\s+/g, '-');
		checkbox.setAttribute('id', uid);
		label.setAttribute('for', uid);
		label.textContent = todoText;
		this.todos.appendChild(tmpl);
		event.target.value = '';
	};
}
customElements.define('slim-todo-list', SlimTodoList);

</script>

Let it snow

Wed, 13 Dec 2023 00:00:00 GMT

Welcome to 7 Days of Web Components! A series of interactive blog posts that will introduce and explore the world of web components.

This series will cover the basics of web components, more complex and real-world examples, and discussions of the wider ecosystem/future of web components. These posts will also be littered with tricks and insights I've picked up along the way.

The result should be a series that will be in no way technically complete or robust, but will hopefully offer some fresh perspectives to both beginners and seasoned builders of web components alike.

I hope you enjoy!

Please note: This blog post is filled with interactive code examples. If you're reading this from an RSS feed, I highly encourage you to open the original post.

A sneak peek

Today we're going to start what will be a multi-day introduction to web components. This will lay the groundwork for some more fun and exploratory posts later on.

Here's what we're building today. A tiny portal into a winter wonderland. ☃️

Your first web component

To start with the absolute basics, "web components" is a loose term used to reference a set of evolving browser APIs that can be used to create custom HTML elements. You can think of web components as the browser-native way of building reusable user interfaces.

There are three primary browser APIs that are commonly used together to build web components:

Custom Elements: A JavaScript API for creating custom HTML elements
Shadow DOM: A JavaScript API that is primarily used for creating scoped styles and component slots (i.e. rendering children within a component template)
HTML Templates: An HTML element (and associated JavaScript API) that typically acts as a way to define the template markup of a web component

In today's post, we'll just be discussing the custom elements API as it is the bare minimum needed to build a web component. Shadow DOM and templates, along with some other web component APIs, will be discussed in the coming days.

So what does the most basic web component look like? Like this:

<let-it-snow></let-it-snow>

<script type="module">
	class LetItSnow extends HTMLElement {
		constructor() {
			super();
		}
	}
	customElements.define('let-it-snow', LetItSnow);
</script>

This web component does absolutely nothing. It renders nothing and has no functionality. But it is a web component (or more precisely custom element). There are a few key ingredients to make note of:

1. A JavaScript class that extends the native HTMLElement interface

class LetItSnow extends HTMLElement {}

This is the defining trait of web components, they extend the built-in HTMLElement interface that all other HTML elements are built on top of.

A key takeaway to internalize is that web components are, definitionally, HTML elements. From the browser's perspective, <let-it-snow> is just as much an HTML element as a  or <div> element.

The implications of this are extremely important. Web components do not follow the same rules, conventions, and mental models of a “component” you might find in React, Svelte, or Vue. Instead, they follow the rules, conventions, and mental models of HTML elements.

2. A class constructor method that immediately calls super()

constructor() {
	super();
}

According to JavaScript class semantics calling super() is how a class inherits from its base class –– that is, calling the super method will execute the code contained within the base class (i.e. HTMLElement). With super your custom element becomes an HTML element, but without it's just a plain old JavaScript class.

3. The customElements.define API registers the component with the browser

customElements.define('let-it-snow', LetItSnow);

This is how your custom HTML tag name is associated with a custom element class. Without this API any instances of your custom element in an HTML document will have no functionality.

4. Custom element tags follow a specific naming convention

To avoid naming collisions with regular HTML elements, all custom elements must follow a few rules:

Starts with a lowercase ASCII character
Contains at least one hyphen
Does not contain uppercase ASCII characters
Does not contain some special characters as defined by the spec

Note: Unfortunately, while the spec says that some names like <emotion-😍> are valid, in practice, it has been found that browsers do not support all possible conventions.

Web component architecture

Before we talk about interactivity there's one more thing we need to cover: "HTML Web Components" versus "JavaScript Web Components."

These names refer to the two major ways of building/architecting web components.

HTML web components are perhaps the simpler and more flexible way of building web components (and are what we will focus on in today's post). The core premise of HTML web components is to write plain HTML and then wrap the parts you want to be interactive using a custom element.

These components only use the custom elements API and do not use any other APIs you might find in the "web components" bucket, such as shadow DOM or templates.

They look like this:

<counter-button>
	<button>Clicked <span>0</span> times</button>
</counter-button>

JavaScript web components, on the other hand, are historically what you might think of as "regular" web components. They use a wider variety of web component APIs to create components that are similar to single-page application (SPA) components, popularized by tools like React.

They look like this:

<counter-button></counter-button>

Said a different way, the HTML web component will hydrate/progressively enhance existing HTML, while the JavaScript web component will dynamically generate UI at runtime (using APIs like template and shadow DOM). There are benefits and drawbacks to both models, so it's usually a case of picking the right tool (read: architecture) for the right job.

We'll cover both architectures a fair bit during this series, but if don't want to wait here are some great posts that talk more about HTML web components and some of the differences they have with JavaScript web components.

HTML web components by Jeremy Keith
HTML Web Components by Jim Nielsen
HTML Web Components are Just JavaScript? by Miriam Eric Suzanne
HTML Web Components by Chris Ferdinandi
A year working with HTML Web Components by Hawk Ticehurst

Adding interactivity

Okay, now it's time to add some behavior!

Our <let-it-snow> component will include a button that toggles a snow animation, so we need to create a button that responds to a click event. This can be done like so:

<let-it-snow>
	<button>Let it snow</button>
</let-it-snow>

<script type="module">
	class LetItSnow extends HTMLElement {
		constructor() {
			super();
			this.button = this.querySelector('button');
			this.button.addEventListener('click', this.toggleSnow);
		}
		toggleSnow = () => {
			alert('No snow yet, but soon!');
		};
	}
	customElements.define('let-it-snow', LetItSnow);
</script>

This is also the point where we can add some basic component styles (hidden in a collapsible view).

<details> <summary>Default component styles</summary> <pre class="astro-code dark-plus" style="background-color: var(--code-block-background); color:var(--text-primary); overflow-x: auto;" tabindex="0"><code>let-it-snow { display: flex; justify-content: center; align-items: center; width: 100%; aspect-ratio: 2/1; border-radius: 6px; } let-it-snow button { font-family: inherit; font-size: inherit; font-weight: 500; color: white; background-color: rgb(95, 85, 236, 0.5); border: 2px solid rgb(95, 85, 236); border-radius: 8px; padding: 6px 10px; z-index: 1; } let-it-snow button:hover, let-it-snow button:active { cursor: pointer; background-color: rgb(95, 85, 236, 0.7); } let-it-snow button:focus-visible { outline: solid 2px white; outline-offset: 2px; }</code></pre> </details>

You can try it out here:

There are two important things I want to highlight:

1. Using this.querySelector to access the children of your web component

When writing a web component class, this refers to the root web component node. We can take advantage of this to easily get a reference to the button inside <let-it-snow> by calling this.querySelector.

You can think of it as doing a search that will be scoped to your web component and its children. This stands in comparison to calling document.querySelector which will search the entire document. The former is quicker (i.e. a smaller DOM tree to search) and less error-prone. Nice!

2. Most event listeners should go in the constructor method

One thing we haven't talked about yet is the fact that custom elements have component lifecycle methods similar to other popular component models. You can add custom code to the following callback methods that will be executed at specific times during the component lifecycle.

connectedCallback – Called when a component is added to the DOM.
disconnectedCallback – Called when a component is removed from the DOM.
attributeChangedCallback – Called when a component attribute is changed, added, removed, or replaced.
adoptedCallback – Called when a component is moved from one HTML document to another via the document.adoptedNode method.

An extremely common pattern is to see event listener code being set up in connectedCallback and removed in disconnectedCallback.

class LetItSnow extends HTMLElement {
	constructor() {
		super();
		this.button = this.querySelector('button');
	}
	connectedCallback() {
		// Event listener is added when component is added the the DOM
		this.button.addEventListener('click', this.toggleSnow);
	}
	disconnectedCallback() {
		// Event listener is removed when component is removed the the DOM
		this.button.removeEventListener('click', this.toggleSnow);
	}
	toggleSnow = () => {
		alert('No snow yet, but soon!');
	};
}
customElements.define('let-it-snow', LetItSnow);

While this works, it's unnecessary, error-prone (it's common for people to forget to remove event listeners in disconnectedCallback), and technically incorrect.

According to the HTML Standard event listener code should be set in the constructor method.

In general, the constructor should be used to set up initial state and default values, and to set up event listeners and possibly a shadow root.

There's a little bit more to say about this, but I've already written about it so I encourage you to read this blog post that goes into more depth on the topic.

An easy rule of thumb that I use, however, is:

Code that only needs to run once when the component is created (like configuring event listeners) should go in the constructor.
Code that needs to be run every time the component is added/removed from the DOM (like rendering tasks) should be put in connectedCallback and disconnectedCallback.

Stateful styling with custom data attributes

To wrap everything up, let's create our winter wonderland. This will be done almost entirely with CSS and take advantage of my favorite way of styling UI.

Custom data attributes are a method of storing extra information in HTML elements. You create them by prefixing any attribute name you want with data- and then store a corresponding value as a string –– for example data-gap="10px". When combined with CSS attribute selectors they can be used to create stateful styles in your UI.

If you want a short (and more fun) explainer about this topic, I made a TikTok and YouTube Short earlier this year that you can watch.

Also, to be extremely clear, custom data attributes are not considered to be a part of the "web component" label. I do, however, believe they are a wonderful pairing with HTML web components, so I'm giving them some attention here. Consider this one of the aforementioned tricks/insights I've gained along the way that I'm sharing now.

To add our winter wonderland, we can create a data-snow attribute (no value required in this case!) that will act as a boolean attribute that can be added and removed from <let-it-snow> to toggle the snow animation on and off.

We can do this by switching out the alert from earlier with toggleAttribute:

class LetItSnow extends HTMLElement {
	constructor() {
		super();
		this.button = this.querySelector('button');
		this.button.addEventListener('click', this.toggleSnow);
	}
	toggleSnow = () => {
		this.toggleAttribute('data-snow'); // <-- Here!
	};
}
customElements.define('let-it-snow', LetItSnow);

From here we can add the panning image animation (image courtesy of DALL·E):

let-it-snow[data-snow] {
	background-image: url('/imgs/winter-wonderland.png');
	background-size: 150%;
	background-repeat: repeat-y;
	animation: pan-y 10s linear infinite alternate;
}
@keyframes pan-y {
	from {
		background-position-y: top;
	}
	to {
		background-position-y: bottom;
	}
}

Here's the result:

Finally, the snow! A new DOM node is needed to create the animation, so we'll add an empty <div> as a child of our web component.

<let-it-snow>
	<button>Let it snow</button>
	<div class="snow" role="presentation"></div>
</let-it-snow>

The snow animation is an adapted version of Jon Kantner's Snow in 262 Bytes of CSS:

let-it-snow {
	/* ... other let-it-snow styles ... */
	position: relative;
}
let-it-snow[data-snow] .snow,
let-it-snow[data-snow] .snow:before,
let-it-snow[data-snow] .snow:after {
	--move-x: 48px;
	--move-y: 144px;
	content: '';
	position: absolute;
	background: radial-gradient(#fff, #fff0 6%) 0 0 / var(--move-x) var(--move-x);
	width: 100%;
	height: 100%;
	animation: snow 4s linear infinite;
}
let-it-snow[data-snow] .snow:before {
	animation-duration: 3s;
}
let-it-snow[data-snow] .snow:after {
	animation-duration: 2s;
}
@keyframes snow {
	to {
		background-position: var(--move-x) var(--move-y);
	}
}

And... we've made a <let-it-snow> web component!

Admittedly, it's a bit of a weird component, but hopefully, it was a fun and informative start to this series.

As I said at the beginning, this is day one of a series of posts that will be released every day for the next 12 days. In the next post, we're diving a bit deeper into the basics of web components with templates.

Follow me on Mastodon for updates. See you in the next one!

Next post: Templates and todo lists

class LetItSnowAlert extends HTMLElement {
	constructor() {
		super();
		this.button = this.querySelector('button');
		this.button.addEventListener('click', this.toggleSnow);
	}
	toggleSnow = () => {
		alert('No snow yet, but soon!');
	};
}
customElements.define('let-it-snow-alert', LetItSnowAlert);

class LetItSnowPanOnly extends HTMLElement {
	constructor() {
		super();
		this.button = this.querySelector('button');
		this.button.addEventListener('click', this.toggleSnow);
	}
	toggleSnow = () => {
		console.log("hello?");
		this.toggleAttribute('data-snow');
	};
}
customElements.define('let-it-snow-pan-only', LetItSnowPanOnly);

</script>

You're (probably) using connectedCallback wrong

Wed, 29 Nov 2023 00:00:00 GMT

In what has become my biggest web component related TIL (today I learned) to date, you and I are almost definitely using the connectedCallback lifecycle method incorrectly.

Let me explain.

Prompted by a recent discussion with Thomas Broyer, I was reminded that when setting up a web component you can take advantage of the fact that the constructor is only run once to do things like configuring event listeners.

This, however, has always struck me as having a bad code smell because it is extremely common to see event handling code configured in connectedCallback and correspondingly removed in disconnectedCallback. If you look through the other responses to that thread and most web component code online, nearly everyone will configure their components in the following way:

class MyComponent extends HTMLElement {
	constructor() {
		super();
	}
	connectedCallback() {
		// Add event listeners when component is added to the DOM
		this.addEventListener('click', this.clickHandler);
		this.addEventListener('mouseover', this.mouseoverHandler);
	}
	disconnectedCallback() {
		// Remove event listeners when component is removed from the DOM
		this.removeEventListener('click', this.clickHandler);
		this.removeEventListener('mouseover', this.mouseoverHandler);
	}
	clickHandler = () => {
		// Handles click event
	};
	mouseoverHandler = () => {
		// Handles mouseover event
	};
}

But this, as I've discovered, is incorrect.

MDN got it wrong... kind of

I vividly remember learning, early on, that most component setup should be offloaded to the connectedCallback lifecycle method. I found the original MDN article on custom elements (notably one of the very first I ever read about web components) where this information comes from. In the section on lifecycle methods, they say:

connectedCallback(): called each time the element is added to the document. The specification recommends that, as far as possible, developers should implement custom element setup in this callback rather than the constructor.

While it's easy to casually assume what "custom element setup" entails, it's not actually clear. And with Thomas's suggestion that "most people do too much in connectedCallback," I decided to go look at the spec.

In section 4.13.2 of the HTML Standard, I found my answer.

In general, work should be deferred to connectedCallback as much as possible—especially work involving fetching resources or rendering. However, note that connectedCallback can be called more than once, so any initialization work that is truly one-time will need a guard to prevent it from running twice.

In general, the constructor should be used to set up initial state and default values, and to set up event listeners and possibly a shadow root.

There it is... "event listeners [should be set up in the constructor]."

So while MDN was correct in saying that the spec recommends deferring work to connectedCallback, it fails to clarify that this "work" does not include configuring event listeners –– something I had always assumed should be included.

According to the spec, we should be writing our web components like this:

class MyComponent extends HTMLElement {
	constructor() {
		super();
		// Add event listeners when component is created
		this.addEventListener('click', this.clickHandler);
		this.addEventListener('mouseover', this.mouseoverHandler);
	}
	clickHandler = () => {
		// Handles click event
	};
	mouseoverHandler = () => {
		// Handles mouseover event
	};
}

I have to admit, this actually makes sense! Event listener code is ostensibly something that should only be configured once when the component is first created. There's really no need to reconfigure this anytime the component is removed and re-added to the DOM (such as when persisting a web component across a page transition using the View Transitions API) –– it's unnecessary work.

Also for those worried about potential bloated memory issues, you probably* don't need to be. Since this is configured in the constructor method it follows regular JavaScript class semantics –– any state, default values, event listeners, shadow dom, etc. will be cleaned up when the class/component is no longer used.

*One big exception:

If you've configured any listeners (or any state for that matter) that live outside of your component (such as on the global window object) you will need to manually add and remove references to those listeners, states, etc. when the component is added/removed from the DOM. These will not be automatically cleaned up when the component is no longer used.

class MyComponent extends HTMLElement {
	constructor() {
		super();
	}
	connectedCallback() {
		// Add event listener when component is added to the DOM
		window.addEventListener('resize', this.handler);
	}
	disconnectedCallback() {
		// Remove event listener when component is removed from the DOM
		window.removeEventListener('resize', this.handler);
	}
	handler = () => {
		// Handles window resize event
	};
}

My new rule of thumb

This brings me to my new rule of thumb when building web components:

Code that only needs to run once should be put in the constructor.
Code that needs to be run every time the component is added/removed from the DOM should be put in connectedCallback and disconnectedCallback.

I've got a lot of web component code to go back and update... 😅

How about you?

A year working with HTML Web Components

Mon, 27 Nov 2023 00:00:00 GMT

While the term "HTML Web Components" is fresh out of the oven, the architecture it refers to has been sitting on the counter at room temperature for a while now. I’ve been experimenting with this way of building web components for almost a year, and in this post, I want to talk about some of the big takeaways I've come to thus far.

“Regular” web components

As an increasing number of people already know, “web components” is a loose term that refers to a set of evolving browser APIs that allow you to create custom HTML elements. You can think of web components as a browser-native way of building reusable UI.

There are three primary APIs that are commonly used together to build “web components”:

Custom Elements: A JavaScript API for creating custom HTML elements
Shadow DOM: A JavaScript API that is primarily used for creating scoped styles and component slots (i.e. rendering children within a component template)
HTML Templates: An HTML element (and associated JavaScript API) that typically acts as a way to define the template markup of a web component

For the first decade-ish of their inception and usage, web components have been predominantly marketed, documented, and used in a way that mirrors single-page application (SPA) component models, popularized by frameworks like React, Svelte, and Vue.

Web component APIs, just like SPA component APIs, use JavaScript to encapsulate bits of markup, style, and behavior to represent and dynamically render distinct pieces of UI at runtime. In the same way you can build a React component and access it via a custom JSX tag (i.e. <CounterButton />) you can do the same with web component APIs and access it via a custom HTML tag (i.e. <counter-button>).

This model has worked quite well, but it is not without its paper cuts. You might have heard about a lot of them at this point, but to call out a few big ones, “regular” web components…

Are unable to be server-side rendered (SSR)*
Have inflexible styling rules when using Shadow DOM
Currently have incomplete support for full accessibility and ARIA semantics when using Shadow DOM

*The Declarative Shadow DOM API will change this but it does not yet have full browser support at the time of writing.

For me (and others), these paper cuts added up. During the last year, there has been an increasing level of experimentation with a different method of building web components.

HTML web components

In 2022, projects like Eleventy’s WebC and Enhance started pioneering a web component architecture that focused exclusively on using the custom elements API, and nothing else from the "web component" bucket of APIs. Fast-forward a year, this method of building web components has been pushed forward and finally has a name.

The core premise of HTML web components is to write HTML as you would normally and then “enhance” it by wrapping the parts you want to be interactive using a custom element tag.

For example, if you wanted to define the markup for a counter button it would look like this:

<!-- HTML web component -->
<counter-button>
	<button>Count is <span>0</span></button>
</counter-button>

<!-- Regular web component (for comparison) -->
<counter-button></counter-button>

Rather than dynamically generating the component UI at runtime using JavaScript like you would with regular web components, the HTML web component is parsed, rendered, and styled as normal HTML. That HTML will then be seamlessly hydrated once the JavaScript associated with the custom element tag is executed.

It also addresses all the earlier mentioned paper cuts:

Component markup is fully SSR-able
Component markup can now be styled like regular HTML
Common accessibility practices can be applied without issue

With that light context setting complete, below are some insights, takeaways, and general musings from a year of working with this architecture.

HTML web components are islands

I often like to casually describe this way of building web components as “wrapping HTML with custom elements to declaratively define interactive UI.” The custom element tag acts as a sort of box of interactivity –– any HTML you put inside of that box can be made interactive using the powerful lifecycle methods and functionality that the custom element API provides.

This description/mental model might sound familiar to some — it certainly was for me — these are islands!

Realizing that HTML web components (and custom elements at large) can be thought of as "islands" as described in the islands architecture, really made things click for me early on. As the analogy goes, in a sea of static HTML, a custom element/HTML web component denotes an island of interactivity.

Fun fact: Custom elements are so good at being islands it’s how Astro implemented their islands architecture.

Progressive enhancement is a piece of cake

HTML web components are one of the best tools I’ve come across for adhering to the design philosophy of progressive enhancement. My favorite feature of custom elements, in particular, enables a method of styling that wonderfully supports the goal of adhering to progressive enhancement: the :defined pseudo-class.

With this pseudo-class, you can declare styles for when a custom element has not yet been hydrated. You'll commonly see this demonstrated by simply hiding a custom element until it has been defined using the customElements.define() method.

counter-button:not(:defined) {
	display: none;
}
counter-button:defined {
	display: block;
}

But this can lead to layout shift issues if not carefully accounted for. Plus on top of that.. this is CSS! You can push it so much further. Perhaps, we could add disabled styling to the button when it hasn't been hydrated (note: you should also probably add the disabled attribute by default too and remove it once JS executes).

counter-button:not(:defined) button {
	cursor: not-allowed;
	background: grey;
}
counter-button:defined button {
	cursor: pointer;
	background: white;
}

Maybe you like fancy component skeletons with animated shimmers.. easy.

/* Some default button styles */
counter-button button {
	background-color: #dfdfdf;
	border: none;
	border-radius: 6px;
	padding: 8px 20px;
}
/* Skeleton/shimmer styles applied before JavaScript has loaded */
counter-button:not(:defined) button {
	color: rgba(0, 0, 0, 0); /* Hide button text */
	display: inline-block;
	-webkit-mask: linear-gradient(
			-70deg,
			rgba(0, 0, 0) 30%,
			rgba(0, 0, 0, 0.3),
			rgba(0, 0, 0) 70%
		) right/300% 100%;
	background-repeat: no-repeat;
	animation: shimmer 3s infinite;
}
@keyframes shimmer {
	100% {
		-webkit-mask-position: left;
	}
}
/* Button styles applied after JavaScript has loaded */
counter-button:defined button {
	color: #000000;
}

The options are only limited by what you can come up with using CSS. The point is that with :defined you have a trivial browser-native way of declaring pre-JavaScript and post-JavaScript styles on your components. It’s an amazing tool for the progressive-enhancement-conscious developer.

HTML web components are not a silver bullet

Like all things, there are some notable trade-offs when using HTML web components compared to regular web components.

For one, component markup must be copied/repeated anywhere you want to use the component. That is to say, you lose out on the reusable “component-ness” of a regular web component. This is not ergonomic, especially with component templates that have more complex markup.

<!-- HTML web component markup... -->
<counter-button>
	<button>Count is <span>0</span></button>
</counter-button>

<!-- ...must be repeated... -->
<counter-button>
	<button>Count is <span>0</span></button>
</counter-button>

<!-- ...every time they are used... -->
<counter-button>
	<button>Count is <span>0</span></button>
</counter-button>

Additionally, by forgoing shadow DOM, you lose out on native-scoped styling. You can still achieve a sort of pseudo-component-scoped styling by prepending the name of your custom element to all CSS styles, but this can get a bit cumbersome to repeat in my experience.

/* This is kind of like scoped styling.. right? */
counter-button button {
	font: inherit;
	border: none;
	border-radius: 6px;
}

Without shadow DOM you also have no ability to natively add component slots (i.e. render children within a component template).

The good news is that if you’re willing to look outside of native browser APIs and to the land of web frameworks (which I’d wager most people are) these are solved problems!

Projects like WebC and Enhance implemented their own version of component templating, scoped styling, and component slots. In my case, however, I've landed on Astro as my preferred pairing with HTML web components.

Astro and HTML web components

I could spend an entire post gushing about Astro, but to give a brief intro for those less familiar: Astro is a web framework that started as a static site generator and has expanded to support the whole gamut of web architectures and use cases. In 2023, they have:

Static, server, and hybrid rendering modes
A simple templating syntax and component model (we’ll come back to this later)
Scoped component styles
An extensive plug-in ecosystem
Built-in markdown and MDX support
File system-based routing
A built-in <Image /> component
Built-in internationalization features
Custom API endpoint support
Custom middleware support
A built-in, lightweight, type-safe content management system (CMS)
And on.. and on..

On top of that, they also have, without a doubt, the best documentation on earth right now. If you haven’t given Astro a try yet I can’t recommend it enough.

So where do HTML web components fit into this picture? They pair perfectly with Astro’s component model.

The Astro component model

Astro components “are HTML-only templating components with no client-side runtime.” All they can do is send static HTML, CSS, and JavaScript (that will be executed at a global page level) to the browser.

The anatomy of an Astro component is delightfully simple:

---
// Component script (JavaScript)
// This will be executed at build time or on-demand (i.e. on the server)
const greeting = 'world';
---

<!-- Component template (HTML) -->
<p>Hello {greeting}</p>

<style>
	/* Component styles (CSS) -- scoped by default */
	p {
		color: blue;
	}
</style>

<script>
	// Client script (JavaScript)
	// This will be sent to and executed on the browser
	console.log('Hello from the browser');
</script>

With Astro components, we have all the makings to solve the issues with HTML web components.

A component model and templating syntax
Scoped styling
Even a <slot /> element

Putting it all together, a simple hello world component that will render a greeting based on the value of a text field might look like this:

---
// Components can start with an initial server rendered value
const initialName = 'world';
---

<!-- 
Astro template syntax will compile this into static HTML 
before sending it to the client
-->
<hello-world>
	<input type="text" value={initialName} />
	<p>Hello <span>{initialName}</span>!</p>
</hello-world>

<script>
	// HTML web component code that will execute in the browser
	class HelloWorld extends HTMLElement {
		constructor() {
			super();
		}
		// Lifecycle method that runs when the custom element
		// is connected to the DOM
		connectedCallback() {
			this.input = this.querySelector('input');
			this.span = this.querySelector('span');
			this.input.addEventListener('input', this.updateName);
		}
		updateName = (e) => {
			const val = e.target.value;
			this.span.textContent = val;
		};
	}
	customElements.define('hello-world', HelloWorld);
</script>

<style>
	/* Styles will be automatically scoped to the component! */
	input {
		font: inherit;
		border: none;
		border-radius: 4px;
	}
	span {
		font-style: italic;
	}
</style>

HTML web components make Astro better too

On the flip side, HTML web components solve my biggest issue with Astro components — the fact they don’t have a client-side runtime!

Typically if you need interactive UI in Astro you either need to write vanilla JavaScript (fine for small scripts but can get unwieldy fast) or you can take advantage of the fact that Astro can render other UI framework components like React, Svelte, Vue, etc.

Rendering other component models is a really cool feature but I don’t like that it requires that I need to juggle multiple different syntaxes, framework conventions, and so on while developing. I’d much prefer a model that lets me stay within the boundaries of Astro’s syntax and conventions. HTML web components enable this reality.

To give credit where it’s due, Astro has actually (for a very long time) documented this method of combining Astro components with custom elements. These docs are another place where I initially found inspiration to try out the concept of HTML web components.

Finally, a really exciting premise I’ll leave you with is that when all of this is further combined with the new View Transitions API you have the makings for Astro to become a compelling SPA framework as well. There’s so much more to talk about here, but that will need to be left for a future post/video.

A “proper” example

One of my first “proper” HTML web components used Astro to build an audio player to build a website to host my late father’s music.

Like the examples above, this AudioPlayer component (along with a supporting SongList component) is a custom element that wraps around an <audio> element and some other bits of HTML to build out the rest of the UI. This is then enhanced by a fair bit of JavaScript and CSS.

And here’s the thing, without getting into the details further, it just worked.

Of course, there were the usual development hiccups (like how the heck does the HTML audio element API work?!), but as a method of building reusable interactive UI, Astro and HTML web components have come to be my favorite during the last year. In my experience, it’s effectively no different than any of the other major component models.

With one big exception…

The ergonomics could still be improved

After a handful of months building with Astro and HTML web components, I continued to discover more paper cuts, specifically regarding the verbosity of the custom elements API.

To be clear I don’t fault the custom elements API for being low-level and verbose, it needs to be. But as a day-to-day API for developing UI, it’s not my favorite. I went looking for a framework that could provide the terseness and functionality of something like Lit, but that catered to an HTML web components architecture.

Unfortunately, WebC and Enhance don’t fit the bill because they don’t integrate well/at all with Astro components and I never found anything else that checked the specific boxes I was looking for, so a few months ago I decided to build my own.

Say hello to Stellar

Stellar is a tiny framework that improves the ergonomics of building HTML web components.

This is achieved by providing a handful of custom attributes called “directives” that implement event handling and a reactivity model. With Stellar, building a working counter button looks like this:

<counter-button>
	<button @click="increment">Count is <span $state="count">0</span></button>
</counter-button>

<script type="module">
	import { Stellar } from 'stellar-element';
	class CounterButton extends Stellar {
		increment = () => this.count++;
	}
	customElements.define('counter-button', CounterButton);
</script>

There’s much more to read in the docs, but I do want to quickly address a question (and associated cool feature of Stellar) that some may have after a close look at the above syntax: how/where is count initialized?

To answer that I have to introduce a concept I’ve come to call “HTML-based state.”

HTML-based state

Stellar, like many other web frameworks, ships a reactivity model that lets you declaratively define pieces of stateful UI.

Unlike other web frameworks, however, state is defined a little differently than what you might have experienced when using tools like React, Svelte, or Vue. In most frameworks, state is defined in JavaScript and then passed into component markup using some type of templating syntax. In Stellar, this relationship is inversed. Reactive state is defined in HTML and then made accessible for manipulation in JavaScript.

In practice, this means a handful of custom attributes called "directives" that begin with a $ can be declaratively added to elements within a Stellar component to access the reactivity model.

For example, the $state directive allows you to define a piece of reactive state based on the existing text content of a stateful element.

When trying to understand a reactive state declaration, the following code...

<p $state="text">Hello world!</p>

...should be interpreted in the following way:

The paragraph element is marked as stateful via the $state directive
The name of the state is text and can be accessed in JavaScript by calling this.text
The initial value of the state is the string "Hello world!"

Note: As a convenience, all reactive state is coerced to the correct data type when being accessed in JavaScript. For example, when accessing the count state from above it will be of type number.

State should start on the server

An intentional goal of this model is to be extremely SSR-friendly and align (mostly) well with hypermedia-driven principles. While the above examples demonstrate handwriting state directly inside HTML elements, the real use case and goal is to declare initial state in your server and pass the state into Stellar components using the templating language of your server framework.

When used in a framework like Astro, initial component state can start in the server, be encoded directly into your HTML, and then be seamlessly hydrated on the client without any layout shift issues or flashes of new content once JavaScript is parsed and executed.

---
// State starts in the server!
const initial = 'Hello world!';
const count = 0;
---

<hydrate-server-state>
	<p $state="text">{initial}</p>
	<button @click="increment">
		Count is: <span $state="count">{count}</span>
	</button>
</hydrate-server-state>

<script>
	import { Stellar } from 'stellar-element';
	class HydrateServerState extends Stellar {
		constructor() {
			super();
			console.log(this.text); // Logs "Hello world!"
			this.text = 'Hey there!'; // Update paragraph element with text "Hey there!"
			console.log(this.text); // Logs "Hey there!"
		}
		// Increment count state and update span element with new count
		increment = () => this.count++;
	}
	customElements.define('hydrate-server-state', HydrateServerState);
</script>

The usual disclaimers

Stellar is still under active development and has mainly been a project built for me and my preferences, so all the usual disclaimers apply: Something something incomplete. Something something here be dragons.

If you’re still interested in giving it a try, however, please let me know how it goes! You can file an issue or send me a toot with your feedback.

The tip of the iceberg

Using HTML web components has been a deeply refreshing and encouraging method of building interactive UI that I strongly believe has the potential to be a serious trend in how we build the web going forward.

While this post has been a collection of my thoughts and takeaways loosely tied together, I’ve been working on an even bigger video (I was a filmmaker for several years before I found tech) about the topic where I dive further into using Astro, HTML web components, and HTMX to build delightfully simple, yet surprisingly robust, web applications.

If that sounds exciting and/or interesting, subscribe to my YouTube and TikTok to be the first to see it when it’s released.

Until next time 👋🏼

HTML Web Components is the wrong name

Tue, 21 Nov 2023 00:00:00 GMT

I’m psyched. My favorite way of building web components is starting to come into vogue and with all the recent discussion about this concept, I can’t help but toss my hat and thoughts into the ring.

I'm currently writing a much longer post about my time experimenting with, building, and using these components during the last year (plus I may or may not be soft-launching a tiny web framework that I may or may not have been working on for several months specifically focused on building this type of web component... who knows), but with things moving fast I wanted to at least chime in with my thoughts about the recently proposed and initially adopted name “HTML Web Components.”

This is an extremely new term to describe this concept –– about a week old as of writing these words. So while the dust hasn’t fully settled I want to add my two cents and implore those building and writing about this that we consider finding a different name.

My big issue can be boiled down to the idea that "web components" is an extremely overloaded term that I would argue has a principle definition that can roughly be described as "a set of evolving browser APIs that allow you to create custom HTML elements." That is to say, "web components" are themselves literally HTML elements, so when I see the term “HTML Web Components” I can’t help but read it as “HTML HTML.”

For me, this name is confusing and does not do a good enough job of properly or intuitively distinguishing how this model is different from “regular” web components.

I should also acknowledge and clearly state my bias when thinking about this name. I've spent years teaching students and coworkers about various programming concepts (especially web components as of the last couple of years), so I often lean towards the perspective of a student or new learner.

In some ways, you might consider this post an argument in support of choosing a name that will help new learners ease into the world of web components –– which is already filled with so many potential potholes and points of confusion (no shade, but looking at you Shadow DOM).

I started a thread that already has some discussion on the topic with some very valid counterpoints raised, but I still think this name is worth reviewing. Below are a few of those counterpoints and my thoughts on them.

It would be great to re-use the "Web Component" branding

Reference

I actually agree and think this is one of the more compelling reasons to stick with "HTML Web Components!" Brand recognition is powerful and well worth considering.

With that said, "web components," I'd argue, is one of the most fraught and convoluted web development brands and concepts of the last decade. I worry that explicitly rolling up to this branding will just add further confusion –– especially for those starting to learn about web components.

A different name that does not include the words "web component" could still very easily fall under the "web component" banner/branding, but it will not contribute to an overloaded phrase that already means a lot of different things to a lot of people.

In the best case, this is an opportunity to start fresh, so to speak. I could see an alternative name (if done well) pulling the interest/curiosity of those who have previously held strong negative opinions about "web components" by simply avoiding those words up front and center. Maybe?? 🤷🏻‍♂️

"HTML Web Components" focuses on the "HTML" part of web components

Reference

Jim Nielsen has written a few posts at this point where he differentiates between the two types of web components by calling them "HTML Web Components" and "JavaScript Web Components." In his words:

I like the term “HTML web components” because it makes me think of the HTML-centered part of [the web component] “suite of technologies”

Like the branding counterpoint, I also really like this idea –– it makes a lot of sense to me to roughly categorize "web components" into an HTML-focused bucket and a JS-focused bucket.

With that said, what does "HTML-centered" mean? Especially for someone who might know less about web components? When you start getting into the weeds of web components you'll find that "HTML Web Components" and "JavaScript Web Components" require almost nearly the same amount of JavaScript and HTML –– i.e. the Custom Elements API accounts for the vast majority of weight in a web component.

Of course, as one learns more they will eventually grasp the idea that this naming convention reflects/indicates a web component architecture versus a web component implementation strategy.

And I suppose there lies a key question that needs answering: Is it more desirable to have the name indicate an architectural differentiation or have the name better reflect a sort of blueprint of how this type of component is implemented?

*Editor's note: As I'm doing a final pass I'm starting to wonder if this is a false dichotomy because an architecture can/does in some way indicate an implementation strategy...

Hopefully, the point I'm trying to make is coming across, but if not the core idea is that I worry people will not initially understand what "HTML" is supposed to mean in "HTML Web Component" and get wires crossed especially when considering that a non-zero group of people defines "web components" as a way of creating custom HTML elements.

Said a different way, what does an "HTML custom HTML element" or a "JavaScript custom HTML element" entail? I'd argue the naming does not make this clear and I really wish it did a better job of that.

This simply might not matter in the scheme of things

Reference

Chris Ferdinandi pointed out that this all might not matter in the big picture, noting that some of the alternative names that have been suggested might stray a bit too far into buzzwordy territory. I think he correctly points out that some of these names could "[turn] into a 'yesteryear buzzword' the way people sometimes treat progressive enhancement today."

I've not named nearly enough things to have a strong opinion or experience on this one. I could see it going both ways, but I will admit that "HTML" and "Web Components" lean pretty heavily toward the "timeless" (versus "buzzwordy") end of the scale. So barring an even better alternative name, this is likely a +1 towards "HTML Web Components."

So.. what should we name this?

Personally, my favorite suggestion has been Ryan McNeely’s “enhanced components” or “progressive tags” but even those don’t feel quite right to me. To build on McNeely, I’d perhaps suggest “progressive web components” or even better “progressive custom elements.” They both indicate that progressive enhancement is a core principle of working with this model and the latter name makes clear this is a method of building interactive UI using only custom elements and nothing else from the "web component" bucket of APIs.

Zach Leatherman also (perhaps unintentionally) suggested "HTML Custom Elements", which I like as well. It still kind of reads as "HTML HTML" to me, but at least it avoids using "web component."

I’m not fully sold on any of these names to be clear. I think they do a better job of correctly conveying what we’re talking about, but I question if they are any more intuitive than "HTML Web Components" for someone who's learning about web components for the first time.

The big call to action is one final round of name suggestions that keep in mind the historical baggage of the term "web components" and are considerate of the new learners that will enter the web component world in the years to come.

The train might have left the station already

Admittedly the train is already mostly out of the station with the fantastic posts I've linked to all using “HTML Web Components” front and center, but if there’s any willingness to reconsider I’d love to discuss and see if this naming can be a more accurate (and ideally intuitive) reflection of the concept.

With all that said, this is a strong opinion loosely held on my part, and without any great alternative name(s) I do think "HTML Web Components" checks enough boxes as is. So if the consensus and desire (from those who have already written about this and the wider community) are to move forward with "HTML Web Components" I will happily (for the most part) roll with it.

I at least wanted to convey these thoughts before it was too late. I invite you to add to the discussion in the form of response blog posts or adding to this thread.

As always, naming things is the hardest part of programming…

Let me dictate my own realm

Tue, 02 May 2023 00:00:00 GMT

At the end of last year, Robin Sloan published a newsletter declaring "the platforms of the last decade are done" and made a call for new thinking, projects, hopes, and dreams about what the next era of platforms and social media may look like.

Below is one of my hopes.

I'm old enough to just barely remember a time before the internet became a horizon-swallowing monolith.

By the time I was ready to surf the web, Facebook poke wars, FarmVille, and Truth Is posts were my generation's starter pack for communicating on the web. It means, by and large, I have never known an internet that isn't trying to extract every bit of attention and value it can from me.

It also means I missed many of the early days of internet culture and communication. So, after leaving Twitter last fall, I gave RSS feeds a try for the first time in my life.

It has been a striking experience.

During the last decade, I have been conditioned to constantly think about "curating" my algorithm across various platforms. What I like, dislike, comment on, share, save, watch (and for how long) are, at this point, well-worn tools in my algorithmic toolbelt for crafting and steering the content that gets served on each of my feeds.

With RSS, however, there is none of this –– just a dead simple subscribed or not subscribed. What I read (or don't read) has no consequence on seeing future content from an author, and I will never be served content from a feed I am not subscribed to.

Curating an algorithm can produce delightful results when done right, but it can also be exhausting to engage in –– especially when trying to avoid the death spirals of doom scrolling, FOMO/isolation, division, and on and on... I know this. You know this. We all know this.

What has been shocking to me, however, is how insidious this habit/proclivity towards curation can be.

While using RSS, I have found myself regularly getting anxious that if I don't finish reading a post in one sitting it will disappear into the digital abyss, or if I skip out on a post that doesn't particularly interest me I'll start seeing less from that author. I have to regularly remind myself that isn't how RSS works.

I've always known on some level that content algorithms can play a role in how I act and feel, but it has been striking to see, with such clarity, how much of my thoughts and behavior have conformed to how algorithms of the last decade work.

On the topic of algorithms, Robin Sloan says in his newsletter:

I suspect the best answers are grounded in good old-fashioned human recommendations, but who knows? Maybe TikTok has it right; maybe everybody deserves one (1) audition with the capricious god-algorithm of the realm. Maybe there’s something to be isolated and improved there.

I think I land somewhere in the middle.

My hope is a future internet where at any time and for any reason I can let an AI delight me with something new or take a breather and tune into the simplicity/reliability of an RSS-like algorithm.

My hope is that the platforms of the next era will let me choose the algorithms that dictate my realm.

An SSR framework in 37 lines of code

Tue, 12 Jul 2022 00:00:00 GMT

During the last year, I've become completely enthralled by the worlds of both frontend web framework development and modern web standards/conventions (such as web components, unbundled development, and so on).

With a goal of trying to combine these two worlds I've been capturing my research, experimentation, and takeaways in the form of Delgada –– a web framework for building slim multi-page websites.

While Delgada is still under very active development, I recently took a step back to synthesize my learning, which resulted in a surprisingly feature-rich server-side rendering (SSR) framework, implemented in just 37 lines of code.

Features of this SSR framework include:

Ship zero JavaScript by default
Expressive markup and styling using tagged templates
Island-based architecture via web components
No build step
Zero configuration

The point of this is not to provide a feature-complete implementation of SSR by 2022 standards, but to show that one can get shockingly far with very little code by building on top of the web standards and conventions available today. Think of it as a celebration of the modern web and what it enables.

In the rest of this post, I'll talk about the features, conventions, and syntax of this framework and discuss how it's enabled.

Finally, the source code (along with a demo) for the SSR implementation can be found in this GitHub repo.

House-keeping complete. Let's dive in!

Project structure

We'll start with a birds-eye-view of a basic demo project structure to get oriented with the conventions of using this framework.

The goal of this structure is to emulate modern web conventions and should hopefully feel straightforward and familiar to most reading this.

my-website/
├── public/
│   ├── favicon.png
│   └── global.css
├── src/
│   ├── components/
│   │   ├── SomeComponent.js
│   │   └── AnotherComponent.js
│   └── pages/
│       ├── About.js
│       └── Index.js
├── package.json
└── server.js

At the root of the project are the server and package.json files. A public directory contains all the static assets and a src directory contains the components that will be rendered server-side.

The server

Below is an example server.js file. It contains, amongst other things, the primary API of the SSR implementation (which I'll just call slim-ssr going forward).

import { register } from 'slim-ssr';
import { Index } from './src/pages/Index.js';
import { About } from './src/pages/About.js';
import express from 'express';

const routes = [
	{ path: '/', component: Index },
	{ path: '/about', component: About },
];

const islands = ['WebComponent.js'];

const app = express();
register(app, routes, { islands });

const port = 3000;
app.listen(port, () => {
	console.log(`Listening on http://localhost:${port}`);
});

A function called register is the first introduction to slim-ssr. The register function is responsible for setting up and handling the routing/file serving of a slim-ssr website.

Another thing you might notice is that Express is being used as the underlying server. For slim-ssr, this keeps things simple and gives a solid groundwork to build on top of, but it could be easily switched out for another server or server framework.

Routing

Routes are defined as a simple array of objects with a path and component property.

const routes = [
	{ path: '/', component: Index },
	{ path: '/about', component: About },
];

Inside slim-ssr, routing is handled by these 6 lines of code.

for (const route of routes) {
	app.get(route.path, (req, res) => {
		res.set('Content-Type', 'text/html');
		res.send(Buffer.from(route.component(req)));
	});
}

It takes the routes array discussed above, iterates over every route object, and serves the HTML returned by the component function at the endpoint defined in path. Also notice that the component function is passed the client request (i.e. component(req)) –– we'll come back to this later.

Serving web components/islands

Web components/islands (which will also be discussed later in more depth) are registered as an array of strings, where each string is the name of a web component file in the src/components/ directory.

Each file will be served to the client at the root URL (/) of a slim-ssr website. So if there's a web component called WebComponent.js, it will be served at /WebComponent.js.

const islands = ['WebComponent.js', 'AnotherWebComponent.js'];

In slim-ssr, the following code enables this behavior.

if (options.islands) {
	for (const island of options.islands) {
		app.get(`/${island}`, (_, res) => {
			res.set('Content-Type', 'application/javascript');
			res.sendFile(island, {
				root: path.join(process.cwd(), 'src', 'components'),
			});
		});
	}
}

It first checks that an islands array has been provided (since it's an optional config). For every file name provided, an absolute path to each web component file is constructed (i.e. the current working directory + /src/components/WebComponent.js) and then served at the root URL.

Static file serving

Similar to Next.js, (and just like the web component file serving above) all files in the public directory are also served to the client at the root URL via the code below.

app.use(express.static(`${process.cwd()}/public`));

Template syntax

Before discussing components, we need to cover the template syntax of this framework, which will be used to define component markup and styles.

JavaScript has a powerful built-in templating language called template literals (or template strings). A more advanced form of template literals (and what slim-ssr uses) are something called tagged templates.

In slim-ssr, an html and css tag are defined/exported and can be used to write expressive markup and styling like so:

// Basic markup and styles
html`<h1>Hello world!</h1>`;
css`
	h1 {
		color: red;
	}
`;

// Use JavaScript expressions directly in markup/styles
const name = 'Universe';
const color = 'red';
html`<h1>Hello ${name}!</h1>`;
css`
	h1 {
		color: ${color};
	}
`;

// Conditional rendering/styles
const age = 17;
let darkMode = true;
html`<p>You ${age >= 16 ? 'can' : 'cannot'} drive.</p>`;
css`
	body {
		background: ${darkMode ? 'black' : 'white'};
	}
`;

// Mapping over data to generate markup/styles
const fruits = ['apple', 'banana', 'orange'];
const tokens = [
	{ name: 'primary-color', value: 'rgb(210, 210, 210)' },
	{ name: 'secondary-color', value: 'rgb(180, 180, 180)' },
];
html`
	<ul>
		${fruits.map((fruit) => html`<li>${fruit}</li>`)}
	</ul>
`;
css`
	:root {
		${tokens.map((token) => css`--${token.name}: ${token.value};`)}
	}
`;

All the above is enabled by just 15 lines of code.

export function html(strings, ...values) {
	const parts = [strings[0]];
	for (let i = 0; i < values.length; i++) {
		if (Array.isArray(values[i])) {
			for (const value of values[i]) {
				parts.push(String(value));
			}
		} else {
			parts.push(String(values[i]));
		}
		parts.push(strings[i + 1]);
	}
	return parts.join('');
}

export const css = html;

The html function accepts an array of strings and an arbitrary set of value arguments (which represent JavaScript expressions that may exist in a template). It builds up these different parts into an array of strings that are then joined and returned as the final rendered HTML.

It also notably has some special logic for handling expressions that map over arrays of data to generate markup/styles –– something that is not cleanly handled in regular template literals.

The css function is simply just the html function re-exported with a different name.

A quick note on developer experience

By default, tagged templates will be rendered/treated as strings in code editors which results in a less than ideal developer experience when writing component markup/styles. This, however, can be changed with extensions/tooling.

In the case of VS Code, installing the lit-html and es6-string-html extensions make a world of difference while writing HTML/CSS in tagged templates. They can be used to add a ton of helpful features like syntax highlighting, IntelliSense, quick hover info, HTML tag folding, and so on.

Emmet support inside tagged templates can also be enabled in VS Code by changing the "Emmet: Include Languages" setting and adding mappings for "javascript": "html" and "typescript": "html".

Component model

In 2022, web components are living in a bit of a weird teething phase when it comes to SSR. The Declarative Shadow DOM –– which is the API that will enable web components to be server-side rendered –– is only supported in Chromium-based browsers at this time.

This means if web components are adopted as the sole component model of slim-ssr, it would fail to reach its stated goal of shipping zero JavaScript by default. That is to say, in any non-Chromium-based browser, client-side JavaScript would be required to render UI that only needs HTML and CSS.

In the future, it should be possible to use web components for rendering static and dynamic UI server-side, but for now, we have to look elsewhere for defining static content. Lucky for us, it's possible to achieve an expressive component model that can render static content server-side using functions and the tagged templates discussed above!

Static components

An idea I've been playing with during the last few months while creating Delgada is to have a distinct separation between components that are static (i.e. send HTML/CSS to the client) and components that are dynamic (i.e. send HTML/CSS/JavaScript to the client).

It's a design decision that I have come to really enjoy and so I'm using it here.

To quickly break it down:

Static components are functions that return a string of HTML
Static component props are function arguments
Static component styles are variables that contain a string of CSS

import { html, css } from 'slim-ssr';

export function Greeting({ name }) {
	return html`<h1>Hello ${name}!</h1>`;
}

export const styles = css`
	h1 {
		color: red;
	}
`;

To use a static component simply import and add the component function within the markup of another static component.

To correctly pick up the styles of a component, they also must be imported and added to the styles of the target component as shown in the below code snippet.

import { html, css } from 'slim-ssr';
import { Greeting, styles as GreetingStyles } from 'Greeting.js';

export function Index() {
	return html`
		<!DOCTYPE html>
		<html lang="en">
			<head>
				<title>Home</title>
				<style>
					${styles}
				</style>
			</head>
			<body>
				${Greeting({ name: 'Reader' })}
				<p>This is the home page.</p>
			</body>
		</html>
	`;
}

export const styles = css`
	p {
		color: blue;
	}

	${GreetingStyles}
`;

Using the client request object

As briefly mentioned earlier, components that are defined in the routes object in server.js will be passed a client request object that can be optionally used.

This request object can be used to enable features such as conditional rendering based on request parameters. For example, the component below uses a URL parameter to render a greeting.

import { html, css } from 'slim-ssr';

export function Hello(req) {
	const name = req.params.name;
	return html`<h1>Hello ${name ?? 'Person'}</h1>`;
}

A name can be added to the end of the page URL in the form /hello/{name}. If no name is provided the greeting is conditionally rendered to return "Hello Person" as the default.

In server.js a new route is added that uses Express's parameter syntax.

const routes = [{ path: '/hello/:name?', component: Hello }];

Finally, since the request object is only passed to the components directly contained in routes if a child component needs access to the request object it will need to be passed down as a prop.

Dynamic components / islands

Islands architecture (or "component islands") is a method of building websites that has really come in vogue during the last year. As Jason Miller describes in his 2020 article introducing the concept:

The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be "hydrated" on the client into small self-contained widgets, reusing their server-rendered initial HTML.

It's an architecture that is great at isolating JavaScript to only the parts of your website that need it. In the case of slim-ssr websites, we'll be accomplishing this architecture via web components.

Basic usage

Given a <counter-button> web component (that increments a count on every button click), it can be added to a web page by using the counter button in a static component and then manually linking to the web component file (i.e. /CounterButton.js) in a script tag. Nothing crazy at this point.

import { html } from 'slim-ssr';

export function Index() {
	return html`
		<!DOCTYPE html>
		<html lang="en">
			<head>
				<title>Home</title>
				<script type="module" src="/CounterButton.js"></script>
			</head>
			<body>
				<counter-button></counter-button>
			</body>
		</html>
	`;
}

Some will have noticed, however, that this doesn't actually meet the definition of islands architecture.

We've created a placeholder that will be hydrated on the client into a small self-contained widget, but there is no server-rendered HTML at this point (since we're not using the Declarative Shadow DOM API).

Enter: Pascal Schilp's writing on SSR and custom elements.

In the article, Pascal points out that any markup nested inside a web component can be conditionally styled during the time it takes for the web component JavaScript to be executed with the following CSS selector.

web-component:not(:defined) button {
	/* Apply arbitrary styles to a button nested 
  inside <web-component> while it's not defined. */
}

We can take this fact and restructure the counter button so that a <button> is accepted as a slotted element to achieve the server-rendered HTML aspect of islands architecture.

By simply copying and pasting the initial state of the <counter-button> and its associated styles into the static component, website visitors will see a button that looks like the final hydrated button before its JavaScript has been run.

A nice bonus: This will also address the issue of flash of undefined custom elements (FOUCE) that web components often fall prey to.

<counter-button>
	<button>Clicked <span id="count">0</span> times</button>
</counter-button>

counter-button:not(:defined) button {
	background-color: #efefef;
	color: black;
	border: 2px solid #000;
	border-radius: 8px;
	padding: 6px 10px;
}

counter-button:not(:defined) button:hover {
	cursor: pointer;
	background-color: #e6e6e6;
}

/* ... other static component styles ... */ ;

One more scenario worth mentioning (that is also discussed in Pascal's article), is that we can take advantage of the fact that arbitrary styles can be applied to the button to better represent its current state.

In this case, when the component is not hydrated it will not be interactive. So instead of styling the button normally, it could instead be styled to imply it's in a disabled state.

counter-button:not(:defined) button {
	background-color: lightgrey;
	color: darkgrey;
	border: 2px solid #000;
	border-radius: 8px;
	padding: 6px 10px;
}

counter-button:not(:defined) button:hover {
	cursor: not-allowed;
}

Once the component is hydrated the normal button styles defined inside the web component will kick in and override the disabled styles.

Clearly, exposing the internals of every web component as slotted children is not the most ideal solution, but it does at least meet the stated goals of slim-ssr and starts to demonstrate what a world with full Declarative Shadow DOM support will look like –– which I think is pretty exciting.

While this conclusion may be discouraging to some, I think a recent tweet by Danny Moerkerke is a great reminder of how to think about web components:

Web Components are a standard so features take longer to be added, contrary to frameworks that can basically add any feature they like.

It doesn’t mean that Web Components are bad or will never be ready.

Be patient, standards take time.

So yes, while it's unfortunate that the SSR story of web components is still in a teething phase, I hope the ideas above act as a catalyst of excitement for what can still be accomplished today and the fact that there's a lot of work being done to improve this story in the future.

Taking these ideas further

At only 37 lines of code, there's a lot of headroom to play with and ways to push the ideas laid out above even further. Some ideas that I've already implemented in Delgada or I'm actively exploring are:

File-system based routing

For not too much code, file-system based routing can be achieved. Delgada already does this to statically generate websites.

It's a fairly straightforward case of recursively iterating through all the static component files in the src/pages/ directory, executing the component code to render final HTML output, and then writing those outputs to files in a build directory –– making sure to mirror the directory structure inside src/pages/ in build.

Automatically add script tags for islands

A minor quality of life improvement that requires very little code is automatically inserting a script tag into every page that uses web components. Here's an implementation of this concept in Delgada.

Optional inline styles

Some may have noticed that all the page styles in the code snippets above were eventually inlined.

<head>
	<style>
		${styles}
	</style>
</head>

While this is great for improving first-time page loads, it's not so great for web pages that have a lot of recurring visitors who would benefit from an external CSS file that can be cached by the browser.

For about 20 lines of code, the option to define styles as inline or as an external file is possible.

In Delgada, this manifests as the ability to define a metadata object for each page with various configuration options. One of them is the ability to change whether the styles of a given page should be inlined or not.

export const metadata = {
	// Will generate a separate CSS file for the given page
	inlineCSS: false,
};

// ... other static component code ...

Page templates

Another feature that is basically free because static components are just functions is the ability to define page templates/layouts.

Template components can be defined using the same syntax as a static component and accepts a slot prop. In the example below, a template can be used to reduce the boilerplate of web pages.

import { html } from 'slim-ssr';

export function Template(slot) {
	return html`
		<!DOCTYPE html>
		<html lang="en">
			<head>
				<title>My Website</title>
			</head>
			<body>
				${slot}
			</body>
		</html>
	`;
}

import { html } from 'slim-ssr';

export function Index() {
	return html`<h1>Hello World!</h1>`;
}

To use the template, the routes array in server.js simply needs to be updated so that page components are wrapped by the template component.

import { Index } from './src/pages/Index.js';
import { Template } from './src/templates/Template.js';

const routes = [
	{
		path: '/',
		component: () => {
			Template(Index);
		},
	},
];

Delgada takes this one step further by also automatically passing the metadata object to all templates so that it can be used to pass arbitrary data from a page into a template.

export const metadata = {
	title: 'My Website',
	inlineCSS: false,
};

import { html } from 'slim-ssr';

export function Template(slot, metadata) {
	return html`
		<!DOCTYPE html>
		<html lang="en">
			<head>
				<title>${metadata.title}</title>
			</head>
			<body>
				${slot}
			</body>
		</html>
	`;
}

Use a modern runtime like Deno or Bun

Adding TypeScript support to a Node-based web framework can be kind of tricky.

An alternative I've been exploring is to build a web framework on top of a modern runtime like Deno or Bun that supports TypeScript execution out of the box.

Component scoped CSS in static components

I'm also looking into adding scoped CSS support in static components since all the styles currently live in the global scope of any given page.

It's a topic I haven't put too much research into yet, so if anyone reading this has any resources or tips please do send a post or DM my way!

Template directives

Pulling inspiration from Lit (a framework for building web components), the templating of slim-ssr could be vastly improved via "directives."

Directives are functions that customize the way a template expression gets rendered and can either simplify the creation of markup/styles or add extra functionality that doesn't exist currently.

Lit's list of built-in directives offers some great inspiration for what's possible.

Incremental build-time rendering

Another cool optimization that could be added is what Thomas Allmer refers to as "On-Demand to Build-Time Cache SSR" or "Incremental Build-Time Rendering". Others might also know this concept from Next.js as "Incremental Static Regeneration."

The basic idea is to render and send a page request as normal, but also write the rendered HTML to a file that is saved in a cache. If there's a subsequent request made for the same page the cached file will be sent instantly instead of re-rendering everything.

Conclusions

In a time when everyone seems to be talking about bloated website bundles and inattentive usage of NPM packages, I've discovered a breath of fresh air and a delightful simplicity in what the modern web can enable in 2022.

It, of course, still has its discomforts and growing pains but it has me really excited for what the future holds. I hope after reading this you might be feeling some of that excitement too.

Liked what you read? Or maybe not? Have a question? Let me know on Mastodon!

The mega full-stack resource guide

Thu, 10 Sep 2020 00:00:00 GMT

The guide is split into five main categories.

<section> <h2 id="prelude">Prelude</h2> <h3 id="why-is-this-guide-a-thing">Why Is This Guide A Thing?</h3> I have a meticulously organized digital life. My computer's file system allows me to track down any photo, video, or document I've created during any month over the past 13 years. My Google Drive is similarly organized to keep track of documents such as the high school resume I used to get my first job or the documents I made for every single class during my 5 years of college. And, importantly for this post, I have a Chrome bookmark system that allowed me to stay organized and learn computer science/software engineering after a sudden change of direction in my last 2 years of college. <img src="/imgs/bookmarks.gif" alt="A gif of my Chrome bookmarks." /> Contained in these bookmark folders are links to hundreds of resources ranging from artificial intelligence to development tooling. This catalog of resources allowed me to organize my thinking as I learned new topics and to ultimately collect some incredible content that was instrumental to my learning during college. Now, as a recent graduate, I want to pass on some of those resources that were so helpful to me. My hope is that those in their own process of learning might find something useful in all of this just as I did. <h3 id="about-this-guide">About This (Long) Guide</h3> As hinted via the title above, this guide is focused on full-stack web development resources. This is due in part to an effort to limit the scope of this guide, but also because I'm really passionate about the internet and what it has to offer –– it's quite a festive place. In addition to simply providing an organized list of links, I've included high-level explanations of each topic and how it fits into the world of full-stack web dev. I've also included some of my own thoughts and personal recommendations (denoted by 🔥) for some of the resources. It's my way of highlighting those resources which have been invaluable to me and an opportunity to give some plain-English insights/information that might be helpful to those learning about these topics. I hope you enjoy it! </section>

<section> <h2 id="dev-resources">Development Resources</h2> <img src="/imgs/dev-resources.png" alt="An illustration of a terminal icon." /> I start this guide with development tools because even with all the knowledge of full-stack development in the world you need tooling to put it to action. For those new to the world of software tooling, it encompasses a huge variety of subtopics. Because of this, you can get lost down some pretty deep and overwhelming rabbit holes, but at it's most basic it usually means choosing a good text editor and terminal that is suited to the work you'll be doing. <h3 id="text-editor-resources">Text Editors / IDEs</h3> Text editors and IDEs (Integrated Development Environments) are desktop applications, command-line applications, or web applications where you write code –– basically think Microsoft Word but specialized for writing code. <img src="/imgs/vs-code.png" alt="An illustration of the VS Code logo." /> There is an almost endless number of text editors and IDEs available that offer various benefits and drawbacks, so don't be afraid to try out different options until you find something that feels comfortable. My current favorite is the very popular Visual Studio Code made by Microsoft (which is not to be confused with Microsoft's IDE––Visual Studio). VS Code is a flexible text editor with a huge number of settings and third-party extensions that can customize the editor's look and functionality to fit and improve your workflow. In addition to that, VS Code comes with some incredible built-in extensions for JavaScript and TypeScript that make it a very useful editor for web development. <ul> <li> 🔥 <a href="https://discuss.atom.io/t/what-is-the-difference-between-an-ide-and-an-editor/32629" >What Is The Difference Between An IDE And An Editor?</a > </li> <li>🔥 <a href="https://code.visualstudio.com/">VS Code Website</a></li> <li> 🔥 <a href="https://code.visualstudio.com/docs">VS Code Documentation</a> </li> <li> 🔥 <a href="https://welearncode.com/vscode-setup/">VS Code Setup</a> </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=u21W_tfPVrY&ab_channel=Fireship" >VS Code Top Ten Pro Tips</a > </li> <li> 🔥 <a href="https://www.openvim.com/">Interactive Vim Tutorial</a> </li> <ul> <li>Vim is a very powerful command-line text editor.</li> </ul> <li> <a href="https://missing.csail.mit.edu/2020/editors/">Vim Tutorial</a> </li> <li><a href="https://atom.io/">Atom Website</a></li> <ul> <li>Atom is another great desktop text editor made by Github.</li> </ul> <li><a href="https://atom.io/docs">Atom Documentation</a></li> <li><a href="https://codesandbox.io/">Code Sandbox IDE</a></li> <ul> <li> Code Sandbox is an online editor that is great for prototyping JavaScript-based web apps. </li> </ul> </ul> <h4>Text Editor Extension Resources</h4> Below are some text editor extension resources that are worth a peek. Emmet makes the job of writing HTML a breeze by defining a succinct syntax that can be expanded into full HTML. A cheat sheet of the syntax can be found below. Kite and TabNine are AI powered coding assistants that provide some very impressive code autocompletion features. <ul> <li> <a href="https://docs.emmet.io/cheat-sheet/">Emmet Cheat Sheet</a> </li> <li><a href="https://www.kite.com/">Kite</a></li> <li><a href="https://www.tabnine.com/">TabNine</a></li> </ul> <h3 id="terminal-shell-resources">Terminals / Shells</h3> Terminals, sometimes casually referred to as "command lines" or "consoles", are desktop applications that allow you to interact with a shell. A shell is a text-based user interface that allows you to control your computer. Instead of using a mouse to click UI elements and icons, you type commands into the shell that allow you to do things like open desktop applications, run code, navigate your computer's file system, automate tedious or repetitive tasks, and so much more. Becoming proficient with a terminal/shell combo is a massively valuable skill in the world of not only full-stack development but of software engineering at large. Finally, just like text editors and IDEs, there are many terminals and shells with benefits and drawbacks. So once again have fun and try different options until you find something that works for you. My current terminal/shell combination is iTerm2 and zsh. iTerm2 is a great terminal with a rich set of features and customization options, but is unfortunately MacOS only. Zsh is the default shell for MacOS. <ul> <li>🔥 <a href="https://www.iterm2.com/">iTerm2</a></li> <li>🔥 <a href="https://hyper.is/">Hyper</a></li> <ul> <li> Hyper is another really clean cross-platform terminal created using web technologies. </li> </ul> <li> 🔥 <a href="https://github.com/rothgar/mastering-zsh">Mastering Zsh</a> </li> <li>🔥 <a href="https://ohmyz.sh/">Ohmyzsh Website</a></li> <ul> <li> Ohmyzsh is a fantastic framework for generally improving the experience of using zsh. </li> </ul> <li> <a href="https://dev.to/aspittel/my-terminal-setup-iterm2--zsh--30lm" >Terminal Setup: iTerm2 + Zsh</a > </li> <li> <a href="https://scriptingosx.com/2019/06/moving-to-zsh/" >Moving to Zsh</a > </li> <li> <a href="http://zpalexander.com/switching-to-zsh/" >Switching to Zsh</a > </li> <li> <a href="https://github.com/ohmyzsh/ohmyzsh">Ohmyzsh GitHub</a> </li> </ul> <h2 id="browser-resources">Browser Resources</h2> <img src="/imgs/browsers.png" alt="An illustration of various major browser logos." /> In the world of full-stack web development, the next thing to consider is browsers. These are the applications that allow you to access the internet and execute/render the frontend code (i.e. websites) you will create. These browsers also offer tools for debugging and analyzing your website's code. Learning how to work with these tools early on (and especially once you start learning JavaScript) is something I can't recommend enough. Finally, it is very important to know that the frontend code you write will not always work or look the same across different browsers (the reason for this can be better understood in the 'How Browsers Work' and 'Browser Engines' sections below). As a result, it's highly recommended to have many of the <a href="https://www.w3counter.com/globalstats.php">popular browsers</a> downloaded so you can test your website on each browser. Pro Tip: An amazing tool for determining whether or not your frontend code will work on a particular browser is <a href="https://caniuse.com/">Can I Use?</a>. <h3>🔥 Browser Development Tools</h3> Understanding how to debug your code is one of the most important aspects of learning how to develop for a platform like the web. Browsers like Chrome and Firefox offer some absolutely incredible debugging and development tools. LEARN HOW TO USE THESE TOOLS. <ul> <li> 🔥 <a href="https://developers.google.com/web/tools/chrome-devtools/" >Chrome DevTools Guide</a > </li> <li> <a href="https://developers.google.com/web/tools/lighthouse/" >Google LightHouse Guide</a > </li> <ul> <li> Google Lighthouse is a great tool that can automatically audit the performance, accessibility, SEO, and more of your website. </li> </ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Tools" >Firefox Developer Tools Guide</a > </li> <li> <a href="https://developer.apple.com/safari/tools/" >Safari Web Development Tools</a > </li> <li> <a href="https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium" >Microsoft Edge Developer Tools</a > </li> </ul> <h3>How Browsers Work</h3> Understanding how browsers work under the hood will give context to the code you write and fundamentally change how you think about full-stack web development… or at least it did for me 😁. This is an admittedly advanced topic since there is a very different skillset at play when creating a web browser versus making a website, but I still think it's worth reviewing at some point during your full-stack education and then continuing to revisit the topic as you learn more. <ul> <li> 🔥🔥🔥 <a href="https://alistapart.com/article/from-url-to-interactive/" >How Browsers Work Under The Hood –– Aaron Gustofson Series</a > </li> </ul> <h3>Browser Engine Resources</h3> Another really cool topic that is an even more focused look into how browsers work is learning about browser engines. This topic is not necessary to learn web development, but can once again be a nice way to gain a deeper insight into what is happening inside your browser. Also, be warned, this an advanced topic. Browser engines, in short, are the core pieces of software built into web browsers like Chrome and Firefox that do the work of executing and rendering the website code that you write. Typically, browser engines are comprised of two primary types of engines: <ul> <li> Rendering Engines –– Responsible for rendering the pixel-by-pixel layout of a website </li> <li> JavaScript Engines –– Responsible for interpreting/compiling and executing JS code (as well as WebAssembly code in some cases) </li> </ul> These engines are the primary reason that the frontend code you write may not work or look the same across browsers. Browsers will often use different engines that have unique implementation details which can cause differences in how a website is laid out or interpreted. A Quick Note: It is also common for the term "browser engine" to only refer to the part of a browser that is in charge of rendering a webpage. This is because it's very common for JavaScript engines to be built in a way that they can function independently from a browser, whereas the rendering engine is a fundamental and baked in part of browsers. So keep that all in mind as you learn more about these engines in the wild. <ul> <li> 🔥 <a href="https://www.lambdatest.com/blog/browser-engines-the-crux-of-cross-browser-compatibility/" >Browser Engines: The Crux Of Cross Browser Compatibility</a > </li> <li> 🔥 <a href="https://hacks.mozilla.org/2017/05/quantum-up-close-what-is-a-browser-engine/" >Quantum Up Close: What Is A Browser Engine?</a > </li> <li> <a href="https://gizmodo.com/which-browser-engine-powers-your-web-browsing-and-why-d-1833935288" >Which Browser Engines Powers Your Web Browsing––And Why Does It Matter?</a > </li> <li> <a href="https://www.browserstack.com/guide/browser-rendering-engine" >Understanding The Role Of Rendering Engine In Browsers</a > </li> <li> <a href="https://securitygladiators.com/web-browsers-engines/" >Web Browsers And Their Engines: Know Everything</a > </li> <li> <a href="https://www.wikiwand.com/en/Browser_engine" >Wikipedia: Browser Engines</a > </li> </ul> <h4>Chrome Engines</h4> <ul> <li><a href="https://v8.dev/">V8 Website</a></li> <li> <a href="https://www.chromium.org/blink">Blink Website</a> </li> </ul> <h4>Firefox Engines</h4> <ul> <li> <a href="https://mozilla-spidermonkey.github.io/" >SpiderMonkey Website </a> </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey" >MDN SpiderMonkey: The Mozilla JavaScript Runtime</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Gecko" >MDN Gecko Rendering Engine</a > </li> <li> <a href="https://servo.org/" >Servo––Parallel Browser Engine Project</a > </li> <li> <a href="https://github.com/servo/servo/wiki/Design">Servo Design</a> </li> <li><a href="https://blog.servo.org/">Servo Blog</a></li> <li> <a href="https://www.youtube.com/watch?v=UGl9VVIOo3E&feature=youtu.be&list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&ab_channel=WebEnginesHackfest" >Servo: Today & Tomorrow</a > </li> </ul> <h4>Safari Engines</h4> <ul> <li><a href="https://webkit.org/">WebKit Website</a></li> </ul> <h4>Miscellaneous Resources</h4> <ul> <li> <a href="https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html" >Let's Build A Browser Engine!</a > </li> </ul> </section>

<section> <h2 id="client-side-resources">Client-Side / Frontend Programming</h2> <img src="/imgs/client-side-resources.png" alt="An illustration of desktop screen with a web browser open." /> Client-side or frontend programming is the area of web development dedicated to creating everything a user of a website will see (i.e. the UI). In its simplest form, all you need to make a website is HTML. Unfortunately, an HTML-only website will look and feel quite bland which is why CSS is also used to change the style of a website, and JavaScript is used to add more complex behavior to a website. From that point other languages, libraries, and tools like TypeScript or React are additives that make the job of creating and maintaining websites easier. There are many comprehensive web development guides available out there today but I'll take a moment to call out the <a href="https://developer.mozilla.org/en-US/" >Mozilla Developer Network</a >. Very few resources match the quality and robustness of the Mozilla Developer Network (MDN). It is a resource that is linked to many times in this guide and is probably one of the single most helpful resources I used to grapple with many of the web development topics I've learned in the last two years. It's a website that I highly recommend you take the time to peruse and see what kind of content is available. <ul> <li> 🔥🔥🔥 <a href="https://developer.mozilla.org/en-US/docs/Learn" >MDN Learn Web Development</a > </li> <ul> <li>MDN's structured full-stack web development course.</li> </ul> <li> 🔥 <a href="https://drstearns.github.io/tutorials/" >Dave Stearns Web Development Tutorials</a > </li> <ul> <li> These amazing tutorials were used for a server-side programming course I took in college, but it also includes some incredible client-side tutorials that are worth reading as well. </li> </ul> <li> 🔥 <a href="https://info340.github.io/" >INFO 340 Client-Side Web Development Book</a > </li> <ul> <li> This is a fantastic client-side development book for a class I took in college. It's written in a very human readable way. </li> </ul> <li> <a href="https://frontendmasters.com/books/front-end-handbook/2019/" >Frontend Developer Handbook</a > </li> <li> <a href="https://blog.codeanalogies.com/2018/05/09/the-relationship-between-html-css-and-javascript-explained/" >The Relationship Between HTML, CSS, and JavaScript Explained</a > </li> </ul>  <h2 id="html-resources">HTML Resources</h2> <img src="/imgs/html.png" alt="An illustration of the HTML5 logo." /> As I stated above, HTML (Hyper-Text Markup Language) is the absolute baseline for what you need to make a website. It is the place where you include the content of your website and define the structure of your webpages. An analogy I'm fond of is, if the content (i.e. text, images, etc.) of your website is a pile of bones then HTML is what you use to structure those bones into a skeleton (i.e. a webpage). <img src="/imgs/content-to-html.png" alt="An illustration of a pile of bones with an arrow pointing to a skeleton." /> You can use a thing called HTML tags to, for example, define a piece of text as being a paragraph or a title. Then by ordering these tags one after another you can define how all the pieces fit together. <h3>Getting Started</h3> These are some more comprehensive tutorials that cover all the major aspects of HTML. The HTML Dog resource is one that I've found to be particularly helpful with its simple intuitive explanations. <ul> <li> 🔥 <a href="https://htmldog.com/guides/html/" >HTML Dog –– HTML Tutorial</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics" >MDN –– HTML Basics</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML" >MDN –– HTML Tutorial</a > </li> </ul> <h3>HTML Tags References</h3> Tag Reference resources can be thought of as a sort of HTML tag dictionary. It's a place where you can browse all the different tags that are available to use inside an HTML file with included explanations and examples of how to use them. Here are a few of my favorites. <ul> <li>🔥 <a href="https://htmlreference.io/">HTML Reference IO</a></li> <li> 🔥 <a href="https://htmldog.com/references/html/tags/" >HTML Dog –– Tag Reference</a > </li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element" >MDN –– Tag Reference</a > </li> </ul> <h3>HTML Attribute References</h3> HTML attributes are special words that you can use inside an HTML tag to modify or define behaviors in those tags. For example, by using the "class" attribute in a tag you can associate some CSS styles with that tag. These references below are once again a sort of dictionary with definitions of all the attributes you can use in an HTML file. <ul> <li> <a href="https://htmldog.com/references/html/globalattributes/" >HTML Dog –– Global Attributes Reference</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes" >MDN –– Attributes Reference</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes" >MDN –– Global Attributes Reference</a > </li> </ul> <h3>HTML Character Codes References</h3> Character code references are another type of dictionary that defines all the possible characters you can use in an HTML document and their associated code that you type. Say, for example, you wanted to include the division symbol on a webpage you can type "÷" and it will be converted into ÷. <ul> <li> 🔥 <a href="https://www.toptal.com/designers/htmlarrows/arrows/" >HTML Character Code Reference</a > </li> <li> <a href="https://htmldog.com/references/html/characters/" >HTML Dog –– Character Code Reference</a > </li> <li> <a href="https://www.freeformatter.com/html-escape.html" >HTML Character Escape Tool</a > </li> </ul> <h3>HTML Meta Tags</h3> Meta tags are HTML tags that contain information about a particular webpage. These tags can define things such as the title or description of a webpage. Notably, these meta tags can also define the information that is crucial for website SEO (search engine optimization). Below is a favorite resource of mine for automatically generating SEO related meta tags and also provides some great educational material if you scroll down below the tool. <ul> <li>🔥🔥🔥 <a href="https://metatags.io/">Meta Tag Generator</a></li> </ul> <h3>Accessibility</h3> Website accessibility is an incredibly important topic when making websites that can cater to all users. Accessibility can take many forms –– everything from blindness to having a broken arm to even having a slow internet connection. They all affect a user's ability to access a website and its content. Being able to design websites that accommodate the gamut of accessibility issues will not only lead to a better experience for those with disabilities but very often leads to great experiences for those without disabilities too. <ul> <li> 🔥 <a href="https://www.w3.org/WAI/fundamentals/accessibility-intro/" >Introduction To Web Accessibility</a > </li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility" >MDN –– Accessibility</a > </li> <li> <a href="https://www.levelaccess.com/how-browsers-interact-with-screen-readers-and-where-aria-fits-in-the-mix/" >How Browsers Interact with Screen Readers & Where ARIA Fits In</a > </li> <li> <a href="https://developers.google.com/web/fundamentals/accessibility/semantics-builtin/the-accessibility-tree" >The Accessibility Tree</a > </li> <li> <a href="https://www.smashingmagazine.com/2018/12/voiceover-screen-reader-web-apps/" >I Used The Web For A Day Using A Screen Reader</a > </li> <li> <a href="https://bighack.org/5-most-annoying-website-features-i-face-as-a-blind-screen-reader-user-accessibility/" >5 Most Annoying Website Features I Face As A Blind Person Every Single Day</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> 🔥 <a href="https://svgontheweb.com/" >A Practical Guide To SVGs On The Web</a > </li> <li> <a href="https://dev.to/kenbellows/stop-using-so-many-divs-an-intro-to-semantic-html-3i9i" >Intro To Semantic HTML</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding" >MDN –– Multimedia & Embedding Guides</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables" >MDN –– HTML Tables Guides</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Forms" >MDN –– HTML Forms Guides</a > </li> <li> <a href="https://imagekit.io/blog/lazy-loading-images-complete-guide/" >A Complete Guide To Lazy Loading Images</a > </li> </ul>  <h2 id="css-resources">CSS Resources</h2> <img src="/imgs/css.png" alt="An illustration of the CSS3 logo." /> After HTML, the next thing you would typically use is CSS (Cascading Style Sheets). CSS gives you the ability to add style to an HTML file (read: make your website look festive and fancy). Following the same skeleton analogy from above, CSS would be like adding clothes to your HTML skeleton. <img src="/imgs/html-to-css.png" alt="An illustration of a skeleton with an arrow pointing to a skeleton with clothes on." /> CSS is incredibly powerful and lets you define everything from the color of text to complex animations. <a href="http://www.csszengarden.com/">CSS Zen Garden</a> is a fantastic introductory website that shows off this power by using different CSS styles on the same HTML to create totally unique looking websites. <h3>Getting Started</h3> Once again, here are some more comprehensive tutorials for those looking for a structured walkthrough of CSS. <ul> <li> <a href="https://htmldog.com/guides/css/">HTML Dog –– CSS Tutorial</a> </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/CSS_basics" >MDN –– CSS Basics</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS/First_steps/How_CSS_works" >How CSS Works</a > </li> <li> <a href="https://learn.shayhowe.com/html-css/getting-to-know-css/" >Getting To Know CSS</a > </li> <li> <a href="https://speckyboy.com/good-bad-css-practices/" >Good And Bad CSS Practices For Beginners</a > </li> </ul> <h3>CSS Syntax & Terms</h3> A part of learning CSS includes learning some special vocabulary for the syntax you're looking at. Knowing what a "property" is, or what a "selector" is, or what the difference between a "rule set" and "declaration block" is will make your process of learning CSS much easier. <ul> <li> 🔥 <a href="https://www.impressivewebs.com/css-terms-definitions/" >CSS Terms & Definitions</a > </li> <li> 🔥 <a href="http://apps.workflower.fi/vocabs/css/en">CSS Vocab</a> </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Syntax" >CSS Syntax</a > </li> <li><a href="https://flukeout.github.io/">CSS Diner</a></li> </ul> <h3>CSS References</h3> Similar to HTML, these resources are effectively dictionaries for CSS properties. <ul> <li>🔥 <a href="https://cssreference.io/">CSS Reference IO</a></li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Reference?redirectlocale=en-US&redirectslug=CSS%2FCSS_Reference" >MDN –– CSS Reference</a > </li> </ul> <h3>CSS Layout / Box Model</h3> One of the most powerful aspects of CSS is the fact that it lets you define the layout of your website and the spacing between elements. These are a few resources that cover this topic. <ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Introduction" >MDN –– Intro To CSS Layout</a > </li> <li> <a href="https://courses.cs.washington.edu/courses/cse154/19au/resources/assets/layout/css-layout.pdf" >CSS Layout Slidedeck</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model" >MDN –– Box Model</a > </li> <li> <a href="https://learn.shayhowe.com/html-css/opening-the-box-model/" >Opening The Box Model</a > </li> </ul> <h3>CSS Flexbox</h3> Flexbox is, from my experience, an absolute-must-learn topic when picking up CSS. It is a much easier and more powerful way of defining the layout of elements on a webpage. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=K74l26pE4YA" >CSS Flexbox In 100 Seconds</a > </li> <li> 🔥 <a href="https://css-tricks.com/snippets/css/a-guide-to-flexbox/" >A Complete Guide to CSS Flexbox</a > </li> <ul> <li> Make sure to read "Background" and "Terminology" sections of this guide. </li> </ul> <li>🔥 <a href="https://flexboxfroggy.com/">Flexbox Froggy</a></li> <li> <a href="https://www.internetingishard.com/html-and-css/flexbox/" >Internetting Is Hard –– Flexbox Tutorial</a > </li> <li> <a href="https://bennettfeely.com/flexplorer/">Flexplorer</a> </li> </ul> <h3>CSS Grid</h3> Grid is another incredibly powerful way to layout elements on a webpage. As the name suggests it allows you to orient elements on a webpage in a grid. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=uuOXPWCh-6o" >CSS Grid In 100 Seconds</a > </li> <li> 🔥 <a href="https://css-tricks.com/snippets/css/complete-guide-grid/" >A Complete Guide to CSS Grid</a > </li> <ul> <li> Make sure to read all the collapsed sections at the beginning such as the "Introduction". </li> </ul> <li> 🔥 <a href="https://codepip.com/games/grid-garden/">Grid Garden</a> </li> <li> <a href="https://www.youtube.com/watch?v=705XCEruZFs" >The Joy Of CSS Grid –– Build 3 Beautifully Simple Responsive Layouts</a > </li> <li><a href="https://learncssgrid.com/">Learn CSS Grid</a></li> </ul> <h3>CSS Responsive Design</h3> A massive concern when creating websites is the fact that it can be viewed on everything from a massive desktop screen to a tiny mobile phone. Responsive design is the area of CSS and website design that is concerned with this issue. By using CSS Media Queries you can define how your website should look on those devices and change the styles of each element so that they look good on every screen size. <ul> <li> 🔥 <a href="https://www.internetingishard.com/html-and-css/responsive-design/" >Internetting Is Hard –– Responsive Design Tutorial</a > </li> <li> <a href="https://drstearns.github.io/tutorials/responsive/" >Responsive CSS</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/Mobile" >MDN –– Mobile Web Development</a > </li> <li> <a href="https://www.internetingishard.com/html-and-css/responsive-images/" >Internetting Is Hard –– Responsive Images</a > </li> </ul> <h3>CSS Animations</h3> CSS defines some incredibly powerful (yet simple) syntax for creating animations. With this syntax you can create everything from simple transitions to complex multistep animations. Below are a couple of learning resources, as well as some tools and libraries that make the job of creating complex CSS animations a lot easier. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=HZHHBwzmJLk" >CSS Animations In 100 Seconds</a > </li> <li> 🔥 <a href="https://thoughtbot.com/blog/css-animation-for-beginners" >CSS Animations For Beginners</a > </li> <li> <a href="https://drstearns.github.io/tutorials/animations/" >CSS Animations</a > </li> <li> <a href="https://nelsonmichael.dev/introduction-to-css-transitions-ckc396nae003u5es1097h5rr1" >Introduction to CSS Transitions</a > </li> <li><a href="https://animista.net/">Animista</a></li> <ul> <li>A tool for generating CSS animations.</li> </ul> <li><a href="https://keyframes.app/">Keyframes App</a></li> <ul> <li>A tool for prototyping CSS animations.</li> </ul> <li><a href="https://animate.style/">Animate.css</a></li> <ul> <li>A general purpose CSS animation library.</li> </ul> <li> <a href="https://michalsnik.github.io/aos/" >Animate On Scroll (AOS)</a > </li> <ul> <li>A CSS animation scroll library.</li> </ul> <li> <a href="https://easings.net/en">Easing Functions Cheatsheet</a> </li> </ul> <h3>Color & Gradients Resources</h3> As I hinted in the CSS introduction paragraphs above, the ability to define colors and also gradients is a power granted by CSS. Below are some of my favorite tools I've come across for helping pick color codes, color palettes, accessible colors, and gradients when creating a website. <ul> <li>🔥 <a href="https://htmlcolorcodes.com/">HTML Color Codes</a></li> <li>🔥 <a href="http://khroma.co/">Khroma</a></li> <ul> <li>An AI powered color generator.</li> </ul> <li> <a href="https://accessible-colors.com/">Accessible Colors</a> </li> <li><a href="https://coolors.co/">Coolors Color Generator</a></li> <li><a href="https://webgradients.com/">Web Gradients</a></li> <li><a href="https://cssgradient.io/">CSS Gradients</a></li> </ul> <h3>Typography & Font Resources</h3> Defining a website font is also a power granted by CSS. I'll also take this opportunity to sing my praises to Google Fonts as a resource that you should absolutely try out. They have a decently sized catalog of high-quality free to use fonts that can drastically improve the look of your website. <ul> <li>🔥🔥🔥 <a href="https://fonts.google.com/">Google Fonts</a></li> <li> 🔥 <a href="https://www.internetingishard.com/html-and-css/web-typography/" >Internetting Is Hard –– Web Typography</a > </li> <li> <a href="https://jmattthew.github.io/better-font-finder/better-font-finder.html" >Google Font Finder</a > </li> <li><a href="https://getsnapfont.com/">Snapfont</a></li> <li><a href="https://www.dafont.com/">Dafont</a></li> <li><a href="https://www.fontsquirrel.com/">Font Squirrel</a></li> <li><a href="https://www.fontspring.com/">Font Spring</a></li> </ul> <h3>Icon & Graphic Resources</h3> The title says it all. Below are some great resources for finding website icons and graphics. Each one is a little different in what it offers so check them all out and see which you prefer. <ul> <li> <a href="https://orioniconlibrary.com/">Orion Icon Library</a> </li> <li><a href="https://css.gg/">700+ CSS Icons</a></li> <li><a href="https://heroicons.com/">Heroicons</a></li> <li><a href="https://fontawesome.com/">Font Awesome Icons</a></li> <li><a href="https://primer.style/octicons/">Octicons</a></li> <li><a href="https://ionicons.com/">Ionicons</a></li> <li> <a href="https://worldvectorlogo.com/">World Vector Logo</a> </li> <li> <a href="https://www.awwwards.com/martamoskwa/collections/free-icons-sets/" >Awwwards Icon Sets Collection</a > </li> <li> <a href="https://9elements.github.io/fancy-border-radius/" >Fancy Border Radius Generator</a > </li> <li><a href="https://blobs.app/">CSS Blobs</a></li> <li><a href="https://www.humaaans.com/">Humaaans</a></li> <li><a href="https://undraw.co/">unDraw</a></li> </ul> <h3>CSS Preprocessors</h3> Preprocessors simplify the process of writing complex CSS by defining a simpler/more powerful CSS syntax you can use and then converts that to regular CSS which can be run by a browser. <ul> <li> <a href="https://www.freecodecamp.org/news/css-preprocessors/" >CSS Preprocessors Explained</a > </li> <li> <a href="https://raygun.com/blog/css-preprocessors-examples/" >Popular CSS Preprocessors With Examples</a > </li> <li><a href="https://sass-lang.com/">Sass</a></li> <li><a href="http://lesscss.org/">Less</a></li> </ul> <h3>CSS Frameworks</h3> CSS Frameworks are another way to make the job of writing CSS easier. They offer predefined styles that you can use on your HTML elements and make the job of creating a website with a cohesive design a breeze. <ul> <li> <a href="https://blog.zipboard.co/a-beginners-guide-to-css-front-end-frameworks-8045a499456b" >A Beginner's Guide To CSS Frameworks</a > </li> <li> <a href="https://drstearns.github.io/tutorials/cssframeworks/" >CSS Frameworks</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=NtRmIp4eMjs" >CSS Variables In 100 Seconds</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=kpXKwDGtjGE" >CSS Psuedo-Classes In 100 Seconds</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=e1KpKBHJOrA" >CSS Psuedo-Elements In 100 Seconds</a > </li> <li> <a href="https://medium.com/@devdevcharlie/things-nobody-ever-taught-me-about-css-5d16be8d5d0e" >Things Nobody Ever Taught Me About CSS</a > </li> <li> <a href="https://ishadeed.com/article/the-just-in-case-mindset-css/" >The Just In Case Mindset In CSS</a > </li> </ul>  <h2 id="javascript-resources">JavaScript Resources</h2> <img src="/imgs/javascript.png" alt="An illustration of the JavaScript logo." /> With JavaScript comes the power to start creating truly complex and robust websites. In the skeleton analogy, JavaScript is what brings the skeleton to life (read: gives the webpage interactive behavior). <img src="/imgs/css-to-js.png" alt="An illustration of a clothed skeleton with an arrow pointing to a dancing clothed skeleton." /> You can define behaviors like what happens when you click a button. You can dynamically create, manipulate, or delete elements on a webpage based on user interaction. You can make HTTP requests to get data from a server and so much more. <h3>Getting Started</h3> Nowadays there seems to be an almost endless number of JavaScript tutorials out there. Below are my top picks. I'll also take a moment to say that The Modern JavaScript Tutorial has consistently stood out as an absolutely incredible resource for gaining a comprehensive understanding of JavaScript. <ul> <li> 🔥🔥🔥 <a href="https://javascript.info/">The Modern JavaScript Tutorial</a> </li> <li> 🔥🔥 <a href="https://www.youtube.com/watch?v=Sh6lK57Cuk4&list=PL0vfts4VzfNixzfaQWwDUg3W5TRbE7CyI" >That Weird JavaScript Course –– Fireship.io</a > </li> <li> 🔥🔥 <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide" >MDN –– JavaScript Guide</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics" >MDN –– JavaScript Basics</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript" >MDN –– A Re-Introduction to JavaScript</a > </li> </ul> <h3>JavaScript Basics</h3> Below are some nice resources that cover various JavaScript basics. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=Mus_vwhTCq0" >JavaScript Pro Tips</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=x7Xzvm0iLCI" >JavaScript Loops</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=YOlr79NaAtQ" >What Is 'this' In JavaScript? In 100 Seconds</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=L8CDt1J3DAw" >Beyond Console Log In 100 Seconds</a > </li> <li> <a href="https://info340.github.io/javascript.html" >JavaScript Fundamentals</a > </li> <li> <a href="https://dmitripavlutin.com/gentle-explanation-of-this-in-javascript/" >A Gentle Explanation Of "this" In JavaScript</a > </li> </ul> <h3>The DOM</h3> Understanding the DOM (Document Object Model) is one of the most important parts of learning client-side JavaScript. At a high-level, the DOM is a representation (specifically a tree data structure) of every element on a webpage that browsers use to keep track of page changes and rendering. The reason we care about this is because browsers expose the ability to read and manipulate the DOM using JavaScript. This is how JavaScript has the power to dynamically create, manipulate, or delete elements on a webpage. The DOM is also the reason that single page applications or UI libraries like React are possible. <ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Manipulating_documents" >MDN –– Intro To The DOM</a > </li> <li> <a href="https://www.digitalocean.com/community/tutorials/how-to-make-changes-to-the-dom" >How To Make Changes To The DOM</a > </li> <li> <a href="https://www.digitalocean.com/community/tutorials/how-to-traverse-the-dom" >How To Traverse The DOM</a > </li> <li> <a href="https://www.loom.com/share/1fb07561c8984a4f8cbf37d77f969088" >DOM Tree Video Explanation</a > </li> </ul> <h3>JavaScript Events</h3> Events are another very important topic to understand when learning about client-side JavaScript. They enable your website to have dynamic interactivity with a user. There are many events that you can set up your JavaScript to "listen" for such as a mouse click, keyboard input, or even if the user has access to the internet. When one of those events occurs you can define a piece of code that will be executed as a result. The combination of listening for events and then executing code as a result enables some truly complex behavior in your websites. <ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events" >MDN –– Intro To Events</a > </li> <li> <a href="https://drstearns.github.io/tutorials/eventarch/" >Event-Driven Application Architecture</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/Events" >DOM Events Reference</a > </li> </ul> <h3>JSON</h3> JSON (JavaScript Object Notation) maintains a special importance in the world of web development because a majority of the data sent across the internet is formatted as JSON. Most modern programming languages have methods for writing/reading (often referred to as "serializing/deserializing") JSON which means that you can have a frontend website written in JavaScript sending data and communicating with backend server written in something like Go without any issues. Below you will find some links for learning more about JSON and its syntax. <ul> <li> <a href="https://www.digitalocean.com/community/tutorials/an-introduction-to-json" >An Introduction To JSON</a > </li> <li> <a href="https://www.impressivewebs.com/what-is-json-introduction-guide-for-beginners/" >What Is JSON? An Introduction and Guide For Beginners</a > </li> </ul> <h3>AJAX & Fetch</h3> On the note of sending data and communicating with servers, AJAX (Asynchronous JavaScipt and XML) and Fetch are the way that JavaScript is able to communicate with servers by sending HTTP requests. In particular, Fetch offers a very clean way of requesting and receiving data from a server using promises. <ul> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch" >MDN –– Using Fetch</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/AJAX" >MDN –– AJAX Guide</a > </li> </ul> <h3>Promises & Async/Await</h3> In short, promises and async/await allow JavaScript developers to do asynchronous programming. I'll let the resources below explain the benefit of asynchronous programming in more detail, but it's basically a way of achieving faster programs using concurrency. As an example, a regular synchronous HTTP request will "block" your JavaScript from running other code until the results of that request are returned. However, by using promises/async/await your JavaScript can execute other code while it waits on the HTTP request to be returned. The ultimate result is that more code is run in the same amount of time when using promises and async/await. Additionally, to be even more clear, promises are JavaScript's way of handling asynchronous values, while async/await is a cleaner syntax for working with promises. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=RvYYCGs45L4" >JavaScript Promise In 100 Seconds</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=vn3tm0quoqE" >The Async Await Episode I Promised</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise" >MDN –– Promises</a > </li> <li> <a href="https://codeburst.io/javascript-es-2017-learn-async-await-by-example-48acc58bad65" >Learn Async/Await By Example</a > </li> <li> <a href="https://codewithhugo.com/async-js/" >Async JavaScript: Histories, Patterns, and Gotchas</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Introducing" >MDN –– Intro To Asynchronous JavaScript</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises" >MDN –– Using Promises</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop" >MDN –– Concurrency Model And The Event Loop</a > </li> </ul> <h3>Testing & Debugging Resources</h3> Testing your code is a ridiculously important part of maintaining healthy codebases and projects. It forces you to think critically about the edge cases of your programs and also ensures that new features/updates don't break something you've previously implemented. Testing frameworks make the job of testing your code much easier and streamlined and are well worth checking out. Below are a few resources for diving deeper into the world of JavaScript testing frameworks, as well as some debugging resources. <ul> <li> <a href="https://www.lambdatest.com/blog/top-javascript-automation-testing-framework/" >Best 8 JavaScript Testing Framework In 2020</a > </li> <li> <a href="https://www.testcraft.io/front-end-testing/" >A Comprehensive Guide To Front End Testing</a > </li> <li> <a href="https://info340.github.io/jest.html">Testing With Jest</a> </li> <li> <a href="https://developers.google.com/web/tools/chrome-devtools/javascript" >Debugging JavaScript In Chrome DevTools</a > </li> </ul> <h3>JavaScript Modules</h3> Modules are simply JavaScript files/functions that can be imported into another JavaScript file/project. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=qgRUr-YUk1Q" >JavaScript Modules In 100 Seconds</a > </li> <li> 🔥 <a href="https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/" >ES Modules: A Cartoon Deep Dive</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules" >MDN –– JavaScript Modules</a > </li> <li> <a href="https://www.youtube.com/watch?v=WGlT921ixx4" >Unbundling The JavaScript Module Bundler</a > </li> </ul> <h3>JavaScript ES6</h3> Fun fact, "ECMAScript" is actually the official name of JavaScript. This is because the committee that defines the language specification of JavaScript is part of the European Computer Manufacturers Association (ECMA). In 2015, the ECMA released a new specification for JavaScript that brought a ton of new features and improvements to the language. The name of this release was "ECMAScript 2015," but since it is considered the sixth version of the language to be released it is commonly referred to as simply "ES6." Below are a number of resources that cover those changes and improvements. <ul> <li>🔥 <a href="https://flaviocopes.com/es6/">The ES6 Guide</a></li> <li> 🔥 <a href="http://stack.formidable.com/es6-interactive-guide/#/" >Interactive ES6 Guide</a > </li> <li> 🔥 <a href="https://info340.github.io/es6.html">ES6 Features</a> </li> <li> 🔥 <a href="https://drstearns.github.io/tutorials/es6/" >ECMAScript6 Features</a > </li> <li> <a href="https://flaviocopes.com/javascript-arrow-functions/" >Intro To JavaScript Arrow Functions</a > </li> </ul> <h3>Regular Expressions</h3> Regular expressions (regex for short) are a way of performing complex pattern matching and are incredibly helpful for validating user input. As an example you can use regex to ensure that a user has written a valid email address in a sign up form. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=sXQxhojSdZM" >Regular Expressions (Regex) In 100 Seconds</a > </li> <li> 🔥 <a href="https://regexone.com/" >RegexOne –– Interactive Regex Guide</a > </li> <li> 🔥 <a href="https://rubular.com/" >Rubular –– Regular Expression Tester</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions" >MDN –– Regular Expressions</a > </li> <li><a href="https://regexcrossword.com/">Regex Crossword</a></li> </ul> <h3>🔥 JavaScript Libraries</h3> JavaScript has become quite famous at this point for its massive ecosystem of third-party packages/libraries. Below you will find some of my favorite libraries that I've come across. <ul> <li> <a href="https://info340.github.io/javascript-libraries.html" >JavaScript Libraries</a > </li> <ul> <li> This reading gives a nice introduction to libraries and how to use them. </li> </ul> <li><a href="https://lodash.com/">Lodash</a></li> <ul> <li> Lodash is an amazing utility library that makes it easier to work with arrays, numbers, objects, strings, and so on. </li> </ul> <li> <a href="https://immutable-js.github.io/immutable-js/" >Immutable.js</a > </li> <ul> <li> Immutable is another utility library for immutable data structures. </li> </ul> <li><a href="https://blotter.js.org/">Blotter.js</a></li> <ul> <li> Blotter is a library that provides some super cool and unconvential text effects. </li> </ul> <li><a href="https://animejs.com/">Anime.js</a></li> <ul> <li> Anime is an incredible JavaScript animation library. </li> </ul> <li><a href="https://brm.io/matter-js/">Matter.js</a></li> <ul> <li>Matter is a 2D physics engine for the web.</li> </ul> <li><a href="https://ptsjs.org/">Pts.js</a></li> <ul> <li>Pts is a really cool visualization library.</li> </ul> <li><a href="https://dixonandmoe.com/rellax/">Rellax</a></li> <ul> <li>Rellax is a lightweight parallax library.</li> </ul> <li> <a href="https://riccardoscalco.it/textures/">Textures.js</a> </li> <ul> <li>Textures provides SVG patterns for data visualizations.</li> </ul> </ul> <h3>JavaScript 3D Graphics</h3> That's right! You can create 3D graphics using JavaScript. It's pretty neat. <ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL" >MDN –– Getting Started With WebGL</a > </li> <li> <a href="https://www.awwwards.com/awwwards/collections/webgl/" >Awwwards WebGL Collection</a > </li> <li><a href="https://threejs.org/">Three.js</a></li> <li> <a href="https://www.awwwards.com/awwwards/collections/three-js/" >Awwwards Three.js Collection</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li>🔥 <a href="https://whatthefuck.is/">Whatthefuck.is</a></li> <ul> <li> A series of articles written by the creator of Redux (Dan Abramov) explaining various JavaScript topics/concepts. </li> </ul> <li> 🔥 <a href="https://stateofjs.com/">State of JavaScript Report</a> </li> <li> 🔥 <a href="https://overapi.com/javascript">JavaScript Cheat Sheet</a> </li> <li> 🔥 <a href="https://info340.github.io/functional-programming.html" >Functional Programming In JS</a > </li> <li> 🔥 <a href="https://flaviocopes.com/javascript-timers/" >Discover JavaScript Timers</a > </li> <li> <a href="https://drstearns.github.io/tutorials/mvc/" >The Model-View-Controller (MVC) Architecture</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode" >MDN –– Strict Mode</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation" >MDN –– Client-Side Form Validation</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain" >MDN –– Inheritance And The Prototype Chain</a > </li> <li> <a href="https://hacks.mozilla.org/2017/06/a-crash-course-in-memory-management/" >A Crash Course In Memory Management</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management" >MDN –– Memory Management</a > </li> </ul> <h2 id="typescript-resources">TypeScript Resources</h2> <img src="/imgs/typescript.png" alt="An illustration of the TypeScript logo." /> Moving on from JavaScript we start to enter the territory of languages, libraries, and tools that are not strictly necessary for creating frontend websites but sure do make the job of creating them easier. One such language is TypeScript. Created by Microsoft, TypeScript is a "superset of JavaScript" meaning it's JavaScript with extra features. Those extra features are namely a type system. Instead of letting JavaScript determine what types of data (i.e. numbers, strings, etc.) your variables contain or your functions return, you explicitly define the data types yourself like you would in a language such as Java or C. The benefit of doing this is that you and larger teams can catch a ton of small mistakes that could lead to runtime errors. Accidentally passed a number into a function that should accept a string? No problem, TypeScript has got your back and will let you know. <h3>Getting Started</h3> <ul> <li> 🔥 <a href="https://www.typescriptlang.org/docs/handbook/" >TypeScript Handbook</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=eCZhz0JCVx0" >All You Need To Know About TypeScript</a > </li> <li> <a href="https://www.typescriptlang.org/">TypeScript Website</a> </li> <li> <a href="https://www.youtube.com/watch?v=ahCwqrYpIuM" >TypeScript –– The Basics</a > </li> <li> <a href="https://www.youtube.com/watch?v=O6A-u_FoEX8" >The Magic Of TypeScript Decorators</a > </li> <li> <a href="https://basarat.gitbook.io/typescript/" >TypeScript Deep Dive</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> <a href="https://www.typescriptlang.org/play" >TypeScript Playground</a > </li> <li> <a href="https://www.typescriptlang.org/tsconfig" >TypeScript TSConfig Reference</a > </li> <li> <a href="https://www.typescriptlang.org/tools">TypeScript Tools</a> </li> <li> <a href="https://2ality.com/2018/04/type-notation-typescript.html" >Understanding TypeScripts Type Notations</a > </li> <li> <a href="https://github.com/formium/typescript" >Helpful TypeScript Coding Guidelines</a > </li> <li> <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/" >Announcing TypeScript 4.0</a > </li> </ul> <h2 id="javascript-framework-resources"> Frontend JavaScript Frameworks </h2> <img src="/imgs/react.png" alt="An illustration of the React logo." /> Another massive topic of frontend web development that is not strictly needed but is very often used these days is frontend JavaScript libraries and frameworks. These libraries and frameworks make the job of creating and maintaining complex user interfaces/websites much easier. Below are some resources focused on general frontend framework information, as well as the most popular front-end framework in 2020 –– React. <h3>Getting Started</h3> <ul> <li> 🔥 <a href="https://blog.logrocket.com/history-of-frontend-frameworks/" >History of Front-End Frameworks</a > </li> <li> 🔥 <a href="https://jsreport.io/the-ultimate-guide-to-javascript-frameworks/" >The Ultimate Guide to JavaScript Frameworks</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks" >Understanding Client-Side JavaScript Frameworks</a > </li> </ul> <h3>Getting Started With React</h3> <ul> <li> 🔥🔥🔥 <a href="https://www.youtube.com/watch?v=Tn6-PIqc4UM" >React In 100 Seconds</a > </li> <li> 🔥🔥🔥 <a href="https://reactjs.org/tutorial/tutorial.html" >Official React Tutorial</a > </li> <li> 🔥 <a href="https://info340.github.io/react.html" >Introduction To React</a > </li> <li> 🔥 <a href="https://github.com/petehunt/react-howto">React How To</a> </li> <li> 🔥 <a href="https://ui.dev/react-aha-moments/">React 'Aha' Moments</a> </li> <li><a href="https://reactjs.org/">React Website</a></li> <li> <a href="https://camjackson.net/post/9-things-every-reactjs-beginner-should-know" >9 Things Every React Beginner Should Know</a > </li> <li> <a href="https://www.taniarascia.com/getting-started-with-react/" >React Tutorial: An Overview and Walkthrough</a > </li> <li> <a href="https://hackernoon.com/simple-react-development-in-2017-113bd563691f" >Simple React Development In 2019</a > </li> </ul> <h3>React State Management</h3> <ul> <li> 🔥 <a href="https://wattenberger.com/blog/react-hooks" >Thinking In React Hooks</a > </li> <li> <a href="https://daveceddia.com/visual-guide-to-state-in-react/" >A Visual Guide To State In React</a > </li> <li> <a href="https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207" >A Cartoon Guide To Flux</a > </li> <li> <a href="https://code-cartoons.com/a-cartoon-intro-to-redux-3afb775501a6" >A Cartoon Intro To Redux</a > </li> </ul> <h3>React + TypeScript</h3> Why not combine two great technologies? Well you can! <ul> <li> 🔥🔥🔥 <a href="https://fettblog.eu/typescript-react/getting-started/" >TypeScript and React Guide</a > </li> <li> 🔥 <a href="https://react-typescript-cheatsheet.netlify.app/" >React TypeScript Cheatsheets</a > </li> <li> <a href="https://dev.to/busypeoples/notes-on-typescript-pick-exclude-and-higher-order-components-40cp" >React & TypeScript Series</a > </li> <li> <a href="https://egghead.io/courses/use-typescript-to-develop-react-applications" >Use TypeScript To Develop React Applications</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li>🔥 <a href="https://reactrouter.com/">React Router</a></li> <ul> <li> The go to library for implementing client-side routing in React. </li> </ul> <li>🔥 <a href="https://create-react-app.dev/">Create React App</a></li> <ul> <li>The go to tool for creating new React applications.</li> </ul> <li>🔥 <a href="https://www.framer.com/motion/">Framer Motion</a></li> <ul> <li>A library for implementing super clean UI animations.</li> </ul> <li><a href="https://nextjs.org/">Next.js</a></li> <ul> <li>A great library for server-side rendering using React.</li> </ul> <li> <a href="https://react-dnd.github.io/react-dnd/about" >React Drag and Drop</a > </li> <ul> <li> A library for implementing drag and drop functionality in your React app. </li> </ul> <li><a href="https://formik.org/">Formik</a></li> <ul> <li>A library for creating and using forms in React.</li> </ul> <li> <a href="https://medium.com/life-at-paperless/how-to-use-the-react-profiler-component-to-measure-performance-improvements-from-hooks-d43b7092d7a8" >How To Use React Profiler Component To Measure Render Performance</a > </li> <li> <a href="https://jasonformat.com/wtf-is-jsx/">WTF Is JSX?</a> </li> <li> <a href="https://pomb.us/build-your-own-react/" >Build Your Own React</a > </li> <li> <a href="https://mfrachet.github.io/create-frontend-framework/" >Build A Frontend Framework From Scratch To Understand How It Works</a > </li> </ul> <h2 id="client-side-api-resources">Client-Side APIs</h2> <img src="/imgs/client-side-apis.png" alt="An illustration of a desktop computer connecting with the internet." /> Application Programming Interfaces (APIs) are the way that different pieces of software are able to interact with each other. As the "What Is An API?" article below describes, an API is like a menu at a restaurant. When thinking of APIs from a client-side perspective you are the customer who is ordering food, while comparatively, when thinking of APIs from a server-side perspective you are the restaurant making/delivering the food. As a client/customer, you don't have to worry about how the food is sourced or made. You simply just have to know the phone number of the restaurant, order a dish that's on the menu, and it will be delivered to you. Translated to the world of programming, it means you can request (read: order) data or resources such as <a href="https://dog.ceo/dog-api/">pictures of dogs</a> or <a href="https://icanhazdadjoke.com/api">horrible dad jokes</a> from an API (read: menu) that lives on a server (read: restaurant) somewhere on the internet –– it could even be your own server. When that data is delivered to your website you can then use it however you please. One final note is that client-side APIs can take three primary forms in web development: 1) Your Own API, 2) Third-Party APIs, and 3) Browser APIs. <h3>Getting Started</h3> <ul> <li> 🔥🔥🔥 <a href="https://www.leverege.com/blogpost/what-is-an-api" >What Is An API? –– A Simple, Non-Technical Explanation</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs" >MDN –– Client-Side Web APIs</a > </li> </ul> <h3>Your Own API</h3> Creating your own APIs is essentially what server-side development is/can be boiled down to. Thus resources and discussion on the topic can be found in the sections below. <h3>Third-Party API Resources</h3> Third-Party APIs are APIs created by someone else (usually a company). The relationship to those APIs is exactly as described above where you are the customer ordering data or resources that will be delivered to your website. <ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Third_party_APIs" >MDN –– Third-Party APIs</a > </li> <li><a href="https://apilist.fun/">API List</a></li> <ul> <li>A public list of free third-party APIs</li> </ul> <li><a href="https://rapidapi.com/">API Marketplace</a></li> <ul> <li>Another public list of free third-party APIs</li> </ul> </ul> <h3>Browser API Resources</h3> Browser APIs are a little bit different (and a little bit cooler in my opinion). The same customer-restaurant relationship can be used, but the restaurant location has changed. Rather than being located at some far-away server, the restaurant is the web browser itself (i.e. Chrome or Firefox). This new type of restaurant also serves slightly different and slightly cooler menu items. There are browser APIs for using <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API" >Bluetooth</a >, checking <a href="https://developer.mozilla.org/en-US/docs/Web/API/Ambient_Light_Events" >ambient light levels</a >, connecting <a href="https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API" >game controllers</a >, <a href="https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_Image_Capture_API" >capturing photos or videos</a >, and many more options. <ul> <li> 🔥 <a href="https://blog.greenroots.info/10-lesser-known-web-apis-you-may-want-to-use-ckejv75cr012y70s158n85yhn" >10 Lesser-Known Web APIs You May Want To Use</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Introduction" >MDN –– Introduction To Web APIs</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/API" >MDN –– Guide To Web APIs</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/Reference/API" >MDN –– Web API Reference</a > </li> <li> <a href="https://developer.chrome.com/apps/api_index" >Chrome APIs List</a > </li> <li> <a href="https://developer.chrome.com/apps/api_other" >Chrome Web APIs</a > </li> </ul> <h2 id="webassembly-resources">WebAssembly Resources</h2> <img src="/imgs/webassembly.png" alt="An illustration of the WebAssembly logo." /> At the absolute cutting edge of frontend web technologies is one of my favorite topics to get lost in during the last year or so –– WebAssembly. WebAssembly is a low-level binary format/assembly-like language that runs in the browser –– in fact as of December 2019 it is <a href="https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en" >the 4th official language of the web</a >. By writing programs in languages like C/C++, Rust, Go, and <a href="https://webassembly.org/getting-started/developers-guide/" >others</a > that can compile to WebAssembly the internet could eventually be capable of running photo/video editing software, AAA video games, and <a href="https://webassembly.org/docs/use-cases/">much more</a> right inside a browser. Note: Even though WebAssembly is the 4th official language of the web it is not supposed to be a language that will replace JavaScript but will rather work alongside it. <h3>Getting Started</h3> Read a Cartoon Intro To WebAssembly. Just read it. <ul> <li> 🔥🔥🔥 <a href="https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/" >A Cartoon Intro To WebAssembly [Article Series]</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=HktWin_LPf4" >A Cartoon Intro To WebAssembly [YouTube]</a > </li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/WebAssembly" >MDN Guide To WebAssembly</a > </li> <li> <a href="https://webassembly.org/">WebAssembly Website</a> </li> <li> <a href="https://github.com/WebAssembly">WebAssembly GitHub</a> </li> <li> <a href="https://flaviocopes.com/webassembly/" >Flavio Copes: An Introduction To WebAssembly</a > </li> <li> <a href="https://rsms.me/wasm-intro">Introduction To WebAssembly</a> </li> <ul> <li> This introduction to WebAssembly is more technical than the others. </li> </ul> <li> <a href="https://codelabs.developers.google.com/codelabs/web-assembly-intro/index.html" >Google Codelabs: An Introduction To WebAssembly</a > </li> </ul> <h3>How WebAssembly Is Being Used</h3> Since WebAssembly is still in its infancy, the use cases for when to use it are actively being explored. Watching and reading about what other companies are doing with WebAssembly can be a great way to start envisioning what's possible. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=BnYq7JapeDA" >How AutoCAD Used WebAssembly</a > </li> <li> 🔥 <a href="https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/" >WebAssembly Cut Figma's Load Time By 3X</a > </li> </ul> <h3>Diving Deeper Into WebAssembly</h3> These are all fantastic articles and videos that explore the various facets and histories of WebAssembly. <ul> <li> 🔥 <a href="https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/" >WebAssembly's Post-MVP Future: A Cartoon Skill Tree</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=MaJCfdmr9Wg" >WebAssembly: A Game Changer For The Web</a > </li> <li> <a href="https://www.youtube.com/watch?v=6r0NKEQqkz0" >The History Of WebAssembly</a > </li> <li> <a href="https://www.youtube.com/watch?v=7mBf3Gig9io" >WebAssembly: Disrupting JavaScript</a > </li> <li> <a href="https://hacks.mozilla.org/2018/06/babys-first-rustwebassembly-module-say-hi-to-jsconf-eu/" >Baby's First WebAssembly Module</a > </li> <li> <a href="https://hacks.mozilla.org/2017/07/creating-a-webassembly-module-instance-with-javascript/" >Creating A WebAssmebly Module Instance In JavaScript</a > </li> <li> <a href="https://hacks.mozilla.org/2017/07/memory-in-webassembly-and-why-its-safer-than-you-think/" >Memory In WebAssembly (And Why It's Safer Than You Think)</a > </li> <li> <a href="https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/" >Calls Between JS and WASM Are Finally Fast</a > </li> <li> <a href="https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/" >Making WebAssembly Even Faster</a > </li> </ul> <h3>WebAssembly + Rust</h3> During the last few years, Rust has positioned itself to be one of the primary languages to use for developing WebAssembly modules. Some incredible tools and libraries have been created to support the Rust/WebAssembly ecosystem. There is even a WebAssembly working group that is actively working to make Rust's support of WebAssembly even better. As a final note, a great place to start is the Rust and WebAssembly book that covers all the major aspects of Rust/WebAssembly development. <ul> <li> 🔥 <a href="https://rustwasm.github.io/docs/book/" >Rust and WebAssembly Book</a > </li> <li> 🔥 <a href="https://rustwasm.github.io/">Rust and WebAssembly Website</a> </li> <li> 🔥 <a href="https://hacks.mozilla.org/2018/03/making-webassembly-better-for-rust-for-all-languages/" >Making WebAssembly Better For Rust & For All Languages</a > </li> <li> 🔥 <a href="https://hacks.mozilla.org/2018/04/javascript-to-rust-and-back-again-a-wasm-bindgen-tale/" >JavaScript to Rust and Back Again: A wasm-bindgen Tale</a > </li> <li> <a href="https://rustwasm.github.io/docs/wasm-bindgen/" >The wasm-bindgen Guide</a > </li> <li> <a href="https://rustwasm.github.io/docs/wasm-pack/" >The wasm-pack Book</a > </li> <li> <a href="https://rustwasm.github.io/wasm-pack/">wasm-pack Website</a> </li> <li> <a href="https://github.com/rustwasm/wasm-pack">wasm-pack GitHub</a> </li> <li> <a href="https://rustwasm.github.io/2018/09/26/announcing-web-sys.html" >Web-sys Crate Announcement</a > </li> </ul> <h3>WebAssembly + TypeScript</h3> For those who don't want to go off and learn Rust you can still take advantage of WebAssembly by using TypeScript! Kind of. AssemblyScript is a strict variant of TypeScript that can be used to write WebAssembly modules. It means you can use your knowledge of JavaScript to gain some of the powers of WebAssembly. And just like Rust, there is a great guide/documentation that covers how to get up and running. <ul> <li> 🔥 <a href="https://www.assemblyscript.org/introduction.html" >AssemblyScript Documentation</a > </li> <li> <a href="https://www.assemblyscript.org/">AssemblyScript Website</a> </li> <li> <a href="https://github.com/AssemblyScript/assemblyscript" >AssemblyScript GitHub</a > </li> </ul> <h3>WebAssembly Runtimes</h3> Even though WebAssembly is predominantly discussed in the context of the web it does not mean it is restricted to it. In the same way that JavaScript was able to move off the web with JavaScript runtimes like Node.js and Deno, so to can WebAssembly. Currently, there is active and evolving development on two primary WebAssembly runtimes called Wasmtime and Wasmer. <ul> <li><a href="https://wasmtime.dev/">Wasmtime Website</a></li> <li> <a href="https://bytecodealliance.github.io/wasmtime/introduction.html" >Wasmtime Guide</a > </li> <li> <a href="https://github.com/bytecodealliance/wasmtime" >Wasmtime GitHub</a > </li> <li> <a href="https://github.com/bytecodealliance/wasmtime-demos" >Wasmtime Demos</a > </li> <li><a href="https://wasmer.io/">Wasmer Website</a></li> <li><a href="https://webassembly.sh/">WebAssembly.sh</a></li> <li> <a href="https://hacks.mozilla.org/2019/09/debugging-webassembly-outside-of-the-browser/" >Debugging WebAssembly Outside The Browser</a > </li> </ul> <h3>WebAssembly System Interface (WASI)</h3> Taken from WASI's introductory document, it is: "An API designed by the Wasmtime project that provides access to several operating-system-like features, including files and filesystems, Berkeley sockets, clocks, and random numbers." The goal is for this API to be standardized and designed to work independently of browsers and JavaScript. <ul> <li> 🔥 <a href="https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md" >WASI Intro Document</a > </li> <li>🔥 <a href="https://wasi.dev/">WASI Website</a></li> <li> 🔥 <a href="https://hacks.mozilla.org/2019/08/webassembly-interface-types/" >WebAssembly Interface Types</a > </li> <li> <a href="https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/" >Standardizing WASI</a > </li> <li> <a href="https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-background.md" >WASI Background</a > </li> <li> <a href="https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-documents.md" >WASI Document Guide</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> 🔥 <a href="https://github.com/mbasso/awesome-wasm" >Awesome WASM GitHub</a > </li> <li>🔥 <a href="https://webassembly.studio/">WebAssembly Studio</a></li> <li> 🔥 <a href="https://blog.scottlogic.com/2019/05/17/webassembly-compiler.html" >Build Your Own WebAssembly Compiler In TypeScript</a > </li> <li> 🔥 <a href="https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/" >Announcing The Bytecode Alliance</a > </li> <li> <a href="https://bytecodealliance.org/">Bytecode Alliance Website</a> </li> <li> <a href="https://github.com/bytecodealliance" >Bytecode Alliance GitHub</a > </li> <li> <a href="https://developers.google.com/web/updates/2019/12/webassembly" >WebAssembly Debugging In Chrome DevTools</a > </li> <li> <a href="https://webassembly.github.io/spec/core/index.html" >WebAssembly Specification</a > </li> <li> <a href="https://www.w3.org/community/webassembly/" >W3C WebAssembly Community</a > </li> <li> <a href="https://www.w3.org/wasm/">W3C WebAssembly Working Group</a> </li> <li> <a href="https://www.w3.org/TR/wasm-core-1/" >W3C WebAssembly Core Spec</a > </li> <li> <a href="https://webassembly.github.io/spec/js-api/index.html" >W3C WebAssembly JavaScript Interface</a > </li> </ul> </section>

<section> <h2 id="server-side-resources">Server-Side / Backend Programming</h2> <img src="/imgs/server-side-resources.png" alt="An illustration of a server icon." /> In a sense, server-side programming could be described as the job of designing and implementing APIs. As stated earlier, Application Programming Interfaces (<a href="https://www.youtube.com/watch?v=JjXBrJfp5TE" >APIs</a >) are the way that different pieces of software are able to interact with each other. Continuing the earlier customer-restaurant analogy, as a restaurant you are exclusively preoccupied with taking customer orders, sourcing and making food, and delivering it back to the customer. Another really important component of this job is designing a menu (read: API) that is clear and best serves the customer. Translated to the world of programming, it means at its core server-side programming is comprised of: <ul> <li>Accepting HTTP requests (read: accept orders)</li> <li> Processing the requests and finding/creating the data or resources that were requested (read: make the food) </li> <li> Sending the data/resources back to the client (read: deliver the order) </li> </ul> With all this being said, this analogy breaks down in a couple of ways because for starters a client does not always ask for data/resources to be returned to them. Rather, they might also make a request to add, update, or delete data stored on the server-side (such as adding a profile picture, updating a credit card number, or deleting a user account). In addition to that, the model I've described above (that of getting, adding, updating, and deleting data/resources) is based on a form of internet communication called HTTP (more details below). HTTP is the predominant method of communication on the internet but it does not mean it's the only one. <h3>Getting Started</h3> These are some great resources to get a better understanding of what server-side programming is and what it entails. <ul> <li> 🔥🔥🔥 <a href="https://drstearns.github.io/tutorials/" >Dave Stearns Server-Side Web Development Tutorials</a > </li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_web_server" >MDN –– What Is A Web Server</a > </li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Introduction" >MDN –– Introduction To The Serverside</a > </li> <li> 🔥 <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview" >MDN –– Client-Server Overview</a > </li> </ul> <h3>How To Communicate On The Internet</h3> <img src="/imgs/server-side-apis.png" alt="An illustration of a server communicating with the internet." /> Thus far when describing how APIs work we've focused on how the API is a menu that one piece of software can use to determine what another piece of software offers/provides. What we haven't focused on is how these two pieces of software communicate with each other. To reference the analogy from client-side APIs, I said the frontend would use a phone number to call/message the restaurant to tell them its order. But this does not mean that calling/messaging is the only way to communicate with the restaurant –– the same holds true for the internet. The defacto way of communicating on the internet is HTTP/HTTPS (Hyper-Text Transfer Protocol [Secure]). Understanding this communication protocol and how to work with it is crucial for server-side development. In particular, learning about the meaning of HTTP functions like GET, POST, PUT, and DELETE will be very helpful as you dive into learning and using server-side languages/frameworks. For the majority of web development use cases, you only need to worry about HTTP, but as you continue your backend journey you'll discover other communication protocols like WebSockets, MQTT, SMTP, XMPP, and more. <ul> <li> 🔥🔥🔥 <a href="https://drstearns.github.io/tutorials/http/" >The Hyper-Text Transfer Protocol</a > </li> <li> 🔥🔥 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP" >MDN –– HTTP</a > </li> <li> 🔥 <a href="https://drstearns.github.io/tutorials/https/" >Communicating Securely With HTTPS</a > </li> <li> 🔥 <a href="https://www.ably.io/concepts" >Real-Time Messaging Concepts/Protocols</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API" >MDN –– WebSockets APIs</a > </li> </ul> <h3>Testing / Debugging Your APIs</h3> Testing and debugging your APIs is a critical part of the server-side development process and lucky for you (and I) there are some great tools created for doing just that. <ul> <li>🔥 <a href="https://hoppscotch.io/">Hoppscotch</a></li> <li>🔥 <a href="https://www.postman.com/">Postman</a></li> <li><a href="https://insomnia.rest/">Insomnia</a></li> </ul> <h3>API Design</h3> As I stated earlier the design of an API (read: menu) is also a critically important job as it can help the client (read: customer) be confident that they are requesting the correct data/resources/actions. The predominant way of designing APIs in 2020 is to follow the REST pattern and is well worth learning. <ul> <li> 🔥 <a href="https://drstearns.github.io/tutorials/rest/" >Designing APIs According To A RESTful Pattern</a > </li> <li> <a href="https://bocoup.com/blog/documenting-your-api" >REST API Documentation Best Practices</a > </li> <li> <a href="https://www.restapitutorial.com/">REST API Tutorial</a> </li> <li> <a href="https://github.com/RestCheatSheet/api-cheat-sheet" >API Design Cheat Sheet</a > </li> <li> <a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" >The Original REST Paper</a > </li> </ul> <h3>Server-Side Architectures</h3> As the size and complexity of your server-side applications grow (as well as how many users your application has), how you organize or architect the various components will become a greater and greater concern. In 2020, a hugely popular architecture is that of microservices. The idea of microservices is to break up your server-side application into small connected logical units using technologies like Docker (resources can be found in the Cloud section) so that your application is easier to maintain and can scale to many more users. <ul> <li> 🔥🔥 <a href="https://www.nginx.com/blog/introduction-to-microservices/" >Introduction to Microservices Series</a > </li> <li> <a href="https://martinfowler.com/articles/microservices.html" >Another Microservices Series</a > </li> <li> <a href="https://github.com/RestCheatSheet/microservices-cheat-sheet" >Microservice Cheat Sheet</a > </li> <li> <a href="https://github.com/RestCheatSheet/platform-cheat-sheet" >Platform-Building Cheat Sheet</a > </li> <li> <a href="https://engineering.videoblocks.com/web-architecture-101-a3224e126947" >Web Architecture 101</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side" >MDN––Server-side Website Programming</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Web_frameworks" >MDN –– Guide To Server-Side Frameworks</a > </li> <li> <a href="https://drstearns.github.io/tutorials/cors/" >Cross-Origin Resource Sharing Tutorial</a > </li> <li> <a href="https://www.codecademy.com/articles/what-is-cors" >What Is CORS?</a > </li> <li> <a href="https://drstearns.github.io/tutorials/env/" >Environment Variables</a > </li> <li> <a href="https://drstearns.github.io/tutorials/sessions/" >Tracking Sessions</a > </li> <li> <a href="https://drstearns.github.io/tutorials/authentication/" >Authenticating Users</a > </li> </ul> <h2>Server-Side Programming Languages</h2> The next couple of sections will be dedicated to a handful of programming languages you can use on the server-side. Over time you will discover the same high-level ideas, goals, and strategies of server-side programming are generally used no matter what language and server-side framework you choose. As a result, picking a server-side language just comes down to a matter of the language/framework itself and what kinds of benefits and drawbacks they offer. <h2 id="javascript-runtime-resources">JavaScript Runtimes</h2> Starting off with what I think is a natural transition from frontend to backend programming is using JavaScript on the server! From its origins as a scripting language for Netscape Navigator (a very old web browser), JavaScript could only be interpreted and run in a browser. However, when creating server-side programs you need code that can run on a computer (a server is essentially just a specialized computer for handling network requests). Lucky for you, there are pieces of software called JavaScript runtimes to do just that. These runtimes allow you to run JavaScript on a computer like a regular Java or Python program, while also giving extra functionality such as accessing a computer's file system and responding to network requests––creating the foundation for writing JavaScript that runs on a server. The most famous and widely used JavaScript runtime is Node.js. However, a new runtime called Deno (created by the same person who invented Node.js) is also starting to pick up steam and capture attention. <h2>Node.js Resources</h2> <img src="/imgs/node-js.png" alt="An illustration of the Node.js logo." /> As stated above, Node.js (also sometimes referred to as "Node") is easily the most famous and widely used JavaScript runtime for executing JS code outside a browser. <h3>Getting Started</h3> These are some great resources to get oriented with Node.js and dive deeper into its core topics. The Introduction to Node.js tutorials are one of the primary sources I used to learn Node and are well worth a read. <ul> <li> 🔥🔥🔥 <a href="https://nodejs.dev/learn">Introduction to Node.js</a> </li> <li> 🔥🔥 <a href="https://www.youtube.com/watch?v=ENrzD9HAZK4" >Node.js Ultimate Beginner's Guide In 7 Easy Steps</a > </li> <li>🔥 <a href="https://nodejs.dev/">Nodejs.dev Website</a></li> <li><a href="https://nodejs.org/en/">Nodejs.org Website</a></li> <li> <a href="https://nodejs.org/dist/latest-v14.x/docs/api/" >Node Documentation</a > </li> <li> <a href="https://www.freecodecamp.org/news/the-definitive-node-js-handbook-6912378afc6e/?source=linkShare-53f0cd20ca9c-1537896927" >The Definitive Node.js Handbook</a > </li> <li> <a href="https://www.tutorialspoint.com/nodejs/index.htm" >Node.js Tutorial</a > </li> <li> <a href="https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js" >Why The Hell Would I Use Node.js? A Case By Case Tutorial</a > </li> </ul> <h3>Node.js Development Environment</h3> Setting up a Node.js development environment is actually fairly straightforward since all the primary tools you need (i.e. the Node.js runtime and the Node Package Manager) are both downloaded when you install Node. The only other useful piece of a Node developer environment would be to use an IDE or a text editor extension for working with Node. My recommendation is to use VS Code as it already comes with an incredible JavaScript/TypeScript/Node extension built-in. <ul> <li> <a href="https://www.tutorialsteacher.com/nodejs/setup-nodejs-development-environment" >Setup Node.js Development Environment</a > </li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/development_environment" >Setting Up A Node.js Development Environment</a > </li> <li> <a href="https://cloud.google.com/nodejs/docs/setup" >Node.js Development Environment Setup</a > </li> </ul> <h3>Node.js Package Management</h3> A huge benefit to using Node.js is its <a href="https://snyk.io/blog/npm-passes-the-1-millionth-package-milestone-what-can-we-learn/" >insanely large</a > ecosystem of third-party packages you can use (i.e. pieces of Node software written by someone else that you can use in your own Node projects). A piece of software called the Node Package Manager (NPM) is installed when you install the Node.js runtime and is the mechanism for including and tracking the packages your Node projects use. Note: Another popular Node.js package management tool that you'll often see is called Yarn. <ul> <li> <a href="https://www.sitepoint.com/npm-node-package-manager/" >Beginner's Guide To NPM</a > </li> <li><a href="https://www.npmjs.com/">NPM Website</a></li> <li><a href="https://www.npmtrends.com/">NPM Trends</a></li> <li> <a href="https://github.com/g-plane/tiny-package-manager" >Tiny-Package-Manager: Learn How NPM Or Yarn Works</a > </li> </ul> <h3>Node.js Web Frameworks</h3> Just as you can use frameworks in client-side development to make the job of creating websites easier, so to can you use server-side frameworks to make the job of creating server-side applications easier. There are many Node.js frameworks to choose from, but easily one of the most well known and well-used frameworks is Express. <ul> <li> 🔥 <a href="https://flaviocopes.com/express/">Introduction To Express</a> </li> <li><a href="https://expressjs.com/">Express Website</a></li> <li> <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs" >MDN –– Express / Node Guide</a > </li> <li> <a href="http://expressjs.com/en/guide/using-middleware.html" >Using Express Middleware</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> <a href="https://drstearns.github.io/tutorials/nodeweb/" >Node.js Microservices</a > </li> <li> <a href="https://nodejs.org/en/docs/guides/debugging-getting-started/" >Debugging Node.js Programs</a > </li> <li> <a href="https://www.codementor.io/@ziad-saab/let-s-code-a-web-server-from-scratch-with-nodejs-streams-h4uc9utji" >Let's Code A Web Server From Scratch With Node.js Streams</a > </li> <li> <a href="https://codeburst.io/building-a-simple-single-sign-on-sso-server-and-solution-from-scratch-in-node-js-ea6ee5fdf340" >Building A Simple Single Sign On (SSO) Server From Scratch</a > </li> <li> <a href="https://github.com/antsmartian/lets-build-express" >Let's Build Express</a > </li> </ul> <h2>Deno Resources</h2> <img src="/imgs/deno.png" alt="An illustration of the Deno logo." /> Deno is a new JavaScript runtime, created by the same person who made Node (Ryan Dahl). The runtime builds on the learning/takeaways Ryan had from building Node and as a result, includes some pretty great features when compared to Node. Some of these features include: <ul> <li>Deno has much better security built into it</li> <li>It supports both JavaScript and TypeScript</li> <li> It has a pretty incredible set of built-in tools inspired by the Go language </li> <li> It has a high-quality audited standard library also inspired by the Go language </li> </ul> As a final note, don't worry about needing to learn Deno right now in 2020. Node is not going anywhere and will likely remain the dominant JavaScript runtime for many years to come. I'd rather suggest casual exploration when approaching Deno –– it has some seriously cool features that can be fun to play around with. Plus, if/when it reaches industry dominance you'll already be slightly ahead of everyone else 😉. <h3>Getting Started</h3> When diving into Deno I highly recommend watching Ryan Dahl's talk on the 10 things he regrets about Node.js. It gives some great insight and context for the goals and design choices of Deno. Beyond that, the Deno Manual is a wonderfully written resource for getting started with Deno. <ul> <li>🔥🔥🔥 <a href="https://deno.land/manual">The Deno Manual</a></li> <li> 🔥🔥 <a href="https://www.youtube.com/watch?v=M3BM9TB-8yA" >10 Things I Regret About Node.js - Ryan Dahl Talk</a > </li> <li> 🔥🔥 <a href="https://www.youtube.com/watch?v=F0G9lZ7gecE" >Deno In 100 Seconds</a > </li> <li>🔥🔥 <a href="https://deno.land/">Deno Website</a></li> <li> 🔥 <a href="https://blog.logrocket.com/deno-1-0-what-you-need-to-know/" >Deno 1.0: What You Need To Know</a > </li> <li> <a href="https://dev.to/kryz/write-a-small-api-using-deno-1cl0" >Write A Small API Using Deno</a > </li> </ul> <h3>Deno Development Environment</h3> This is the official setup guide found in the Deno Manual. It covers all the bases in a well written and clear way. It's all you should need. <ul> <li> 🔥 <a href="https://deno.land/manual/getting_started/setup_your_environment" >Set Up Your Deno Environment</a > </li> </ul> <h3>Deno Package Management</h3> Deno takes a very different approach to package management compared to Node. Rather than using NPM to install and track dependencies, you import URLs pointing to the third-party modules you want to use right within any given JavaScript/TypeScript file you're creating. When your code is executed the modules located at the given URLs will be automatically fetched and installed. Note: These modules are only downloaded and installed the first time your code is run. After that, the modules are cached (read: saved locally on your computer) so that the code can be re-executed many times without the worry of having to fetch and install the modules every single time––which could take forever on slow networks. Modules can be hosted anywhere on the web such as GitHub, a personal web server, or a CDN (content distribution network). Below are some links to Deno's own third-party module hosting service and other popular CDNs where Deno modules can be found. As an additional aside, this way of approaching package management is once again a design decision inspired by the Go language and is, in my opinion, a very welcome and super clean solution. <ul> <li><a href="https://deno.land/x">Deno.land/x</a></li> <li><a href="https://www.skypack.dev/">Skypack</a></li> <li><a href="https://jspm.org/">JSPM</a></li> </ul> <h3>Deno Web Frameworks</h3> Since Deno is such a new runtime the landscape of popular frameworks and libraries is still evolving. Oak seems to be gathering some popularity since it takes a lot of design inspiration from Express and could be worth checking out. That being said, I also left a link to the "Modules" section of the Awesome Deno GitHub where you can find links to other web frameworks as well. <ul> <li> <a href="https://oakserver.github.io/oak/">Oak Website</a> </li> <li><a href="https://github.com/oakserver/oak">Oak GitHub</a></li> <li> <a href="https://github.com/denolib/awesome-deno#modules" >Other Web Frameworks</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> <a href="https://github.com/denolib/awesome-deno">Awesome Deno</a> </li> <li> <a href="https://github.com/denoland/deno">Deno GitHub</a> </li> <li><a href="https://deno.land/posts">Deno News</a></li> <li> <a href="https://deno.land/std@0.66.0">Deno Standard Library</a> </li> <li> <a href="https://doc.deno.land/builtin/stable">Deno Runtime API</a> </li> <li><a href="https://doc.deno.land/">Deno Doc</a></li> <li> <a href="https://github.com/denoland/deno/blob/master/docs/contributing/style_guide.md" >Deno Style Guide</a > </li> <li> <a href="https://github.com/denosaurs/denon">Denon GitHub</a> </li> <ul> <li>This is analogous to Node's nodemon package.</li> </ul> </ul> <h2 id="python-resources">Python Resources</h2> <img src="/imgs/python.png" alt="An illustration of the Python logo." /> For those who are not as familiar with Python, it is a very high-level general-purpose programming language. A huge goal of Python is readability and results in a language that can accomplish a lot with very little code. Like Node, Python also has a massive ecosystem of third-party modules. When combined with the fact that Python is a general-purpose language it means that you can write high-quality code for many areas of computer science such as data science, machine learning, scientific computing, IoT, and (importantly for this guide) web development. <h3>Getting Started</h3> The official Python tutorial was my primary method of learning the syntax and ideas behind Python and is worth reading through (even if casually). Beyond that, I've included some other great resources I've used to pick up bits and pieces of Python info. <ul> <li> 🔥 <a href="https://docs.python.org/3/tutorial/index.html" >The Official Python Tutorial</a > </li> <li> <a href="https://wiki.python.org/moin/BeginnersGuide/Programmers" >Python Wiki Beginner's Guide</a > </li> <li> <a href="https://medium.com/quick-code/advanced-python-made-easy-eece317334fa" >Advanced Python Made Easy</a > </li> <li> <a href="https://docs.python-guide.org/" >The Hitchhiker's Guide To Python</a > </li> <li> <a href="https://www.fullstackpython.com/flask.html" >Full Stack Python</a > </li> </ul> <h3>Python Development Environment</h3> One of the downsides of Python, in my opinion, is that setting up a development environment is not as trivial as one might hope. There are a lot of ways that a development environment can be set up and truth be told I'm not even completely confident in the one I have––it's still a work in progress. That being said the resources below are some of the most helpful ones I've come across for learning about the various ways that one can approach a Python development environment for web development. <ul> <li> 🔥 <a href="https://jacobian.org/2019/nov/11/python-environment-2020/#atom-entries" >Python Development Environment, 2020 Edition</a > </li> <li> 🔥 <a href="https://medium.com/@briantorresgil/definitive-guide-to-python-on-mac-osx-65acd8d969d0" >Definitive Guide To Python On MacOS</a > </li> <li> 🔥 <a href="https://code.visualstudio.com/docs/python/python-tutorial" >Getting Started With Python In VS Code</a > </li> <li> <a href="https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-macos" >How To Install Python 3 and Set Up a Local Programming Environment On MacOS</a > </li> <li> <a href="https://realpython.com/python-virtual-environments-a-primer/" >Python Virtual Environments: A Primer</a > </li> <li> <a href="https://towardsdatascience.com/comparing-python-virtual-environment-tools-9a6543643a44" >Comparing Python Virtual Environment Tools</a > </li> <li> <a href="https://medium.com/@grassfedcode/goodbye-virtual-environments-b9f8115bc2b6" >Goodbye Virtual Environments?</a > </li> <li> <a href="https://www.kevinpeters.net/auto-formatters-for-python" >Auto Formatters For Python</a > </li> <li> <a href="https://github.com/psf/black">Black Formatter</a> </li> </ul> <h3>Python Package Management</h3> Another big downside of Python is its disjointed package management ecosystem. There are a lot of tools trying to solve the same problem with no community consensus on what is best. The result, at least for me, has been a lot of reading, testing, and general uncertainty about what fits my workflow the best. My current favorite is called Poetry and is very similar to NPM. <ul> <li>🔥🔥 <a href="https://python-poetry.org/">Poetry Website</a></li> <li> 🔥🔥 <a href="https://www.pythoncheatsheet.org/blog/python-projects-with-poetry-and-vscode-part-1/" >Python Projects With Poetry Series</a > </li> <li> <a href="https://johnfraney.ca/posts/2019/05/28/create-publish-python-package-poetry/" >Create and Publish a Python Package With Poetry</a > </li> <li> <a href="https://codingdose.info/2019/06/16/develop-and-publish-with-poetry/" >Develop and Publish Your Python Package With Poetry</a > </li> <li> <a href="http://andrewsforge.com/article/python-new-package-landscape/" >Python's New Package Landscape</a > </li> <li> <a href="https://hynek.me/articles/python-app-deps-2018/" >Python Application Dependency Management in 2018</a > </li> <li> <a href="https://johnfraney.ca/posts/2019/03/06/pipenv-poetry-benchmarks-ergonomics/" >Pipenv and Poetry: Benchmarks and Ergonomics</a > </li> <li> <a href="https://johnfraney.ca/posts/2019/11/19/pipenv-poetry-benchmarks-ergonomics-2/" >Pipenv and Poetry: Benchmarks and Ergonomics II</a > </li> <li> <a href="https://blog.ionelmc.ro/2014/05/25/python-packaging/" >Packaging a Python Library</a > </li> <li> <a href="https://medium.com/hackernoon/reaching-python-development-nirvana-bb5692adf30c" >Why You Should Use pyenv + Pipenv For Your Python Projects</a > </li> <li> <a href="https://pythonspeed.com/articles/pipenv-docker/" >Faster Docker Builds With Pipenv, Poetry, or pip-tools</a > </li> <li> <a href="https://gist.github.com/pandafulmanda/730a9355e088a9970b18275cb9eadef3" >Python3 Virtualenv Setup</a > </li> <li> <a href="https://virtualenv.pypa.io/en/stable/" >Virtualenv Documentation</a > </li> </ul> <h3>Python Web Frameworks</h3> From my knowledge and experience, the two big web frameworks for Python are Flask and Django. Flask is a more lightweight framework that gives you the flexibility to implement whatever you might need but at the cost of writing more code. Comparatively, Django is a heavier framework that gives you a lot of prebuilt software for things such as user authentication. This means you can write less code but at the cost of less flexibility if you need to create something non-traditional or more customized to your needs. I've only worked with Flask at this point, so those are the resources that will be linked below. <ul> <li> <a href="https://flask.palletsprojects.com/en/1.1.x/" >Flask Website</a > </li> <li> <a href="https://codeburst.io/flask-for-dummies-a-beginners-guide-to-flask-part-uno-53aec6afc5b1" >Flask For Dummies</a > </li> <li> <a href="https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world" >The Flask Mega Tutorial</a > </li> <li> <a href="https://dev.to/dbanty/flask-rest-api-introduction-la4" >Flask REST API Series</a > </li> <li> <a href="https://pythonhow.com/how-a-flask-app-works/" >How A Flask App Works</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> 🔥🔥🔥 <a href="https://realpython.com/">Real Python Tutorials</a> </li> <li> 🔥🔥🔥 <a href="https://www.pythoncheatsheet.org/">Python Cheat Sheet</a> </li> <li>🔥 <a href="https://mathtocode.com/">Math To Code</a></li> <ul> <li>An interactive NumPy tutorial</li> </ul> <li> <a href="https://www.learnpython.org/">LearnPython.org</a> </li> <li> <a href="https://towardsdatascience.com/whats-init-for-me-d70a312da583" >What's init For Me?</a > </li> <li> <a href="https://medium.com/free-code-camp/whats-in-a-python-s-name-506262fe61e8" >What's In Python's name?</a > </li> <li> <a href="https://medium.com/@m0etaz/python-beyond-the-basics-ii-16964d70c4da" >Python: Beyond The Basics II</a > </li> <li> <a href="https://medium.com/hackernoon/python-tricks-101-2836251922e0" >Python Tricks 101</a > </li> <li> <a href="https://medium.com/hultner/try-out-walrus-operator-in-python-3-8-d030ce0ce601" >Try Out The Walrus Operator In Python 3.8</a > </li> <li> <a href="https://python.swaroopch.com/">A Byte Of Python eBook</a> </li> <li> <a href="https://medium.com/octopus-wealth/python-scripts-26e3d0bd5277" >Python Scripts</a > </li> <li> <a href="https://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/" >Open Sourcing a Python Project The Right Way</a > </li> <li> <a href="https://medium.com/georgian-impact-blog/python-tooling-makes-a-project-tick-181d567eea44" >Python Tooling Makes a Project Tick</a > </li> <li> <a href="https://isaak.dev/2020/08/python-libraries-to-make-your-code-readable-and-maintainable" >Python Libraries To Make Your Code Readable, Reliable, And Maintainable</a > </li> <li> <a href="https://medium.com/testcult/intro-to-test-framework-pytest-5b1ce4d011ae" >Intro To Test Framework Pytest</a > </li> <li> <a href="https://pytest.org/en/latest/">Official Pytest Website</a> </li> <li> <a href="https://medium.com/@yeraydiazdiaz/what-the-mock-cheatsheet-mocking-in-python-6a71db997832" >What The Mock? A Cheatsheet for Mocking in Python</a > </li> </ul> <h2 id="go-resources">Go Resources</h2> <img src="/imgs/go.png" alt="An illustration of the Go logo." /> Go is another general-purpose programming language that can be casually put in the same category as C/C++ and Rust. It does not run quite as fast as <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html" >C++</a > or <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-rust.html" >Rust</a > (although it is still much faster than <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-node.html" >Node</a > or <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-python3.html" >Python</a >). However, what it loses (slightly) in speed it makes up for in convenience, readability, and all the comforts of a modern language. For example, Go's <a href="https://www.reddit.com/r/golang/comments/5hqvc1/what_are_the_built_in_go_tools_what_are_they_used/" >built-in tooling</a > is easily the best I've ever seen in a language and has led to an incredibly enjoyable developer experience anytime I've had to use it. Along with some of its other <a href="https://go.dev/solutions/webdev/">features</a>, it makes Go an amazing language to work with for server-side development. Pro-Tip: If you're just starting out with Go always type "Golang" instead of "Go" into Google searches––the results will be far more relevant. <h3>Getting Started</h3> These are a few great resources for getting started with Go, however, the server-side tutorials by Dave Stearns discussed below were my primary method for learning Go. <ul> <li>🔥 <a href="https://go.dev/">Go.dev Website</a></li> <li>🔥 <a href="https://tour.golang.org/welcome/1">A Tour Of Go</a></li> <li><a href="https://golang.org/">Go Website</a></li> <li> <a href="https://golang.org/doc/code.html">How To Write Go Code</a> </li> <li><a href="https://golang.org/doc/">Go Documentation</a></li> <li> <a href="https://www.golang-book.com/books/intro" >An Introduction to Go Book</a > </li> <li> <a href="https://gowebexamples.com/" >Learn Web Programming In Go By Example</a > </li> <li><a href="https://gobyexample.com/">Go By Example</a></li> </ul> <h3>🔥🔥🔥 Dave Stearns Server-Side Tutorials</h3> During college, I took a class on server-side development that used Go as the primary language. The creator of the course (Dave Stearns) wrote a series of tutorials to parallel the curriculum. The tutorials on Go are some of the most clearly written and informational readings I've ever come across and were the primary mechanism that I used to learn the language. They are all worth reading. <ul> <li> <a href="https://drstearns.github.io/tutorials/gointro/" >Introduction To Go</a > </li> <li> <a href="https://drstearns.github.io/tutorials/golang/" >The Go Language</a > </li> <li> <a href="https://drstearns.github.io/tutorials/goslicemap/" >Go Slices And Maps</a > </li> <li> <a href="https://drstearns.github.io/tutorials/gojson/" >Go Structs And JSON</a > </li> <li> <a href="https://drstearns.github.io/tutorials/goweb/" >Go Web Servers</a > </li> <li> <a href="https://drstearns.github.io/tutorials/tokenizing/" >Tokenizing HTML Streams In Go</a > </li> <li> <a href="https://drstearns.github.io/tutorials/testing/" >Automated Testing In Go</a > </li> <li> <a href="https://drstearns.github.io/tutorials/godb/" >Talking To Databases From Go</a > </li> <li> <a href="https://drstearns.github.io/tutorials/gohandlerctx/" >Sharing Values With Go Handlers</a > </li> <li> <a href="https://drstearns.github.io/tutorials/gomiddleware/" >Middleware Patterns In Go</a > </li> <li> <a href="https://drstearns.github.io/tutorials/mutexes/" >Protecting Data Structures With Mutexes</a > </li> </ul> <h3>Go Development Environment</h3> Setting up a development environment for Go is pretty straightforward. All you need is to download the language (and thus the command line tools for working with Go) and a Go language extension for your text editor of choice. <ul> <li> <a href="https://golang.org/doc/editors.html" >Editor Plugins And IDEs</a > </li> <li> <a href="https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins" >IDEs And Plugins For Go</a > </li> <li> <a href="https://www.golang-book.com/guides/machine_setup" >Go Machine Setup (Windows/MacOS)</a > </li> </ul> <h3>Go Package Management</h3> As I hinted at in the Deno section above, Go has a pretty unique (and cool) way of approaching package management when compared to other languages like Node or Python. As part of Go's command line tool that is installed with the language there is a command called <code>go get</code> that can be used to download a package at a given URL. The package is installed locally to your computer and from there you can import it into any Go file you might be writing. <ul> <li> <a href="https://golang.org/cmd/go/#hdr-Add_dependencies_to_current_module_and_install_them" >Go Get Documentation</a > </li> <li><a href="https://pkg.go.dev/">Search For Go Packages</a></li> </ul> <h3>Go Web Frameworks</h3> There are some web frameworks out there for Go, but in most cases, the built-in packages mean you don't need any third-party libraries for server-side development! <h3>Miscellaneous Resources</h3> <ul> <li><a href="https://awesome-go.com/">Awesome Go</a></li> <li> <a href="https://golang.org/doc/cmd">Go Command Documentation</a> </li> <li> <a href="https://golang.org/doc/effective_go.html">Effective Go</a> </li> <li> <a href="https://golang.org/doc/articles/wiki/" >Writing Go Web Applications Tutorial</a > </li> <li> <a href="https://kasvith.me/posts/lets-create-a-simple-lb-go/" >Create A Simple Load Balancer With Go</a > </li> <li><a href="https://gophercises.com/">Gophercises</a></li> <li> <a href="https://github.com/golang/go/wiki">The Go Wiki</a> </li> <li><a href="https://blog.golang.org/">Go Blog</a></li> <li><a href="https://play.golang.org/">Go Playground</a></li> <li> <a href="https://github.com/tmrts/go-patterns" >A Curated List Of Go Patterns</a > </li> <li> <a href="https://golang.org/pkg/">Go Standard Packages</a> </li> <li> <a href="https://blog.golang.org/cover">Go Test Coverage</a> </li> <li> <a href="https://www.reddit.com/r/golang/comments/ii64br/howwhy_is_concurrent_code_faster_than_sequential/?utm_source=share&utm_medium=ios_app&utm_name=iossmf" >How/Why Is Concurrent Code Faster Than Sequential Code?</a > </li> <li> <a href="http://www.doxsey.net/blog/go-concurrency-from-the-ground-up" >Go Concurrency From The Ground Up</a > </li> <li> <a href="https://www.youtube.com/watch?v=cN_DpYBzKso" >Concurrency Is Not Parallelism Talk</a > </li> <li> <a href="https://www.youtube.com/watch?v=f6kdp27TYZs" >Go Concurrency Patterns Talk</a > </li> <li> <a href="https://golang.org/ref/mem">The Go Memory Model</a> </li> </ul> <h2 id="rust-resources">Rust Resources</h2> <img src="/imgs/rust.png" alt="An illustration of the Rust logo." /> Rust is a language I'm only starting to get familiar with but one that I'm pretty excited about. It is a low-level systems language that can be thought of as a C/C++ competitor with some very nice benefits and features. Notably, it can run really fast (as fast as <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html" >C</a >/<a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html" >C++</a >) while at the same time providing memory safety and an incredible(-y strict) compiler/type system that together can catch a ton of bugs and output very helpful/descriptive errors messages and hints. On the downside, Rust has some fairly complicated syntax and idioms compared to other languages, so it comes with a pretty steep learning curve. It's definitely not a server-side language you should start out with. With all that being said, Rust's position sat squarely in the world of <a href="https://www.rust-lang.org/what/wasm">WebAssembly</a> and <a href="https://www.rust-lang.org/what/networking">server-side</a> use cases has caught my attention in a big way. <h3>Getting Started</h3> When it comes to learning Rust you will find that the primary method of conferring information is through books. In fact, the official method for learning Rust is often called "The Book" in the Rust community and it's well worth reading. There is also a counter-part to the book that teaches Rust using a more hands-on example-based approach which I've personally found very helpful. <ul> <li>🔥🔥 <a href="https://doc.rust-lang.org/book/">The Book</a></li> <li> 🔥🔥 <a href="https://doc.rust-lang.org/stable/rust-by-example/" >Rust By Example</a > </li> <li>🔥🔥 <a href="http://www.arewewebyet.org/">Are We Web Yet? </a></li> <li> 🔥 <a href="https://brson.github.io/fireflowers/">Fireflowers</a> </li> <li><a href="https://www.rust-lang.org/">Rust Website</a></li> </ul> <h3>Rust Development Environment</h3> This is the official getting started page found on the Rust website. It covers installing the language and provides links to developer tools for popular text editors and IDEs. It's all you should need to get up and running. <ul> <li> 🔥 <a href="https://www.rust-lang.org/learn/get-started" >Getting Started With Rust</a > </li> </ul> <h3>Rust Package Management</h3> Rust has a fantastic package management ecosystem that is very similar to NPM. Rust provides a command-line tool called Cargo that operates very similar to NPMs command-line tool. Also instead of calling third-party code "packages", the term "crates" is used. <ul> <li><a href="https://crates.io/">Crates.io</a></li> <li> <a href="https://doc.rust-lang.org/cargo/index.html" >The Cargo Book</a > </li> </ul> <h3>Rust Web Frameworks</h3> Similar to Deno, the ecosystem of Rust web frameworks seems to be evolving still. However, it is much further along than Deno with Rust being nearly 5 years older. The first link below does a great job analyzing some of the popular options in the ecosystem and providing recommendations. <ul> <li> 🔥 <a href="https://www.lpalmieri.com/posts/2020-07-04-choosing-a-rust-web-framework-2020-edition/" >Choosing A Rust Web Framework, 2020 Edition</a > </li> <li><a href="https://actix.rs/">Actix Framework</a></li> <ul> <li>Similar to Flask or Express</li> </ul> <li><a href="https://rocket.rs/">Rocket Framework</a></li> <ul> <li>Similar to Django</li> </ul> </ul> <h3>Miscellaneous Resources</h3> <ul> <li> 🔥 <a href="https://www.figma.com/blog/rust-in-production-at-figma/" >Rust In Production At Figma</a > </li> <li> 🔥 <a href="https://hacks.mozilla.org/2018/12/rust-2018-is-here/" >Rust 2018 Is Here… But What Is It?</a > </li> <li> 🔥 <a href="https://polyfloyd.net/post/how-rust-helps-you-prevent-bugs/" >How Rust Helps You Prevent Bugs</a > </li> <li> <a href="https://github.com/rust-unofficial/awesome-rust/blob/master/README.md#audio" >Awesome Rust</a > </li> <li> <a href="http://nbaksalyar.github.io/2015/07/10/writing-chat-in-rust.html" >Rust In Detail: Writing A Scalable Chat Service From Scratch</a > </li> <li> <a href="https://doc.rust-lang.org/nightly/edition-guide/introduction.html" >Rust Nightly Edition Book</a > </li> <li> <a href="https://cfsamson.github.io/books-futures-explained/introduction.html" >Futures Explained In 200 Lines of Rust</a > </li> </ul> <h2 id="database-resources">Database Resources</h2> <img src="/imgs/database.png" alt="An illustration of a database icon." /> Continuing the customer-restaurant analogy, databases can be thought of as the fridge or cold room in a restaurant. It's the place where food and ingredients (read: your application data) can be stored before they're ready to be cooked and delivered to a customer. Just as fridges come in many different shapes and sizes, there are a variety of database types that solve different problems. The link below is an amazing video that discusses the various database types you might use. For the purposes of this guide (and my own limited knowledge of the entire database ecosystem), we will mainly focus on the most popular type of database––relational databases. The most simple analogy I can think of is that relational databases are like spreadsheets that can be connected together. They use SQL (Structured Query Language) to create and maintain these spreadsheets. Below you will find resources for a popular dialect of SQL called MySQL. Additionally, relational databases and SQL are so dominant that you will sometimes see non-relational database options casually referred to as "NoSQL databases." That being said, I would once again highly recommend watching the video linked below to get a better understanding of what else is out there. <ul> <li> 🔥🔥🔥 <a href="https://www.youtube.com/watch?v=W2Z7fbCLSTw" >7 Database Paradigms</a > </li> </ul> <h2>MySQL Resources</h2> <img src="/imgs/mysql.png" alt="An illustration of the MySQL logo." /> MySQL is one of many flavors of SQL and just happens to be the version of SQL I learned. It can do all the core operations of any other SQL language but with minor syntax and feature differences. <h3>Getting Started</h3> <ul> <li> 🔥 <a href="https://www.mysqltutorial.org/basic-mysql-tutorial.aspx" >Basic MySQL Tutorial</a > </li> <li> <a href="https://www.elated.com/mysql-for-absolute-beginners/" >MySQL For Absolute Beginners</a > </li> </ul> <h3>Advanced SQL Concepts</h3> <ul> <li> <a href="https://www.mysqltutorial.org/mysql-stored-procedure-tutorial.aspx" >MySQL Stored Procedures</a > </li> <li> <a href="https://www.mysqltutorial.org/mysql-triggers.aspx" >MySQL Triggers</a > </li> <li> <a href="https://www.mysqltutorial.org/mysql-views-tutorial.aspx" >MySQL Views</a > </li> <li> <a href="https://www.mysqltutorial.org/mysql-functions.aspx" >MySQL Functions</a > </li> <li> <a href="https://www.reddit.com/r/webdev/comments/b46iyd/sql_joins/" >SQL Joins Infographic</a > </li> </ul> <h3>Using MySQL With Backend Languages</h3> <ul> <li> <a href="https://www.mysqltutorial.org/mysql-nodejs/" >MySQL Node.js Tutorial</a > </li> <li> <a href="https://www.mysqltutorial.org/php-mysql/" >MySQL PHP Tutorial</a > </li> <li> <a href="https://www.mysqltutorial.org/python-mysql/" >MySQL Python Tutorial</a > </li> </ul> <h2>NoSQL Resources</h2> A big name in the NoSQL space that often comes up is MongoDB which uses JSON as it's storage medium (compared to the spreadsheet-like format of SQL databases). <ul> <li> <a href="https://flaviocopes.com/mongodb-vs-sql/" >How MongoDB Is Different From A SQL Database</a > </li> <li> <a href="https://flaviocopes.com/mongodb/">MongoDB Basics Tutorial</a> </li> <li> <a href="https://flaviocopes.com/node-mongodb/" >How To Use MongoDB With Node.js</a > </li> </ul> <h2 id="cloud-resources">Cloud Resources</h2> <img src="/imgs/cloud.png" alt="An illustration of various Cloud company logos." /> Finally, we get to the cloud. Physically speaking, the cloud is just a network of servers spread across the entire world that is owned and operated by a variety of companies (notably Amazon, Microsoft, and Google). For the purposes of full-stack software engineering, the benefit of the cloud is that you can rent the computing power and storage capacity of this network to run your web applications at any scale––whether your app has tens of users or billions of users. One of the big tasks of using the cloud is determining what services and technologies to use. There are a mind-boggling number of these services available to use (Amazon's AWS has over 150+ options alone). Notably for web development, there are tons of options for web application deployment and options for database deployment. Some of these options lean towards automating the process of deployment while others are more flexible and let you use technologies like Docker and Kubernetes to set up your own custom environment. Take your time to research these various services along with there drawbacks and benefits and you'll be golden. Additionally, the first link below offers a great introduction to some of these services and what's possible in the cloud. <h3>Getting Started</h3> <ul> <li> 🔥🔥🔥 <a href="https://www.youtube.com/watch?v=1pBuwKwaHp0" >Cloud Computing In The Year 2020</a > </li> <li> <a href="https://mashable.com/2013/08/26/what-is-the-cloud/" >What Is The Cloud?</a > </li> <li> <a href="https://linchpinseo.com/guide-to-the-cloud/" >Beginner's Guide To Understanding The Cloud</a > </li> </ul> <h3>Docker / Kubernetes (K8s) Resources</h3> At a high-level (that leaves out a lot of details), Docker is a way of packaging your web applications into what are called "containers" so that they can be deployed basically anywhere. This is very powerful because it means you as a developer don't have to worry about getting your application to run on different servers with different operating systems. Kubernetes (sometimes called K8s for short) is essentially a piece of software for organizing and managing Docker containers in the Cloud. <ul> <li> 🔥 <a href="https://www.youtube.com/watch?v=Gjnup-PuquQ" >Docker In 100 Seconds</a > </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=gAkwW2tuIqE" >Learn Docker In 7 Easy Steps - Full Beginner's Tutorial</a > </li> <li> 🔥 <a href="https://drstearns.github.io/tutorials/docker/" >Containerizing With Docker</a > </li> <li> <a href="https://www.freecodecamp.org/news/comprehensive-introductory-guide-to-docker-vms-and-containers-4e42a13ee103/" >A Comprehensive Intro To Docker, Virtual Machines, and Containers</a > </li> <li><a href="https://www.docker.com/">Docker Website</a></li> <li> <a href="https://www.docker.com/get-started" >Docker Getting Started</a > </li> <li> <a href="https://docs.docker.com/get-started/overview/" >Docker Overview</a > </li> <li> <a href="https://docs.docker.com/develop/develop-images/dockerfile_best-practices/" >Best Practices For Writing Dockerfiles </a> </li> <li><a href="https://kubernetes.io/">Kubernetes Website</a></li> <li> <a href="https://kubernetes.io/docs/tutorials/kubernetes-basics/" >Kubernetes Basics</a > </li> <li> <a href="https://kubernetes.io/docs/home/" >Kubernetes Documentation</a > </li> </ul> <h3>Heroku Resources</h3> Heroku is another Cloud service (just like Amazon AWS or Microsoft Azure), but notably it is my go to service for deploying smaller applications and websites. Plus when combined with the tips from the third link you can effectively get 24/7 uptime for free. <ul> <li> 🔥🔥🔥 <a href="https://railsautoscale.com/heroku-free-dynos/" >Tips For Running Free Dynos On Heroku In 2020</a > </li> <li> 🔥 <a href="https://trifinlabs.com/what-is-heroku/">What Is Heroku?</a> </li> <li> <a href="https://devcenter.heroku.com/start" >Heroku Getting Started</a > </li> <li> <a href="https://devcenter.heroku.com/categories/reference" >Heroku Documentation</a > </li> </ul> <h3>Miscellaneous Resources</h3> <ul> <li><a href="https://aws.amazon.com/">AWS Website</a></li> <li> <a href="https://drstearns.github.io/tutorials/deploy2aws/" >Deploying to AWS</a > </li> <li> <a href="https://aws.amazon.com/education/awseducate/">AWS Educate</a> </li> <li> <a href="https://azure.microsoft.com/en-us/" >Microsoft Azure Website</a > </li> <li> <a href="https://azure.microsoft.com/en-us/developer/students/" >Azure Student Developer Resources</a > </li> <li> <a href="https://cloud.google.com/">Google Cloud Website</a> </li> <li> <a href="https://cloud.google.com/gcp/getting-started" >Google Cloud Getting Started</a > </li> <li> <a href="https://www.digitalocean.com/">DigitalOcean Website</a> </li> <li> <a href="https://drstearns.github.io/tutorials/deploy2do/" >Deploying to Digital Ocean</a > </li> <li> <a href="https://workers.cloudflare.com/">Cloudflare Workers</a> </li> <li> <a href="https://www.youtube.com/watch?v=3OP-q55hOUI" >Cloud Run Quick Start––Docker To Serverless</a > </li> </ul> <h2 id="miscellaneous-resources">Miscellaneous Resources</h2> Finally, here are all the resources that didn't neatly fit into the other categories but are still well worth a look 👀. <h3 id="inspiration-resources">Sources For Inspiration</h3> <ul> <li> 🔥 <a href="https://www.awwwards.com/collections/" >Awwwards Collections</a > </li> <li>🔥 <a href="https://dribbble.com/">Dribbble</a></li> <li><a href="https://www.awwwards.com/">Awwwards</a></li> <li><a href="https://lookup.design/">Lookup.design</a></li> <li> <a href="https://www.cssdesignawards.com/">CSS Design Awards</a> </li> <li> <a href="https://bestwebsite.gallery/">Best Website Gallery</a> </li> <li><a href="https://codepen.io/">Codepen</a></li> </ul> <h3 id="general-education-resources">General Education Resources</h3> <ul> <li>🔥🔥🔥 <a href="https://roadmap.sh/">Developer Roadmaps</a></li> <li> 🔥 <a href="https://sidewaysdictionary.com">Sideways Dictionary</a> </li> <li> 🔥 <a href="https://choosealicense.com/" >Choose An Open Source License</a > </li> <li> 🔥 <a href="https://www.freecodecamp.org/learn/">FreeCodeCamp</a> </li> <li> 🔥 <a href="https://www.youtube.com/watch?v=tpIctyqH29Q&list=PL8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo&index=1" >Crash Course Computer Science Series</a > </li> <li> 🔥 <a href="https://missing.csail.mit.edu/" >The Missing Semester of Your CS Education</a > </li> <li> <a href="https://research.hackerrank.com/" >HackerRank Developer Skills Report</a > </li> <li><a href="https://web.dev/">Web.dev</a></li> <li> <a href="https://developers.google.com/web" >Google Developers - Web</a > </li> <li> <a href="https://www.tutorialspoint.com/index.htm">TutorialsPoint</a> </li> </ul> <h3 id="reading-resources">Great Blogs / Books / Articles</h3> <ul> <li> 🔥🔥🔥 <a href="https://code-cartoons.com/@linclark">Anything</a> <a href="https://hacks.mozilla.org/author/lclarkmozilla-com/" >Written</a > By <a href="https://twitter.com/codecartoons">Lin Clark</a> </li> <li>🔥 <a href="https://www.taniarascia.com/">Tania Rascia Blog</a></li> <li>🔥 <a href="https://flaviocopes.com/">Flavio Copes Blog</a></li> <li> 🔥 <a href="https://www.zainrizvi.io/blog/the-impostors-advantage/" >The Impostor's Advantage</a > </li> <li> 🔥 <a href="https://mtlynch.io/human-code-reviews-1/" >How To Do Code Reviews Like A Human (Part 1)</a > </li> <li> 🔥 <a href="https://mtlynch.io/human-code-reviews-2/" >How To Do Code Reviews Like A Human (Part 2)</a > </li> <li> <a href="https://www.freecodecamp.org/news/">FreeCodeCamp News</a> </li> <li> <a href="https://www.uxpin.com/studio/ebooks/">Free UX Ebooks</a> </li> <li> <a href="https://code.tutsplus.com/tutorials/mvc-for-noobs--net-10488" >MVC For Noobs</a > </li> <li> <a href="https://github.com/kamranahmedse/design-patterns-for-humans" >Design Patterns For Humans</a > </li> <li><a href="https://12factor.net/">The 12 Factor App</a></li> <li> <a href="https://faculty.washington.edu/ajko/books/cooperative-software-development/#/" >Cooperative Software Development Book</a > </li> </ul> <h3 id="stock-image-resources">Stock Image Resources</h3> <ul> <li>🔥 <a href="https://www.pexels.com/">Pexels</a></li> <ul> <li>Free/copyright free stock images.</li> </ul> <li><a href="https://unsplash.com/">Unsplash</a></li> <ul> <li>Free/copyright free stock images.</li> </ul> <li> <a href="https://generated.photos/">AI-Generated Human Photos</a> </li> </ul> <h2>Wrapping Up</h2> Congratulations! You've officially made it through the mega full-stack web development resource guide. It was definitely not a short read 😅. I hope you picked up some new knowledge along the way. Learning the many domains of full-stack web development can be a lot to grapple with at times but if you take your time and pace it out the results are more than worth the effort. If you would like more useful resources, thoughts, and information on web development topics, you can <a class="bold" href="https://fosstodon.org/@hawkticehurst">follow me</a> on Mastodon. Best of luck on your own web development journeys! You got this. 💫 </section>

Hawk Ticehurst

Declarative signals

Signals, in JavaScript

Signals, as HTML

HTML-based state

Let's do some coercion

Rendering HTML

Rendering state in a custom way

Derived state

What did we miss?

Reactive properties

State that starts in the server

Islets architecture

CSS Web Components for marketing sites

HTML Web Components

CSS Web Components

How far does this go?

Bring your own base class

Web components are built on inheritance

Creating good dependency-free web component DX

Clean up the boilerplate!

Make it pop

Declarative interactivity

So many possibilities

I want a marketplace of base classes

Web components reading list

My web component reading list

In the next episode...

Web components in VS Code

The toolkit

Why web components?

Theming

Listening for theme changes

Integrating with web frameworks

One notable exception

A word of warning

In the next episode...

Portable HTML web components

Browser-native MDX

Component definitions right inside markdown

HTML web components too!

Watch out for how markdown parsers handle script tags

An example and a segue

Portable HTML web components

It's all a bunch of tradeoffs

A hybrid model

There are no silver bullets

In the next episode...

Getting shady

A sneak peek

Shadow DOM is just another tool

Shadow DOM modes

Creating shadow DOM

Adding styles to shadow DOM programmatically

Overriding shadow DOM styles

1. :host styles

2. ::part() psuedo-element

3. CSS variables

An API for your styles

Templates and shadow DOM

1. Statically created templates

2. Dynamically created templates

3. Declarative shadow DOM

Slots

Named slots

Styling slotted content

In the next episode...

Templates and todo lists

A sneak peek

Templates

A quick example

Using templates in web components

A todo list (the hard way)

A todo list (the template way)

How to think about new web component features

In the next episode...

Let it snow

A sneak peek

Your first web component

Web component architecture

1. `:host` styles

2. `::part()` psuedo-element