DEV Community: Matt Swensen

The single most important factor that differentiates front-end frameworks

Matt Swensen — Sun, 11 Jun 2023 05:14:49 +0000

There are tons of blog posts on the internet about how frameworks differ and which one to pick for your next web project. Usually they cover a few aspects of the framework like syntax, development setup, and community size.

This isn’t one of those posts.

Instead, we’ll go directly to the crux of the main problem front-end frameworks set out to solve: change detection, meaning detecting changes to application state so that the UI can be updated accordingly. Change detection is the fundamental feature of front-end frameworks, and the framework authors’ solution to this one problem determines everything else about it: developer experience, user experience, API surface area, community satisfaction and involvement, etc., etc.

And it turns out that examining various frameworks from this perspective will give you all of the information you need to determine the best choice for you and for your users. So let’s dive deep into how each framework tackles change detection.

Major frameworks compared

We’ll look at each of the major players and how they have tackled change detection, but the same critical eye can apply to any front-end JavaScript framework you may come across.

React

“I’ll manage state so that I know when it changes.” —React

True to its de-facto tagline, change detection in React is “just JavaScript.” Developers simply update state by calling directly into the React runtime through its API; since React is notified to make the state change, it also knows that it needs to re-render the component.

Over the years, the default style for writing components has changed (from class components and pure components to function components to hooks) but the core principle has remained the same. Here’s an example component that implements a button counter, written in the hooks style:

export default function App() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(count - 1)}>decrement</button>
      <span>{count}</span>
      <button onClick={() => setCount(count + 1)}>increment</button>
      <button onClick={() => setTimeout(() => setCount(count + 1), 1000)}>increment later</button>
    </div>
  );
}

The key piece here is the setCount function returned to us by React’s useState hook. When this function is called, React can use its internal virtual DOM diffing algorithm to determine which pieces of the page to re-render. Note that this means the React runtime has to be included in the application bundle downloaded by the user.

Conclusion

React's change detection paradigm is straightforward: the application state is maintained inside the framework (with APIs exposed to the developer for updating it) so that React knows when to re-render.

Angular

“I’ll make the developer do all the work.” —Angular

When you scaffold a new Angular application, it appears that change detection happens automagically:

@Component({
  selector: 'counter',
  template: `
    <div>
      <button (click)="count = count - 1">decrement</button>
      <span>8</span>
      <button (click)="count = count + 1">increment</button>
      <button (click)="incrementLater()">increment later</button>
    </div>
  `
})
export class Counter {
  count = 0;

  incrementLater() {
    setTimeout(() => {
      this.count++;
    }, 1000);
  }
}

What’s really happening, is that Angular uses NgZone to observe user actions, and is checking your entire component tree on every event.

For applications of any reasonable size, this causes performance issues, since checking the entire tree quickly becomes too costly. So Angular provides an escape hatch from this behavior by allowing the developer to choose a different change detection strategy: OnPush. OnPush means that the onus is on the developer to inform Angular when state changes so that Angular can re-render the component. Aside from the default naive strategy, OnPush is the only other change detection strategy Angular offers. With OnPush enabled, we must manually tell Angular’s change detector to check the new state if it ever gets updated asynchronously:

@Component({
  selector: 'counter',
  template: `
    <div>
      <button (click)="count = count - 1">decrement</button>
      <span>8</span>
      <button (click)="count = count + 1">increment</button>
      <button (click)="incrementLater()">increment later</button>
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class Counter {
  constructor(private readonly cdr: ChangeDetectorRef) {}

  count = 0;

  incrementLater() {
    setTimeout(() => {
      this.count++;
      this.cdr.markForCheck();
    }, 1000);
  }
}

For applications of any reasonable complexity, this approach quickly becomes untenable.

Alternative solutions are introduced to wrangle this problem. The primary one that the Angular docs suggest is to use RxJS observables in conjunction with the AsyncPipe:

enum Action {
  INCREMENT,
  DECREMENT,
  INCREMENT_LATER
}

@Component({
  selector: 'counter',
  template: `
    <div>
      <button (click)="update.next(Action.DECREMENT)">decrement</button>
      <span>8</span>
      <button (click)="update.next(Action.INCREMENT)">increment</button>
      <button (click)="update.next(Action.INCREMENT_LATER)">increment later</button>
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class Counter {
  readonly update = new Subject<Action>();

  readonly count = this.update.pipe(
    switchScan((prev, action) => {
      switch (action) {
        case Action.INCREMENT:
          return of(prev + 1);
        case Action.DECREMENT:
          return of(prev - 1);
        case Action.INCREMENT_LATER:
          return of(prev + 1).pipe(delay(1000));
      }
    }, 0),
    startWith(0)
  );

  readonly Action = Action;
}

Under the hood, AsyncPipe takes care of subscribing to the observable, informing the change detector when the observable emits a new value, and unsubscribing when the component is destroyed. Observables are a powerful way to model state changes over time, but they come with some serious drawbacks:

They are difficult to debug.
They have a very steep learning curve.
They are great for modeling streams of values (think: mouse movements), but they are overkill for the more common use cases (simple state changes like the on/off state of a checkbox).

To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be as efficient as possible.

From the Angular docs:

Angular Signals is a system that granularly tracks how and where your state is used throughout an application, allowing the framework to optimize rendering updates.

This is a large paradigm shift, making Angular applications more similar to the other frameworks.

Conclusion

Angular's change detection is a disaster. The developer gets two suboptimal choices: (1) the slow and naive default implementation, or the complexity of managing change detection manually. Signals will make it much better, though nearly a decade too late.

Vue

“I’ll track changes to state and react accordingly.” —Vue

Vue’s approach to change detection is subtly different than both React and Angular. Rather than calling a framework function to change state (React) or changing state and then informing the framework that it has been changed (Angular), you work with state objects that have been specially instrumented by the framework to intercept and detect changes.

Confusingly, Vue has two different APIs that wrap the same underlying change detection engine differently. Under the “Options API,” you define an object that contains your state, and Vue assigns a proxied version of that object as a member of this for use in the component’s functions:

<template>
  <div>
    <button @click="decrement">decrement</button>
    <span>8</span>
    <button @click="increment">increment</button>
    <button @click="incrementLater">increment later</button>
  </div>
</template>

<script>
  export default {
    data() {
      return {
        count: 0
      };
    },
    methods: {
      decrement() {
        this.count--;
      },
      increment() {
        this.count++;
      },
      incrementLater() {
        setTimeout(() => {
          this.count++;
        }, 1000);
      }
    }
  };
</script>

Alternatively, the “Composition API” is somewhat similar to React’s hooks: a framework function is called to retrieve a state object that Vue can monitor for changes:

<script setup>
  import { ref } from 'vue';

  const count = ref(0);

  function increment() {
    count.value++;
  }

  function decrement() {
    count.value--;
  }

  function incrementLater() {
    setTimeout(() => {
      count.value++;
    }, 1000);
  }
</script>

<template>
  <div>
    <button @click="decrement">decrement</button>
    <span>8</span>
    <button @click="increment">increment</button>
    <button @click="incrementLater">increment later</button>
  </div>
</template>

Conceptually, the object returned from ref() has a getter and a setter for value, which allows Vue to track changes to it.

Conclusion

Vue utilizes JavaScript language features to allow developers to work with stateful variables without thinking about change detection.

Svelte

“I’ll figure it out for you at compile time.” —Svelte

On the surface, Svelte’s version of our counter component looks pretty similar to the other frameworks:

<script>
  let count = 0;
  function decrement() {
    count--;
  }
  function increment() {
    count++;
  }
  function incrementLater() {
    setTimeout(() => {
      count++;
    }, 1000);
  }
</script>

<div>
  <button on:click="{decrement}">decrement</button>
  <span>{count}</span>
  <button on:click="{increment}">increment</button>
  <button on:click="{incrementLater}">increment later</button>
</div>

But Svelte’s approach to change detection is completely novel in comparison. At compile time, Svelte analyzes an AST (Abstract Syntax Tree) of the component’s code and injects some code into the compiled output that surgically updates the DOM when necessary. For example, here is what the compiled decrement() function looks like:

function decrement() {
  $$invalidate(0, count--, count);
}

Where $$invalidate is a call to Svelte’s internals to instruct the compiled component to update the DOM.

This compile-time approach means that Svelte applications don’t need to bundle a large runtime along with the application itself.

Conclusion

Svelte strikes a rare win-win balance: developers don't have to think about change detection at all, and can interact with stateful variables intuitively; yet the end user's experience is improved through better performance because a bare-minimum application (with change detection baked in) is shipped to the browser.

So, what?

The nuances of how various frameworks choose to tame this beast is not limited to how things work at the component level; it ripples out to everything else about the framework. To name just a few examples: the concepts used to create custom React hooks composed of the basic hooks provided by React out of the box are not relevant to generalizing component behavior in Vue; the challenge of working with observables for state management in Angular has led folks to try and find ways to convert component input props to observables; the framework’s API, dictated by its change detection management paradigm, affects how well it integrates with productivity and quality tools like typechecking, testing, and linting. And so on, and so forth.

And those are just examples from the developer’s point of view. Each approach has implications on the performance of the application for the end user. React, Vue, and Angular each ship a runtime to the user’s browser that needs to be parsed and executed. Svelte’s choice to be a compile-time framework obviates this need in most cases, so the user gets a faster loading experience. Each framework has subtleties that make it more susceptible to particular classes of bugs (often around state management or change detection) that the end user will experience.

Find a change detection paradigm that fits the needs of your application, and everything else will fall into place. Pick one that doesn’t work, and you’ll be fighting against it for the life of the project.

How to set up a Wireguard VPN for personal use

Matt Swensen — Sun, 19 Mar 2023 00:04:28 +0000

VPNs are a great way to level up your privacy online. Here’s how to set one up from scratch.

Step 1: spin up and connect to your cloud server

Using your cloud provider of choice, provision a new server instance. Since the VPN will be for personal use only, inexpensive instances will work fine. Select any operating system that Wireguard supports; we’ll assume Ubuntu for this tutorial.

Connect to your server via SSH as the root user.

Root user

Heads up, all commands outlined in this tutorial assume the root user, so you won't see any commands prefixed with sudo.

Step 2: install Wireguard

If you picked Ubuntu for your server’s OS, you can install Wireguard with one command:

apt install wireguard

Working directory

For the remaining steps, change your working directory to /etc/wireguard.

Step 3: generate a key pair for your VPN server

First, generate a private key:

wg genkey > private.key

Then, use the private key to derive a public key:

wg pubkey < private.key > public.key

These are the keys your VPN server will use when encrypting traffic with your client VPN peers.

Step 4: create your server configuration file

With Wireguard installed and keys generated, we’re ready to create our VPN configuration.

First, find the name of the public network interface:

ip route list default

The output might look something like this: default via ... dev eth0 proto static—the eth0 part is what we’re after.

Create a file called wg0.conf with the following contents, being sure to include the private key where required, and replacing eth0 with the name of the network interface:

[Interface]
SaveConfig = true
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = <the contents of private.key>

Step 5: configure IP forwarding

Add the following line at the bottom of /etc/sysctl.conf:

net.ipv4.ip_forward=1

Then run sysctl -p to load the new configuration.

Step 6: allow UDP traffic

Update the operating system firewall to allow traffic on the port specified in the Wireguard configuration:

ufw allow 51820/udp

Restart UFW to pick up the new configuration:

ufw disable
ufw enable

Step 7: configure the Wireguard server to start on boot

systemctl enable wg-quick@wg0.service

Step 8: generate keys for clients

Now we’ll generate keys for the devices that will be connecting to the server. Follow this process for as many clients as you need:

Output the private key with wg genkey
Output the corresponding public key with echo -n '<the private key>' | wg pubkey
Mark the public key as allowed with wg set wg0 peer <the public key> allowed-ips 10.8.0.2; for each client increment the last digit of the IP address

Verify that the public keys have been added as peers by running the wg command with no arguments. If you’ve configured three clients, the output should look something like this:

interface: wg0
  public key: <the server's public key>
  private key: (hidden)
  listening port: 51820

peer: <first client's public key>
  allowed ips: 10.8.0.2/32

peer: <second client's public key>
  allowed ips: 10.8.0.3/32

peer: <third client's public key>
  allowed ips: 10.8.0.4/32

Step 9: configure clients

Finally, configure your client devices to connect to your Wireguard VPN server. This process will be a little different depending on whether you are using the iOS app, Android app, or another Linux installation of Wireguard. Generally, though, your client configuration should look something like this:

[Interface]
PrivateKey = <the client private key>
Address = <the client IP address>/24
DNS = <the DNS resolvers you wish to use (optional)>

[Peer]
PublicKey = <the server public key>
Endpoint = <the server IP address>:51820
AllowedIPs = 0.0.0.0/0

The 0.0.0.0/0 configuration value indicates that all internet traffic should be tunnelled through the VPN connection.

Happy tunneling!

How to develop over HTTPS on localhost

Matt Swensen — Fri, 11 Mar 2022 15:16:41 +0000

There are a number of reasons you may wish to use HTTPS as part of your web application development workflow:

Your app will likely be deployed to users via HTTPS; the closer your development environment is to production, the less likely you are to run into bugs.
Browsers behave differently in secure contexts, and you want to avoid production-only surprises.
You might be integrating with third-party services or APIs that require the use of HTTPS.

Keep reading to find out how to set up SSL for local development.

Step 1: Generate a self-signed SSL certificate

Unless you are developing on a remote development environment with a static IP address, you won’t have a unique domain name that points to your development environment (and even if you are, you may not want or need one). Without a unique domain name, our only option for and SSL certificate is a self-signed one for local use only. Use this command to generate one:

tl;dr: Use the command below to generate your self-signed certificate and private key.

openssl req -x509 -out localhost.crt -keyout localhost.key -newkey rsa:2048 -nodes -subj '/CN=localhost' -extensions EXT -config <(printf "[req]\ndistinguished_name = dn\n[dn]\nCN=localhost\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

Let’s pick that command apart. Feel free to skip to step 2 if you don’t care about the details.

openssl req - We’re using the openssl program to generate our certificate. openssl has many sub-commands; the one we are using is req, which is for generating certificates and certificate requests.
-x509 - Output a self-signed certificate (rather than a certificate signing request that you might send off to a certificate authority—often called a “CA” for short—to be verified and signed for production use).
-out localhost.crt - Write the certificate to a file called localhost.crt.
-keyout localhost.key - Write the private key to a file called localhost.key.
-newkey rsa:2048 - Generate and use a new private key (as opposed to an existing key, which you’d specify with the -key option) of 2048 bits using the RSA algorithm.
-nodes - Do not encrypt the private key.
-subj '/CN=localhost' - Sets the subject of the certificate request. For production certs, this would include information about the company or business seeking the certificate (such as location, department, email address, etc.), but since this is a development-only certificate, the only necessary information is the “common name” (“CN” for short), localhost.
-extensions EXT - Specifies that the extensions section of our config is delineated with a header titled EXT. That config is defined in the next part of the command.
-config <(printf "...") - The -config option takes a file name containing configuration options, but rather than use a separate file we use input redirection (the < character) and a subshell (the command embedded between parentheses, which returns the string config) to pass the config contents directly, for convenience.

The contents of the configuration are shown more readably below:

[req]
distinguished_name = dn
[dn]
CN=localhost
[EXT]
subjectAltName=DNS:localhost
keyUsage=digitalSignature
extendedKeyUsage=serverAuth

[req] - Options for the req subcommand are below this heading.
distinguished_name = dn - Indicates that the distinguished name fields will be found in a section of the config titled dn.
[dn] - The heading for the fields as indicated above.
CN=localhost - The common name (“CN”) for the certificate; in this case: localhost.
[EXT] - The heading for the extensions, as indicated by the -extensions parameter above.
subjectAltName=DNS:localhost - Indicates that the certificate should match the localhost domain name.
keyUsage=digitalSignature - Indicates that the key may be used for signing the certificate.
extendedKeyUsage=serverAuth - Indicate that in addition to signing the certificate, the private key will also be used to identify the server for SSL/TLS.

Step 2: Install and trust the certificate

Now your local operating system needs to know that the certificate is trustworthy. (Otherwise you’ll see a warning when you access https://localhost that the certificate is not trusted. This warning can be bypassed but trusting the certificate at the OS level gives a smoother development experience.)

For macOS, this can be achieved by following these steps:

Open the Keychain Access app.
Drag and drop your localhost.crt file onto the app.
Right click on the new certificate entry and choose “Get Info”.
Expand the “Trust” section of the Get Info dialog.
For “Secure Sockets Layer (SSL)”, choose “Always Trust”.
Close the dialog and input your password (or TouchID) to save the changes.

There should be a similar process for trusting the certificate in Windows and Linux.

If you’re working on a team, write some documentation for your teammates on how to do this (or point them to this article) so that new engineers can get up and running quickly.

Step 3: Configure your development server to use the certificate and private key

Lastly, your development server applications need to be updated to use the certificate and private key. This will be different for each language and framework. Here are some examples:

For Netlify, the netlify dev server can be configured to use your SSL certificate in development by adding the following to your netlify.toml file:

[dev.https]
  certFile = "localhost.crt"
  keyFile = "localhost.key"

For Node.js servers, pass the key and cert options to https.createServer.

Once configured, you should be able to access your development server via HTTPS on localhost!

Additional reading

How to set up a simple web server development container for VS Code

Matt Swensen — Wed, 26 Jan 2022 16:18:46 +0000

Sometimes it’s nice to have a lightweight development container that automatically serves the contents of a directory, for rapid prototyping or building static web pages—without having to setup a tool chain on your local environment or install web server software (and its dependencies) on your local machine.

If you’re using VS Code’s extension for developing inside containers, below is a recipe for a comfortable development setup containing these three main attributes:

Lightweight; small image footprint and minimal container boot up time
Automatic; once the container starts, the files are being served on a local port without the need to run another command
Complete; has all the dependencies required by VS Code for the full development lifecycle

To achieve this, we’ll use the Alpine Linux operating system with Nginx as our development web server.

Step 1: define development container in a Dockerfile

We’ll include the dependencies required by VS Code’s remote containers extension as well as the specific tools we need for development.

.devcontainer/Dockerfile:

# We'll base our dev container image on Alpine Linux.
FROM alpine:3.15

# Then we'll add the dependencies we need:
# - musl, libgcc, and libstdc++ are required by VS Code's server
# - git and gnupg are useful for remote development so that we
# can commit and sign commits from within the container
# - and of course nginx itself
RUN apk add \
  musl \
  libgcc \
  libstdc++ \
  git \
  gnupg \
  nginx

# Finally, we'll remove nginx's default content and replace it
# with a symlink to our source code.

RUN rm -rf /usr/share/nginx/html
RUN ln -s /workspaces/my-app /usr/share/nginx/html

Heads up

You'll want to replace /workspaces/my-app with whatever directory VS Code mounts your source code to inside the container.

Step 2: configure VS Code to utilize our image

With our image definition done, we’ll add some configuration to instruct VS Code to run it.

.devcontainer/devcontainer.json:

{
  "name": "my-app",
  // Tell VS Code to build our dev container from our Dockerfile.
  "build": {
    "dockerfile": "./Dockerfile"
  },
  // Automatically expose port 8080 (mapped to container's port 80, nginx's default) for development
  "appPort": "8080:80",
  // Make sure our nginx container's default command runs, which starts up the web server in the background.
  "overrideCommand": false
}

Step 3: profit

With those files in place, VS Code has everything it needs to spin up the development container with the source code mounted inside. Once it’s running, you can load up your project’s files in the browser (or even try VS Code’s built-in development browser) on port 8080 for easy side-by-side development:

Happy prototyping!

How to Make an .ico File Using the macOS Terminal

Matt Swensen — Thu, 11 Feb 2021 13:03:36 +0000

Suppose you have an icon or logo at multiple resolutions and would like to combine them into a single favicon.ico file for your website. These are the commands you need to get up and running from the comfort of your own terminal.

Step 1: install ImageMagick

Check out the ImageMagick downloads page for instructions on how to get it running on your machine. Personally, I like to use containerization to keep my Mac free from extraneous software that I rarely use, so I’ll install ImageMagick in a Docker container instead (make sure you have Docker installed):

docker run -it --rm -v /absolute/path/to/icons/directory:/workdir -w /workdir ubuntu

This command will drop you into a bash session on the container. From there, it’s easy to get ImageMagick installed:

apt update
apt upgrade
apt install -y imagemagick

Tip!

ImageMagick has a dependency on tzdata, so you will be prompted to configure your time zone upon installation. Since this is an ephemeral installation, you can just type 1 for each prompt to get through the installation process quickly.

Step 2: create the file

ImageMagick gives us a handy convert command that makes the process super easy:

convert input-file-16x16.png input-file-24x24.png input-file-32x32.png input-file-64x64.png favicon.ico

This will create the desired favicon.ico file.

Step 3: verify the .ico file

ImageMagick also provides a nice utility called identify for inspecting our file to ensure it is formatted as we expect.

identify favicon.ico

The output should look something like this:

favicon.ico[0] ICO 16x16 16x16+0+0 8-bit sRGB 0.000u 0:00.000
favicon.ico[1] ICO 24x24 24x24+0+0 8-bit sRGB 0.000u 0:00.000
favicon.ico[2] ICO 32x32 32x32+0+0 8-bit sRGB 0.000u 0:00.000
favicon.ico[3] ICO 64x64 64x64+0+0 8-bit sRGB 24838B 0.000u 0:00.000

You Might Not Need Sass: Modern CSS Techniques

Matt Swensen — Tue, 15 Sep 2020 12:46:12 +0000

Sass and other CSS preprocessors have some great features and have been widely used for years. CSS is rapidly evolving, though, and some of the features that were previously only possible through preprocessors are now achievable in plain CSS. While updating the styles for mjswensen.com, I found plain CSS to be powerful enough on its own and completely migrated away from Sass. Depending on the size and needs of your project (and target browser support), you may be able to simplify your CSS tool chain as well by using these techniques.

The Sass features we will be re-creating in vanilla CSS in this article:

Parameterized Mixins
Color Manipulation
Variables

Parameterized Mixins

In Sass, you can define a collection of reusable styles, and then include the styles in multiple places throughout your stylesheet.

@mixin alert ($color: yellow) {
  color: $color;
  border: 1px solid currentColor;
  padding: 1em;
}

.error {
  @include alert(red);
}

.success {
  @include alert(green);
}

<div role="alert" class="success">Submitted successfully.</div>

We can achieve this same functionality in vanilla CSS using custom properties and some changes to our markup:

.alert {
  color: var(--color, yellow);
  border: 1px solid currentColor;
  padding: 1em;
}

.error {
  --color: red;
}

.success {
  --color: green;
}

<div role="alert" class="alert success">Submitted successfully.</div>

Tradeoffs

Though we can achieve something similar to Sass’s @mixin/@include with vanilla CSS, there are some tradeoffs to this approach:

There is less clarity around how to use the alert class since it’s --color “parameter” is implicit; you have to reference the HTML to see how it is being used and what the value of --color might be, whereas with Sass the parameters are explicit.
Sass can catch incorrect usages of mixins at compile time and surface errors to the developer, whereas the CSS approach will silently fail if used incorrectly.
Since the CSS approach involves both the stylesheet and the markup, there is more room for mistakes in refactoring a “mixin,” especially in large projects.

Color Manipulation

Sass has long provided a powerful library for manipulating colors. Similar functionality has been proposed for CSS in the CSS Color Module Level 4 specification but is not available for widespread use at the time of writing. However, using the widely available CSS calc() function, we can achieve some simple color manipulations without any tooling on top of our CSS.

In Sass, we can use the rgba() and desaturate() functions to get semi-transparent and desaturated versions of a given color, respectively:

$main-color: hsl(14, 75%, 58%);
$semi-transparent-main: rgba($main-color, 0.1);
$desaturated-main: desaturate($main-color, 20%);

We can achieve the same effect in CSS by splitting the color components into their own custom properties and operating on them individually:

:root {
  --main-color-h: 14;
  --main-color-s: 75%;
  --main-color-l: 58%;
  --semi-transparent-main: hsla(
    var(--main-color-h),
    var(--main-color-s),
    var(--main-color-l),
    0.1
  );
  --desaturated-main: hsl(
    var(--main-color-h),
    calc(var(--main-color-s) - 20%),
    var(--main-color-l)
  );
}

Tradeoffs

The Sass syntax for color manipulation is more compact, easier to use, and easier to read. There are also limitations to the CSS-only approach, at least until the color() function becomes a W3C recommendation and gains browser adoption.

Variables

One of the most then-groundbreaking features of CSS preprocessors was the ability to define and reuse values via variables. As seen in the examples above, we can now do the same thing in vanilla CSS using custom properties. But there are some nuances in the difference between Sass variables and custom properties that are worth mentioning.

Since Sass is a compiled language (compiles down to CSS), variable values are evaluated at compile time rather than at runtime. This comes with a couple of tradeoffs to consider:

Sass variables’ values can’t change in response to browser context changes (like media queries), while custom properties can.
Sass can warn you if you try to use a variable that hasn’t been initiated (if the name is misspelled, for example), while CSS will fall silently when using an undefined variable.
Both Sass variables and custom properties are “global,” but “global” has different meanings. For Sass, “global” means in scope for the current compilation target and any dependency stylesheets (and their dependencies). In CSS, “global” means really global: the values are visible to all stylesheets, markup, and scripts loaded on the page.

Conclusion

Modern vanilla CSS can cover some of the preprocessors’ flagship features, but at a cost of readability and maintainability. The overhead of a CSS build process may be worth it for larger projects or teams. For smaller or solo projects, though, CSS is powerful enough to stand on its own.

Building Stripe.com's Tabbed Preview Widget From Scratch in 30 Minutes

Matt Swensen — Thu, 09 Apr 2020 12:39:00 +0000

In this video I try to build a fully functional tabbed preview widget in HTML and CSS from scratch in 30 minutes—without looking at the original code. After the time’s up, I peek under the hood to see the approach of the original author and compare and contrast it to my approach.

The build process

Setting up a development environment

For this short project I used a very simple setup: an index.html file served by browser-sync for automatic reloads on save. It can be run without previous download or install via npx, which is included by default in node/npm installations.

npx browser-sync --server --files index.html

Configuring the widget’s container

Since this widget doesn’t appear to respond to the window size, I used the macOS screenshot tool (command-shift-4) to measure the dimensions and simply hard-code them into the CSS.

Managing the active tab state

The original Stripe implementation uses JavaScript to maintain the state of the currently active tab, which is a perfectly reasonable approach. I thought it might be fun to see if we could do it without JavaScript. I landed on using radio-type HTML inputs and some CSS selector tricks to achieve the same effect. In a professional setting, I would have likely used JavaScript—one could argue that this is an inappropriate use of radio inputs since this is an informational widget and not part of a form with user-provided data.

The book I referenced in the video is called Resilient Web Design by Jeremy Keith and is freely available to read online.

Sliding the content left and right based on the active tab

I wrapped the code snippets in a container and positioned it absolutely, altering the left property based on the active tab. We discuss a better approach to this later on when we inspect Stripe’s solution.

Giving the widget a 3D appearance

To give the widget a 3D appearance, I rotated the widget around the X and Y axes, but it didn’t quite have the right effect. I should have used the rotate3d() function instead.

Adding a shine effect

For the shine effect, I added an ::after pseudo-element, positioned absolutely to stretch the width and height of the container, and added a background gradient. To keep the text beneath it selectable (and tabs clickable), pointer-events: none was required so that mouse events would fall through it.

My final code

Here is what I ended up with at the end of the session.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Code Preview Widget</title>
  <style>
    .container {
      --width: 490px;
      --bg: #31335B;
      --radius: 8px;
      --border-active: #596481;
      width: var(--width);
      height: 380px;
      background-color: var(--bg);
      border-radius: var(--radius);
      color: white;
      display: grid;
      grid-template-columns: repeat(5, 1fr);
      grid-template-rows: auto 1fr;
      transform: rotateX(-10deg) rotateY(10deg);
      position: relative;
    }

    .container::after {
      content: '';
      position: absolute;
      top: 0;
      right: 0;
      bottom: 0;
      left: 0;
      background-image: linear-gradient(to bottom right, hsla(0, 0%, 100%, 0.15), transparent);
      pointer-events: none;
    }

    .content {
      grid-column-start: 1;
      grid-column-end: 6;
      position: relative;
    }

    .slide-wrapper {
      display: flex;
      overflow-x: hidden;
      position: absolute;
      transition: left 400ms ease-in-out;
    }

    #js:checked ~ .content .slide-wrapper {
      left: 0;
    }

    #rb:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -1);
    }

    #py:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -2);
    }

    #go:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -3);
    }

    #other:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -4);
    }

    .content pre {
      width: var(--width);
      overflow: hidden;
    }

    input[type="radio"] {
      display: none;
    }

    #js:checked ~ label[for="js"],
    #rb:checked ~ label[for="rb"],
    #py:checked ~ label[for="py"],
    #go:checked ~ label[for="go"],
    #other:checked ~ label[for="other"] {
      background-color: var(--bg);
      border-left: 1px solid var(--border-active);
      border-right: 1px solid var(--border-active);
      border-bottom: 1px solid var(--bg);
    }

    label {
      background-color: #2D2F4A;
      border-top-left-radius: var(--radius);
      border-top-right-radius: var(--radius);
      text-align: center;
      padding: 0.25em;
      border-bottom: 1px solid var(--border-active);
    }
  </style>
</head>
<body>
  <div class="container">
    <input type="radio" name="tab" id="js" checked>
    <input type="radio" name="tab" id="rb">
    <input type="radio" name="tab" id="py">
    <input type="radio" name="tab" id="go">
    <input type="radio" name="tab" id="other">
    <label for="js">
      Node.js
    </label>
    <label for="rb">
      Ruby
    </label>
    <label for="py">
      Python
    </label>
    <label for="go">
      Go
    </label>
    <label for="other">
      ...
    </label>
    <section class="content">
      <div class="slide-wrapper">
        <pre><code>// Set your secret key
  const stripe = require('stripe')('sk_test_BQokikJOvBiI2HlWgH4olfQ2');

  // Get the payment token ID submitted by the form:
  const token = request.body.stripeToken;

  (async () => {
    const charge = await stripe.charges.create({
      amount: 999,
      currency: 'usd',
      description: 'Example charge',
      source: token,
    });
  })();</code></pre>
        <pre><code># Set your secret key
  Stripe.api_key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

  # Get the payment token ID submitted by the form:
  token = params[:stripeToken]

  charge = Stripe::Charge.create({
    amount: 999,
    currency: 'usd',
    description: 'Example charge',
    source: token,
  })</code></pre>
        <pre><code> Set your secret key
  stripe.api_key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

  # Get the payment token ID submitted by the form:
  token = request.form['stripeToken']

  charge = stripe.Charge.create(
    amount=999,
    currency='usd',
    description='Example charge',
    source=token,
  )</code></pre>
        <pre><code>// Set your secret key
  stripe.Key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

  // Get the payment token ID submitted by the form:
  token := r.FormValue('stripeToken')

  params := &stripe.ChargeParams{
    Amount: 999,
    Currency: 'usd',
    Description: 'Example charge',
  }
  params.SetSource(token)
  ch, _ := charge.New(params)</code></pre>
        <pre><code>TODO</code></pre>
      </div>
    </section>
  </div>
</body>
</html>

Inspecting the original Stripe code

Differences with my approach

Aside from the fact that the Stripe code was much more polished (with additional borders, typography, syntax highlighting, etc.), there were a number things about the original code that were much improved to my version. Here are a couple:

Rather than transitioning the left property to slide the code back and forth, the original author used translateX(), which is more performant.
The original author used the <figure> element to wrap this widget, which is much more semantically correct than the div I used.

Nice touches

Stripe is known for adding a level of polish and detail that most engineering teams can only dream of. Here are just a couple that I noticed:

Using ::before and ::after pseudo-elements with transparent-to-opaque background gradients, the text had an appearance of sliding “under” the edges of the widget as it moved back and forth.
A tasteful box-shadow was added to augment the 3D effect of the widget.

Conclusion

Any questions or suggestions about my tooling, approach, development style? What would you have done differently? I’d love to hear from you. Find me on Twitter or leave a comment on the video.

Tools

Here are the tools I used in this video:

Text editor: Visual Studio Code with theme Right in the Teals by themer, and Fira Code font
Browser: Brave
Development server: Browsersync launched under npx
Application launcher: Alfred
Color picker: Sip

From Electron to Progressive Web App

Matt Swensen — Sun, 24 Mar 2019 02:29:00 +0000

In this post I’d like to review my reasoning behind sunsetting an Electron-based application in favor of a Progressive Web App (PWA).

Choose your platform wisely—you are at the mercy of its maintainers
URLs are amazing
You really can't beat the distribution model of the Web

themer

First a little context. My application, themer, started off as a command-line tool built on Node.js. It uses a set of colors as input and produces matching themes for various text editors, terminal emulators, and other tools. However, actually choosing the colors for your personalized theme was tedious and cumbersome. A friend suggested to me that I build a GUI to help ease this process and provide a tighter feedback loop when creating a personalized theme. Given that Electron bundles a Node.js runtime, and that I could therefore easily wrap my CLI in a “native” GUI for all platforms, an Electron app seemed like a perfect fit. themer’s GUI was born:

The bug

After spending a good amount of time building the GUI and wiring it up to my CLI running in Electron’s Node process, I was able to bundle up the application installers and make them available for download on the GitHub releases page. It wasn’t until after the application was downloaded about 10k times that I discovered a really nasty bug that caused Electron-based applications to crash when using the macOS native color picker:

It took nearly eight months to fix that issue, during which the utility of themer’s GUI was drastically reduced.

The takeaway

When building for a particular platform or framework, you are at the mercy of its maintainers (of course, if the project is open-source, you can attempt to fix problems yourself, but this isn’t always tenable). Even though Electron is popular, a bug like this wouldn’t have lasted a week in a mainstream Web browser (or likely occurred at all).

Shared/persisted state

One requirement for themer’s GUI was that users should be able to save (and ideally share) their themes. Short of some sort of cloud-based service that integrated with the GUI, the best solution was to simply allow themer’s GUI to read and write JSON from the filesystem. One neat thing about Electron is that you can register a custom icon with the operating system for files that match your custom extension:

I went the whole nine yards and implemented Open, Save, Save As..., friendly prompts to prevent accidental discarding of unsaved changes, etc…. basically everything you’d expect from a traditional desktop program. This worked well enough for persisting theme data, but didn’t allow for easily sharing themes with others.

On the Web, there’s a better way to share application state: the URL. themer’s new PWA stores all of the theme-relevant state in the URL’s query string, so sharing your theme is as easy as sending a link (like this one), and saving is as easy as bookmarking (or just using your browser’s history).

The takeaway

The URL is one of the Web’s most wonderful and distinguishing features. This simple and powerful state/location sharing mechanism is one of my favorite parts about the Web, and is glaringly missing from other platforms.

Distribution model

There is a great open-source package available called electron-builder that adds support for pushing updates that your app can automatically download in the background. In all, it was relatively easy to configure and get working, but there was always a voice in the back of my mind that said: “I hope the updater code in this version works; if it doesn’t, no one will be able to install updates beyond this point.”

While it’s still possible to shoot yourself in the foot with a PWA’s ServiceWorker, more of the cacheing and network code lives in the browser itself, leaving less room for error in user-land.

The takeaway

The distribution model for the Web is unparalleled. If you ship a version of your application that is broken, all you have to do is fix it and re-deploy. The platform itself takes care of the rest.

Conclusion

There are, of course, applications that require the use of Electron (like VS Code for filesystem access, etc.), in which case the choice to build a purely Web-based application is not so simple as it was for my small pet project.

Electron is a wonderful piece of software, and building an Electron app was an enjoyable experience filled with learning. After having spent some time with it, though, I am more committed than ever to building for my platform of choice: the Web. I can’t wait to see what the future holds for PWAs and Web technologies in general.

Check out themer’s new PWA and let me know what you think.

Zen and the Art of Software Engineering

Matt Swensen — Sat, 25 Mar 2017 00:58:00 +0000

As part of my on-boarding as software engineer at Nuvi, I had the opportunity to read the classic book Zen and the Art of Motorcycle Maintenance: An Inquiry into Values by Robert M. Pirsig. While the book delves deeply into abstract philosophical concepts, there were a number of concrete principles that I felt had direct application to writing high-quality software.

The efficacy of a machine

Pirsig points out that a machine (or system or tool) really has no inherent efficacy; but rather its efficacy is measured by how satisfied we are with it. I thought this was a compelling point of view because it provides us with a useful measuring stick for our software. For example, I could build a beautiful UI that I believe to be streamlined and intuitive, but if our users have different needs, the tool is not effective for them.

This also applies to developers as they build the software. The book discusses how the true artisan is actively involved in his or her work, being one with the material (the tools, technologies, and code), and has peace of mind when producing good work. If there isn’t peace of mind, it could be a sign of subpar work or an ineffective environment.

Being stuck isn’t a bad thing

An eye-opening point brought up in the book is the idea that being mentally stuck is not a bad thing. It’s so common in day-to-day software work to run into roadblocks, and they are justifiably seen as annoyances that keep engineers from their goal to deliver software. However, these roadblocks provide opportunities for creativity—to think “laterally” as Pirsig calls it—to find new solutions and to innovate.

Gumption is psychic gasoline

Though nearly 40 years later the word “gumption”—defined as shrewd or spirited initiative and resourcefulness—seems somewhat outdated, it accurately describes the creative fuel we need to produce quality work. We should work to ensure that our proverbial tanks of gumption don’t deplete. Pirsig dedicates a significant amount of time in the book to discuss the sources and drains of gumption. These are the ones that stuck out to me:

Don’t try to regain gumption by working furiously to make up lost time. It doesn’t work for motorcycles or for software.
Sometimes making your own motorcycle parts will build gumption. In the software world, I think of this as finding and building the right abstractions in code.
Ego is a gumption trap. So is anxiety about failure.
Bad tools are also a gumption trap.

Conclusion

Creating quality work is an all-encompassing act, requiring conscious effort that is more often focused inwardly rather than on the work itself. To adapt Pirsig’s own words: “The real [software] you’re working on is the [software] of yourself.”

GitHub Pages vs. GitLab Pages

Matt Swensen — Fri, 01 Jul 2016 03:59:00 +0000

I’ve been a longtime fan of GitHub Pages. It is a wonderful option for hosting many types of sites. However, recent movements toward a more secure web and GitHub’s lack of support for HTTPS on GitHub Pages with a custom domain prompted me to start looking at other options, including GitLab Pages.

GitLab Pages has a lot of great features, many of which are similar to those of GitHub Pages (there’s no question that they are shooting for feature parity with the large incumbent). But there was one problem that was an absolute show-stopper for me: painfully slow build queues. For that reason primarily, I moved back over to GitHub Pages.

These are the primary differences I found between the two services:

	GitHub Pages	GitLab Pages
Static site generator support	Jekyll only, no plugins	Completely customizable build, therefore any SSG is supported (including plugins)
Build configuration	Optional; Jekyll sites will be built automatically, and non-Jekyll sites are published directly. Tests can be set up easily through travis-ci.org	Required; without a valid build definition GitLab Pages won’t know how to deploy your site. Setting up the build definition in `.gitlab-ci.yml` is easy and is very similar to setting up `.travis.yml` for GitHub Pages project
Build queue time	Almost always instantaneous, both on the GitHub Pages side and the Travis CI side	Excruciatingly slow; of the several builds I triggered on my site, the average wait time was a couple of hours
Support for HTTPS	Partial	Yes
CDN support	Out-of-the-box	Not provided by GitLab Pages but can be configured with free tiers of popular CDN providers

GitLab Pages has a lot of great features. And the GitLab.com service is generally fantastic, especially given that it’s free. One of my favorite parts is that they offer free build instances (they call them “runners”) as part of the GitLab.com offering (and the CI is built right into the core product—another plus). The only issue is that since the runners are free, they are overworked and the build queues can be hours long (at the time of writing, at least). While it’s still a wonderful service, the delayed builds means a feedback loop that is too slow for feature development and a production deploy time that is too unpredictable.

That slowness and the need to configure CDN myself outweighed my desire to enable TLS on my site for now. And given GitHub’s track record, I also have a sneaking suspicion that TLS support on GitHub Pages is just around the corner. In which case I’ll be extra glad I stayed.

Static Sites Are Awesome

Matt Swensen — Sat, 19 Sep 2015 21:41:00 +0000

When creating landing pages, content sites, or blogs, content management systems shouldn’t be the first tool web developers reach for. Because of the many benefits that come with the simplicity of static sites, they are not only a viable alternative, they are a more practical alternative. And with the popularity of static site generators rapidly on the rise, creating and maintaining static websites is easier than ever.

Why static sites?

For certain types of content, static websites excel over content management systems in lots of areas, including performance, decreased server maintenance, site maintainability, and capacity for version-controlled content.

Performance

In today’s world where site performance is of utmost importance, the most compelling reason to move toward static websites is the performance benefit. Content management systems make use of a database, and reading from the database to serve page content incurs a performance cost. Static sites make no use of a database—all the content is baked right into the final HTML code. The performance win comes from the fact that modern webservers (like Apache or nginx) are heavily optimized to serve such static files extremely quickly.

In a nutshell, with a CMS, the burden of constructing a web page is placed on the server, at the time the page is requested. With a static site, that burden is moved to when the site is assembled before it is deployed. Many programmers will agree that, from a user experience perspective, it is better to have as much processing occur as possible at compile time rather than at run time. This is the approach that static site generators take.

Server maintenance

Another big advantage for static sites is the reduced amount of required server maintenance. With a typical CMS like Wordpress or Drupal, sysadmins will need to install and configure a scripting language runtime (like PHP), a webserver (like Apache), and a database server (like MySQL). Security patches and periodic software updates will also need to be run for each of these. With static sites, only a webserver to serve the static files is required. (It is also arguable that security of the server is improved with this simpler setup.)

Maintainability

Some scoff at the idea of building a static website because it sounds to the unfamiliar ear like writing static webpages individually by hand, which of course is a cumbersome task that content management systems were designed to overcome. However, the “static” part is simply the compile target. Static site generators allow web developers to build sites with familiar programming constructs, like DRY, logic and flow control, templating, etc.

Version control

Without the dependency on a database system, it is also much easier to keep the site’s content under revision control, depending on how the developer has chosen to deploy and publish to the site. This also means that content is more easily synced with code between different environments (i.e., development and production).

Concerns with static sites

The obvious concern with static sites is that they cannot serve dynamic content. However, there are ways to add common dynamic elements to the site without the need of a full-blown CMS. For example, the popular service Disqus provides a fully featured commenting system for a page, simply by adding a small JavaScript snippet. There are also services like Firebase that allow client-side applications to communicate directly with a database.

There are, of course, many cases where a static site is inappropriate. Any service where users log in to access their content is a common example. In these cases, one might consider using a static site for blogs or landing pages and minimize the the scope of the backend code to the core of the application itself.

Deploying and publishing content to static sites

Static sites can be deployed in a variety of ways. One of the simplest ways is to take the compiled output of the static site generator and drop it into an Amazon S3 bucket. As S3 (and similar services) are preconfigured to serve static files, there is no server setup required. Take one more step to put that bucket behind a service like Amazon CloudFront, and the site’s files are now served over CDN, with minimal effort!

Another noteworthy mechanism that works great for open-source sites is GitHub Pages, a free service offered by GitHub. GitHub Pages integrates automatically with one of the most popular static site generators, Jekyll, and so deploying and pushing updates to a site is as simple as git push. GitHub Pages are also served via CDN.

There are also great workflows that allow non-technical people to publish to a static site. For example, Contentful is a content management service that has fast, read-only APIs for retrieving content. Non-tech writers can log into Contentful to create the content, and the static site generator could be configured to receive updates from the API, compile the site, and deploy the changes automatically. A similar workflow based on syncing a Dropbox folder of markdown files with a static site generator could also work well. With the flexibility of static sites, teams can find a publishing paradigm that works well for them.

Conclusion

Static websites are a practical tool in a web developer’s tool belt. The simplicity of a static website can be a welcome replacement for complex content management systems.

Blissful Static Site Development with Jekyll, BrowserSync, and tmux

Matt Swensen — Sat, 20 Jun 2015 05:44:34 +0000

I was recently listening to the Shop Talk Show podcast where Chris Coyier shared a submission from a listener that outlined the development and deployment setup for her personal website. It involved using Dropbox to sync blog posts to a static site generator on her server and sounded pretty slick. I thought I would add to the conversation by sharing my setup for developing this site. These are the technologies that are used in concert:

GitHub Pages
Jekyll
BrowserSync
tmux
iTerm2

Overview

Here is a visual overview of the development setup, created with Lucidchart.

Further explanation of each component is below.

GitHub Pages

GitHub Pages is just about the easiest way to deploy a basic website these days. If you have a GitHub account (free), the process is simple:

Create a repository with a special name: <your username>.github.io (for example, mine is mjswensen.github.io for this website).
Add your website files (index.html, etc.) to the repository.
Commit and push. Within a few minutes (usually just seconds), your site will be live at http://<your username>.github.io/.

If you want a custom domain instead of the default, it’s easy to set that up, too.

The best part? It’s fast. GitHub distributes the content on GitHub Pages via CDN out of the box, so visitors to your website download your content quickly no matter where they are. One of my recent posts happened to be trending on Hacker News one morning and that page had about 7,500 views over the course of a few hours; the site was still responsive as ever during that time, despite the drastically increased load.

And it’s free. You really can’t beat that.

Jekyll

Jekyll is a static site generator, which—as the name suggests—makes creating static HTML sites a breeze. Jekyll is one of the most popular static site generators. This is due in part to the fact that it integrates with GitHub Pages. If you build your site with Jekyll, GitHub will detect that your site is a Jekyll site and will compile it for you when you push (as outlined above). So for development, one can install Jekyll and build the site locally, push and have GitHub build the live site, and not have to worry about keeping the compiled site files in source control or uploading them via FTP.

There are a lot of advantages to moving away from content management systems and toward static sites where possible. Increased site performance is the primary one (content management systems usually involve reading from a database, whereas static sites are simply files that can be quickly served from webservers like nginx that have been heavily optimized for that task). It’s also nice to keep content under version control rather than trying to sync databases across different environments.

(Sidenote: Among Jekyll’s many features, one of the most convenient is its native support for Sass. Sass makes writing CSS painless and fun, and the fact that Jekyll will compile the Sass sources automatically is a big plus.)

BrowserSync

While Jekyll by default has a built-in server enabled for testing as you develop, BrowserSync has some incredible features for developing for the modern web:

Live reloading when sources change
Synced page viewing and scrolling across multiple devices or browsers simultaneously
Great debugging features
Automatically go to local site in new Chrome tab on launch

So, while Jekyll watches my source files for changes and generates the site automatically, BrowserSync watches Jekyll’s output directory and pushes changes to the browser automatically. It makes for a great development workflow!

tmux

While starting Jekyll and BrowserSync is pretty simple via the command line, it is the same two commands and requires two terminal windows each time I want to write a new blog post or develop the site. This is where tmux comes in. tmux is a terminal multiplexer, which means that it allows for text-based windows and split panes within a single terminal window, among many other fantastic features.

The best part about tmux is that it is easily scriptable. So for developing this site, I’ve written a Bash script that sets up my tmux session, configures the windows and panes as I like them, and starts Jekyll and BrowserSync in separate panes. The script is pretty simple:

#!/bin/bash

SESSION="mjswensen"
PROJECT_PATH="/Users/mjswensen/Projects/other/mjswensen.github.io"
OUTPUT_PATH="$PROJECT_PATH/_site"

tmux new-session -d -s $SESSION -n "site" -c $PROJECT_PATH

tmux split-window -h -t $SESSION:0 -c $PROJECT_PATH
tmux split-window -v -t $SESSION:0.1 -c $OUTPUT_PATH

tmux send-keys -t $SESSION:0.0 "git status" enter
tmux send-keys -t $SESSION:0.1 "jekyll build --watch" enter
tmux send-keys -t $SESSION:0.2 "browser-sync start --server --files \"*.css, *.html\"" enter

tmux select-pane -t $SESSION:0.0

tmux -CC attach-session -t $SESSION

iTerm2

Finally, I use iTerm2 in place of the standard Terminal.app for Mac. iTerm2 has some amazing features and is a popular choice for terminal emulation among Mac users. The reason I like iTerm2 so much is for its deep tmux integrations. While tmux brings some great features to the terminal, certain common tasks—like switching between windows or copying text, or scrolling—involve cumbersome keyboard commands and workarounds. iTerm2, when attached to a tmux session with the special -CC command-line flag (as seen in the script above), converts tmux windows and panes to native iTerm2 tabs and panes. It sounds simple, but it really makes all the difference. It really is a great solution for tmux fans.

In the end, this is what the iTerm2 window looks like:

Thanks for reading!