Hi, I’m Dustin Boston, a creative and curious Sr. Frontend Engineer at True Anomaly, in Los Angeles, California. I specialize in frontend web development with JavaScript, React, and Node.js. You can also find me on GitHub and LinkedIn.
Rather than an empty “shell component” that takes data and (using JavaScript exclusively) renders the entirety of its contents, web components encourage an approach of composing core content with HTML and then wrapping it in a custom element that enhances its contents with additional functionality.
This perspective highlights how the web uses progressive enhancement by default. It can also make your web components much smaller.
Over the holidays we took a trip to Arizona. We visited the McDowell Sonoran Preserve, which is absolutely beautiful.
Development is the execution of a map toward a goal while research is the pursuit of a goal without a map… In this sense, when it comes to research, speed should be considered an anti-signal and slowness a virtue.
If you can define the steps for a task, then the task is development. Conversely, the tasks that can’t be defined (because there isn’t a known solution) are research tasks.
Thin Desires Are Eating Your Life
A thick desire is one that changes you in the process of pursuing it. A thin desire is one that doesn’t… Thick desires are inconvenient. They take years to cultivate and can’t be satisfied on demand… The thick life doesn’t scale.
I think Cal Newport would call this Deep Work and Quality Leisure Time. I love the idea of doing things in ways that don’t scale.
NoLoJS: Reducing the JS Workload with HTML and CSS
…as new HTML and CSS methods gain traction, we need to consider replacing some “standard” JS patterns with new methods that require no, or lo, JS.
This article contains examples of accordions, expanding form Field elements, input with autofilter suggestions dropdown, modals and popovers, offscreen nav, smooth scrolling, and sticky content.
Today my coworker made an interesting comment about some code I wrote. The code looked like this:
const isParty = !cake || !iceCream ? false : true;My intention was to say “if there isn’t any cake or there isn’t any ice cream, then it’s not a party.” And I think we can all agree with that. My coworker said that maybe we should “De Morgan” this code. So I took to the internet to understand what that meant!
Interestingly, there’s a whole field of study devoted to logic statements like this. And there are two rules in particular that apply directly to this scenario. So let’s take a look at them and see how they could improve our party code.
not (A and B) is the same as (not A) or (not B). Since our party code is in the second form, we know we can refactor it to make our intention much more clear:const isParty = !(cake && iceCream) ? false : true;not (A or B) is the same as (not A) and (not B). If we were less picky about our parties, we might have written: const isParty = !(cake || iceCream) ? false : true;. This can be refactored to:const isParty = !cake && !iceCream ? false : true;The goal of De Morgan’s laws in software engineering is to make the code easier to understand. And it does. But there’s still more to be desired. So here’s another principle:
In software (and English) we affirm that something is true rather than negate that it is false, because negation makes things harder to understand.
So instead of saying “it’s not a party if there isn’t any cake or ice cream,” we should say, “it’s a party if there is cake and ice cream.” Here’s how that looks in code. Given:
const isParty = !(cake && iceCream) ? false : true;we can flip the condition to that it reads in the affirmative:
const isParty = cake && iceCream ? true : false;Then we can refactor that by dropping the ternary altogether:
const isParty = cake && iceCream;That’s MUCH easier to understand!
This chart matches common Big-O notations with their names and relative performance ratings. Is illustrates how an algorithm’s efficiency worsens as its computational complexity grows.
| Notation | Name | Performance |
|---|---|---|
| O(1) | Constant | Excellent |
| O(log n) | Logarithmic | Good |
| O(n) | Linear | Fair |
| O(n log n) | Linearithmic | Bad |
| O(n^2) | Quadratic | Horrible |
| O(2^n) | Exponential | Horrible |
| O(n!) | Factorial | Horrible |
Neuroscience Says You Need a Personal Curriculum for 2026 by Jessica Stillman
I’ve been a fan of the DIY Degree, where you systematically study each area of a given field using real syllabi. The Personal Curriculum is a condensed version of the DIY Degree. Here’s how it works:
- Choose a topic you’re curious about.
- Select one book + one podcast episode + one long-form video about the topic to study
- Do one “homework” assignment such as writing a short essay or making a collage
Why make things harder by assigning yourself homework?
The brain thrives on cycles of challenge, feedback, and progress, yet adult life rarely makes space for that kind of experimentation
Going that extra mile with the homework ensures that your brain doesn’t get bored.
QuickJS is a tiny JavaScript engine written in C. Its author, Fabrice Bellard, created FFMPEG and QEMU. QuickJS can run outside of traditional browser environments. This includes packaging JavaScript applications for distribution.
As of writing, QuickJS supports ECMAScript 2023, so you can write modern JavaScript. It is also fast and well-tested.
One of the engine’s features is compiling JavaScript code into bytecode. Bytecode is a compact set of instructions that an interpreter can execute. It makes execution more efficient, which is perfect where performance is important. Additionally, the engine supports compilation of JavaScript into dependency-free standalone executables. We will use this feature to package JavaScript apps.
QuickJS’s small footprint is also suitable for embedded systems and resource-constrained environments.
Recently, Amazon announced its Low Latency Runtime (LLRT), built on QuickJS. According to Amazon, LLRT starts 10x faster and is 2x less expensive than other JS runtimes on AWS Lambda. That’s a pretty impressive use case.
Installing QuickJS in your development environment is straightforward. Here’s how to get started. Note that on Windows, you can use WSL with Linux.
Before jumping in, make sure you have Make and a C compiler like GCC or Clang.
The first step is to get a copy of the source code. You can download the source from the QuickJS website or by cloning it from the GitHub repository. We’ll download it from the website and untar the file:
wget https://bellard.org/quickjs/quickjs-2024-01-13.tar.xz
tar -xJf quickjs-2024-01-13.tar.xzThis command creates the directory quickjs-2024-01-13 with all the necessary source files. I’ll refer to this directory as quickjs from now on.
QuickJS does not rely on V8, WebKit, or Gecko. It is not compatible with NodeJS or Deno APIs. It does have access to the OS through its own APIs. To make sure your code is compatible with QuickJS, ensure the following:
QuickJS focuses on the core JavaScript language, so your code should be platform-agnostic.
For this simple Hello World app we’re putting our files into the quickjs directory. In a business context, you should keep your code separate from QuickJS. Otherwise, you can structure your project as you would any other JavaScript project. You can even use modules.
Once you have the source code, the next step is to compile it. This will convert the code into an executable you can run on your computer. Navigate to the quickjs directory with cd quickjs.
Finally, compile the source with the make command. QuickJS’s Makefile will detect your OS and choose the appropriate compiler and flags. Run:
makeOn macOS, Make will use Clang as the default compiler, whereas on Linux, GCC is more common. Compilation will take a few moments. Once completed, several new files will be added to the quickjs directory. qjs is the command-line tool for executing JavaScript files. qjsc is a tool for compiling JavaScript into bytecode.
You can run a simple JavaScript file to verify your installation. Create a file named hello.js with the following code:
console.log("Hello, QuickJS!");Save the file into the quickjs directory and then execute it using the qjs binary:
./qjs hello.jsIf QuickJS installed, you will see the message “Hello, QuickJS!” Now you have QuickJS set up and ready, it’s time to package an application.
To create a standalone executable, use the qjsc executable in the quickjs directory. You can execute it with these commands:
qjsc -o hello hello.js
./helloIf it works, you will see “Hello, QuickJS!” on your terminal. This is the file that we will distribute.
There are many flags that you can pass to qjsc. Try experimenting with each. For example, output bytecode instead of an executable. Or disable regular expressions to decrease binary size.
The executable for this “Hello, World!” example is 4.6 MB. It may seem large for such a simple program. However, consider the alternatives. Using deno compile I get an executable that is 76 MB. Compiling the hello.js file using Node 21 produces a 98 MB file. So, In perspective 4.6 MB seems pretty good.
You don’t need anything special to distribute a QuickJS-packaged application. Using the standalone executables, you have a range of distribution options.
QuickJS is portable. That means that it can run in many environments. When preparing for distribution, consider the target platforms. If you want your application to work on Windows, macOS, and Linux, you must build the app on each system.
Whether you’re developing IoT devices or building server-side tools QuickJS is a stellar option. It’s easy to use, fast, and produces relatively tiny executables.
Try experimenting with it, push its boundaries, and see how it can be used in your projects. What has your experience with QuickJS been? I’d love to hear your stories, successes, and lessons learned.