Cleaning up package.json keys

I'm in the process of cleaning up some npm packages that haven't been touched in a while, and part of that is pruning all the cruft that has been accumulated in package.json over the years.

I was looking for a canonical order to sort the keys by, and thought the order the npm docs specify the configuration options made sense.

Of course, after manually sorting one package.json file—which probably took 2 minutes—I decided to spend 30 minutes to find our how I could automate sorting the other two.

Luckily there's an npm package for everything. With the sort-package-json package you can go sort your package.jsons in a logical order.

npx sort-package-json **/*/package.json

That's all I had to do to keep my monorepo clean and tidy.

JavaScript Gom Jabbar

You stop to count how many tools and parsers work on your codebase: TypeScript, esbuild, swc, babel, eslint, prettier, jest, webpack, rollup, terser. You are not sure if you missed any. You are not sure if you want to know. The level of pain is so high you forget about anything else.

We've come a long way, but we're not there yet.

Local or session storage?

Local storage tends to be the obvious place to persist data locally in a web application. We tend to grab straight for localStorage, but it's not the only tool in our workbox. Another option is sessionStorage. Let's review their similarities and differences, and determine when to use which.

Read more

Reusable Alpine Components by Ryan Chandler

I've been using Alpine often lately. Ryan has written a lot of good stuff on Alpine, but his reusable components post is what really got me kickstarted.

You should be careful to not abstract too early. If you are finding it difficult to manage your Alpine component from the x-data attribute, this one is definitely for you.

The way this article builds up was very helpful: only use the level of abstraction you need:

  1. No abstractions
  2. Extract to a component function
  3. Use x-spread
  4. Mix in other data

The window.matchMedia API

To execute a piece of code when the viewport is a certain size, the first thing that comes to mind is adding a resize event listener to the window object. This is one way, but not always the best. Sometimes the lesser known window.matchMedia API is a better fit.

Read more

Embed a web page with a web component and the shadow DOM

Today, my colleague Freek asked for help embedding the webview of an email campaign in an iframe. He needed it in an iframe because embedding the HTML directly caused layout issues because the website's CSS clashed with it.

After setting up the iframe, we needed to find a way to dynamically resize it based on its contents to avoid double scrollbars on the page. While possible, it required some icky scripting.

I took a step back. The problem at hand was that the CSS needed to be scoped somehow. While iframes were the only solution for a long time, these days we have the shadow DOM.

Read more

A Tale of Client Side Framework Performance

Jeremy Wagner measured some performance differences between React and vanilla JavaScript. While I'm not surprised that running your code on bare metal code is faster than a framework, it's interesting to see some exact numbers.

React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.

If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.

Even with server-side rendering, React and other virtual DOM frameworks add loading time because they need to load more code and hydrate the page before it's interactive.

A vanilla addEventListener callback performs about 40 times faster (!) than an event handled in a React component. React's overhead worth when you have a lot of complex state, not "simple state" like menu toggles.

Read the full article on CSS-Tricks.

Shotgun upgrade your npm dependencies with yarn upgrade --latest

Every now and then I do a quick checkup of a project's npm dependencies. I like to keep them up to date by often doing small upgrades. It's a lot less painful than doing large upgrades once a year.

One annoying part of this process is ensuring every dependency is on the latest major version. For example, if a project requires lint-staged@^8.0.0, yarn upgrade won't upgrade it to lint-staged@^9.0.0 (luckily of course, it's the behaviour I want during everyday development).

Today I learned about yarn upgrade --latest, which will upgrade all dependencies to the highest available version, despite the version constraints in your package.json file. lint-staged@^8.0.0 would happily upgrade to lint-staged@^9.0.0, even if it breaks semver boundaries.

Read more