Forem: AsyncBanana

How to use ESM on the web and in Node.js

AsyncBanana — Sat, 03 Sep 2022 16:19:28 +0000

ESM (or ECMAScript Modules) is a modern module format with many advantages over previous formats like CommonJS. It is supported natively in most web browsers, is very fast, and opens up new opportunities for tree shaking, among other features. However, it is a major shift from CommonJS/AMD/UMD, and it can be hard to use if you are used to one of those module formats.

What is ESM?

ECMAScript Modules is a module format created as part of the ECMAScript (read: JavaScript) standard. It was standardized in the ES6 ECMAScript version, which you might know for adding many syntax features. ES Modules aims to solve a significant problem in JavaScript: There is no built-in way to share code between scripts. You might be familiar with importing things using require(). That is using CommonJS, which is only supported in some bundlers and Node.js. Additionally, there are some problems with CommonJS, like its synchronous nature. ESM aims to solve all of these issues while making one module format universal. Today, Chrome, Safari, and Firefox fully support ESM, so you should not have any problem running it in modern browsers. Additionally, Node v12+ supports ESM, although you have to tell it you are using ESM rather than CommonJS. We will talk more about how to how to do this later on.

ESM Syntax

The syntax used to import and export modules is a little more complicated than in other module systems like CommonJS, but it still is fairly easy to pick up. The most basic example is this:

// script.js
import { example } from "./library.js";
example();

// library.js
export const example = function () {
    console.log("hello world");
};

Here we import a function called example from library.js. Notice the brackets around example. That shows that we are only importing example. So if we wanted to import multiple things we could do this:

import { example, example2 } from "./library.js";

As you can see, we put both example and example2 in between the brackets to import both of the exported variables. Now, what if there was only one thing exported? Using export default, we can remove the brackets.

// script.js
import defaultExample from "./library.js";
defaultExample();

// library.js
export default function () {
    console.log("hello world");
}

Default exports also allow us to name the imported value whatever we want. We can also do this with named exports, but it is a little more complicated:

import { example as newExampleName } from "./library.js";
newExampleName();

Another thing you might want to do is dynamically import something. Dynamic imports work a lot like require() in CommonJS, except that they run asynchronously:

import("./library.js").then((library) => {
    library.example();
});

Finally, you might want to import all functions in a module, which you can do using import * as:

// script.js
import * as library from "./library.js";
library.example();
library.example2();

// library.js
export const example = function () {
    console.log("hello world");
};
export const example2 = function () {
    console.log("hello world again");
};

Using ESM with Node

Make sure you are using Node v12 or higher

Per-file

The simplest way to use ESM in Node.js is to just replace .js with .mjs as the file extension for the script in which you want to use ESM. The new file extension tells Node that it should treat the file as ESM rather than CJS. This also works the other way. You can use .cjs to designate a file as CommonJS if the default is ESM (more on that in the next section).

Package-wide

Often you want a whole package to be ESM by default. To do this, you must add "type": "module" to your package.json. Adding "type": "module" means files will be treated as ESM files unless they have a .cjs extension. However, dependencies can still use CommonJS.

Importing CJS Modules From ESM

To ease the transition to ESM, Node offers the ability to load CommonJS modules from ESM. You can retrieve the module.exports object by importing it as a default export. For example:

// script.mjs
import example from "example-package";
example.helloworld();

// example-package index.cjs
module.exports = {
    helloworld: function () {
        console.log("hello world");
    },
};

This feature is very helpful as it allows you to use NPM packages built with CommonJS.

Importing ES Modules from CJS

Unfortunately, Node does not support importing ES Modules from CommonJS modules. Luckily, many compilers allow you to convert ESM to CommonJS, allowing you to write a library that offers a great experience for both groups. TypeScript is the most notable in this category. You can write code using ES Modules and target both ESM and CJS.

Migrating from CJS To ESM

There are tools to help make migrating code from CommonJS to ES Modules easy. One of the most popular tools is cjstoesm, a command line tool that automatically transforms CommonJS code in Node to its ESM equivalent. Almost all CommonJS code is transformed. However, there are some things that are not transformed. The most notable is the __dirname. __dirname is not part of Node.js, but it is one thing that Node does not suppport in "ESM mode". Luckily, there are replacements. A simple way to polyfill __dirname is to do this:

const __dirname = new URL(".", import.meta.url).pathname;

This snippet uses import.meta.url, which is available in all ESM contexts.

Another thing that is harder to migrate is conditional imports. You can use dynamic importing to replace running require() dynamically, but problems arise with that due to how import() is asynchronous and require() is not. Luckily, there is a simple solution to this. If you are using Node.js v14.8 or later, you can use top-level await to make import() synchronous. For example,

// CommonJS
const module = boolean ? require("module1") : require("module2");

// ES Modules
const module = await (boolean ? import("module1") : import("module2"));

With these tips, you should not have much trouble at all converting CommonJS code to ES Modules.

Using ESM on the Web

Native ESM

The simplest way to use ESM on the web is by utilizing the native support for it. For about over 95% of users (Caniuse), ESM is supported without polyfills. To load a script with ESM, you need to add type="module" in the script tag.

<script src="./esmscript.js" type="module">

Then, all modules you import from that script will also load as ES modules.

To create a backup script for browsers that do not support ES Modules, you can use the nomodule attribute. nomodule tells any browser that supports ES Modules not to load the script, so only browsers without ESM support will load it.

Bundlers

While just using the browser's native ESM support is simple to start with, you will be missing out on a lot of features and optimizations, like tree shaking, support for CommonJS dependencies or automatic fallback generation. Luckily, many bundlers support ESM by default. The most notable modern ESM bundlers for the web is Vite. Vite is a bundler created by the Vue team that is extremely fast and feature-rich. By default, Vite minifies and optimizes your code, and you can do a lot more with Vite/Rollup plugins. To create a Vite project, you have to run npm create vite@latest. This will help you set up a project with Vite using ES Modules. If you want legacy browser support using nomodule, you can use the plugin @vitejs/plugin-legacy. Another feature that Vite, along with most other bundlers, has is support for dependencies that use CommonJS. Obviously, CommonJS requires transformation and therefore can add some code weight, but it is better than nothing, and you can still use ESM along with it.

Conclusion

Now you are familiar with ES Modules' syntax and how to implement it on the web and in Node.js. Make sure to sign up for the newsletter or RSS here. I hope this article has been helpful for you, and thanks for reading.

React vs Svelte: Which is better in 2022?

AsyncBanana — Tue, 30 Aug 2022 23:58:37 +0000

Imagine you are doomscrolling through Facebook, checking out the news on the New York Times' website, or listening to music on Spotify. As it turns out, all of these websites use either React or Svelte, along with many other popular websites. As you can see, React and Svelte are both very prevalent libraries (or frameworks, depending on how you define each). For many developers trying to plan their next website, they have to ask: "What should I use to build my app's interface?" This article aims to answer that question for React and Svelte. With that, let's get started on the comparison.

Learning Curve

React

Let's start with React. React can take some time to adjust to, although it is usually not very hard to learn. The hardest part of React to learn is how it uses a declarative paradigm, unlike JavaScript, which is generally imperative. The difference is essentially this: with imperative JavaScript, you manipulate the DOM to represent the data using your own code, whereas with React, you simply update the data and tell React what part of the data goes where, and React will automatically update the DOM. Another more general way to explain this is with imperative coding you specify how to update the data whereas with declarative coding you only specify the data.

There are some other things that take getting used to, but they are generally easy to learn. First, instead of HTML, you have to use JSX. JSX is like JavaScript and HTML combined, and it is what allows you to represent your data using declarative markup. For example, this would create a heading that contains whatever the JavaScript string date is set to:

<h1>{date}</h1>

As you can see, it is HTML enhanced using JavaScript.

Finally, you will have to take some time to learn all of React's hooks (useState(), useEffect(), etc). However, this should not take long.

Svelte

Svelte can take a little longer to learn. First, you still have to get used to writing declarative code. Svelte is very similar to React in that way, as they both are declarative (most other modern UI libraries also do this, including Vue and Angular). However, there are some differences in syntax that can make Svelte harder to learn than React. Unlike React, which uses JSX, Svelte has its own syntax for components. Instead of being defined inside functions (or classes), Svelte each have their own .svelte file. This component design is known as SFC, or single file components. Using SFC has the advantage of allowing for more syntax flexibility, which Svelte uses. The syntax flexibility helps Svelte in some other areas, but it also makes learning Svelte harder. To show you, here is a sample Svelte component:

<script>
    const example = "123";
</script>
<h1>{test}</h1>

As you can see, the <script> tag holds all of the component's JavaScript. That includes data, imports, and all of the logic. However, you still do need things like conditionals inside the markup. Unlike JSX, where you just embed a JavaScript function, Svelte has its own syntax for conditionals and loops. That is where things can get a little harder to learn. For example, if you are trying to conditionally add markup, you will have to use #{if boolean}.

{#if boolean}
<h1>boolean is true</h1>
{/if}

You need to do something similar for loops. Additionally, Svelte is more feature-rich, which is helpful but increases the time necessary to learn all of the features. For example, Svelte includes support for tweening values. One place where Svelte is better in terms of learning its state, as Svelte does not require you to use usestate(). Instead, you can just reassign a variable in the component script and the component will automatically update with the new variable value.

Summary

Both libraries require you to learn how to write declarative code, but React takes first here because of how it utilizes native JavaScript more.

Winner: React

Syntax Brevity

React

React's syntax is not super verbose, but it is not concise either. If you are using class components, it will be a lot more verbose. However, we will focus on using hooks and function components here. The biggest elements that contribute to its code size beyond the basic HTML is the state management (you need to use useState() and setState()) as well as how conditionals and loops work. However, React is still less verbose than some frameworks, as it cuts out most unnecessary boilerplate. For example, here we have a simple to-do list component. This component includes adding to-do items using a text input with the enter key or a button and then removing to-do items using the X button next to them.

function TodoList() {
    const [todos, setTodos] = useState([]);
    const [newTodo, setNewTodo] = useState("");
    return (
        <div>
            <ol>
                {todos.map((todo) => (
                    <li key={todo}>
                        {todo}
                        <button onClick={() => setTodos(todos.filter((td) => td !== todo))}>
                            X
                        </button>
                    </li>
                ))}
            </ol>
            <form
                onSubmit={(e) => {
                    setTodos(todos.concat([newTodo]));
                    setNewTodo("");
                    e.preventDefault();
                }}
            >
                <input
                    type="text"
                    value={newTodo}
                    onChange={(e) => {
                        setNewTodo(e.target.value);
                    }}
                />
                <button type="submit">Add Todo</button>
            </form>
        </div>
    );
}

As you can see, it is 34 lines long. We will create a functionally identical to-do list example in Svelte to compare.

Svelte

Many of the same reasons Svelte lost the learning curve section give it an advantage here. The conditionals and loops are much more concise, and the state management is much simpler. Additionally, Svelte supports two-way bindings, meaning that the input value can be bound to newTodo more simply. Because of these features, Svelte takes the lead for its to-do list component at only 25 lines.

<script>
    let todos = ["test","test2"];
    let newTodo = ""
</script>

<ol>
    {#each todos as todo,index}
        <li>
            {todo}
            <button on:click={()=>todos = todos.filter((td)=> td !== todo)}>
                X
            </button>
        </li>
    {/each}
</ol>
<form on:submit={(e)=>{
            todos.push(newTodo)
            todos = todos
            newTodo = ""
            e.preventDefault()
        }}>
    <input type="text" bind:value={newTodo}/>
    <button type="submit">
        Add Todo
    </button>
</form>

Obviously, this is not a huge difference, but it can add up when you are building a large app.

Summary

Svelte's unique features, like using {#if} for conditionals allow it to take the lead here. React is concise, but it still constrained by having to be implemented in plain JavaScript (aside from compiling JSX). The Svelte to-do list component was only 25 lines, compared to 34 lines for the same component implemented in React.

Winner: Svelte

Performance

React

React is not the most optimized library for building interfaces. It is extremely heavy, at 42kb minified and gzipped, and can be slow when rendering. However, there are some solutions to this. The primary solution is Preact, which is a React-compatible library that is only 4kb minified and gzipped. Preact also includes features like the ability to use native HTML attributes in JSX instead of the JSX version. There are also libraries like Solid and Inferno which vary in terms of React compatibility and performance but are good alternatives to consider.

Svelte

Svelte is very unique in that instead of providing a runtime API that you directly interface with, it runs your Svelte code through a compiler. While React technically also does this, all React does is transform JSX tags into JSX function calls. In contrast, Svelte code is completely transformed in the compilation process. This means that your website is usually light and fast since it avoids the overhead of high-level functions in a runtime library. However, with large apps, your compiled code can grow larger, although with code splitting this is usually not a big problem.

Summary

While you can make React apps faster by using a tool like Preact, that is not built-in, so Svelte wins this category. Svelte's use of an optimizing compiler that removes the need for a large runtime makes Svelte extremely fast.

Winner: Svelte

Ecosystem

React

React has the largest ecosystem out of any UI library. In fact, when you search for react on NPM, there are more than 200k packages that come up. This includes everything from component libraries to state containers. Additionally, Meta created and has developed its own ecosystem around React.

Svelte

Svelte has a much smaller but quickly growing ecosystem. Currently, searching Svelte brings up about 5,000 packages. However, one thing to note is that Svelte includes tools like state management, so many ecosystem tools are unnecessary.

Summary

Ultimately, React wins by a large margin in this category. While Svelte's ecosystem is growing quickly, it is still nowhere near React.

Winner: React

Conclusion

As you can see, it is tied 2-2, so you could choose either. If you are more of a beginner and want something that is easier to learn and has a larger ecosystem, choose React. Otherwise, if you want something that is fast to build with and runs fast, choose Svelte. Both are great choices. Thanks for reading, and make sure to sign up for the mailing list here.

10 ways to speed up JavaScript loading

AsyncBanana — Thu, 18 Aug 2022 19:02:51 +0000

In many modern websites, there is a lot of JavaScript. In fact, according to the HTTP Archive, the average desktop page had over 500 kilobytes of JavaScript. The problem is that JavaScript takes time both to download and parse, which makes websites load much slower and therefore affects retention, as users will leave if a website takes too long to load. Luckily, there are easy ways to reduce the amount of JavaScript you are loading on your website and make the JavaScript you are loading load faster, which we will go over today.

How to make your JavaScript load faster

1. Lazy loading

Not all JavaScript requires instant loading when a user first visits a website. For example, you could have an email signup prompt at the bottom of a page. Unless the user scrolls down to there, it is not necessary to load. Because of this, many web developers use a technique called lazy loading. Instead of loading all of the JavaScript at once, lazy loading offloads some JavaScript. There are multiple different forms of lazy loading. For example, for elements that do not need to be immediately active but still should be active fairly quickly, you could wait until the page is idle using requestIdleCallback(). Or, as we have already talked about, if there is an interactive element further down the page, you could wait until the user scrolls down to that element using intersectionObserver. Now, the question remains: How do you actually load the code later on? One of the best ways to do this is dynamic import() which is part of ECMAScript Modules (ESM). Dynamic importing helps you load a script at any time by running an import() function. For example, this would load a script once the browser was idle:

// Note: This must be run in an ESM script. You can use <script type="module"> instead of <script> to make this ESM
requestIdleCallback(() => {
    import("/script.mjs");
});

Another option is simply using the async or defer attribute on scripts. This technique is much less flexible, but it is an easy way to make a script wait until the DOM is assembled.

2. Minification

Minification is an easy way to improve performance a lot. It is usually done using automated minfiers like Terser or ESBuild. These tools essentially shrink your code by removing spacing, long variable names, and other things that are helpful in development but increase script size in production. For example, let's say I minified this code with Terser:

window.addEventListener("DOMContentLoaded", (event) => {
    const images = document.getElementsByTagName("img");
    for (const image of images) {
        image.width = 50;
        image.height = 50;
    }
});

The output would be:

window.addEventListener("DOMContentLoaded", (e) => {
    const t = document.getElementsByTagName("img");
    for (const e of t) (e.width = 50), (e.height = 50);
});

That is a 67-byte reduction, from 203 to 136 bytes! That little would not make a noticeable difference, but for larger scripts, minification can make quite an impact.

3. Bundling

Script size is not the only thing that matters. The request count does too, as each request adds overhead. Basically, you want to keep the number of scripts you have to a minimum. However, splitting code is generally a code practice for keeping code clean. Luckily, like minifiers, there are automated tools to solve this. These are called bundlers. Bundlers analyze your code, look at what scripts are importing each other, and figure out how to combine them. The most well-known bundlers are Webpack, Rollup, and Vite.

Another advantage of using a bundler is that most bundlers also function as build tools, making it easy to do things like minification and TypeScript compilation. For more information on bundlers, check out my article on them.

4. Code Splitting

You might be surprised that this is right after bundling. "I bundle my code just to split it back up?" Not necessarily. In fact, this is a feature of bundlers. While reducing request count is great, you do not want the user to have to load all of the code on your website at once. You could solve this by creating a new full bundle for each page, but this would negate some of the benefits of caching (which we will talk about later). To solve this, we have code splitting. Code splitting combines the advantages of bundling and lazy loading while ensuring that any unnecessary code for the page is not loaded. Bundlers perform code splitting by analyzing a map of imports and figuring out what scripts are required to be in their own bundle. Most bundlers do this automatically, although it can be helpful to write code that is more easily analyzed (e.g. using static imports where possible).

5. Tree Shaking

Another common feature of bundlers is tree shaking. You might import a part of a library but not need the rest. However, if you do this without tree shaking, end users will end up loading the whole library, which can add a lot of JavaScript. Tree shaking solves this; Bundlers that support tree shaking automatically remove unused parts of libraries, heavily reducing the code you import. For example, take a look at Lodash (lodash-es to be specific), a large JavaScript utility library. The entire module is almost 100 kilobytes minified, but if you just used the intersect() function, you would only import 2.7 kilobytes of code. Now, in Lodash's case, there are packages that only contain individual functions, but these can be more annoying to use if you are using a lot of functions, and many libraries do not do this.

6. ECMAScript Modules

For lots of the previously mentioned features to work, ECMAScript Modules (ESM) is very helpful or even essential. ESM is a module spec developed to standardize how to share code between different files. Before ESM, there were conflicting standards like CommonJS and UMD, which were not even natively supported by browsers. ESM unified these standards and offered syntax that helped with features like tree shaking (notice how I said to use lodash-es over standard lodash in the previous). Additionally, because ESM is natively supported in browsers, you do not need a heavy polyfill to be able to use ESM.

// ESM
import { something } from "test";
export const something = "test";
// CJS
const something = require("test").something;
module.exports.something = "test";

7. CDN

Hosting static files on your own server is pointless. Using a full server for actual server-side computation increases your cost, development complexity, and website loading time. Instead, CDNs are better solutions. A CDN (Content Delivery Network) is a network of servers designed for serving static files quickly and cheaply. Instead of serving from just one server, you can serve files from tens or hundreds of servers (depending on the CDN), which reduces latency as the servers are closer to users. Additionally, CDNs often configure things like caching and compression for you, saving time. Some popular examples of CDNs are Cloudflare CDN and Amazon CloudFront.

8. Caching

While first load experience is essential, you also need to think about performance for repeat visitors of your website. One way to make repeat visits significantly faster is through caching. Browser caching works by saving a copy of website resources and using that copy instead of downloading it again. This means that repeat visits feel almost instantaneous. To set up caching, you need to set the Cache-Control header in the response for the resource you are caching. If you are using a CDN, this is likely automatically configured for you. If you are not, it is simple enough to set up.

9. Compression

I am sure you have come across .zip or .tag.gz files. You might also know that along with transforming a directory into a file, they also reduce the size of the files. The size reduction is done using compression. Compression works by running an algorithm to find ways to make a file smaller by shrinking repeated statements and doing some other things depending on the algorithm used. There are many popular compression algorithms, like deflate, lz4, Brotli, and Zstandard. The compression that zip and gzipped files use is deflate.

Implementing compression can be a little hard to do, but there are simple ways to do it. The simplest way is to use a CDN that automatically compresses files, as we talked about at #7. Another simple way to implement compression is to run a file server that supports compression. However, if you cannot do either of those, there are some other solutions. Lots of build tools/bundlers have plugins that automatically generate compressed forms of files, which you can serve to have the browser automatically decompress it. The browser tells you what compression algorithms it supports using the Accept-Encoding header, and your server tells the browser what compression algorithm is used in the response using the Content-Encoding header. For more information, check out MDN's article on HTTP Compression.

10. Lighthouse & Automated Performance Auditing

Lighthouse is a tool that helps you automatically audit your website's performance, along with a few other categories like SEO and Accessibility. It can be extremely helpful for finding performance issues and providing an easy path to solving them. If you have Chrome or another Chromium-based browser, Lighthouse should be available by default. If you are using another browser, you could download the extension or use PageSpeed Insights. PageSpeed Insights also offers data from real users, which can be helpful if you want to see what users are actually experiencing.

Conclusion

With these tips, you should achieve large performance gains in your website, translating to more retention and conversion. Thanks for reading!

What is Bun, and does it live up to the hype?

AsyncBanana — Wed, 17 Aug 2022 00:41:49 +0000

When you think of a bun, you probably think of bread. However, now, there is another Bun. Bun is a new JavaScript runtime that claims to offer more features and performance than Node.js and Deno. It was created by Jarred Sumner and only was released publicly a little more than a month ago.
Since then, it has quickly managed to gain 30,000 stars. In this article, we will investigate what bun is and whether Bun lives up to its hype.

Warning: Bun is very experimental. Many features do not work. For information on unfinished features, check out Bun's Roadmap

Why is Bun supposed to be better than Node.js or Deno.

Bun is a runtime designed around a few central principles:

First, Bun is designed to start and run faster than Node.js and Deno. It claims that it is significantly faster than both server-side JavaScript runtimes through its use of JavaScriptCore rather than V8, its use of Zig for API writing, and lots of tuning and benchmarking.

Quick guide to JavaScript engines: V8 is the engine created by Google for Chrome and JavaScriptCore is the engine created by Apple for Safari. Node.js and Deno both use V8, whereas Bun uses JavaScriptCore.

According to benchmarks done by the creators of Bun, Bun can be over 2x the speed of Node.js and Deno in I/O intensive operations like HTTP servers and SQL. These claims might sound ludicrous. After all, it is all JavaScript, and V8 is pretty optimized. However, notice I said I/O intensive. That means most of the execution time is spent in the runtime's API rather than the actual JavaScript engine. Since Bun theoretically has a much faster I/O implementation than Node.js or Deno, Bun could be much faster in these cases. Later on, we will run our own benchmarks to see how much more performant the I/O implementation and JavaScript engine is.

Second, Bun is "batteries included." I sort of lied when I said Bun was a JavaScript runtime. It is much more than just that. Similar to Deno, it includes a bundler, TypeScript transpiler, and even a test runner. Additionally, Bun includes a CSS-in-JS tool, template builder, environment variable loader, and more. This feature is very interesting, as performance-optimized and expansive usually do not go together in developer tools. However, Bun managed to do this because they do not have the same code weight constraint as web libraries do. Theoretically, while another feature built into Bun increases the installation size, it should not impact performance. Additionally, the tools built into Bun are designed to run quicker than most alternatives. Of course, you still might prefer the choice. Ultimately, it is just your preference (of course, you can still use other tools).

Finally, Bun is designed to be Node-compatible. Bun includes full support for CommonJS (require() is transformed into import.meta.require() in Node.js modules), Node-API, and some Node.js modules. This feature is extremely helpful, as it allows you to access the vast ecosystems of Node.js. However, there are still many things not implemented, as Bun is still early software and Node's API is extensive, so we will see how well it actually works later on.

Now, we see how Bun is supposed to improve over existing server-side JavaScript runtimes. Let's look at how it stacks up in its current form.

Is Bun Fulfilling its promises?

Performance

On the website, Bun lists some benchmark results. Now, we will check out the benchmark code and run it ourselves. We will be running the FFI, Log, gzip, Async, and SQLite benchmarks.

Benchmark Explanation

First, let's look at the FFI benchmark. The FFI benchmark is pretty simple. The Bun, Node, and Deno program all call a Rust program through FFI, which exposes a few functions: An empty function, a long string, and a hash.

Next, there is the Log benchmark. As the name implies, the log benchmark focuses on the performance of console.log(). First, the programs log "hello", and then they log { hello: "object"}. The code across all of the runtimes is identical.

Now, let's check out the gzip benchmark. The gzip benchmark benchmarks roundtrip, compressing, and decompressing "Hello World!" repeated 1,000 times. The Node.js implementation used its built-in zlib module, Deno used the web standard CompressionStream API, and Bun used its own built-in gzip compression. This test is good because it shows the differences in each implementation of gzip compression/decompression, rather than using the same library for each.

Now, let's take a look at the async benchmark. The code in this test is identical across runtimes. They benchmark a synchronous empty function, an asynchronous empty function, and an asynchronous function running await 1. It seems odd that they do not do more, but it still seems ok.

Finally, we have the SQLite benchmark. The benchmark performs a few queries on the Northwind SQLite database (which is the standard "Hello World" for SQL). Node uses better-sqlite3, Deno uses deno-sqlite, and Bun uses its built-in SQLite implementation. This benchmark seems like it is just trying to show that Bun's Zig SQLite implementation is fast, although it is a little unfair to Deno as deno-sqlite uses WASM, which often brings a performance disadvantage and therefore means that there can be faster Deno SQLite implementations.

Whew! That was a lot. Now we can get on to the interesting part: the actual results. For context, I am running Linux 5.18 on a Ryzen 6900HS with 16 Gigabytes of DDR5 memory, and the speed is measured by average time per run.

Benchmark Results

FFI

Test	Bun	Node.js	Deno
Noop	4.93 ns	11.51 ns	3.91 ns 🏆
Hash	66.93 ns	177.48 ns	59.89 ns 🏆
String	190.93 ns	51.97 ns 🏆	127.01 ns

In this test, Bun was a bit of a mixed bag. It did about as well as Node but generally worse than Deno. The results were not bad, but they were not such a great start for something claiming significant performance advantages. However, part of it might be because I am testing this on a completely different CPU and architecture than the creator of Bun, and therefore what I am using might not be optimized yet.

Log

Test	Bun	Node.js	Deno
console.log('hello')	642.26 ns 🏆	1,610 ns	3,960 ns
console.log({ hello: 'object'})	893.41 ns 🏆	2,700 ns	6,750 ns

Now we are seeing some speed! Bun won both tests by a large margin. I assume this is because of Bun's static optimization, which is great to see.

gzip

Test	Bun	Node.js	Deno
roundtrip - "Hello World!".repeat(9999))	260.85 µs 🏆	478.23 µs	476.81 µs
gzipSync("Hello World!".repeat(9999)))	201.1 µs 🏆	397.02 µs	281.01 µs
gunzipSync("Hello World!".repeat(9999)))	62.85 µs 🏆	70.33 µs	152.52 µs

Once again, Bun wins all benchmarks. I suspect this is because Bun's gzip implementation is optimized and written in Zig.

Async

Test	Bun	Node.js	Deno
Sync	225.34 ps	222.76 ps 🏆	228.55 ps
Async	162.28 ns	58.62 ns 🏆	59.4 ns
Await 1	274.72 ns	110.44 ns	101.38 ns 🏆

Bun did not do so well on this benchmark and got last in two of the three benchmarks by a large margin, probably because of some element of JavaScriptCore.

SQLite

Test	Bun	Node.js	Deno
SELECT * FROM "Order"	18.74 ms 🏆	52.49 ms	135.07 ms
SELECT * FROM "Product"	46.85 µs 🏆	160.91 µs	232.57 µs
SELECT * FROM "OrderDetail"	213.36 ms 🏆	1.05 s	663.34 ms

This was an excellent final benchmark for Bun. Bun beat both Node and Deno by a large margin on every benchmark, showing just how fast Bun's Zig SQLite implementation is.

Summary

Overall, I was somewhat disappointed by these results. Given the benchmarks Bun shows on its website, I would have expected it to be significantly faster than Node.js and Deno in most or all benchmarks. But, of course, the creators of Bun would focus on the most positive benchmarks rather than showing them indiscriminately. Nonetheless, Bun performed pretty well, especially given it is still in a very early stage and more optimizations are planned in the future.

Extra Features

One of Bun's main selling points is the extra features. We will review some of the most significant additional features and see how well they work.

Task Runner

Bun's task runner is like the task runner included in Node, except it is noticeably faster. In fact, it is even possible to use Bun's task manager in a Node project and take advantage of how fast it is. While a task runner is an expected essential tool (both Node/NPM and Deno include one by default), I decided to include it here because it is so much faster than the ones in NPM and Deno. Additionally, Bun's task manager can run almost any script without using the run subcommand, whereas npm can only do that for a few select script names.

Package Manager

Once again, a package manager is expected, but Bun's package manager exceeds expectations because of its performance. In fact, Bun should be even faster than PNPM or Yarn. There are three reasons for that. First, Bun uses symlinks. That means that packages for each project are linked to a central location, so modules used in another project do not need to be redownloaded. Second, Bun uses a binary lockfile. Binary files are usually serialized and deserialized faster, which decreases the overall time used by the package manager. Finally, Bun's package manager is written in Zig. As we have already discussed, Zig is a fast language, much faster than JavaScript, which most other JavaScript package managers use.

Transpiler

Bun's transpiler is a great feature, which transpiles TypeScript, JSX, and even vanilla JavaScript. You might have been suprised to hear the last part. After all, why would you need to transpile plain JavaScript? Here is where one of Bun's performance-improving features comes in. Bun automatically optimizes JavaScript ahead of time. Most of this feature is still in development, but the developers plan to add an optimized binary format for JavaScript in the future. These optimizations would have very interesting implications for edge apps and other short-lived processes. However, we can't talk about it much yet because most of it is still in development.

The other transpilers are pretty good. The TypeScript transpiler is fast, although it does not have type checking currently, instead just stripping types (you are expected to use your text editor/IDE to type check). The JSX transpiler also works pretty well, although for many cases, it would not work well due to the lack of @jsxpragma support, meaning you can only use React, not Preact or any other JSX library/framework. I was able to set up a react app by simply running bun create react, which was pretty nice (no react-scripts used!). This also shows the CSS importing, as one of the JSX files imports CSS, which works seamlessly.

File loaders

A helpful feature of Bun is how it supports many filetypes by default. For example, you can load a YAML or TOML file by simply importing it. In my testing, this functioned quite well, although bun-types did not seem to signal to TypeScript that .toml files were supported, which made my editor flag the .toml import. You could likely fix this with a quick type declaration file, and bun-types should eventually fix this.

Additionally, environment variables from .env files automatically. Creating a .env file in the project directory will automatically load the variables into process.env and Bun.env. In my testing, Bun successfully found the .env file and loaded the variables in process.env.

Summary

Bun has a very good feature set. There are some rough edges and unfinished features, but it can still be very helpful for quickly creating a project.

Node.js compatibility

Now let's see how well Bun can work with Node.js modules currently. Out of all of them, I expect this element to be the most unfinished, but it will still be interesting to see how Bun fares.

Next.js

This one is an easy one to find out, because Bun supports Next.js by default. However, the support currently has some issues. First, you need to rerun bun --use-next whenever you import a new module. This issue could become annoying, although the developers of Bun are working to create an automatic solution for this. Second, Bun does not currently support features like getStaticPaths, API routes, and React Server Components. This is probably the biggest issue, as these features are quite important. Additionally, locales and all of next.config.js are unsupported. Basically, Next.js works on Bun, but it is not near feature complete yet.

Vite

Vite is a popular bundler, used by frameworks like SvelteKit and Astro. Unfortunately, Bun does not support Vite at all, as many Node modules used in Vite are not part of Bun yet (https,child_process, perf_hooks, etc). Luckily, Bun is working on Vite support, so hopefully we will see Vite working on Bun soon.

Express

Express works, but only to a minimal extent. Even basic examples are malfunctioning and, once again, modules like https are missing. Luckily, Bun is working on it.

Summary

Overall, it seems like Node.js compatibility is nowhere near where it needs to be, but that is an ongoing focus of development, so I expect this to change as development progresses.

Comparison with Node and Deno

Now we will see how Bun compares to Node.js and Deno in general:

Element	Bun	Node	Deno
Created	2021	2009	2018
Created By	Jarred Sumner	Ryan Dahl	Ryan Dahl
Language Written in	Zig	C++	Rust
JavaScript Engine	JavaScriptCore	V8	V8
Ecosystem	Very small	Very large	Small
Benchmarks in First	8	3	3
Benchmarks in Last	3	5	6
Package Manager	bun install	npm	URL-based packaging
TypeScript Support	🟢	🔴	🟢
JSX Support	🟢	🔴	🟢
WebAssembly Support	🟢	🟢	🟢
Permissions System*	🔴	🔴	🟢
Testing Framework	🟢	🔴	🟢
Web Compatibility	🟡	🟡	🟢
Node Compatibility	🟡	🟢	🟡
MacOS Support	🟢	🟢	🟢
Linux Support	🟢	🟢	🟢
Windows Support	🟡*	🟢	🟢

* Windows supported through WSL. Native support in progress

Conclusion

Bun is a very promising project. Initially, I was skeptical of Bun, especially of its use of JavaScriptCore rather than V8, but after this, I am now convinced that Bun has a lot of potential. Currently, the ecosystem and uneven Node support is stopping me from using Bun that much, but the development of Bun is moving along very quickly, so I expect Node compatibility to improve a lot over the next few months/year. Additionally, the Bun ecosystem should grow quickly.

TL;DR Bun's Node.js support and ecosystem currently limit it, but it is very promising for the future.

I hope you learned something from this, and thanks for reading.

State of JS 2021 Results and Analysis

AsyncBanana — Mon, 21 Feb 2022 04:24:34 +0000

This week for State of the Web, we have a special edition about one of the most extensive surveys in web development, the State of JS. State of JS is a survey about everything related to JavaScript, including language features, front-end frameworks, and bundlers. This year's version, the 2021/2022 version, collected more than 15,000 responses. This article looks at the results and what they mean for web development.

There are a few terms in this that mean things specific to this survey:
Usage: The percentage of people that have used the library or feature out of the total survey takers
Awareness: The percentage of people who know about a feature/library out of the total survey takers
Interest: (Only for libraries) The percentage of people that want to learn a library out of everyone who does not already use that library
Satisfaction: (Only for libraries) The percentage of people who have used a library and are satisfied out of everyone who has used that library

Languages Features + Web APIs

First, let's look at the usage of modern language features and web APIs.

Language Features

Nullish Coalescing (??) and Optional Chaining (?.) Quickly Grow

Two new features in JavaScript, nullish coalescing and optional chaining, have grown quickly. Nullish coalescing is a feature that allows you to return the right-hand side of the operator if the left-hand side is null, and optional chaining allows you to return undefined when accessing properties of a nonexistent object instead of erroring.

// Nullish coalescing
1 ?? 2 // returns 1
null ?? 2 // returns 2

// Optional chaining
const obj = {a: undefined}
obj.a.test // errors
obj.a?.test // returns undefined

These methods have been gaining momentum quickly, with more than 65% of users reporting to have used nullish coalescing and >75% using optional chaining. This is despite being introduced in ES2020. They have most likely grown so much because they help provide clearer, more efficient code, they are easy to adopt, and you can easily transpile them into older syntax using something like Babel or ESBuild.

ESM Dynamic Imports are gaining steam

Dynamic importing is a way to dynamically load ECMAScript Modules, similar to how you could call require() dynamically for CommonJS. If you have not heard of ESM before, it is a module format introduced in ES6 that is native to browsers. However, before dynamic importing, you had to import modules statically at the top of your JavaScript module. Static imports are helpful for tree shaking and static analysis, but sometimes you need to import things dynamically. Now, you can run the function import() to import modules.

// Static importing
import something from "./example.js" // Always has to be at the top of the file
// Dynamic importing
const something = await import("./example.js")

Dynamic importing opens doors to ESM code splitting, lazy loading, and more. Because of all these features, dynamic importing has grown a lot, with almost 50% of users reporting to have used it. This feature is also related to a newer feature, top level await, as top-level await makes it possible to import modules dynamically outside of am async function. Top-level await very new but already has 31% usage according to State of JS.

Web APIs

Service workers and PWAs are mainstream

Service Workers are scripts that can intercept HTTP requests coming from websites, which allows for more advanced caching, offline access, and other network capabilities. They have been around for a few years now and have steadily gained usage. In this survey, they come in at 45% usage. The growth of service workers is bolstered by Progressive Web Apps (PWAs), which usually require service workers and have a usage rate of 52.3%. Progressive web apps are web apps that can you can install like a native app and include many native capabilities. The high usage rate is surprising, especially since Firefox does not support PWAs and has stated they do not intend to do so.

WebAssembly is growing but is still uncommon

WebAssembly is an Assembly-like language designed for the web and serverless. It can be faster than JavaScript, and allows you to use a wider variety of languages that compile to WebAssembly, but its usage rate is still low, at 15.6%. That still growing (usage was only at 10.5% in 2020), and awareness is very high at 97.9%, but it still has not gone mainstream. That is likely due to how hard it is to adopt (you need to learn another language) and the smaller ecosystem. To learn more about WebAssembly, check out this State of the Web webassembly article.

Websockets are very popular

Websockets are connections designed for real-time communication both from client to server and server to client. More than half of the respondents to State of JS 2022 said they had used Websockets before, making it the most well-used browser API. That is likely due to the wide use cases, from real-time chat to gaming to streaming analytics, and the fact that the Websocket browser API has been around for a long time and is supported in browsers like IE 11.

WebGL is well known but uncommonly used

WebGL is a browser API that enables web developers to create graphical applications with an OpenGL ES-like interface. While most people are aware of it (87.6%), only 21.6% of people actually use it. That is likely because of the WebGL learning curve, as well as the alternatives to WebGl, like SVG, and, more notably, Canvas. Another interesting related browser API is WebGPU, which mirrors the Vulkan API and is being standardized.

Libraries

Almost any web developer is using bundlers, frameworks, and more. Because everyone needs them, there are many different JavaScript tools, and it can be hard to choose between them. Now we will look at the state of libraries like bundlers, frameworks, mobile/desktop tools, and monorepo tools.

Front-end frameworks

React keeps the crown of usage

React has been the most popular front-end framework in the State of JS for 5 years and continues this tradition this year. React has a usage rate of 80%, significantly higher than the next most popular framework, Angular (at 54%). React is popular because it is relatively stable and established and has a lower learning curve than something like Angular. For more information on why Facebook created React and its current state, take a look at State of the Web: React. However, newer frameworks have some advantages over React, which this article covers later.

Vue is steadily growing

Vue is a newer alternative to React that has grown over the past few years. It now has a 51% usage rate and seems like it could surpass React in the future. Vue has the advantage of a different template syntax and is faster, both in loading speed and runtime performance.

Svelte and Solid take the highest satisfaction

Svelte and Solid lead the front-end frameworks in satisfaction, both with 90%. Svelte has been around for a few years and offers a concise template syntax and a compiler that compiles to native JavaScript. Developers use Svelte for its performance and the power of the templating language, which offers things like two-way binding and the ability to update the DOM by reassigning a variable with data rather than having to use something like setState(). Svelte has already gained some usage, with a 20% usage rate.

On the other hand, Solid is a newer framework closer to React but is the fastest framework by far. Solid uses the same JSX and hooks patterns but has a different updating system that removes the need for a virtual DOM and the need to reevaluate components every time the state is changed. Solid's bundle size is also significant smaller than React's. In contrast to Svelte, since Solid is newer, it has much less usage, at 3%.

Other interesting newer frameworks

There are some other newer frameworks, like Lit, Alpine.js, and Stimulus. Lit is a web component-based framework that aims to offer an easy to use layer over web components. It has only 7% usage but 40% interest. Alpine.js is another interesting framework that is special in that you use attributes inside HTML to control behavior. However, I cannot recommend it, as it does not have very good runtime performance. Alpine is slightly lower than Lit with usage and interest, at 6% and 33%. Finally, Stimulus is another framework that is part of the Hotwire project. Stimulus is somewhat like Alpine, although it relies a little less on HTML attributes. It is designed to compliment Hotwire Turbo, which provides HTML AJAX, by making it possible to add small bits of interactivity where needed. Stimulus is the smallest framework, with 2% usage and 21% interest.

Backend Frameworks

Express is the top framework by far

Express is a basic Node.js backend framework that provides routing and middleware. That simplicity has made it the most used backend framework by a large margin, with 80% usage, compared to 45% for the next highest, Next.js. Express also tops awareness and does moderately well in interest at 59%. Additionally, Express is growing, so it does not seem like it will soon lose its throne.

Front-end framework based frameworks are growing

Nowadays, many backend frameworks use front-end frameworks. For example, take the second most popular backend framework, Next.js. Next.js is built for React. In fact, about half of the frameworks in State of JS integrate with various front-end frameworks like React, Vue, and Svelte. This trend is quickly growing as people look for alternatives to running a Single Page App (SPA) due to SPA's SEO and performance.

SvelteKit has the happiest developers

Once again, we see Svelte. However, this time it is for Svelte's official framework, SvelteKit. SvelteKit offers built-in server-side rendering and static generation for Svelte websites, as well as other helpful features for Svelte developers. SvelteKit is like Next.js, but it is the official Svelte backend framework, and it is for Svelte, not React. Because Svelte has such high satisfaction and SvelteKit works very well with Svelte, SvelteKit has a satisfaction rate of 96%, which is the highest satisfaction out of all the backend frameworks.

Other new frameworks like Remix and Astro have high satisfaction

There is a group of frameworks at 91% satisfaction. They are Astro, Fastify, Next.js, and Remix. Next.js is not new, but all of the other frameworks are, and each brings new features to the table.

Next.js

Next.js has been around for a few years and is established as the most popular framework for React, but it has still managed to match or do better than other newer frameworks in satisfaction. However, Next.js satisfaction has decreased after peaking at 92%, although that is not a huge drop.

Fastify

Fastify is unique in that it is not designed to be used with a front-end framework. Instead, it is more like Express, just significantly faster. According to Fastify's own benchmarks, Fastify is more than 3x faster than Express. Fastify also offers built-in support for JSON parsing and JSON Schema. Fastify's performance has given it 11% usage and 60% interest, which is not bad for a new Express alternative.

Remix

Remix is a React backend framework created by the creators of React Router, the most popular client-side router for React used today. Remix focuses on web fundamentals, server-side rendering, and advanced routing to improve performance and user experience. Remix is also designed to have support for multiple serverless providers just like SvelteKit. Because of all of its features, Remix is growing at a fast pace. It only has 5% usage due to it being released very recently, but it already has 69% interest and, of course, 91% satisfaction.

Astro

Astro is probably the most innovative of the bunch. Not only does it offer partial hydration on the component level using the "Islands" architecture, it also supports multiple different client-side frameworks. You can even use multiple at the same time. For example, you could code most of your site in Svelte but then use React for one component and avoid hydrating the components that are not needed to be interactive, even if other components on the page need to be interactive. These features brought Astro 3% usage and 66% interest, despite Astro being published partway through 2021.

Testing

Jest remains the most popular

Jest, an easy-to-use testing library from Facebook, is the most popular JavaScript testing library. It has a usage rate of 73%, which is significantly higher than the next most popular's, Mocha (50%). Jest's popularity is due to its ease of use and speed.

Testing library takes satisfaction

Testing Library is another testing library that ranks the highest for satisfaction, with a satisfaction rate of 96%. Additionally, Testing Library has moderately high usage, at 35%. The interesting thing about Testing Library is that it is not a testing runtime, nor is it a test runner. What is does it provides a querying toolkit that can be used on DOM runtimes like Jest or a real browser. The querying toolkit tries to mimic user behavior, which helps you make better UI tests.

Vitest makes testing fast

Vitest is a mostly Jest compatible testing framework that uses Vite under the hood. Using Vite makes Vitest significantly faster than Jest and makes it possible to use only one build pipeline for testing and building if you use Vite already. Vitetest has been well received, with satisfaction at 94% and interest at 82%. In fact, the most modern testing pipeline you could use is probably Testing Library running on Vitest.

Build Tools

Webpack is the most used

Webpack is the most used bundler/build tool (no surprises here). That is because Webpack was created when the alternatives were much worse, and it has been able to retain its dominant position. However, it is now being challenging by alternatives like Vite, so its future domination is uncertain.

Vite is becoming the next big thing in bundling

Vite is a bundler that has quickly grown to 30% usage and is used by frameworks like SvelteKit and Astro, despite only becoming public in the past two years. Vite also has the highest satisfaction rating, at 98%. Most people attribute Vite's popularity to its massive speed improvements due to ESM and easy configuration. Vite's growth is also bolstered by the fact that was created by the team behind Vue and is used in modern Vue frameworks like Vitepress.

esbuild and SWC are climbing quickly

esbuild and SWC are both JavaScript build tools that are significantly faster than previous tools due to the choice to use languages like Go and Rust, as well as better multithreaded design. They replace tools like Babel and Terser and can be tens of times faster. That speed has brought large amounts of interest (81% for esbuild and 75% for SWC) and satisfaction (96% and 94% for esbuild and SWC, respectively). SWC is especially notable, as Next.js recently adopted it, so it has a bright future ahead.

tsc CLI is quietly becoming popular

Surprisingly, the TypeScript CLI is the second most popular build tool after Webpack, at 79% usage. The usage was up from 62% in the 2020 survey, so the usage is proliferating. The TypeScript CLI is the main way to compile TypeScript projects. However, projects like esbuild and SWCD offer TypeScript compilation, and TypeScript cannot do much beyond compiling TypeScript.

Conclusion

Whew! That was a lot. If you want to view the full results, you can look at 2021 State of JS Results. If you enjoyed reading this article, be sure to subscribe to RSS and join the mailing list here. I hope you learned about a new tool today, and thanks for reading!

State of the Web: React

AsyncBanana — Sun, 13 Feb 2022 20:56:53 +0000

React is one of the most popular JavaScript frameworks out there. While many other frameworks offer some advantages, React has retained dominance. There is also a vast ecosystem around React, which is changing quickly. This article aims to provide an overview of the recent trends in React, like Remix, server components, partial hydration, and more.

Background of React

Bolt & FaxJS

Around a decade ago, Facebook started looking for a way to modernize its web app. It was becoming increasingly complicated, and they needed a framework to make it easier to build and maintain. To fix this, they created a project called Bolt. Bolt was an MVC framework built on top of JavelinJS, and it solved many of the problems Facebook had. However, it was not perfect. Jordan Walke, a developer at Facebook, created the next iteration of Bolt, called FaxJS. It offered many features that React has today, like rendering on both client and server, DOM diffing, and more. Jordan Walke renamed FaxJS FBolt and started using it in Facebook's codebase.

React's creation

In 2013, Facebook renamed FBolt, you guessed it, React. Additionally, they started working on JSX, an abstraction layer for defining UI in React. JSX made compiling HTML like statements to JavaScript function calls. Interestingly, according to a post by the React team, JSX was initially based on a system in PHP that allowed for embedding XML literals. JSX was initially just a fork of jsx-xml-literal.

Initial Growth

React started growing quite a bit after that. React's GitHub repository reached 10k stars in late 2014, 20k in 2015, and 50k in 2016. Additionally, React's ecosystem started to grow with things like Reactiflux.

Hooks

Hooks are ways of defining lifecycle methods in functional components. In 2019, React released hooks, which completely changed the way people wrote applications in React. Before hooks existed, you had to use classes for stateful components. Functional components could only be simple components that just relied on props. However, hooks offered a way of accessing state through functions, which opened the door to completely using functional components. Nowadays, most new applications use hooks instead of class components, as hooks are simpler to use and more concise.

Why People use React

Dynamic updating

React automatically updates your UI if your data changes, saving a significant amount of time. For example, if you had a table of various transactions set to update every 15 seconds, you would have to define the difference checking and updating manually. However, with a framework like React, you can just change the value of the data, and everything happens for you. Dynamic updating also makes your UI easier to reason with, as you can guarantee it represents the data.

Isomorphic rendering

React can render UI on both the client and server with the same code. That opens up opportunities for server-side rendering and hydrating on the client. In this way, React contrasts with lots of traditional templating languages where you could generate static HTML but not make that automatically interactive.

React does this through two different APIs. Their primary rendering API function exposed through react-dom is render, which renders the JSX passed on to the client. However, to render HTML on the server, there is renderToString under react-dom/server, which renders static HTML that can be hydrated later using render.

Advanced templating

React allows you to do many things to reduce repetition in your code, including embedding JavaScript and modularizing markup inside components. These features help reduce repetition and the maintenance burden by making it easier to update repeated pieces of markup.

The State of React

Remix and the new React frameworks

Remix is a new React framework (like Next.js), created by the people who made React Router, that was only recently open-sourced but has been growing very quickly. Remix promises better integration with web platform features, integration with the edge, and simpler isomorphic code. Remix has already managed to gain 12k stars. Another unique thing about Remix is that instead of offering static site generation and dynamic server-side rendering, it focuses entirely on server-side rendering. That means that while Remix does not support static site generation, if you prefer rendering dynamic data on the server rather than using API fetching on the client, Remix works quite well. Of course, there are tradeoffs to both rendering on the server and fetching data on the client for dynamic data, and it depends on your use case. Finally, due to the author's experience building React Router, Remix has advanced routing, with features like nested routing and isolated errors.

Remix is not the only new React framework. There are others, like Astro. Astro is a promising static site generator that supports multiple ways of building UI, including React. Astro is also notable because it supports partial hydration, which reduces the JavaScript sent to the client by only including what is needed to make your web app interactive.

React 18

React 18 is an upcoming React release that offers many new features, like the concurrent renderer. The concurrent renderer allows for multiple versions of the UI to be built at once, which opens up opportunities for new features like automatic batched updates, streaming server-side rendering, and more. These features help improve performance. For example, automatic batched updates reduce the amount of UI updates needed, which increases performance on the client.

CSS

There are numerous approaches to using CSS in React. Of course, you can use native CSS, but there are many other approaches that work better with React's UI style.

CSS in JS

CSS in JS integrates with React very well. The most popular CSS in JS tool is styled-components, which allows you to define styles inside JavaScript using tagged templates. However, there are newer approaches to CSS in JS that are often superior in certain ways. Some of the most interesting of those are Linaria and vanilla-extract. Linaria is a library that aims to optimize CSS in JS by compiling CSS in JS to native CSS. Linaria also has built-in React integration, making it easier to add dynamic styling without a high runtime cost. vanilla-extract does the same thing but better integrates with TypeScript and offers features like building custom utility styles.

Atomic CSS

Atomic CSS works well with React due to its scoping. Since the styles are atomic, they are automatically scoped to just the elements that use them, making it easier to reason about styling with components. Additionally, Atomic CSS's repetition can be solved using components. Some of the most notable Atomic CSS libraries currently are Tailwind and UnoCSS. Tailwind is, by far, the most dominant Atomic CSS library out there due to its wide variety of features and ease of use. UnoCSS is a more recent project that is significantly faster and more flexible than Tailwind.

Faster React Replacements

While React has many advantages, performance is not one of them. Luckily, there are replacements for React that retain a identical or almost identical API. The most notable are Preact and Solid. First, we have Preact. Preact is faster and significantly smaller (3kb Gzipped) than React while having an identical API. You can use Preact almost anywhere, and it can be used as a drop in replace with preact/compat. Second, there is Solid. Solid does not have an identical API to React, but the ways it differs allows it to get a large performance advantage. In terms of runtime performance, Solid is significantly faster than both Preact and React. Solid achieves this by forgoing a virtual DOM and building components only once instead of whenever state updates. Solid is also smaller than React, although it is a bit bigger than Preact.

Conclusion

I hope you learned something from this today. If you enjoyed reading this, sign up for the mailing list here and subscribe to RSS to get more of these articles. Thanks for reading!

10 ways to speed up web font loading

AsyncBanana — Fri, 11 Feb 2022 01:17:56 +0000

Fonts are popular tools on the web nowadays. Most modern websites use custom fonts, usually from Google Fonts, because it adds a custom touch to the interface and allows for more options. However, there are many performance implications with fonts on the web. Fonts are often hundreds of kilobytes and are on another domain, slowing down the website. Luckily, you can solve these problems. Here are ten tips to improve font loading performance on a website.

The list

1. Self your fonts

When you go on a website, you often see something like this:



<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet">

That means the website is using Google Fonts to load fonts. Google Fonts is excellent for prototyping, as it is straightforward but is terrible for performance. Performance is bad because Google Fonts has a complicated string of requests to get a font, which adds significant latency.

As you can see, the font loading with Google Fonts can be complicated. However, you can reduce how many requests are needed to just one by self-hosting the font and putting the @font-face declaration inside your CSS bundle instead of an external stylesheet. A tool like Google Webfonts Helper can be helpful for this.

2. Use modern web font formats

Fonts are like images on the web because of how their formats work. With images, modern web formats like AVIF and WebP replaced less compressed formats like PNG and JPEG. Similarly, web fonts have WOFF and WOFF2, which provide superior compression to formats like TrueType and OpenType (TTF and OTF). Additionally, web fonts are almost universally supported:

At this point, because of the almost universal browser support, the best thing to do is use WOFF2 with a WOFF fallback, although you could even just use WOFF2, as ~96% of users support it.

3. Subset your fonts

Font subsetting means trimming your fonts down to only the characters you need. Subsetting can yield massive amounts of size savings without having any drawbacks as long as you are not using the characters you remove. The simplest way to do this is subsetting to remove languages that you do not use. For example, take Inter, one of the most popular fonts. If you include all languages, which includes the Latin alphabet, Cyrillic, Vietnamese, and Greek, the size of the WOFF2 font is 95kb. However, chances are you are not using all of those languages. If you remove all characters outside of the English language, the size is reduced to just 16kb! There are many ways to subset fonts, including Google Fonts (and by extension, Google Webfonts Helper), Everything Fonts, and fontTools.

The size reduction is beneficial for performance, but you can do even better if you are willing to take on more complexity. Instead of subsetting by wide character ranges, you can subset to include precisely what you use. Tools like fontTools allow you to subset fonts by arbitrary character lists. The problem with this approach is that you need a complicated build process to get every character you use. Or, of course, you can manually add each character, but that is a lot of work 🙁.

4. Use font-display

By default, text will not show up in many browsers until the correct font is loading. That behavior is called Flash of Invisible Text, or FOIT. Some other browsers display text using the fallback font while it is loading, which makes sure text is not invisible but can cause a layout shift.

Luckily, you can customize font loading through the font-display option in your @font-face declaration. The two recommended values for font-display are swap and optional. swap uses a fallback font and then switches to the custom font once it is loaded, and optional blocks page load for a maximum of 100ms to let the font load, and if it does not, it uses a fallback font.



@font-face {
  font-family: 'Example';
  font-style: normal;
  font-weight: 400;
  src: local('Example'), local('Example'), url(https://example.com/example.woff2) format('woff2');
  font-display: swap;
}

font-display: optional is the best for when you don't need the font to be loaded because it prevents any layout shift and ensures the text is not invisible. However, font-display: swap is best when you need the font to load because it swaps in the font even if it takes more than 100ms.

5. Match your fallback font with your custom font

Fonts are usually spaced and sized differently. For example, Merriweather is larger than Georgia, even if the CSS font size is the same. These inconsistencies can cause a layout shift if you use font-display: swap and make fonts less consistent if you use font-display: optional. Luckily, you can configure your fallback font to look a lot more like the web font you are using. Matching both fonts can be done by customizing spacing and font size to remove the inconsistencies. A helpful tool for this is Font Style Matcher, which allows you to look at two different fonts, configure various spacing properties, and see a demo of the layout shift.

6. Use a CDN

CDNs are great for speeding up static content delivery. They deliver content closer to your users and often offer other ways of speeding up delivery. It is a good idea to host your fonts on a CDN, along with all of your other static assets. Using a CDN also has the advantage of reducing server costs, as CDNs are generally cheaper compared to serving the request from your source server.

7. Preload your fonts

Preloading is often a good idea for various resources, as it makes the browser know it needs to download a resource sooner and increases that resource's priority. It is the same idea for fonts. However, you do not always want to preload your fonts because it might make a font load unnecessarily. That is because the browser automatically detects whether the website uses a font on the page before downloading it, even if the @font-face is present. Now, you might know that you always use the fonts you include with @font-face. There is one other potential problem. If your font is low priority, it might make other resources take longer to load. However, if both of these things are not true, preloading can be a great way to speed up your font loading.

8. Use local()

Depending on the font, users can often have the font you are using locally installed on their machine. If they do, you can easily use the font locally to prevent any performance degradation from a custom font. You do this using a local() statement in your @font-face src rule.



@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
        url('example.com/awesome-font.woff2') format('woff2')
}

This @font-face checks if the user has the font locally, and if they do not, downloads it remotely. That means that users with the font get a free performance boost while adding little complexity to the code and no disadvantage to users who do not have the font locally.

9. Implement Caching

Caching is very important, especially if you have lots of repeat visitors. Caching allows the font to load from the disk after the first time it is downloaded. You can implement caching through the Cache-Control header. If you use a CDN like Cloudflare, it is simple to do from the dashboard. Otherwise, you can do it by simply sending the header with your font responses.

10. Don't use custom fonts

I bet you didn't see that one coming 😉. I am talking about system font stacks. System fonts are great for body text or other text that isn't important for branding, as it is built-in and makes the interface more comfortable because it is the same font as the operating system.
You can implement system UI fonts through the system font stacks linked above or the system-ui font family.

Conclusion

That is all! I hope you enjoyed learning how to optimize your web fonts, and I hope this has helped you optimize fonts on your websites. If you enjoyed reading this, be sure to sign up for the mailing list here. Thanks for reading!

State of the Web: Static Site Generators

AsyncBanana — Sun, 30 Jan 2022 20:22:20 +0000

Static site generators (SSGs) can be beneficial for making large websites without reducing performance. They have existed for more than a decade, but they have evolved a lot, especially more recently due to the rise of "Jamstack." This article goes over the background of static site generators, why people use them, and the current state of them.

Background of Static Site Generators

Static websites have risen and fallen across the lifetime of the internet. The first websites were fully static, built-in plain HTML. This worked well for the first websites because it was straightforward, as there is no build process and you need nothing more than a simple static file web server, and most websites did not need much more functionality. However, as the web started to evolve, this changed. Eventually, people started using server-side languages to dynamically generate HTML, using languages like PHP, Ruby, and Perl. This was the beginning of the usage of dynamic websites.

The rise of CMSs

Not everyone who writes knows how to program too. Because of that, it was hard for people who did not know how to program to manage content. That is why people created CMSs. CMSs made it easy for marketers to create and manage content without touching code. The first CMSs were enterprise CMSs like FileNet and Documentum (now OpenText). However, as many people know, this did not last forever. A few years later, in 2003, Matt Mullenweg and Mike Little created WordPress. WordPress' was completely open-source and quickly grew to become the most popular CMS on the web, and it still is. However, while it became popular, WordPress did not make everyone happy. This is where static site generators come in.

Jekyll and the first static site generators

I was tired of complicated blogging engines like WordPress and Mephisto. I wanted to write great posts, not style a zillion template pages, moderate comments all day long, and constantly lag behind the latest software release.

This excerpt is from Tom Preston Warner's announcement of Jekyll, and it started the rise of static site generators. Instead of using basic HTML pages, static sites would bring the more advanced tools like Liquid. Unlike WordPress, Jekyll would build the HTML at build-time rather than runtime, which was simpler and cheaper to run on a server. Jekyll grew in popularity, partially due to GitHub's adoption of Jekyll for GitHub pages. After Jekyll's creation, many more static site generators followed, which helped static site generation grow to a large category in web development. Now let's look at why static site generators are helpful.

Why Static Site Generators are significant

Performance

Static site generators are significantly faster than dynamic websites because they run expensive computations beforehand and compile static files. First, let's dig deeper into the first point. If you run a website with dynamic software like WordPress, there are multiple steps to send your content to the user. Before actually sending the HTML, WordPress has to fetch the content from a database, likely MySQL, build the page, run any relevant plugins, and finally send the file. These steps take valuable time, and if they take too long, the user could leave before the content loads. Some of this can be alleviated using caching, but caching is imperfect, so users often get served a page uncached. On the other hand, with static site generators, everything is built beforehand, so users do not need to wait for database fetching or computations.

Another thing static files allow is static file hosting. If you run a WordPress server, you need a compute unit, like a bare metal server or virtual machine. When doing this, you make it so users can only access the uncached website from one location. That is fine if your users are close to your server, but they are likely not. If, for example, a user is in Singapore and you are in the US, the connection needs to travel almost halfway around the world to reach your server. The connection distance adds a significant amount of latency. It is possible to cache it globally on a CDN, but once again, it is hard to get a 100% cache hit ratio and often nearly impossible since it is hard to cache HTML files. On the other hand, if you use static site generators, you can cache everything easily (most static hosting services integrate with a CDN), and cache invalidation is much simpler.

Server Costs

Once again, CDNs help in this area. First, let's look at the pricing of WP Engine, one of the most popular managed WordPress hosts. For up to 25,000 visits, you have to pay $25 (USD) a month. Between 25,000 and 75,000 visits, the cost rises to $59 a month. Once again, you can put a CDN in front of the host, but visits often miss the cache. In contrast, static file hosting is extremely cheap. For example, the hosting ByteofDev runs on is Cloudflare Pages. The free tier offers unlimited requests and bandwidth. The pricing means that even if traffic suddenly spiked 10 times, not only would my website remain online and fast, it would not cost me any more money.

The State of Static Site Generators

JavaScript Client-Side Frameworks

Many modern static site generators integrate with modern JavaScript frameworks like React, Svelte, and Vue. Using a framework like those mentioned earlier instead of a traditional templating language gives you access to the vast ecosystem of framework-specific components and code that can run on both the build server and client. Currently, the most popular SSG that does this is Next.js, which supports both dynamic rendering and static rendering. However, many other popular SSGs do this, like Gatsby, VitePress, and Astro. Next.js and Gatsby both support React, VitePress supports Vue, and Astro supports multiple frameworks, including React, Svelte, and Vue.

Fast Building

As we have learned, SSGs are all about the build step. No one likes to wait a long time for their website to build. SSGs like Hugo and Zola are trying to create a build experience that is significantly faster than previous SSGs. Hugo is usually around 6 times faster than Jekyll and is even faster compared to Next.js or other framework-based SSGs. There are multiple reasons for this. First, Hugo and Zola are written in Go and Rust, respectively, rather than JavaScript or Ruby, which most other static site generators use. Go and Rust are much faster than Ruby and JavaScript because they use static types (along with manual garbage collection in Rust's case) and are compiled beforehand. Second, they both are designed to use multithreading. Multithreading multiple allows tasks to run simultaneously by utilizing multiple CPU cores instead of running everything sequentially on one CPU core. Finally, Hugo and Zola simply focus on optimizing their code for fast build times.

While the SSGs mentioned before are currently the fastest SSGs by a large margin, there is still innovation for speed on the JavaScript framework-based front. One of the biggest bottlenecks in JavaScript framework-based SSGs is the bundling step. The first SSGs of this type primarily used Webpack, but many modern SSGs have started using next-gen bundlers like Vite, which help speed up builds by a large margin. Even SSGs like Next.js, which still use Webpack, are beginning to adopt faster elements like SWC instead of Babel and Terser. Astro is pretty notable in this as it both uses Vite and has migrated its core compiler to Go using WebAssembly.

Partial Hydration

JavaScript is one of the most significant contributors to page bloat. If you use one of the SSGs that use a JavaScript framework, you are likely sending unnecessary JavaScript to the client. However, partial hydration can solve this. To understand why, let's first look at what hydration is. Most JavaScript frameworks run code on both the build step and the client. The build step creates the HTML. However, interactivity is still needed. To solve this, they use hydration. Hydration uses client-side JavaScript to make static HTML interactive. Sounds good, right? The problem is that frameworks often send code for parts of the HTML that are not interactive. Doing that slows down page loading without actually changing anything.

The solution is partial hydration, which allows you to define what you want to hydrate. There are two forms of this, page-level and component-level. Page-level hydration is a form of partial hydration that works with SSGs like SvelteKit and allows partial hydration on a per-page basis. You can choose whether to include JavaScript for each page. However, you often want to include JavaScript, but only for one part of the page. To do this, you can use component-level partial hydration. Component-level hydration allows you to implement partial hydration in a significantly more granular way by defining precisely what components you want to hydrate. The most popular way of doing this is using the Islands Architecture, which Astro uses.

Conclusion

That is it! Hopefully, now you know a lot more about static site generators. If you want my personal recommendation, it is Astro, for the reasons I have mentioned in various parts of this article. If you liked this article, be sure to join the newsletter here and subscribe to the RSS feed here. Thanks for reading!

State of the Web: Bundlers & Build Tools

AsyncBanana — Sun, 23 Jan 2022 20:40:23 +0000

Ever since Browserify, bundlers have been extremely important in the web ecosystem. They provide the ability to automatically process code, which opens up opportunities for performance optimization and non-native languages. This article looks at the background of bundlers, why they are essential, and their current state.

Background of Bundlers

The Web Before Bundlers

For a large part of the web, bundlers did not exist. To include scripts, most people just linked to the library on a CDN like CDNJS or Google Hosted Libraries. This would begin to change in 2009 when Node.js was released. Instead of using CDNs, Node.js came with its package manager, npm. npm was easy to use because every library was just one npm install away, and updating was effortless. Because of the ease of use, many people wanted to use npm on the web. However, this was impossible until Browserify came along.

Browserify

Browserify's tagline describes itself pretty well.

Browserify lets you require('modules') in the browser by bundling up all of your dependencies.

Browserify was the first JavaScript "bundler." If you do not know what a bundler is, it is a tool that bundles multiple scripts together into one script and often performs transformations on the scripts it bundles. This means that you can bundle different scripts from NPM with your code by parsing require() statements in your code. Bundling also meant that your site was often faster because there were not as many HTTP requests being sent out, which reduced overhead (this is less the case in modern browsers because HTTP/2 adds the ability to download multiple resources on a single connection). Browserify quickly gained adoption because of these advantages. It is also important to note other ways of using modules on the web, like Require.js, which used AMD instead of CommonJS, and Bower, which fully replaced NPM for the browser.

Grunt & Gulp

While Browserify was great at bundling scripts together, it was not quite as good at transforming code. Let's say you wanted to compile your CoffeeScript code to JavaScript. You can do this with plain Browserify. However, it is unwieldy and relatively inflexible. To fix this, a new group of tools for the web where born, which focused on running code transforms. These are usually called task runners, and the most popular ones are Grunt and Gulp. Grunt was the first task manager, first released in January of 2012. It allowed for more flexible code transforms when using bundlers like Browserify or without a bundler. However, there were still problems with Grunt, which were solved by Gulp. Gulp is faster, as it uses Node streams instead of temporary files and runs tasks in parallel, as well as allowing for people to use a script instead of a JSON configuration file. This was still not perfect, though, because it was annoying to use two separate tools. This was fixed by Webpack

Webpack

Webpack combines both bundling and compiling, making it easier than the previous standard of Gulp + Browserify. Webpack first started becoming popular in 2016, and it is still popular to this day. There are also some other advantages of Webpack. First, it supports bundling and transforming non-JavaScript assets, like HTML, CSS, and images. Second, the API is often easier to use (although it is still complicated relative to the newest bundlers). Many tools, like Create-React-App, Next.js, and Vuepress, use Webpack.

Why Bundlers/Build tools are Significant

If you already know why bundlers are used, you can skip this section

Optimization

In general, most people do not write their code like this:

let l="hello";l+=" world!",l=l.repeat(5),console.log(l);

Instead, to make things readable, they would probably write something like this:

let text = "hello"
text +=" world! "
text = text.repeat(5)
console.log(text)

However, the first example is smaller and therefore transferred faster. Now, you might think you have to sacrifice size for readability, but there is a solution, minifiers. Minifiers automatically transform your source code into a smaller form. In fact, the first code example was generated by Terser, which is one of the best minifiers. Bundlers make using minifiers easy through plugins. Additionally, bundlers help perform other optimizations, like tree shaking, which removes unused code. Finally, bundling scripts itself can improve performance by reducing HTTP requests needed.

Non-web Native Languages

Often, it is more efficient to use a language like Sass or Stylus instead of plain CSS. Or, perhaps you are trying to use TypeScript to enforce static typing in your code. Whatever the case, it is often better to use languages that the web does not natively support. Bundlers can help with this. Instead of running a bunch of different commands yourself to compile everything, you can often just add plugins to your bundler config file and run the bundler.

Development Features

Most modern bundlers have features that enable faster iteration, like Hot Module Reload (HMR). HMR automatically reloads specific modules that have changed rather than the whole page, making reloading faster. Additionally, if you are using a framework like React, React state can be preserved, which means that the page data does not reset every time.

Easy Inclusion of Modules

Bundling modules together is the original reason why bundlers were made. Even though there are many other features now, this is still important. Even with the native support of ESM, it is still helpful to be able to import or require modules without having to write full import paths (although import maps could help with this).

The State of Build Tools

Adoption

Nowadays, almost every web developer uses one bundler or another. Webpack is by far the most popular, with Rollup and Vite in second and third, respectively. Currently, Vite is the fastest-growing major bundler, which has been adopted by frameworks like Vitepress, SvelteKit, Astro, and more.

ECMAScript Modules (ESM)

ESM is supported in most modern bundlers. While tools like Browserify do not support ESM, most tools as new or newer than Webpack support ESM. Additionally, ESM is often the recommended way to do things for supported bundlers because it is more future-oriented than CommonJS or AMD, and it is easier to statically analyze imports for tree shaking. ESM also opens up the opportunity for unbundled development, which we cover below.

Unbundled Development

Unbundled development utilizes native ESM support in browsers to offer an ultra-fast development experience. Unlike a traditional bundler which bundles everything in development, unbundled development transforms the code and rewrites import paths to the ESM compliant file path without bundling your code. Additionally, most bundlers that do this pre-bundle dependencies because that decreases the number of imports needed, and dependencies are unlikely to change often. The two most prominent bundlers that utilize unbundled development are Vite and Snowpack. Snowpack, created in 2019, was the first bundler to have an unbundled development experience. However, while Snowpack was popular for some time, this did not last forever. In 2020, the team behind Vue created Vite. Vite has many advantages over Snowpack, like the ease of use, speed, better optimization, and more. Additionally, popular projects like SvelteKit adopted Vite instead of Snowpack. All of this helped Vite pass Snowpack in downloads, and it now has more than 10x downloads compared to Snowpack. In fact, even Astro, a project created by the team behind Snowpack (be on the lookout for an article about Astro), is now using Vite. Overall, if you want fast, unbundled development, I recommend Vite.

Faster Languages

Another way that many people are trying to speed up bundling and code transformation is through using more optimized languages like Go or Rust. Currently, the two most notable tools that do this are esbuild and SWC. esbuild was created by Evan Wallace in 2016 using Go. esbuild performed the role of Babel in transforming modern JavaScript, the TypeScript compiler, Terser, and basic bundling all in one package that was significantly faster than any other tools at that time. SWC was created in 2017 by kdy1 using Rust. SWC is even faster than esbuild, although only marginally. esbuild is currently more popular than SWC and is used by projects like Vite, although Deno and Next.js have adopted SWC.

Low to Zero Config

Webpack has an infamously complex plugin system. While it is very powerful, it can be scary for beginners. Luckily, there are newer bundlers that focus on this. Parcel was created in 2017 by Devon Govett to allow for easy, zero-config bundling. Parcel supports many of the features Webpack plugins provide, like Sass, TypeScript, and JSX, without requiring you to do anything. Additionally, due to caching and the increasing use of Rust, Parcel v2 can be faster than Webpack. Vite is another low-config bundler, although it does not do as much out of the box.

What About Webpack?

Webpack is still the most popular bundler. While it has not been taking advantage of the ability for massive speed improvements specified above, it still has added new features in the most recent version, Webpack 5. The biggest thing added in Webpack 5 is module federation, or micro-frontends. Module federation separates different elements of a website and makes it easier to share pieces of code like component libraries. Another big thing Webpack added in version 5 is better caching, which can improve reload times in development. Overall, Webpack is still advancing, although it is falling behind some bundlers in certain features.

Conclusion

The world of web bundlers is advancing quickly. Hopefully this article gave you an overview of what is currently happening for bundlers. If you liked this article, sign up for the ByteofDev mailing list here (or don't, but I hope you do 🙃), and thank you for reading.

State of the Web: Serverless Functions

AsyncBanana — Sun, 16 Jan 2022 15:55:20 +0000

Serverless functions (also known as Function as a Service) execute code statelessly on the Cloud. This means that they can do things like scale infinitely and run anywhere. There are many different serverless function providers, like AWS Lambda, Cloudflare Workers, and Vercel.

Background of Serverless Functions

Google created the first serverless model in their Google App Engine product, which offered auto-scaling stateless code execution. App Engine was different from most more recent serverless function providers, but it was the first product to try this idea. However, while it was used by companies like Snapchat, it did not catch on with the overall developer community.

The first Function as a Service (FaaS) provider to truly catch on was AWS Lambda. AWS Lambda was a serverless function service that Amazon released in November 2014. Lambda allows for functions written in many different languages to automatically scale in under a second while allowing users not to have to worry about the underlying hardware. Companies like Google, Microsoft, and Oracle also created their own service for serverless functions. Although to this day, Lambda is the most popular serverless function provider, and since its release, it has become faster, more flexible, and easier to use.

However, that is not the end of the story. Since then, many services have improved on AWS Lambda's model in ways like ease of use and performance. The first notable FaaS provider was Vercel (ZEIT Now at the time), which was released in April of 2016 and was a lot simpler to use than Lambda. Another selling point was that it integrated well with Next.js, a React framework made by Vercel. Other, newer services also try to be a lot easier, like Begin, although Vercel is still the most popular in that group.

The second major innovation in serverless functions was edge computing with lightweight isolates. This was pioneered by Cloudflare Workers, a serverless product released in September 2017. It promised to allow your code to run on any of the many Points of Presence Cloudflare has worldwide, and it used V8 Isolates to reduce the startup time to a few milliseconds, and later, even zero.

Why Serverless Functions are Significant

Performance

Many serverless function providers offer high-speed services. As talked about in the background, edge computing has revolutionized serverless functions. Because serverless functions are stateless, they do not need to always run in the same place. This means they can work like CDNs and automatically deliver content from data centers close to users (the "edge") rather than one centralized location. Serving from the edge can be a huge difference in latency for large networks like Cloudflare's. Not all serverless function providers support this, but a growing number do, like Netlify, Cloudflare Workers, Vercel, AWS Lambda@Edge, and more.

Scalability

Unlike virtual machines, serverless functions can usually scale from zero to infinity. This means that you never get overloaded by requests, and you don't have to waste money on computing power that you are not using. Whenever users request the HTTP endpoint, most serverless function providers automatically determine whether there are already running functions that can process the request. If there are not, a new function is created. Additionally, if function instances are not processing anything, they are automatically stopped. Some virtual machine and container services also offer autoscaling, but because it takes longer to start a virtual machine/container, it is much less granular.

Ease of Setup

Serverless functions abstract over the hardware usually (hence the serverless). Instead of worrying about setting up servers and operating systems, the provider takes care of everything. This is not necessarily unique to serverless functions, as containers and virtual machines usually do this too, but with serverless functions, you don't even need to worry about the operating system or software running your code. The advantage of not managing your hardware and operating system is that you can get started a lot faster and not have to worry about as much.

The State of Serverless Functions

Language support

You can use almost any language with serverless functions. Whether you are using JavaScript, Go, or C, most serverless function providers support them. However, if you use a V8-based serverless function setup (most edge serverless function setups do this), language support might be more limited. Since V8 is primarily a JavaScript engine, the best-supported language is JavaScript. However, sometimes you want to use languages that do not support compiling to JavaScript. The solution is often WebAssembly, a portable assembly-like language that most modern languages support as a compilation target. WebAssembly also has other advantages, like how it can often perform faster. For more information on WebAssembly, you can look at our article on WebAssembly.

Production readiness

Serverless functions are used by many different companies and are supported by some of the biggest names in web hosting like AWS and Cloudflare. While serverless functions are somewhat new, they are still very production-ready.

Running on the Edge

Edge serverless functions are still experimental for the most part. However, some services are battle-tested, namely AWS Lambda@Edge and Cloudflare Workers. These services have existed for multiple years and are used by companies like NPM and Amazon. There are also other more recent services offered by companies like Vercel, Netlify, and Fastly.

Conclusion

That is it! Hopefully, now you understand serverless functions, why they are helpful, and what state they are currently in. If you liked this article, be sure to sign up for the mailing here. I hope you learned something, and thanks for reading.

State of the Web: Deno

AsyncBanana — Sun, 09 Jan 2022 22:04:56 +0000

Deno is a modern JavaScript runtime, competing with Node.js, that promises features like secure I/O and built-in TypeScript support. Ryan Dahl, Node.js' original creator, created Deno, building it in Rust.

Background of Deno

In Ryan Dahl's talk Ten things I regret about Node, he talked about many problems with Node. This includes things like Node's failure to embrace web standards, security, Node's way of compiling native modules (GYP), and NPM. Then, he revealed Deno. Deno was a new project that fixed many of the problems Ryan Dahl had earlier mentioned, along with extra advantages like built-in TypeScript support. Ryan Dahl initially built Deno in Go but later switched to Rust.

Since Deno was first announced, it has made significant progress. 1.0 was released in August 2020, and companies like Slack have adopted Deno. In addition, Deno has also released their own edge serverless function platform, Deno Deploy.

Why Deno is significant

Security

V8 is a sandboxed language that makes it impossible for code to do something outside of its boundaries. However, Node.js allows access to things like networking and the filesystem inside the sandbox, which removes the security benefits of V8. Even for trusted programs, this can be hurtful because insecure code or malicious dependencies could deal significant damage and steal information.

Deno solves with a system of permissions. These permissions make you define precisely what the program can do outside of the sandbox, like filesystem access and environment variables. For example, if you wanted to allow for reading files within the local assets directory, you would run Deno with a command like:

deno run --allow-read=./assets

Because of these capabilities, you can ensure that your code does not reach outside of its boundaries, increasing security.

Standardized APIs

Because the Node.js and web platforms evolved in parallel, they have many differences. There are many examples of this, like the module system and HTTP requests.

ECMAScript Modules and CommonJS

When Node.js was first created, JavaScript could not use other modules beyond embedding them in <script> tags and using them from the global window scope. Since HTML and the window were unavailable on the server, Node.js needed a module format. Nodejs decided to adopt a form of CommonJS, which was a popular, simple, synchronous module format. However, CommonJS was not native to browsers (you would have to use a library like Browserify), and there were differences between implementations of CommonJS.

Years later, in 2016, a new module specification called ECMAScript Modules (ESM) was finalized in ES6. This module specification would work without any libraries in browsers. Additionally, it would solve many problems with CommonJS, like asynchronous module loading and tree shaking. However, it took a while for Node.js to add ESM support, and even after that, ESM adoption in Node.js was not very high, with the majority of NPM packages still only include CommonJS versions. Additionally, Node.js does not have an entirely standards-compliant ESM implementation and differs in things like including .js file extensions.

In contrast, Deno only works with entirely standards-compliant ESM. This makes using Deno a lot simpler for both users and library authors. Speaking from experience, using one module format is a lot simpler than including both ESM and CommonJS. Deno also is more straightforward in that it sticks to the standards, so you know that your module code works correctly in browsers.

HTTP Fetching

Sending HTTP requests is another area of incompatibility which Deno solves. Node.js allows for HTTP requests through the http and https standard library functions. However, the modern way of running HTTP requests on the web is through the fetch() API, which is standardized and is simpler than http. Node.js does not support fetch(), and so people have had to turn to using packages like node-fetch for the simplicity of fetch() or cross-fetch for full cross-platform compatibility. This is problematic because it is another dependency needed, and it is not immediately available without importing. However, Deno supports the fetch() API by default, which solves these problems.

Decentralized Module Hosting

No, just because it is decentralized does not mean it uses blockchain 😉 (although there is a Deno package hosting service that is backed by blockchain). Instead, Deno's decentralized module hosting allows you to request modules by URL instead of from a centralized package database like NPM. Doing this allows for more freedom in module hosting. Deno does offer a module hosting service itself at deno.land/x, but there are many others you can use, and you can even link to any ESM CDN or something else that serves a JavaScript file. Many people worry about the remote code changing because it is not necessarily controlled, but most Deno module hosting services are immutable, and Deno caches the remote file, so it only changes if you explicitly reload the cache.

Built-in TypeScript support

Deno allows you to directly run a TypeScript file like JavaScript without passing it through a compiler. Deno even optimizes this process by caching the resulting JavaScript and using SWC, a fast Rust-based compiler, if type checking is not required. Built-in TypeScript support increases efficiency because you don't need to set up a build step if you are building an application with TypeScript. There are ways to do automatic TypeScript compiling in Node.js, like through ts-node, but they are not as feature-rich and are not installed by default.

The State of Deno

Ecosystem

Currently, this is the biggest problem with Deno and is a big reason why most Node.js developers are not migrating to Deno (this is a nasty problem because if Node.js developers don't migrate, the ecosystem grows more slowly). There are 3,501 modules on deno.land/x, compared to 1.3 million on NPM. However, many people use other package hosting services (see "Decentralised Module Hosting" above), and most modern web packages should work on Deno. The biggest blockers to Node compatibility are CommonJS and the Node API. Deno provides a Node.js compatibility mode, but it is experimental.

Development

Deno is very actively developed, with monthly releases and new features in each release. Deno is even backed by a official company, which can be both good or bad depending on how you look at it. There are more than 600 contributors to Deno, which is growing. Basically, Deno is a very actively maintained project

Deployment

Deno can be deployed pretty widely, although not as widely as Node.js.

Containers & Managed VMs

Deno has ok support for various container services. Deno.land provides an official Docker image for services that support Docker. However, while most popular container services support Deno, the support is often unofficial and not always maintained. Here is a list of tools and resources for running Deno on container services:

Serverless Functions

Serverless is where the Deno company comes in. Their primary commercial offering is Deno Deploy, a serverless edge function runner for Deno scripts. It is conceptually similar to Cloudflare Workers in that it uses V8 Isolates for ultra-fast startup times. The advantage of Deno Deploy is that it includes the Deno API and all of the other features that make Deno so helpful. However, Deno Deploy is still in beta, so you might want to look elsewhere right now. Here is a list of tools and resources to run Deno on various serverless function providers:

Conclusion

Deno is an up-and-coming technology and might someday replace Node as the primary way to run JavaScript. Join the mailing list here if you want to learn more about emerging technologies in web development weekly. I hope you learned something from this, and thank you for reading.

Building the fastest object and array differ

AsyncBanana — Sat, 01 Jan 2022 23:14:34 +0000

I maintain Microdiff, a performance and size optimized library for deep object diffing.
Someone posted in a Microdiff issue that asked me to write a blog post about how I made Microdiff fast.

I believe that an explainer (perhaps a blog post?) of the inefficiencies you've noticed with other libraries and how you've overcome them (including the "edge cases" you're saying are unsupported) would be very interesting. They'd also help correctly interpret the benchmark results.

So, I decided to do that. This blog post describes how I made Microdiff faster than most other object and array diffing libraries.

Disclaimer: I am very biased on this subject.

Intro to diffing

Diffing (difference tracking) is tracking what is different between two objects. For example, let's say you have two objects, object a and object b.

const a = {
    bananas: true,
    apples: true,
    peaches: true
}
const b = {
    bananas: true,
    apples: false,
    lemons: true
}

With Microdiff, to get the differences, you would do this

import diff from "microdiff"
console.log(JSON.stringify(microdiff(a,b)))

/*
[
    {
        'type':'CHANGE',
        'path':['apples'],
        'value':false,
        'oldValue':true},
    {
        'type':'REMOVE',
        'path':['peaches'],
        'oldValue':true
    },
    {
        'type':'CREATE',
        'path':['lemons'],
        'value':true
    }
]
*/

As you can see, all changes, whether values were changed, added, or removed, were recorded. Diffing is essential for many things, like Virtual DOMs, because they need to record changes in elements. Now, let's learn about the problems with the diffing ecosystem before Microdiff.

The Diffing Ecosystem before Microdiff

The diffing ecosystem was in a bad state. Many libraries had millions of downloads but were not maintained actively and were poorly made. Now, let's look at our first example, deep-diff.

Deep-Diff

Deep-Diff is one of the most popular JavaScript libraries for deep object diffing. It gets between 1 and 2 million downloads each week, and tools with more than 10k GitHub stars use it. However, there are many flaws with it. First, the last commit was in 2019, and it doesn't follow modern conventions like supporting ESM and offering bundled TypeScript types.

Additionally, there are problems with its size and performance. It has a size of 5.5kb minified and 1.9kb Gzipped. That size is not terrible, except that this is a simple utility and therefore should have an even smaller size. In comparison, Microdiff has a size of 0.9kb minified and 0.5kb Gzipped. Now, for performance, Deep-Diff also does not do that well. It is not made to be small or fast, as it has many different functions, which adds significant overhead. Additionally, it does not do things like grouping type behavior to improve performance. Because of all these things, Microdiff can be as much as 400% faster.

Deep-Object-Diff

Deep-Object-Diff is another popular diffing library. While it has not been updated since 2018, it has some of the modern features that Deep-Diff was missing, like ESM and built-in TypeScript types. Additionally, it can perform at speeds near Microdiff if you use the basic diffing. However, there are still two problems with it, the size and the information it provides. First, while it is not as big as deep-diff, it is still significant, weighing in at 5.2kb minified and 1kb Gzipped. Second, because of the way the output is designed, it provides few details. Where Microdiff provides the change type, new value, old value, and path, the most detailed diff (detailedDiff) of Deep-Object-Diff does not provide the old value. Additionally, if you want near Microdiff speeds, you have to use the primary diff function instead of detailedDiff, making it so you do not know the change type.

jsdiff

While JSDiff supports object diffing, it is primarily designed for diffing text. It is big, at 15.8kb minified and 5.9kb Gzipped, and extremely slow (2100% slower than Microdiff). I will not go in-depth on why it is so slow because it is simply not designed for object diffing.

What Microdiff does to fix this

Performance focused architecture

Microdiff fixes many of these problems by focusing on performance and size without sacrificing ease of use. Instead of having a web of complicated functions, it is a simple recursive function.
Microdiff also uses strategies like combining type behaviors to reduce size while increasing performance. For example, lets say you want to see the differences between RegEx and JavaScript Dates. In order to get accurate change tracking, you have to stringify the RegEx and turn the Date into a number. A naive implementation of this might be like this:

if (value instanceof RegExp && value2 instanceof RegExp) {
    return value.toString() === value.toString()
} else if (value instanceof Date && value2 instanceof Date) {
    return Number(value) === Number(value2)
}

This works, but what if you needed to check new String() objects or new Number() objects too? (new String() and new Number() do not create primitives, so you have to convert them into primitives like with the Dates and RegExs) To fix this without introducing a lot of if thens, Microdiff's implementation of this is more like this:

const richTypes = { Date: true, RegExp: true, String: true, Number: true };
if (richTypes[Object.getPrototypeOf(value).constructor.name]) {
    return isNaN(value) ? value.toString() === value2.toString() : Number(value) === Number(value2)
}

This code first gets a list of types that cannot be compared directly (richTypes). Then, it checks if the value is one of those types. If it is, then the code checks if the value can be coerced into a number with isNaN. If it can (which is true in the case of dates and new Number()s), it checks the version coerced into a number. If not (which is the case for RegEx and new String()), it coerces the value into a string and compares that version. The actual rich type conversion logic is not that different in Microdiff, although there are a few differences that decrease the size and help the logic fit in with the rest of the code.

Things like that are part of why Microdiff is fast. However, another reason is that it focuses on only more common cases instead of every possible edge case.

Focusing on 99% of cases instead of fixing all edge cases

In this regard, Microdiff has improved massively since its release. In fact, since writing the initial explanation, Microdiff has added support for more rich types and cyclical references. However, there are still cases where Microdiff has less correct behavior, like when comparing objects with prototype properties, because it includes prototype properties. Type combination solves this for the listed types but not for all other types. In testing previously, ways of excluding prototype properties have not been fast. However, I might add a way for you to pass custom inheritance types for string/number coercion, which might help for certain things. Nonetheless, currently, this is not possible.

Conclusion

In conclusion, Microdiff is the fastest diffing library because of its performance-focused architecture and the focus on 99% of cases, and Microdiff is still able to also use modern features and make it possible to use easily. If you are interested in Microdiff, check out the GitHub repo. I hope you have learned something from this, and thank you for reading.