RSSAmplifier

Blog

Marvin Hagemeister

Musings about Preact, virtual DOM and all things related to JavaScript

marvinh.devRSS feed ↗31 posts

Latest posts

Speeding up the JavaScript ecosystem - oxlint and oxfmt

At a certain scale, the characteristics of software development change. We are seeing a massive surge in both the size of repositories and the volume of PRs. Consequently, the sheer number of CI runs required to keep a project moving is exploding. This demand for speed is being further accelerated by more and more work being done in parallel on a local machine. For these reasons, tools need to be…

DDoS'ing the human brain

In a traditional DDoS attack, a server is flooded with so many requests that it can no longer respond to legitimate ones. As developers in the age of AI, we are beginning to experience a version of this in our own heads. The AI provides a massive volume of traffic, and our "thinking context" is increasingly spent just trying to sort, manage and steer the flood. But is spending more mental energy…

Signals vs Query-Based Compilers

Over the winter holidays curiosity got the better of me and I spent a lot of time reading up on how modern compilers achieve interactivity in the days of LSPs and tight editor integrations. And it turns out that modern compilers are built around the same concept as Signals in UI rendering, with some interesting different design choices. Old Days: The Pipeline Architecture The classic teachings…

Building From First Principles

It's funny, sometimes I feel like I'm living in two different programming worlds. There is the online world on Bluesky threads, GitHub, blog posts or other platforms where discussions are often dominated by the latest frameworks, the hottest libraries or discussion that feel very abstract. Then there is the other world I live in, the one I share with my local developer friends. And honestly?…

The missing link in JavaScript tools

Lately, my mind has been occupied with finding ways to make tools simpler to work with. Our tools of today present a pretty fractured architecture. The frontend layer has to deal with many languages at once, ranging from custom templating languages, importing CSS to JSX or plain JavaScript. Each tool, the linter, formatter, type checker, test runner and dev server typically demands its own unique…

Speeding up the JavaScript ecosystem - Semver

Whilst dabbling with the Preact repo I noticed that running npm install takes more than 3s. This seems excessively long and piqued my interest. I was waiting for a good use case to try out cpupro anyway, so this seemed like a perfect fit. The tar library is kinda expected to be up there as a decent amount of time is spent extracting tarballs. What captured my attention was the semver package…

Speeding up the JavaScript ecosystem - Rust and JavaScript Plugins

Over the past year (2024) there has been a strong movement to rewrite JavaScript tools in Rust to make them faster. Rust is well suited for this as it runs much closer to hardware and doesn't rely on garbage collection. This makes it an ideal candidate for computationally intensive tasks. Linting in its basic form is such a task, as it involves parsing and traversing lots of source code. But there…

The modern way to write JavaScript servers

If you've visited Node's homepage at some point in your life you have probably seen this snippet: js import { createServer } from "node:http" ; const server = createServer ( ( req , res ) => { res . writeHead ( 200 , { "Content-Type" : "text/plain" } ) ; res . end ( "Hello World! n" ) ; } ) ; // starts a simple http server locally on port 3000 server . listen ( 3000 , "127.0.0.1" , ( ) => {…

Speeding up the JavaScript ecosystem - Isolated Declarations

Unbeknownst to many, the new isolatedDeclaration feature shipped in TypeScript 5.5 is much more important than you might realize. It just revolutionized how we package and distribute JavaScript code. You don't need to create *.d.ts files manually anymore by invoking the tsc compiler. "Go to source" (the thing when you do ctrl+click or cmd+click on macOS) actually works now and it leads you right…

Speeding up the JavaScript ecosystem - Server Side JSX

In the realm of web development, the efficiency of server-side rendering HTML plays a crucial role in delivering fast and responsive user experiences. However, a notable challenge arises from the existing JSX transforms that turn JSX into valid JavaScript: They are primarily tailored for browser environments, often generating excessive memory overhead and causing frequent Garbage Collection…

Speeding up the JavaScript ecosystem - Tailwind CSS

Admittedly, I currently don’t have a bigger project written with Tailwind CSS at hand at the moment. Those that do use Tailwind are too small in scope to make a meaningful performance analysis. So I thought what better way than to profile Tailwind on its very own tailwindcss.com site! Right at the start I ran into a problem though: The project is built with Next.js which makes it very difficult to…

Speeding up the JavaScript ecosystem - The barrel file debacle

Let's imagine you are working on a big project with many files. You add a new file to work on a new feature and import a function from another directory into your code. tsx import { foo } from "./some/other-file" ; export function myCoolCode ( ) { // Pretend that this is super smart code :) const result = foo ( ) ; return result ; } Excited about finishing your feature, you run the code and…

Speeding up the JavaScript ecosystem - Polyfills gone rogue

In the previous posts we looked at runtime performance and I thought it would be fun to look at node modules install time instead. A lot has been already written about various algorithmic optimizations or using more performant syscalls, but why do we even have this problem in the first place? Why is every node_modules folders so big? Where are all these dependencies coming from? It all started…

So you want to render colors in your terminal

If you've been writing command line tools for other developers to use, there will come a time where the clarity of the output can be enhanced through colors. What appears to be simple on the surface gets a bit messy as soon as you dive into the details on how colors are supported in various terminal emulators. Funnily, much of this complexity is due to historical reasons which have been kept alive…

Speeding up the JavaScript ecosystem - draft-js emoji plugin

I received a very interesting issue via email from Josh Goldberg regarding a website that froze for about 2-3s. The website uses the draft-js rich text editor for some inputs and he was able to narrow it down to something going wrong in the emoji plugin for draft-js. So we decided to hop on a call and continue debugging together. Capturing a quick recording via Chrome's profiler confirms the…

Speeding up the JavaScript ecosystem - npm scripts

If you’re working with JavaScript you’ve likely used the "scripts" field in package.json to set up common tasks for your project. Those scripts can be executed with npm run on the terminal. I noticed that I opted more and more to just call the underlying command directly instead of shelling out to npm run , mostly because it's noticeably faster. But what makes them so much slower in comparison?…

Speeding up the JavaScript ecosystem - eslint

We've talked quite a bit about linting in the past two posts of this series, so I thought it's time to give eslint the proper limelight it deserves. Overall eslint is so flexible, that you can even swap out the parser for a completely different one. That's not a rare scenario either as with the rise of JSX and TypeScript that is frequently done. Enriched by a healthy ecosystem of plugins and…

Speeding up the JavaScript ecosystem - module resolution

In part 1 of this series we found a few ways to speed various libraries used in JavaScript tools. Whilst those low level patches moved the total build time number by a good chunk, I was wondering if there is something more fundamental in our tooling that can be improved. Something that has a greater impact on the total time of common JavaScript tasks like bundling, testing and linting. So over the…

Speeding up the JavaScript ecosystem - one library at a time

Whilst the trend is seemingly to rewrite every JavaScript build tool in other languages such as Rust or Go, the current JavaScript-based tools could be a lot faster. The build pipeline in a typical frontend project is usually composed of many different tools working together. But the diversification of tools makes it a little harder to spot performance problems for tooling maintainers as they need…

Running 1000 tests in 1s

Recently, I tweeted that the whole test suite for Preact , a modern framework to build web apps, runs in approximately 1s. It's composed of 1003 tests at the time of this writing that run in the browser and assert against the real DOM. Here is a video of what that looks like: That tweet struck a nerve, because those numbers aren't even close to be achievable in any of the popular test runners in…

How to skew benchmarks in your favour

A common rite of passage for every frontend framework is to compare the execution speed with the established players. After all you want to know if your efforts paid off. Where does your framework positions itself on the performance scale? Maybe you want to make this the main selling point of your framework, so benchmarks can be a motivating factor in squeezing just that little bit more speed out…

A look at web components

About a week ago, I spent time looking at web components, specifically how we can ease converting Preact components. One of my friends is playing around with them at work and it seemed like a fun challenge to take on. Personally I've never used web components before that. I just didn't have the chance to work on a project which required them so far. So my understanding of them was formed through…

Portals considered harmful

So today I spent a few hours going through various GitHub repos to see how the Portal component in various virtual-dom Frameworks is used (and abused?) in the wild. It's always a fun thing to do for anyone working on frameworks, because users usually discover new ways of how to use features in ways it wasn't intended by the authors. Sometimes something cool comes out of and sometimes so good that…

Stencil Store Challenge

When Manu from the Stencil team pinged me on Twitter regarding a code golfing challenge, I just couldn't resist! So I thought this could be a good exercise to apply techniques we use while working on Preact to a codebase that's foreign to me. Getting ready After the usual git clone and npm install we're good to go. Before we dive in immediately, we should get ourself familar with the overall goal…

State of Preact Devtools #2

A little bit of time has past since the announcement that we are working on our very own devtools extension. A lot has happend since then and I'd love to share some news about what's happening behind the scenes. The good news: I'd consider the current code feature-complete and the next will be the polishing phase. It's safe to say that things are progressing nicely without any hiccups. Screenshot…

State of Preact Devtools

As many of you know the react team released a revamped devtools extension recently. The improvements are countless and not just for endusers, but also the protocol has changed substaintially for the better. Whereas the previous iteration always asked for the information of the complete tree and every detail at once, the new version follows more a pull based approach. It only requests the data it…

Hooks vs Classes a few months later

It's been a while now that the hooks concept took over the frontend world by storm. Originally researched by the very talented React team it solves some longstanding issues surrounding the best way to make behaviours easily composable and shareable. A lot has been written about what they are and how to use them, so I won't repeat that here. Instead I'd love to share the maintainers perspective on…

Applying Preact minification tricks to CSS

One thing we're known for over at Preact is making code a lot smaller than it originally was. In fact the tiny size is one of the main strengths of Preact. A few days ago a friend of mine Jan Willem Henckel shared a link to CSSBattle , where users can compete against each other in trying to replicate an image with just CSS and HTML. The kicker? You have to use as few characters as possible to get…

The Double Encoded VNode

Someone in our Preact Slack channel ( join here ) was running into an issue where the page would be blank as soon as the page loaded. Luckily we got a nice exception logged in the browser console. Error stack traces are awesome as they point you directly to the portion where the error occured and allow you to follow back the trail to see how the error came to be. bash preact.mjs:256 Uncaught…

When should I use preact compat?

What's the difference between preact and preact/compat ? That's a great and one of the more popular questions if you check out the preact tag on StackOverflow. Preact advertises itself as the thinnest possible virtual-dom 3kB abstraction over the real DOM with a react-like API 🚀. This sentence is quite a mouthful, but the key is the last part: " react-like API". While the high-level concepts are…

Preact's best kept secret

I though I'd start the blog with something special that not many Preact users may know about. It's one of the least known features and also one of the most powerful ways to extend Preact: Option-Hooks. They allow anyone to plug into our reconciler and extend Preact without needing to make any modifications in our core. This power is what enables us to ship various addons like preact/compat and…