DEV Community: Florian Rappl

My OSS Projects: Netpack

Florian Rappl — Tue, 06 Oct 2026 08:06:29 +0000

This is the fifth post in my "My Open-Source Projects" series, where I go through some of the OSS projects I started or maintain and tell you the story behind them. So far: AngleSharp, MAGES, Piral, and Electron.NET. This time it's the youngest of the bunch: Netpack - a project that started as an experiment, is not at 1.0 yet, and has a development story that looks very different from everything above.

What Is Netpack, Actually?

Netpack is a web bundler written in C#/.NET. You point it at an index.html (like you would with Vite or Parcel) or directly at a .js / .ts file, and it follows everything that is referenced from there, bundles it, optimizes it, and writes the result to disk.

npm i -D netpack
npx netpack bundle src/index.html --minify

Yes, I know. Another bundler. I can hear the sigh from here.

But there's a twist that makes this one worth a post: the CLI is a single native binary (no .NET runtime to install, nothing to warm up), it ships with batteries included (TypeScript, JSX, CSS & CSS Modules, Sass / LESS / PostCSS including Tailwind, images, Vue, Astro, Svelte, Solid, ...), and - since it is written in C# - it can also be used as a plain .NET library or an MSBuild task. That last part is where I see the real future of the project. More on that later.

The Question

It all started during my winter vacation with a simple question:

Can web tooling written in C#/.NET compete with tooling written in Rust, Go, or Zig?

Look at the tools we use every day: esbuild is written in Go, rspack and SWC are written in Rust, Bun is written in Zig. These languages are a great fit for native tooling - and the results speak for themselves. Their developer ergonomics, on the other hand, are... let's say "acquired tastes". I'm a .NET guy. I find C# much more approachable than Rust and more capable than Go. So the question was: could .NET work here? Maybe only under certain constraints - but could it?

I wrote it up back in January 2025, included a lot of caveats, and ended with a question to the community: viable idea or just trash? This post is, in a way, the long answer.

Step 1: Fake a Bundler with a Regular Expression

To find out, I started with the most simple approach imaginable - a fake bundler:

Open files
Read their content
Use a regular expression to find things like import statements
Resolve the linked modules
Look at package.json files to figure out where a package's entry point lives

(If you've read the AngleSharp post you might feel a disturbance right now. Yes: I am aware that "parse code with a regex" is exactly the thing I spent a decade telling people not to do. This was an experiment. Experiments are allowed to be dirty.)

And quite quickly it became clear that plain .NET is, as expected, too slow for this. Not because C# is slow at reading files or walking graphs - the IO and the algorithms are perfectly fine. What kills it is the startup cost.

By default, .NET compiles your code to an intermediate language, and a JIT (just-in-time) compiler turns that into machine code while the program runs. That needs the .NET runtime to be present, started, and then fed with your code every single time. For a long-running server, nobody cares. For a bundler that you start, let finish in a few hundred milliseconds, and then throw away - it's the whole game.

Step 2: To Beat Native, You Need Native

The experiment wasn't over, though, because .NET has an answer for that: AoT (ahead-of-time) compilation. Instead of shipping intermediate language and compiling at runtime, you compile everything to machine code beforehand. The runtime is fused into the binary, there is no JIT, and the program starts right away.

And... it worked. This proved that the IO performance is truly native and that C#/.NET is in the same ballpark as Rust, Zig, or Go for this kind of tool. (There is still a garbage collector in the room, so it is not identical - but the part that kills small tools, the startup, was gone.)

AoT does come with its own challenges. Some libraries cannot be used or need work to be AoT-compatible, and you lose some of the dynamic flexibility that .NET is known for - no runtime reflection, for instance. But for a tool like this, it's a deal I'm happy to take.

Step 3: Real Parsing, Borrowed Parts

Armed with that insight, I replaced the regular expressions with actual code understanding. For the JavaScript side I used a third-party parsing library (Acornima). For HTML and CSS I used my own project, AngleSharp (which, I'm happy to report, is still doing great - it gets a second career here).

The result was a bundler fast enough to compete with the established tools, such as esbuild or rspack - at least on the benchmark projects I used back then. It could only handle plain JavaScript, though. No TypeScript, no source maps, no real configuration. I published the experiment, called it done, and moved on.

For quite a while that's where I saw the project: done. A successful experiment, a proof that the idea works, a repo with a README and some benchmark numbers. The missing features (TypeScript above all) would have required forking the parsing library, and I only wanted to do that "if there is enough buzz around the project".

Plot twist: it wasn't buzz that got Netpack moving again.

Step 4: Enter the AI Pair Programmer

With the advancements in AI-assisted software development, I took another look. And I realized that many of the missing things - full TypeScript support being the biggest one - could now be added easily.

Here's what made the difference: the AI (mostly Claude) has sufficient understanding of the project to make modifications within the given architecture. That's the key part. The original architecture of the bundler stayed intact. The AI doesn't redesign the thing - it adds missing features and takes care of important bug fixes, inside the structure that was already there.

That's not luck, by the way, it's a bit of homework. The repository contains a CLAUDE.md that explains the architecture and the non-obvious conventions: how the graph is built, how output formats and platforms plug in, that everything has to stay AoT-safe (no reflection, source-generated JSON), and even which names look like they need "tidying" but must never be touched because they hold the NuGet / AoT story together. There's an xUnit test suite with its own conventions, and the file explicitly tells the AI not to claim that tests pass when it couldn't run them. Good rules for humans, too.

The results speak for themselves. The native toolchain today includes a hand-written JavaScript / TypeScript / JSX tokenizer, parser, printer, minifier, and tree-shaker - no Acornima, Babel, or SWC involved. Compare the numbers: in January 2025 I was debating whether the project deserved a fork of someone else's parser. Today it has its own.

And the pace went from "weekend experiment" to "release train":

Note that the axis switches from months to days after the break - there's simply no other way to fit it on a screen. The first GitHub release (0.1.0) was on July 10th, 2026. By August 19th we were at 0.8.2. That's fifteen versions in under six weeks, including days with two or even three releases. My commit history now reads like a speedrun.

Not everything on that timeline is mine, either. Since version 0.6.0, there are also contributions from the outside - most notably from mehrabix, who contributed a whole range of things: the plugin hook system, improved watch mode and incremental builds, asset inlining, the preview command, .env support, better error messages with source snippets, CSS code splitting, split-chunks grouping, and more. A massive thank you!

How It Works

Whatever you throw at it, the shape of a build is always the same: Netpack parses the entry, follows what it references to build a module graph, groups that graph into chunks (pulling shared code into its own chunk), and renders each chunk to disk.

A few details worth knowing:

Most things are handled natively in C#: TypeScript, JSX, CSS, CSS Modules, images (optimized with SkiaSharp in the CLI), JSON, HTML, and even the Vue and Astro compilers - no Node.js round trip required.
A few things have a canonical compiler that lives in the JavaScript world: Sass, LESS, PostCSS (including Tailwind), Svelte, Solid, and .codegen files. For those, Netpack has an opt-in Node bridge that talks to your locally installed packages. If you don't use them, you don't need Node.js for the build. (Yes, the .NET bundler sometimes calls Node. I see the irony too.)
The dev server watches the file system, rebuilds on change, and hot-swaps modules where it can - including React Fast Refresh if react-refresh is installed. If it can't, it falls back to a full reload.
Some things are a bit unusual, and I like them: if your HTML entry point contains an import map, the entries in that map are automatically treated as externals. And if you mark dependencies as --shared, Netpack builds them as their own chunks and wires them into an import map for you.

Getting Started

You install it from npm. The wrapper package picks the right native binary for your platform (Windows x64 / ARM64, Linux x64 / ARM64, macOS ARM64):

npm i -D netpack

Then there are three main commands:

# one-shot production build
npx netpack bundle src/index.html --minify --sourcemap

# dev server with HMR (default port 1234)
npx netpack serve src/index.html

# inspect what ended up in your bundle
npx netpack analyze src/index.html --interactive

You don't need an HTML file; a script is a fine entry point, too: npx netpack bundle src/main.tsx. Your package.json scripts will look like they always do:

{
  "scripts": {
    "dev": "netpack serve src/index.html",
    "build": "netpack bundle src/index.html --minify --sourcemap",
    "analyze": "netpack analyze src/index.html --interactive"
  }
}

Want React and friends as separate, cacheable chunks wired up through an import map? Mark them as shared:

npx netpack bundle src/index.html --shared react --shared react-dom

The analyze command deserves a shout-out: besides the interactive graph explorer, it audits the dependencies that actually made it into your bundle against known vulnerabilities and gives suggestions for where your chunks could be split more efficiently. (Tree-shaken packages are not audited - only what ships.)

For module-federation fans (hi, Piral people): a federation.json entry point gives you Module Federation and Native Federation remotes. Netpack also supports ESM, CommonJS, UMD, and SystemJS output, plus web, Node, and Deno targets. Everything is covered in the documentation.

Using It from .NET

Here's the part where being written in C# pays off. Netpack is not just a CLI - there are three ways in:

1. The MSBuild task. NetPack.Build bundles your web entry point into wwwroot as part of dotnet build / dotnet publish:

dotnet add package NetPack.Build

<PropertyGroup>
  <NetpackEntry>ClientApp/src/index.html</NetpackEntry>
</PropertyGroup>

dotnet build
# -> wwwroot/index.html, wwwroot/index.js, wwwroot/styles.css, ...

That's it - no npm run build step to remember, no extra pipeline stage. There are more MSBuild properties (NetpackMinify, NetpackSourceMaps, NetpackFormat, NetpackEntryNames, ...) and an item group for externals. It's built on the core library and ships a pure-managed image processor, so there's no native dependency to worry about.

2. The library. NetPack.Core is the bundler engine as a managed library. Its only dependencies are AngleSharp and its CSS companion (see, I told you it's still doing great):

using NetPack;

// in memory ...
var result = await Bundler.BundleAsync("src/index.html", new BundleOptions
{
    Minify = true,
    Platform = Platform.Web,
    Format = ModuleFormat.Esm,
});

byte[] indexHtml = result.Outputs["index.html"];

// ... or straight to a directory
await Bundler.WriteToDirectoryAsync("src/index.html", "dist",
    new BundleOptions { Minify = true, SourceMaps = true });

3. The parser, as a library. The TypeScript / JSX front-end is public, too - so you can parse, transform, and print without bundling anything. For instance, you can turn TypeScript into JavaScript from C#:

using NetPack.Syntax;
using NetPack.Syntax.Printer;

var module = Parser.ParseModule("const x: number = 1;", "in.ts");
var js = JsPrinter.Print(module); // -> "const x = 1;"

Why does that matter? Because things that were awkward when your bundler lives in another ecosystem suddenly become straightforward. A bundler that is just a .NET library can be part of an ASP.NET Core web server, or of a build pipeline based on MSBuild, Cake, or Fallout - no child process, no JSON handshake, no "please have Node.js installed on the build agent" in your onboarding doc. It can post-process and optimize the output of ASP.NET Core and Blazor applications from within the same process. Many optimizations and use cases become possible that were difficult before. (The two dashed boxes in the diagram are exactly that: things the library makes possible, which I'm still exploring, versus the solid ones that exist today.)

How Fast Is It, Really?

Time for the honest part. In January 2025, the numbers looked fantastic: netpack finished the small project in 418 ms, esbuild needed 670 ms, rspack roughly 910 ms, and Vite 1.66 s. (That table is, in fact, still on the website. I should update that.) But the world didn't stand still. esbuild got faster, rspack got a major version, and Vite switched to a Rust-based bundler (Rolldown) with version 8.

Here are the current numbers from the repository's performance.md - netpack 0.6.0 against the latest versions of the others, measured with hyperfine on the same test projects (the table was last run for 0.6.0 - the project has moved on to 0.8.2 since):

My reading of that chart:

Library builds: netpack wins (141 ms vs. 150 ms for esbuild).
Small project: a dead heat with esbuild (240 ms vs. 238 ms), both ahead of rspack and Vite.
Medium and large projects: netpack comfortably beats esbuild, but rspack 2 and Vite 8 are faster (around 450 ms vs. 595 ms on the large project).

So: still in the same ballpark as the native tools, and the original thesis holds - but no, it doesn't "beat everyone" anymore. As always, take benchmarks (especially the ones the author runs himself) with a healthy dose of salt. And note that features like source maps and tree-shaking cost time, too - more features, more work to do per build.

Where It Shines

Native startup. An AoT-compiled binary that starts instantly and behaves the same whether it bundles two files or a large app.
Zero-config and batteries-included. Same entry-point convention as Vite or Parcel, with TypeScript, JSX, CSS Modules, Sass / LESS / PostCSS, images, Vue, Astro, Svelte, and Solid on board.
A real toolchain, not a wrapper. Hand-written tokenizer, parser, printer, minifier, and tree-shaker - all in readable C#. (Arguably more readable than the Rust equivalent. I said arguably.)
.NET-native. Library, MSBuild task, and parser - all usable without leaving the .NET world.
Smart defaults for modern web. Import maps as externals, --shared dependencies, Module and Native Federation.
A genuinely useful analyzer, with dependency audits and optimization suggestions.

Where It Struggles

It's pre-1.0 and experimental. The README still carries a warning that it's not production-ready, and it's still true: the chance that it works end-to-end for your project today isn't as high as I'd like. Please test it on side projects first.
The ecosystem is the elephant in the room. Vite is downloaded around 65 million times a week. Its plugin ecosystem, its documentation, and its integration with every framework under the sun can't be replicated - and I'm not going to pretend otherwise. Netpack has hooks (inspired by rspack), but don't expect to drop in your existing Vite plugins.
Not every framework is there. Angular is not supported (yet). Svelte and Solid compile through the Node bridge; Vue and Astro are native, but with limitations documented in their respective pages.
Not every platform is there. There are binaries for Windows x64 / ARM64, Linux x64 / ARM64, and macOS ARM64. macOS x64 and Windows x86 are still missing.
AoT has a price. No reflection, source-generated JSON, and a careful eye on every dependency. That's good for startup, but it limits what libraries I can pull in.
You still need Node.js for some things (Sass, LESS, PostCSS, Svelte, Solid, .codegen). Plain JS / TS / JSX / CSS / HTML bundling needs nothing extra.
Bundler, not type checker. As with the other bundlers in this space, I'd keep running tsc in your CI for actual type checking - Netpack's job is parsing TypeScript and stripping the types, not judging them.

Community, Such As It Is

I want to be upfront about this one: Netpack is very early. At the time of writing the repository has 12 stars - so if you've read this far, you could be a statistically significant part of the community.

That also means every contribution counts, and there's plenty of low-hanging fruit: macOS x64 and Windows x86 binaries, framework support (hello, Angular), docs, bug reports from real projects, and benchmarks on your own machines. If you like where this is going, star it, try it, open an issue, or sponsor the project 🍻. The code is MIT licensed.

What's Next for Netpack

First things first: 1.0. The project is still pre-1.0, but I'm positive that I'll get this done by the end of the year - together with a proper release to the community. My 1.0 homework list: closing gaps in the supported scenarios (looking at you, Angular), settling the APIs - including the .NET ones - and bringing documentation and benchmarks up to date.

I have no illusions, though. The existing bundlers - most importantly Vite as the "meta bundler" - are far too prominent and too well integrated with the ecosystem to be replaced or discarded. Netpack is not going to be your next Vite, and I'm not trying to make it one.

What makes Netpack shine - and where I see its future - is the integration into .NET. As Netpack is .NET "native" (yes, the application itself is also an AoT artifact, but I mean something else here: it's based on C#/.NET and can be used as a library in .NET projects), it can be part of ASP.NET Core web servers or build pipelines based on MSBuild, Cake, or Fallout. In any of these cases, many optimizations and use cases are now possible that would have been difficult beforehand.

That's the Netpack story - from a regular-expression-powered experiment on a winter vacation, via the realization that "to beat native you need native", to a native, AoT-compiled bundler that got fifteen releases in six weeks with a little help from an AI pair programmer. If you'd like to poke around, here are some links:

Website and documentation: netpack.anglevisions.com (docs)
GitHub repository: FlorianRappl/netpack
npm (CLI): netpack
NuGet: NetPack.Core and NetPack.Build
Original announcement of the experiment: netpack (dev.to)
Previous articles in this series: AngleSharp, Mages, Piral, and Electron.NET

Next up in this series: another project, another origin story. Stay tuned.

My OSS Projects: Electron.NET

Florian Rappl — Wed, 30 Sep 2026 13:30:00 +0000

This is the fourth post in my "My Open-Source Projects" series, where I go through some of the OSS projects I started or maintain and tell you the story behind them. So far we've had AngleSharp, MAGES, and Piral. This time: Electron.NET - and it's a bit different, because I didn't start this one. I kind of wandered into the maintainer seat and never left.

What Is Electron.NET, Actually?

Electron.NET lets you build cross-platform desktop apps with .NET - Razor Pages, MVC, Blazor, or even a plain console app - with Electron doing the window-and-pixels part.

If you've never touched Electron: it's the thing behind a scary number of desktop apps you use every day. It bundles Chromium and Node.js, gives you a window, and lets you build the UI with HTML, CSS, and JavaScript. Yes, that means you ship a browser with your app. No, I'm not going to apologize for that, and neither should you - it works, on Windows, macOS, and Linux, with one codebase.

The catch, if you're a .NET developer: Electron speaks JavaScript. Electron.NET is the bridge that lets you stay in C#.

var window = await Electron.WindowManager.CreateWindowAsync(
    new BrowserWindowOptions { Width = 1024, Height = 768 });

That's a native desktop window, created from C#. No main.js in sight.

Not My Project (Originally)

The other projects in this series all started with me having an idea and then regretting it slowly. Electron.NET is different: it was founded by Gregor Biswanger and Robert Mühsig.

Their goal will sound familiar if you've read the AngleSharp post: they wanted a cross-platform GUI framework with C# as the driver. The difference is that they had a big advantage I didn't have back then - they could look at what Electron had already accomplished for Node.js and JavaScript. Robert wrote up the origin story in a blog post from October 2017: Gregor asked if it was possible to build desktop apps with ASP.NET Core, they agreed that Electron-as-is plus an embedded ASP.NET Core was the best bet, and then Robert went to bed while Gregor stayed up and built a working prototype. That's the kind of division of labor I can respect.

Their take was refreshingly simple: let's use an ASP.NET Core server as the HTML/CSS/JS producer, and wrap the Electron API into an interface that is callable from that server.

How It Works: Three Layers, Two Bridges

Once you accept that idea, you end up with three layers:

Rendering layer (HTML / CSS / JS) - the same as always. It talks to Electron through the standard globals and message passing.
Server layer (C# / ASP.NET Core) - produces the UI and talks to Electron through an IPC bridge based on socket.io. (Yes, that's just another flavor of message passing.)
Node.js layer (the original Electron trigger code) - can be extended with custom code, but is otherwise just the other end of the IPC bridge.

Your C# code calls something like Electron.WindowManager.CreateWindowAsync(...), that call travels over the bridge, the Node.js side makes the actual Electron call, and the result comes back the same way. Meanwhile the renderer happily loads whatever your server serves it. It's a little bit of plumbing, and it's very easy to forget about once it works - which is exactly the point.

The Hard Parts

Of course, the idea is the easy part. The journey was (and is) full of questions like these:

How do you package an app correctly? Your app is now a Node.js app, an Electron runtime, and a .NET application that all need to end up in one installer that works on three operating systems.
How do you expose the server - but not too much? There's now a web server running on the client's machine. It needs to be reachable by your own window and by nobody else.
How do you debug this? Three layers, two runtimes, and a bridge in the middle. "Attach a debugger" turns out to be a much bigger sentence than it sounds like.

electronize, Growing Pains, and 5,000 Stars

To get started, Gregor and Robert invented a system of their own: electronize, a CLI tool that handled building and packaging. It was good enough to begin with, and the framework grew quickly - past 2,000 stars by November 2018, 4,000 by November 2019, and on to 5,000 after that.

But then the problems stacked up:

Outdated versions of Electron (which were fixed through electronize, but always somewhat behind)
Unresolved issues piling up
Weird cross-platform bugs - the kind that only reproduce on the one OS you don't have at hand
Missing features, mostly from newer Electron versions that the wrapper hadn't caught up with yet

Those things kept the project from growing further. And if you look at the classic NuGet package's release history, you can see it. Back then, the major version of Electron.NET was the Electron compatibility number: Electron.NET 20 matched Electron 20, Electron.NET 13 matched Electron 13, and so on. That's a nice, honest scheme - and it also means every gap in Electron.NET's release history is a gap in which Electron kept moving without you. The releases came with some regularity through 2019, 2020 and 2021 - and then there's nothing on NuGet for 20 months.

(Do the math on 13.5.1 followed by 23.6.1: that's ten Electron major versions in one go.)

The star curve kept climbing regardless - the repository passed 6,000 stars in January 2024. People clearly wanted this to work.

Stepping In

This is where I stepped in. I joined the team in March 2023 - Gregor announced it in issue #744 under the title "Electron.NET Reloaded". I'll be honest: I wasn't planning on becoming a maintainer of a project with thousands of stars. But I'd been in the "web meets .NET" space long enough that the problems looked solvable rather than scary, and together with a few other new maintainers we made a decision that was either brave or reckless: throw out the tooling and rebuild it from scratch.

The result - launched in November 2025 - is ElectronNET.Core: a completely new system, fully based on MSBuild and .NET, supporting essentially any version of Electron. It's also still pre-1.0 (the latest release is 0.6), and the version number no longer means anything about Electron - which is exactly the point.

What changed, in a nutshell:

No more CLI and no more electron.manifest.json. Everything flows through MSBuild project properties, which means Visual Studio's own project system just works. A whole category of "why does my JSON config not do what I think it does" problems disappeared overnight.
.NET is in control. Instead of Electron launching first and babysitting the .NET process, your .NET app launches first and runs Electron as a child process. Better lifecycle management, more reliable shutdown. The Electron-first route still exists, though - there are eight launch scenarios in total (packaged/unpackaged × console/ASP.NET × .NET-first/Electron-first).
Any Electron version. No more rigid coupling to whatever version a given release happened to bundle - the old "Electron.NET 20 = Electron 20" scheme is gone. You choose the Electron version with a single property in your project file, and the build validates that it's compatible.
ASP.NET is optional. A plain console app is now enough if all you need is to load HTML from the file system or from a remote server.
Debugging that feels like .NET. Press F5, get breakpoints and Hot Reload. You can even build and debug the Linux version of your app from Windows Visual Studio through WSL.
Full API compatibility. Existing code keeps working - including custom host hooks - so migrating is mostly about the project setup, not a rewrite. There's a migration guide for exactly that.

The new package structure is intentionally modular:

ElectronNET.Core - the main package with the build logic and project system integration
ElectronNET.Core.API - the pure API definitions
ElectronNET.Core.AspNet - the ASP.NET-specific runtime pieces
ElectronNET.Core.Templates - project templates to get started quickly

Getting Started

You'll need .NET 8 or 10 and Node.js 22 or newer. For an ASP.NET-based app, create a new ASP.NET Core project and add two packages:

dotnet add package ElectronNET.Core
dotnet add package ElectronNET.Core.AspNet

Then hook Electron into the startup of a minimal API (Razor Pages here, but MVC works the same way):

using ElectronNET;
using ElectronNET.API;
using ElectronNET.API.Entities;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();
builder.Services.AddElectron(); // handy for dependency injection

builder.UseElectron(args, async () =>
{
    var browserWindow = await Electron.WindowManager.CreateWindowAsync(
        new BrowserWindowOptions { Show = false, AutoHideMenuBar = true });

    browserWindow.OnReadyToShow += () => browserWindow.Show();
});

var app = builder.Build();

app.UseStaticFiles();
app.UseRouting();
app.MapRazorPages();
app.Run();

Notice the callback you pass to UseElectron() - it tells you the right moment to set up your UI, which used to be a source of mysterious race conditions.

Then press F5. That's it. You're running a desktop app.

Want a specific Electron version? It's just an MSBuild property in your .csproj:

<PropertyGroup Label="ElectronNetCommon">
    <ElectronVersion>30.4.0</ElectronVersion>
</PropertyGroup>

(That's the default in the docs at the time of writing - the configuration page lists all the other settings.)

Blazor

For Blazor there's exactly one thing to remember - the IsRunningBlazor option, which sets up the renderer in a way that Blazor can run without interference (including hot module replacement during development):

builder.UseElectron(args, async () =>
{
    var options = new BrowserWindowOptions
    {
        Show = false,
        IsRunningBlazor = true, // <-- crucial
    };

    var browserWindow = await Electron.WindowManager.CreateWindowAsync(options);
    browserWindow.OnReadyToShow += () => browserWindow.Show();
});

No ASP.NET? No Problem.

If you don't need a local web server at all, a console app is enough. Create one with dotnet new console, add dotnet add package ElectronNET.Core, and start the runtime yourself:

using ElectronNET.API;
using ElectronNET.API.Entities;

var runtimeController = ElectronNetRuntime.RuntimeController;

await runtimeController.Start();
await runtimeController.WaitReadyTask;

var browserWindow = await Electron.WindowManager.CreateWindowAsync(
    new BrowserWindowOptions { Show = false });

// file system, remote URL, whatever you like
await browserWindow.WebContents.LoadURLAsync("https://example.com");

browserWindow.OnReadyToShow += () => browserWindow.Show();

await runtimeController.WaitStoppedTask;

(This is a trimmed version - the console app page in the wiki has the complete example including the project file settings you need.)

And the Rest of Electron?

The C# API covers a good chunk of what Electron offers: windows, menus, dialogs, the tray, notifications, the clipboard, global shortcuts, the auto-updater, native theme, power monitor, screens, ipcMain, and more. The wiki has a page for each of them.

Where It Shines

You keep your stack. If you know ASP.NET Core - Razor Pages, MVC, or Blazor - you already know 90% of what it takes to build a desktop app. The web skills and the C# skills you have are the skills you need.
Real cross-platform, one codebase. Windows, macOS, and Linux, with the packaging story handled by MSBuild instead of a separate tool.
Flexible architecture. Full ASP.NET host, or a lightweight console app that loads local files or a remote URL. The setup fits the app, not the other way around.
Modern debugging. .NET-first launch, Hot Reload, and WSL for Linux builds is a workflow that just feels like normal .NET development.
The Electron ecosystem is right there. If it works in Electron, it works in Electron.NET - and if there's a custom bit of JavaScript you need, the Node.js layer can be extended with your own code.

Where It Struggles

It's Electron. You're shipping Chromium and a .NET runtime and Node.js. Installers are big, memory usage is what you'd expect from a browser plus a server, and if your app is a small utility, a native UI toolkit might be a better fit.
Two ecosystems to keep in your head. Even with .NET in the driver's seat, you still touch Node.js (which is a requirement), and now and then the JavaScript side of the story.
The API is a wrapper. That's a strength (you get C# instead of JS) but also a limitation: a shiny new Electron feature has to be exposed in the C# API before you can use it comfortably. Keeping up with that is part of what stalled the classic line.
Core is young. It launched in November 2025 and is still pre-1.0 (latest release: 0.6). It's moving fast - new pre-release builds show up almost daily - but "fast-moving" and "settled" are not the same thing.
Migrating from classic takes some effort. Full API compatibility helps a lot, but the project setup is different, and you'll have to work through the migration guide.
The team is small. This is open-source work done in our free time. More on that below.

People Behind It

The README lists four authors: Gregor Biswanger and Robert Mühsig (the founders), softworkz, and me.

The current changelog reads like a thank-you note to everyone who showed up: softworkz has shipped an enormous share of the Core work (infrastructure, build system, integration tests - the list is long), while agracio, AeonSake, Denny09310, NimbusFox, davidroth, markatosi, DYH1319, hilin and adityashirsatrao007 all appear with fixes, features, docs, and sample apps.

Since this is done in our free time, there's a donation page, and you can also sponsor the core maintainers on GitHub (Gregor, me) - or buy me a coffee. Donations can even be used to bump the priority of an issue. For questions you can use the GitHub discussions feature.

Where Electron.NET Shows Up Today

The numbers first: the repository has 7.6k stars and 741 forks. The classic ElectronNET.API package sits at over 650K downloads, and the much younger Core packages have already crossed 40K.

Electron.NET is widely used - for demos, within Microsoft, and within the .NET community. Some of the projects built on top of it:

Papercut SMTP (3.3K stars), the simple desktop email server that developers use to catch outgoing mail during testing.
Sidekick, a helper app for the game Path of Exile.
SecureDNS, an all-in-one cross-platform DNS server.
Ididit, a Blazor habit tracker that runs on the web and on desktop.
Hyprism, an open-source Hytale launcher - built on the new ElectronNET.Core.
AsteroidsWasm, a single C# project that runs as Blazor WASM, Blazor Server, Electron, WPF, WinForms, MAUI, and WinUI3 (which has to be some kind of record).

None of that was in the plan when Gregor stayed up to hack together a prototype, but "let .NET developers use the web stack they already know for desktop apps" turns out to be a pretty good idea.

What's Next for Electron.NET

The Core rewrite removed the technical debt that was holding the project back. The flexible Electron versioning, the integrated build system, and the cross-platform tooling are the foundation for more frequent updates, better tooling and IDE integration, easier community contributions, and support for more platforms. Newer Electron versions are already supported, and the release train is running.

The future certainly holds more treats. I'd tell you what, but I'm not great at keeping surprises - so I'll just say: watch the repository.

That's the Electron.NET story - from a late-night prototype in 2017, through 5,000 stars and a rough patch, to a complete rebuild on top of MSBuild and .NET. If you'd like to poke around, here are some links:

GitHub project: ElectronNET/Electron.NET
NuGet: ElectronNET.Core.API (new, rework) and ElectronNET.API (classic)
Documentation / what's new: What's New
Previous articles in this series: AngleSharp, Mages, and Piral

Next up in this series: another project, another origin story. Stay tuned.

My OSS Projects: Piral

Florian Rappl — Wed, 23 Sep 2026 10:59:45 +0000

This is the third post in my "My Open-Source Projects" series, where I go through some of the OSS projects I started or maintain and tell you the story behind them. First up was AngleSharp, then MAGES. This time: Piral, a framework for micro frontends - and the first project in this series that came out of a client engagement rather than a plane ride or a game studio's grant.

What Is Piral, Actually?

Piral lets you build a frontend application as a stable app shell that gets extended at runtime by independently developed, independently deployed modules called pilets. A pilet ships its own code and assets, can register pages, extend other pilets' extension points, and can be built, tested, and released completely on its own team's schedule - without anyone needing to touch or even redeploy the shell.

If that sounds like "micro frontends," that's because it is. Piral was one of the earlier dedicated frameworks in that space, built specifically around the idea that a single main framework (usually React) drives the shell, while individual pilets are free to bring something else entirely if they need to - Vue, Angular, even something short-lived and purpose-built. The shell doesn't care. It only cares about the contract.

I've written a more detailed technical introduction to the concepts before, if you want the deep dive: Introduction to Microfrontends with Piral. This post is more about where it came from and how it's grown.

Where It Actually Started: A German Energy Company, Then ZEISS

Piral wasn't born as "let's make a framework." It was born as "let's actually ship this customer portal, for real this time."

I'd just come off a large rewrite of the smart-home portal for a large German energy company, where a micro-service-backed, loosely-coupled-frontend approach worked far better than anyone expected. The backend teams had already gone the micro-services route for their own reasons - scaling, ownership, independent release cycles - and it seemed almost wasteful to let all of that independence evaporate the moment it hit the frontend, where everything got welded back together into one shared codebase anyway. So we didn't. Multiple teams could ship independently without stepping on each other - which, if you've ever worked on a large frontend monolith with a dozen teams committing to the same App.tsx, is not a sentence you get to say often.

Then I became the main architect for a new digital customer portal at ZEISS - a large German company that had, by that point, tried and failed to pull off exactly this kind of portal for years. Not for lack of trying, and not for lack of good engineers - it's the kind of project that accumulates false starts simply because "let many teams contribute to one coherent customer-facing app" is a genuinely hard organizational and technical problem, and prior attempts had all run into the same wall: a single frontend codebase that every team had to touch, coordinate around, and eventually avoid touching at all costs.

I noticed the parallels to what had just worked at the RWE SmartHome project and leaned into the same approach: micro-service backends paired with what we'd now call micro frontends, even though nobody was calling it that yet - the term hadn't really entered common usage. It worked. Multiple teams contributing at what genuinely felt like the speed of thought, instead of the speed of "please rebase your branch against the shared frontend repo again, and also here's a merge conflict in a file six people touched this week."

At that point the obvious question was: why keep reinventing this per client? Why not generalize the approach into an actual framework?

Naming It (And Accidentally Foreshadowing Something)

I joined smapiot in February 2019, and the direction was clear from day one: alongside the regular consulting work, there'd be dedicated time to build a framework for micro frontends. By March 2019 we'd settled on a name: Piral, short for "Portals that can go viral." A year later, the "viral" part of that name aged in a way absolutely nobody could have planned for. We still bring it up.

We officially revealed Piral at the O'Reilly Software Architecture Conference Berlin in November 2019. In hindsight, that conference turned out to be the last one O'Reilly ran in that series - it never picked back up after COVID hit, at least as far as I know. So Piral's public debut happened at what turned out to be the end of an era for that particular conference. The response at the time, though, was genuinely great - people wanted to try it immediately, which is not always guaranteed when you show up with "yet another frontend framework" at a software architecture conference. We'd braced ourselves for the usual round of "how is this different from an iframe" questions, and got a refreshing number of "can we pilot this next quarter" ones instead.

Here's the whole arc at a glance, from that first month at smapiot to where things stand now:

Seven years is a long time for a framework built around one client project's success to still be actively developed, still picking up new adopters, and still running its own annual conference. None of that was guaranteed back in that Berlin conference room in 2019. A couple of things worth calling out about the timeline itself: the gaps are real - not every quarter had a headline-worthy event, and I'd rather show honest quiet stretches than pad the axis with filler. And two of the dates lined up in a way I didn't plan: Piral's v1.0 release and the very first Micro Frontends Conference both landed in June 2023, on the same day, which made for a genuinely good excuse for a celebration.

A few of those milestones are worth a beat of their own. The Feed Service has its own steady release cadence running quietly alongside the framework - 1.0.0 in October 2021, 1.17.0 four years later. Piral.Blazor turned into a small ecosystem of its own, from v3 in September 2022 to a dedicated server-side variant targeting .NET 8 in February 2024. And native Module Federation support landing in Piral 1.4.0 (December 2023) was a quiet but important one - it meant Piral could sit alongside, rather than only compete with, one of the other major approaches to shipping micro frontends.

Worth calling out explicitly: the "hundreds of pilets in one app" scaling story isn't something Piral grew into over these seven years - it was a design goal from the very first version, informed directly by watching what broke at scale in that original ZEISS-style setup. What's changed since 2019 isn't the ceiling; it's how many production systems are actually pushing against it.

Not Just Theory: Real Adoption, Including Outside Piral Itself

The consulting projects that followed proved the concept held up outside of ZEISS's specific context, which is always the real test for something that started as "a good idea from one project." It's one thing to make an architecture work when you're the one who designed it and you're in the room for every decision. It's another to hand it to a different team, on a different project, with different constraints, and watch it hold up anyway. Piral did.

What surprised me more, though, was interest from teams that weren't using Piral at all. Larger projects already built on Single-SPA started reaching out for help getting Piral's loosely-coupled integration patterns into their existing workflows. They didn't want to migrate away from code that already worked - nobody sane wants a rewrite of a production system that's doing its job - but they wanted the ideas behind Piral (the decoupling model, the independent deployability, the way pilets could be updated and rolled out without a full redeploy) layered onto the micro frontend setup they already had. In practice, that meant bringing over specific mechanisms - things like our approach to shared dependencies, or the update/rollout model - without asking anyone to throw away months or years of Single-SPA work.

That's a good sign for any architecture: when people want to borrow your patterns even while keeping their own stack. It's a much stronger signal than stars or downloads, because it means the ideas are portable even when the code isn't.

An Ecosystem, Not Just a Library

From the start, Piral was meant to be more than "install a package, get a framework." Different pieces of tooling were deliberately built as their own generic, reusable things - not tightly bolted to Piral internals. That's a design choice, not an accident: a debugging tool that only understands Piral-specific concepts is a much smaller investment than one built around general primitives that Piral happens to use too, but the latter is far more likely to survive the framework's own evolution - and far more useful to anyone standing outside the Piral world entirely.

The clearest example is the Piral Inspector, a browser DevTools extension for inspecting and debugging a running Piral instance - which pilets are loaded, what routes are registered, what dependencies are shared, toggling settings like state-container logging, and even loading new pilets on the fly from a root module URL, a feed URL, or a tarball for quick local testing. It's built with an adapter pattern specifically so its core debugging plumbing (a background script talking to a content script talking to a devtools panel - the standard shape for any browser extension that needs to inspect a page) isn't locked to Piral-only scenarios. It ships for Firefox, Chrome, Opera, and Edge, which is more browser coverage than most internal dev tools ever bother with, and it's a genuinely small, focused codebase - the kind of tool you can actually read end to end in an afternoon if you're curious how it talks to a running app.

Beyond that, the ecosystem includes:

A VS Code extension for authoring pilets and app shells with proper tooling support instead of raw text editing and hope.
A templating system (via the CLI) to scaffold a new pilet or a whole new app shell in seconds, rather than copy-pasting a previous project and deleting things until it works.
The Piral Cloud Feed Service - the commercial piece that ties it all together.

The Feed Service: The Giant Everything Stands On (But Isn't Required)

The Piral Cloud Feed Service is, in practice, the thing that makes rolling out and updating micro frontends at scale actually pleasant - it's how pilets get discovered, versioned, and delivered to app shells without anyone manually wiring up a deployment pipeline per team. Push a new pilet version, the feed picks it up, connected app shells get the update - no rebuild of the shell, no coordinated release train, no waiting for the next sprint's deployment window.

Here's the part I think matters most, philosophically: the Piral framework has no hard dependency on the Feed Service. We built it that way on purpose, from day one, even though it would have been the easier (and more commercially convenient) choice to couple them tightly. How you distribute and update your pilets is entirely up to you - and even if you decide a discovery/delivery service is the right call (it usually is, once you have more than a couple of teams shipping independently), it doesn't have to be ours. Any micro frontend discovery mechanism can plug into the same contract, because the contract itself is just "here's a list of pilets and where to fetch them" - deliberately unglamorous, deliberately not locked to one vendor.

Do I think the Piral Cloud Feed Service is the best option out there? Yes, obviously - I'm somewhat biased, having helped build it, and I've seen what it looks like when teams try to roll their own version of the same thing from scratch. But that's a big enough topic for its own article rather than a paragraph here. If you want to explore it yourself: the landing page has the overview, portal.piral.cloud is where you log into the free community tier, and the licensed version runs fully on-premise for anyone who needs that - a common requirement once you're talking to companies with strict data-residency rules.

Getting a Feel for It

Scaffolding a new app shell:

npx piral new my-shell
cd my-shell
npm start

And a new pilet that plugs into it:

npx pilet new --source my-shell
cd my-pilet
npm start

Inside a pilet, registering a page looks like this:

import { PiletApi } from 'my-shell';

export function setup(piral: PiletApi) {
  piral.registerPage('/hello', () => <div>Hello from a pilet!</div>);
}

That's genuinely most of it for a minimal case. The PiletApi surface is where the interesting extensibility lives - registering pages, extension slots, shared state, notifications, menu items, and more, all without the shell needing to know a given pilet exists ahead of time.

Where It Shines

Loose coupling as a first-class citizen, not an afterthought. Pilets are isolated by design - built, versioned, tested, and deployed independently. A broken pilet release doesn't take down the shell or other pilets, and a team can ship a hotfix to their one pilet at 4pm on a Friday without needing sign-off from anyone outside their own team.
It genuinely scales to a lot of micro frontends. This is the one I'd highlight hardest: Single-SPA-style setups tend to get uncomfortable somewhere around 10 micro frontends, and Module Federation setups can typically stretch to 30-40 depending on how deep the sub-module graph gets before the shared-dependency graph turns into its own puzzle to manage. Piral is, as far as I'm aware, the only micro frontend framework built to comfortably scale into the hundreds of pilets in a single application - which matters a great deal once you're not talking about a handful of teams anymore, but dozens.
Framework-agnostic at the pilet level. React drives most shells, but a pilet can be Vue, Angular, or something else entirely - useful for legacy migration paths (rewrite one piece at a time instead of a big-bang cutover) or short-lived experiments that shouldn't need to match the shell's stack just to get evaluated.
It's an actual ecosystem. Devtools, editor tooling, scaffolding, and a discovery/delivery layer - all usable independently, and none of it locked behind "you must use our cloud service." That's a rarer design principle than it should be.
Not vendor-locked to its own commercial offering. The Feed Service being fully optional, by design, is a rarer stance than you'd think for a company that also sells a feed service - it would have been easier, short-term, to make the two inseparable.

Where It Struggles

Smaller community than the bigger names in the space. Compared to Module Federation or Single-SPA, Piral's community is meaningfully smaller - even though (or maybe partly because) it's used at some genuinely large companies who don't always talk publicly about their stack. Enterprise adoption doesn't show up as GitHub stars.
React and React Router are still baked in, for now. Piral v1's core assumes React and React Router underneath, even though you can swap either out if you're willing to do the work (there are converter packages for Vue, Angular, and others at the pilet level, but the shell's assumptions run deeper). That's changing - Piral v2 is dropping both as hard prerequisites from the ground up - but today, going off the beaten path takes more effort than it should.
The learning curve is real if you're new to micro frontends as a concept. Pilets, extension slots, shared dependencies, feed services - there's genuine architectural thinking required before you ship your first production app shell. This isn't a "npm install and you're basically done" kind of framework, and it was never trying to be one; the complexity it removes downstream (independent team deployments) has to be paid for somewhere, and that's mostly upfront in understanding the model.
The commercial Feed Service, while optional, is where a lot of the "batteries included" experience lives. Rolling your own discovery/delivery mechanism is entirely possible, but you're signing up to build and maintain that piece yourself - versioning, rollout logic, health checks, the works.

Community: Smaller, But Loud in the Right Rooms

Piral has never chased npm download charts, and it shows - but it's shown up consistently where the actual micro frontends conversation happens. We've hosted numerous community talks over the years, at conferences and meetups well beyond our own events, and since 2023 we've run the Micro Frontends Conference annually - a free, one-day virtual event with 15+ speakers, several of whom are genuinely foundational names in this space (people who've built or shaped Module Federation, Single-SPA, and other tools you've likely already used).

The 2024 edition ran June 17th; sponsors across the two editions included JetBrains and several others from across the ecosystem. It's not a Piral-only event by design - the point was, and is, the micro frontends community as a whole, not just promoting our own framework. Running a conference that deliberately platforms competing approaches is a strange thing to do if your only goal is selling your own framework; it's a much more natural thing to do if your actual goal is a healthier ecosystem, which - vested interest aside - is genuinely the goal.

What's Next for Piral

The big one on the horizon is Piral v2, which drops the historical React and React Router requirements from day one instead of treating framework-agnosticism as something you bolt on with extra converters. That's a meaningful shift for a framework that's been React-first since its earliest versions - it means the core assumptions about rendering and routing get rethought rather than patched around, which is a bigger undertaking than it sounds like from one sentence.

Beyond that, the roadmap keeps circling back to making the "hundreds of pilets" scaling story even smoother as real deployments push past what we originally validated it against, and continuing to grow the ecosystem pieces (inspector, editor tooling, templates) independently of the core - the same philosophy that's been there since the beginning: build pieces that are useful even outside of a strict "you must use all of Piral" context. If the last seven years are any indication, the interesting adoption stories will keep coming from places we didn't specifically design for.

That's the Piral story - from a customer portal at ZEISS that finally worked, to a framework that scales to hundreds of independently shipped pilets, to hosting its own community conference. If you want to poke around: the website has the overview, the repository has the code, and the introduction article has the deeper technical walkthrough.

Next up in this series: another project, another origin story. Stay tuned.

My OSS Projects: Mages

Florian Rappl — Wed, 16 Sep 2026 12:30:00 +0000

This is the second post in my "My Open-Source Projects" series, where I go through some of the OSS projects I started or maintain and tell you the story behind them. Last time it was AngleSharp - the HTML parser that started life as a plane-ride fever dream. This time: MAGES, a much smaller project with a surprisingly cool client list.

What Is MAGES, Actually?

MAGES - officially standing for "Mages: Another Generalized Expression Simplifier," because every good project needs a slightly forced backronym - is a small, fast expression parser and interpreter for .NET. You hand it a string like "sin(2) * cos(pi / 4)", it hands you back a number. Except it also does variables, functions, closures, objects, lists, complex numbers, and - as of a couple of years ago - a bit of JSX for fun.

Think of it as "give your .NET app a tiny, embeddable scripting language" without dragging in a full-blown runtime, a NuGet dependency tree the size of a phone book, or a licensing conversation.

var engine = new Mages.Core.Engine();
var result = engine.Interpret("sin(2) * cos(pi / 4)"); // 0.642970376623918

That's the whole "hello world." No config, no ceremony.

The YAMP Prehistory

MAGES didn't start as MAGES. It started as YAMP - "Yet Another Math Parser" - an experiment to see whether I could build a full parser and evaluator with MATLAB-like syntax, powered almost entirely by reflection. Reflection made it wonderfully easy to extend: want a new function? Slap an attribute on a method and YAMP would pick it up. It was never meant to be fast. It was meant to be flexible, and as far as experiments go, it worked.

YAMP ended up seeing more real usage than an "experiment" really has any right to. The best example: it powered the math engine behind SineRider, a Unity web game from 2013 where you graph functions to sled a character through checkpoints - think Line Rider, but the slope comes from an equation you type in, not a mouse drag. It's a delightful bit of edutainment, and knowing that YAMP's reflection-driven, definitely-not-optimized-for-speed parser was quietly evaluating someone's sine wave in a browser game is exactly the kind of thing that makes open source fun.

If you want to see what that original version actually looked like, there's footage of it right here - very much a product of its era. The good news is you don't have to rely on old footage: after the original Unity Web Player build was killed off by browsers dropping NPAPI support, a team of teenagers at Hack Club rebuilt SineRider from scratch in vanilla JavaScript, and it's still there, still free, still very playable today. Current sources live at hackclub/sinerider if you're curious how it's built these days (spoiler: no MAGES or YAMP in there anymore - it's its own thing now).

From Experiment to Grant-Funded Successor

Here's where the story gets a step more interesting than "I wrote a parser on a plane" (that's a different article; see first part of the series). The person behind SineRider wanted to go bigger: not just a game about graphing one function, but a whole world built on the idea that everything - terrain, objects, physics - could be governed by changeable math functions. Picture Minecraft, except the blocks are mutable equations. That's a genuinely ambitious pitch, and it was ambitious enough to catch a Peter Thiel grant.

Part of that grant went toward funding the next generation of the expression engine underneath it. YAMP's syntax could carry over, but its reflection-based guts were never going to be fast enough for a real-time, function-driven game world. So MAGES was built from scratch with one primary constraint: speed.

How MAGES Actually Runs Your Expression

The core architectural decision that makes MAGES fast is that it doesn't walk an AST and evaluate it node-by-node at runtime (which is what YAMP effectively did, dressed up with reflection). Instead, every expression gets compiled down into a small set of VM instructions, which are then executed sequentially by a lightweight stack-based virtual machine. Parse once, compile once, run the compact bytecode as many times as you want.

Because the VM is just consuming a flat instruction stream, the interesting side effect is that the front end (parser, AST) and back end (what actually executes the instructions) are decoupled. Theoretically you could target something other than the built-in VM. I actually did this for fun once: I wrote a backend that "compiles" MAGES code into equivalent JavaScript and runs it on V8. It works, and it was a satisfying afternoon of yak-shaving. The more natural target would honestly be WebAssembly - same idea, different, more useful destination - but that one's still sitting in the "would be cool" pile.

// Compile once, reuse the compiled delegate as many times as you like
var expOne = engine.Compile("exp(1)");
var result = expOne(); // 2.71828182845905

Getting Started

Install it:

dotnet add package Mages

Interpret a one-off expression:

var engine = new Mages.Core.Engine();
var result = engine.Interpret("sin(2) * cos(pi / 4)"); // 0.642970376623918

Pull a function back out and call it directly from C#:

var func = engine.Interpret("(x, y) => x * y + 3 * sqrt(x)") as Mages.Core.Function;
var result = func.Call(4, 3); // 18.0

Since v2.0, complex numbers are first-class citizens - this was a hard requirement to reach parity with what YAMP already offered, since a fair chunk of MAGES's real-world users do actual signal-processing-flavored math and were not going to be pleased with an engine that couldn't take a square root of -1 without complaining:

var result = engine.Interpret("sqrt(-1)"); // i

And since v3.0 (2024), things got a little playful: MAGES understands JSX. Not "JSX-inspired" or "JSX-ish" - the actual JSX grammar, the same tags-with-embedded-expression-blocks syntax React (or Vue, or pretty much any modern web toolchain) uses. The tag structure, attributes, and children all follow the standard JSX rules you already know. The only twist is what happens inside the curly-brace expression blocks: instead of that being JavaScript, it's MAGES doing the evaluating. Same shape, different engine running the logic.

var html = engine.Interpret(
    "<div class={\"hello\" + \",\" + \"there\"}><h1>Hi</h1><p>World.</p></div> | html"
);
// <div class="hello,there"><h1>Hi</h1><p>World.</p></div>

So {"hello" + "," + "there"} there isn't JavaScript string concatenation - it's a MAGES expression, evaluated by the same stack-based VM as everything else, just sitting inside a JSX attribute the way you'd expect from any React component. Pipe the whole thing through html and you get a serialized string back. It's a genuinely fun corner of the language: you get a templating syntax that looks completely familiar to anyone who's touched a modern frontend, backed by an evaluator that has nothing to do with a JS engine.

Reflect on objects and functions at runtime via type:

var meta = engine.Interpret("((x, y, z) => x + y + z) | type | json");
// { "name": "Function", "create": "[Function]",
//   "parameters": { "0": "x", "1": "y", "2": "z" } }

And use placeholders (_) to curry arguments through the pipe operator:

var result = engine.Interpret(@"
    var f = (x, y, z) => x + 2 * y + 3 * z;
    5 | f(1, _, 2)
"); // 17, computed as 1 + 2*5 + 3*2

That pipe-and-placeholder combo is one of my favorite bits of syntax in the whole language - it reads almost like a small shell pipeline, but it's fully typed C# objects flowing through.

Where It Shines

Small and dependency-free. MAGES itself has zero runtime dependencies. It's a netstandard2.1 library, which means it happily runs on things like Unity or Mono, not just modern .NET.
Fast by construction. Compiling to a flat instruction stream for a stack-based VM means repeated evaluation is cheap - exactly what you want if you're evaluating the same handful of user-authored formulas thousands of times a second (looking at you, real-time math games and signal processing tools).
A genuinely pleasant expression syntax. Closures, objects, lists, complex numbers, string interpolation, a pipe operator, and now JSX-flavored templating - it covers far more ground than "just arithmetic."
Easy to embed. new Engine(), call .Interpret() or .Compile(), done. No hosting ceremony.
Great for domain-specific math. If your app's users need to type in formulas - a measurement tool, a spreadsheet-like calculator, a scripting console - MAGES gives you that without writing your own parser (please don't write your own parser).

Where It Struggles

It's a niche tool by nature. It's not going to replace a general-purpose scripting language embedded in your app if you need full standard-library breadth, multi-file modules, or a package ecosystem. It's an expression/formula engine that grew some scripting-language features, not the other way around.
The (optional) type system doesn't exist yet. More on this below, but right now everything is dynamically typed, and if you pass the wrong shape of data into a compiled expression, you find out at runtime like it's 2005.
Tooling is thin. There's no language server, no syntax highlighting extension, no step-through debugger. If you're building something where non-developers will be writing MAGES expressions, you're currently on your own for the authoring experience.
Smaller community, smaller surface area for stuff to just already exist. Compared to AngleSharp's few-hundred-million downloads, MAGES sits at a comparatively modest ~200K total NuGet downloads. That's not a criticism of the project so much as an honest expectation-setter: this is a focused tool for a specific job, not an ecosystem.

Small Crew, Big Reach

MAGES has never had a huge contributor list - it's a much more focused, much smaller codebase than something like AngleSharp. But it has picked up real sponsors along the way, credited right in the README: polytroper (the studio behind that "SineRider, but the whole world is math" follow-up game I mentioned earlier), smapiot (a company I previously worked for), and OMICRON Lab.

That last one deserves its own section.

Where MAGES Shows Up Today

For a project with a comparatively small download count, MAGES keeps turning up in places that make me genuinely proud:

Microsoft PowerToys uses MAGES - it's listed directly in the project's own README as one of its notable consumers. Every time someone runs a calculation through a PowerToys utility, there's a decent chance MAGES is quietly doing the arithmetic.
Flow Launcher, the 15K+ star Windows app launcher, depends on MAGES too - a natural fit, since "type an expression into a launcher and get an instant answer" is exactly the kind of thing MAGES was built for.
OMICRON Lab, an Austrian company building programmable test-and-measurement gear, uses MAGES as the expression engine behind their instruments. This is the one I'm most proud of: their hardware runs user-programmable math over live measurement data, which means MAGES had to be fast and correct with complex numbers - no hand-waving allowed when someone's oscilloscope trace depends on getting the math right. This is also, not coincidentally, exactly why complex number support in v2.0 was a "must ship," not a "nice to have."
LisaCore builds dynamic runtime code execution on top of it.

None of this was the plan when MAGES was a grant-funded rewrite of a reflection-based math parser. But "a small, fast, embeddable expression engine" turns out to be one of those quietly universal building blocks - much like AngleSharp's "a proper HTML parser for .NET" from the last post in this series.

What's Next for MAGES

A few directions I keep circling back to:

Real language tooling. The dream is an actual Language Server Protocol (LSP) implementation with a companion VS Code extension - proper syntax highlighting, inline diagnostics, maybe even autocomplete for the built-in function library. Right now, writing MAGES expressions means writing them blind.
Integration into a new .NET web framework. There are some interesting possibilities for using MAGES as a lightweight expression layer inside web tooling - think templated logic without pulling in a full scripting runtime. Nothing concrete to announce, but it's on the table.
Optional types. This is the big one, and it's a lot harder than it looks. Adding syntax for type annotations is the easy 10%. The actual hard part is making type checking meaningful - catching real errors before runtime, without turning simple one-line formulas into a TypeScript-style compiler project, and producing error messages that are actually useful rather than a wall of "type mismatch at position 47." I don't have a timeline for this. I have opinions about it, which is a different thing entirely.

That's the MAGES story - from a reflection-powered math experiment riding along in a Unity sledding game, to a Thiel-grant-funded rewrite, to quietly doing arithmetic inside Microsoft PowerToys and Austrian test equipment. If you want to poke around, the code lives on GitHub, and the package is on NuGet.

Next up in this series: another project, another origin story. Stay tuned.

My OSS Projects: AngleSharp

Florian Rappl — Wed, 09 Sep 2026 13:30:00 +0000

This is the first post in a new series, "My Open-Source Projects", where I go through some of the OSS projects I started or maintain and tell you the story behind them - the good, the bad, and the "why did I think this was a good idea at 30,000 feet" parts. First up: AngleSharp.

What Is AngleSharp, Actually?

Before the story, the pitch: AngleSharp is a .NET library that parses HTML, SVG, MathML, CSS, and (to a good extent) XML, and gives you back a fully-featured, spec-conformant DOM. Not "DOM-ish." Not "good enough for scraping." The actual W3C DOM API, the same querySelector, querySelectorAll, and element interfaces you already know from the browser console - except it's C#, it runs headless, and there's no browser in sight.

If you've ever reached for a regex to parse HTML: please don't. You know why. AngleSharp exists so that nobody has to write <div[^>]*> ever again.

Now, onto how it got here.

The Original (Slightly Unhinged) Idea

Once upon a time, I had what I thought was a brilliant idea: build a cross-platform GUI toolkit using HTML, CSS, and C#. I was certainly not the first person to think of this - plenty of people had similar thoughts before me - but back then it was still a fairly fresh take.

The more I thought it through, though, the more obvious it became: you can't just take HTML and CSS and strip them down to "the easy 80%". If you want this to actually work, you need the real deal - a proper HTML parser, a proper CSS engine, the whole circus. No shortcuts.

So naturally, the reasonable thing to do was to just... write an HTML5 parser. From scratch. In C#. Sure, why not.

Coding at 30,000 Feet

In 2013 I was flying to the Microsoft MVP Summit, and for reasons that made complete sense to me at the time, I brought a printed copy of the HTML5 spec with me. Not a novel. Not a magazine. The spec.

I started coding on the plane. By the time we landed, the parser was already "working" - in the sense that the happy paths worked. Feed it well-formed markup and it would dutifully produce a DOM. Great success, right?

Well, that's roughly the point where I discovered the dirty little secret of the HTML5 spec: it's massive not because HTML is a complicated language, but because of everything around it - error handling, edge cases, and the glorious pile of "what should happen when the markup is garbage" scenarios that browsers have been quietly agreeing on for decades. Turns out the "happy path" is maybe 20% of the actual spec. The other 80% is browsers being incredibly forgiving about human mistakes.

I kept grinding away at it, and eventually most of the edge cases and tests turned green. And then, like clockwork, I hit the point every side project hits: frustration, a pause, and a "why am I doing this to myself" moment. Every maintainer knows this phase. It has no official name, but "why did I do this to myself" captures it well enough.

Ship It Before It Goes Nowhere

Eventually I picked it back up with a very simple thought: before this thing quietly dies in a local folder, let's write a CodeProject article about it and push the code to GitHub.

I already had some open-source experience at that point - mostly as a contributor. The one project I actually maintained was YAMP, and thanks to some very patient people with a lot more GitHub experience than me, I'd picked up a few things about "doing OSS properly."

So I published the article, pushed the repo, and went to bed.

When I woke up, something had clearly happened. The repository already had 120+ stars, and the article was ranking surprisingly well. Nothing makes you suddenly very motivated about a side project like waking up to numbers you didn't expect.

So I kept going. And going.

Stabilizing, Then Breaking Everything (On Purpose)

For a while, most of the effort went into the internals - making the parsing actually correct, not just "correct enough." Once that settled down, the API itself went through some pretty massive changes. Not always changes that users loved, if I'm honest. Breaking changes are never fun to be on the receiving end of, and I was on the giving end a fair bit during this period.

The big turning point was AngleSharp 0.10. This release quietly laid the groundwork for what would define AngleSharp going forward: modularity. Suddenly you could just add another library and your document could parse JavaScript. Add another one and you got CSS. This came from a lightweight-but-surprisingly-capable dependency injection system and a service-based configuration approach that let you chain extensions together like Lego bricks.

That modular shape is still exactly how the ecosystem looks today:

The Long Road to 1.0

For years, I genuinely wasn't sure I could call the API "stable" and commit to semver. Not because it was shaky - it just felt like a big commitment. Eventually, after years of the API being de facto stable (even if I hadn't officially blessed it as such), I released 1.0.

From that point on, my main driver hasn't been "let's avoid a 2.0 or 3.0 forever." I have nothing against major version bumps. My actual rule is simpler: a breaking change needs to earn its place. If it's not genuinely useful enough to justify the pain it causes downstream, it doesn't happen.

It Was Never a Solo Project

I've told this story mostly in first person so far, which is a bit unfair, because AngleSharp would have died somewhere around "some happy paths seemed to work" if it had stayed a one-person effort.

The project's CONTRIBUTORS.md reads like a highlight reel of people who showed up over the years to fix a parser edge case, argue with me about API naming (we've had opinions), or add a feature I didn't know I needed. In order of first contribution: Andreas Augustin, Jerrie Pelser, Liwen Guo, Raphael Ducom, Georgii Dolzhykov, Joel Verhagen, Michael Ganss, Robin Sue, Henry Roeland, Adrian Phinney, Andreas Håkansson, Jeremy Meng, Yehudah Asher, Dennis Daume, Jakub Świętek, Dennis Gorelik, Georgios Diamantopoulos, Brian Ricketts, Laurynas Ruškys, Martin Wakley, Bastian Buchholz, Keith Hall, Nikita Ilinykh, Thomas Bolon, Alexander Ubillus, Max Katz - and plenty more across the ecosystem repos who deserve just as much credit.

One name on that list deserves a special callout: Michael Ganss. He contributed to AngleSharp early on, then went off and built HtmlSanitizer - a library that cleans HTML of XSS payloads - directly on top of it. So somewhere out there, a chunk of the web's HTML sanitization is running through code that started as a side project on an airplane, maintained partly by someone who used to fix that airplane project's bugs. I don't think you can plan a story arc like that.

Also worth saying clearly: AngleSharp is a .NET Foundation project. That's not nothing - it means the project has a support structure behind it beyond just "one person's spare time and mild sleep deprivation."

Where AngleSharp Shows Up Today

It's easy to undersell this part, so let me just put some numbers on the table. As of writing, the core AngleSharp NuGet package alone sits at over 310 million downloads. Add the satellite packages and you're comfortably north of 500 million installs across the ecosystem.

The curve is the fun part - this is basically a hockey stick with a decade-long windup:

Barely a blip until around 2019, and then it just... doesn't stop. That little dip in early 2025 on the core package is a NuGet stats quirk, not a mass exodus - don't worry, nobody suddenly stopped parsing HTML.

A few of the places AngleSharp quietly does the heavy lifting:

HtmlSanitizer (128M+ downloads on its own) uses AngleSharp to parse and re-render HTML while stripping out anything that could be used for cross-site scripting. If a .NET app on the internet safely accepts user-submitted HTML, there's a decent chance AngleSharp is standing guard.
bUnit, the go-to unit testing library for Blazor components, uses AngleSharp under the hood (via AngleSharp.Diffing) for its semantic HTML comparisons - the thing that lets you assert "this rendered markup is equivalent to that markup" without caring about attribute order or whitespace.
PreMailer.Net inlines CSS into HTML emails (because email clients are still living in 2003) using AngleSharp to actually understand the markup and styles it's rewriting.
WebDriverManager for .NET, which manages Selenium WebDriver binaries, also leans on it.

And then there's the list of projects that depend on it directly - some of which you've almost certainly used: Bitwarden (the password manager), Jackett and Prowlarr (torrent/indexer tooling), Playnite (game library manager), ArchiSteamFarm, OrchardCore (a full CMS/app framework), OpenIddict (OAuth2/OpenID Connect for .NET), YoutubeExplode, and even Microsoft's own ASP.NET Core documentation tooling repository.

None of this was the plan when I was scribbling parser states on a plane. But it turns out "a really solid, standards-compliant HTML parser for .NET" is one of those unglamorous building blocks that ends up everywhere once it exists.

Getting Started

Install the core package from NuGet:

dotnet add package AngleSharp

And parse your first document:

using AngleSharp;
using AngleSharp.Html.Parser;

var parser = new HtmlParser();
var document = await parser.ParseDocumentAsync("<h1>Hello!</h1><p>AngleSharp says hi.</p>");

var heading = document.QuerySelector("h1");
Console.WriteLine(heading.TextContent); // Hello!

That's the "hello world" version. Most real usage, though, goes through a BrowsingContext, which acts like a browser tab - it can load documents from the network, follow links, submit forms, and generally behave like something a bit more alive than a static parser:

using AngleSharp;

var config = Configuration.Default.WithDefaultLoader();
var context = BrowsingContext.New(config);

var document = await context.OpenAsync("https://example.com");

foreach (var link in document.QuerySelectorAll("a"))
{
    Console.WriteLine(link.GetAttribute("href"));
}

Want CSS support too? Add the plugin and register it in the configuration:

dotnet add package AngleSharp.Css

var config = Configuration.Default
    .WithDefaultLoader()
    .WithCss();

var context = BrowsingContext.New(config);
var document = await context.OpenAsync("https://example.com");

var body = document.QuerySelector("body");
var style = body.ComputeCurrentStyle();
Console.WriteLine(style.GetPropertyValue("background-color"));

Same idea for scripting (AngleSharp.Js), XML validation (AngleSharp.Xml), or semantic diffing of HTML fragments (AngleSharp.Diffing) - one With...() call, and a new capability shows up.

Where It Shines

Standards over vibes. The parser follows the actual HTML5 parsing algorithm, including its error-recovery rules. Feed it broken markup, and it recovers the way a browser would - not the way a regex-and-hope solution would.
A real DOM, not a wrapper. querySelector, querySelectorAll, LINQ-to-DOM, form submission, navigation via BrowsingContext - it feels like scripting a browser tab from C#, minus the browser.
Modular by design. Only pay (in dependencies and startup cost) for what you actually use. Need CSS cascade computation? Add one package. Need to run inline <script> tags? Add another.
Performance. It's not trying to be a browser engine, and that's exactly why it's fast - large documents parse in milliseconds, with internal reuse of elements to keep allocations down.
It composes well with automated testing. AngleSharp.Diffing in particular is great for asserting "this HTML is semantically the same as that HTML" without caring about attribute order or whitespace.

Where It Struggles

No project is without trade-offs, and I'd rather tell you about them than let you find out the hard way:

It's not a browser. There's no layout engine, no painting, no actual visual rendering (yet - more on that below). If you need pixel-accurate rendering, you still want something like Playwright or a headless Chromium.
JavaScript support is limited. AngleSharp.Js runs on Jint, which is a real ECMAScript engine, but it's not V8. Heavy, modern JS-driven pages (SPAs relying on a full browser runtime) are not its comfort zone, but definitely possible.
The ecosystem is spread across several repositories. Core, Css, Js, Xml, Io, Diffing, Wasm - it's modular by design, which is a strength, but it also means version compatibility between packages occasionally needs a bit of attention (dependency ranges across separately-versioned repos are always a fun problem to own - but generally the only dependency they all have is the core lib).
Breaking changes did happen historically. Pre-1.0 AngleSharp went through real API churn. It's stable and semver-respecting now, but if you find decade-old blog posts referencing the API, expect it to look different today.

The Wider Ecosystem

Depending on what you need, the packages you'll likely run into are:

AngleSharp (NuGet) - the core: HTML5/XML parsing, DOM, configuration.
AngleSharp.Css - CSSOM, selectors, cascades, computed styles.
AngleSharp.Js - JavaScript execution via Jint.
AngleSharp.Xml - XML parsing plus XSD/DTD validation.
AngleSharp.Io - requesters, cookies, and the networking stack.
AngleSharp.Diffing - semantic DOM diffing, great for tests.
AngleSharp.Wasm - running AngleSharp inside the browser via WebAssembly/Blazor.

If you want to talk to actual humans about it best case is to open an issue in one of the repos. Historically, there's also a Gitter chat and a tag that was / is used on Stack Overflow.

What's Next: Coming Full Circle

Remember that original goal - a cross-platform GUI built on HTML and CSS? That idea got shelved pretty early on in favor of "let's just get the fundamentals right first." But it never really left.

The next big frontier for AngleSharp is rendering. The plan is a general-purpose headless renderer that can be used interactively - moving a pointer, sending keystrokes, the works - or just to grab a screenshot. On top of that, the goal is a cross-platform control (most likely built on Avalonia) that can be embedded into apps.

Am I building a browser? Let's not get ahead of ourselves. But it's fair to say the project is closer to its original vision now than it's been at any point in the last decade.

That's the AngleSharp story - from a stack of printed spec pages on an airplane to a mature parsing ecosystem with XSD validation and WASM support. If you want to poke around, the code lives on GitHub, and the package is on NuGet.

Next up in this series: another one of my projects, and probably another origin story that started with me underestimating how much work something would be. Stay tuned!

netpack

Florian Rappl — Thu, 09 Jan 2025 23:51:37 +0000

This will be a short post... but hopefully with a longer one following up.

During my winter vacation I got some time to do one experiment:

Can web tooling created using C#/.NET yield comparable performance to Rust / Go / Zig ...?

So I did some coding... (that you can find on GitHub)

The Process

I started with a crude bundler logic:

Open files
Read their content
Use a regular expression to detect, e.g., import statements in JS files
Resolve linked modules
Open resolved / existing package.json files to identify module paths

The result was easy: Using AoT (ahead-of-time compilation) .NET can certainly be used for highly performing web projects.

So I continued a bit with the experiment; replacing regular expressions with actual code understanding.

TLDR; Results

The answer is: yes! 🤯

The bundler is at the moment feature-incomplete, but the first results are quite strong. The benchmarks shown in the README indicate that the performance is definitely in the same ballpark as other tools. So fast enough.

More Details

Personally, I think that C#/.NET is much less complicated than Rust and more powerful than Go. It comes with some drawbacks as well - not gonna lie.

The main reason why C#/.NET can be viable in that space is AoT. Without AoT the startup performance (as well as runtime requirements) is killing the whole idea.

AoT, on the other hand, comes with some challenges. Some libraries cannot be used or require some work to be integrated. Hence, some of the flexibility of .NET cannot be used.

For the largest test project also used by tools such as rspack we get these results:

Note that even the bundler is feature incomplete, it is crafted enough to produce a valid result on the project. So even though all results are at the moment preliminary there is at least some validity to it.

Test	esbuild	rspack	Vite	netpack
Small lib	326ms	611ms	601ms	359ms
Small project	670ms	912ms	1658ms	418ms
Medium project	1931ms	2877ms	10601ms	974ms
Large project	2189ms	2422ms	13710ms	1357ms

So yes, netpack already beats the competition and even has potential for even better performance. While it can be optimized further, it will also loose some performance when things such as sourcemaps or tree shaking are introduced. Right now I am positive that in total it should be around the same as of now due to the potential optimizations (such as streaming in the JS AST generation).

The biggest hurdle at the moment is that it only supports JS(X) - no TypeScript yet (it tries to parse these files, but once types are used it will fail). It would be "fairly" easy to support, but I would need to fork Acornima for that and that's something I'd only do if there is enough buzz around the project.

Outlook

There are many more things that would be superb to get into this. Some basics need to be cleared first though. Things such as sourcemaps, TypeScript support, or maybe a configuration system would be great.

There are some things in this experiment that no other bundler does. For instance, if your HTML entry point has an importmap, then the entries in the importmap are automatically taken as externals. Likewise, you can set certain dependencies as shared - in this case there are automatically importmap entries / an importmap created in the resulting HTML. Quite neat.

In the future the bundler will have native (i.e., out-of-the-box) support for SASS, CSS modules, CSS-in-JS, as well as module federation and native federation.

What are your thoughts? Do you think this is a viable idea or just trash? Is a fast .NET-native bundler with sensible defaults something we need?

Great edition - thanks to all the authors for their hard work!

Florian Rappl — Wed, 04 Dec 2024 08:31:48 +0000

What's Hot in Web Dev?

Florian Rappl ・ Dec 4

#webdev #javascript #frontend #node

What's Hot in Web Dev?

Florian Rappl — Wed, 04 Dec 2024 08:31:02 +0000

This year I started a new series on LinkedIn - "Advanced Links for Frontend". Each issue has 10 links to outstanding posts / articles. This bundle contains the links from the last 5 issues (issue 66 to issue 70).

I hope you enjoy this collection. Let me know in the comments which of these articles is your favorite (and why).

Issue 66

How Bun supports V8 APIs without using V8 (part 2) (https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-2) by Ben Grant

What is the best React Native list component? (https://expo.dev/blog/what-is-the-best-react-native-list-component) by Simon Grimm

Centering things: a solved problem? (https://fullystacked.net/centering-things/) by Ollie Williams

WebVM 2.0: A complete Linux Desktop Environment in the browser via WebAssembly (https://labs.leaningtech.com/blog/webvm-20) by Alessandro Pignotti

I Followed the Official AWS Amplify Guide and was Charged $1,100 (https://elliott-king.github.io/2024/10/amplify-overcharge/) by Elliott King

The Different (and Modern) Ways to Toggle Content (https://css-tricks.com/the-different-and-modern-ways-to-toggle-content/) by Daniel Schwarz

Using Typescript in node.js scripts without actually writing Typescript (https://www.jonathancreamer.com/using-typescript-in-node-js-scripts-without-actually-writing-typescript/) by Jonathan Creamer

Overflow Clip (https://ishadeed.com/article/overflow-clip/) by Ahmad Shadeed

Conditional Props in React Using Type Discrimination (https://elanmed.dev/blog/conditional-props-using-type-discrimination) by Elan Medoff

Micro Components - a different approach to a simpler component-based web (https://www.wearedevelopers.com/magazine/micro-components---an-alternative-to-web-components-and-frameworks/) by Chris Heilmann

Issue 67

JavaScript's ??= Operator: Default Values Made Simple (https://www.trevorlasn.com/blog/javascript-nullish-coalescing-assignment-operator) by Trevor Lasn

Fit-to-Width Text: A New Technique (https://kizu.dev/fit-to-width/) by Roman Komarov

Self-contained Executable Programs with Deno Compile (https://deno.com/blog/deno-compile-executable-programs) by Ryan Dahl and Andy Jiang

New in React 19 - Pre-warming (https://github.com/facebook/react/issues/29898) by Ricky Hanlon

Will we care about frameworks in the future? (https://paul.kinlan.me/will-we-care-about-frameworks-in-the-future/) by Paul Kinlan

Introducing the vlt Package Manager & Serverless Registry (https://blog.vlt.sh/blog/introducing-vlt-and-vsr) by Darcy Clark et al.

The Saga Pattern in Elixir (https://peterullrich.com/saga-pattern-in-elixir) by Peter Ullrich

Generating Random Mazes with JavaScript (https://cloudfour.com/thinks/generating-random-mazes-with-javascript/) by Paul Hebert

Beautiful focus outlines (https://medienbaecker.com/articles/focus-outlines) by Thomas Günther

The Tragedy of Running an Old Node Project (https://abdisalan.com/posts/tragedy-running-old-node-project) by Abdisalan Mohamud

Issue 68

Long Frames and INP: Understanding Post-Load Performance (https://dev.to/viniciusdallacqua/long-frames-and-inp-understanding-post-load-performance-2maa) by @viniciusdallacqua

Reporting Core Web Vitals With The Performance API (https://www.smashingmagazine.com/2024/02/reporting-core-web-vitals-performance-api/) by Geoff Graham

React Router v7 (https://remix.run/blog/react-router-v7) by Michael Jackson

The Shadow DOM is in the front (https://abstract.properties/the-shadow-dom-is-in-the-front.html) by Sufian Rhazi

Tailwind CSS v4.0 Beta 1 (https://tailwindcss.com/blog/tailwindcss-v4-beta) by Adam Wathan

Announcing TypeScript 5.7 (https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/) by Daniel Rosenwasser

Handling Cookies is a Minefield (https://grayduck.mn/2024/11/21/handling-cookies-is-a-minefield/) by April King

This Website is Hosted on Bluesky (https://danielmangum.com/posts/this-website-is-hosted-on-bluesky/) by Daniel Mangum

Zero Disk Architecture (https://avi.im/blag/2024/zero-disk-architecture/) by Avinash Sajjanshetty

Google’s Chrome Worth Up to $20 Billion If Judge Orders Sale (https://www.bloomberg.com/news/articles/2024-11-18/doj-will-push-google-to-sell-off-chrome-to-break-search-monopoly) by Leah Nylen and Josh Sisco

Issue 69

Webflow Design Language: Bridging The Gap Between Design & Code (https://webflow.com/blog/webflow-design-language) by Merrick Christensen

Building Reddit’s Frontend with Vite (https://www.reddit.com/r/RedditEng/comments/1dhztk8/building_reddits_frontend_with_vite/) by Jim Simon

Interop and Hard Problems (https://bkardell.com/blog/debt.html) by Brian Kardell

Vite 6.0 is out! (https://vite.dev/blog/announcing-vite6.html) by Evan You

A Complete Guide To Live Validation UX (https://www.smashingmagazine.com/2022/09/inline-validation-web-forms-ux/) by Vitaly Friedman

Placeholders in Form Fields Are Harmful (https://www.nngroup.com/articles/form-design-placeholders/) by Katie Sherwin

Browser APIs: Must-Know Secrets for Every Frontend Developer! (https://dev.to/mukhilpadmanabhan/browser-apis-must-know-secrets-for-every-frontend-developer-55lk) by @mukhilpadmanabhan

I learned React Native as a web developer, and I got everything wrong (https://fernandorojo.co/mistakes) by Fernando Rojo

Why TanStack Start is Ditching Adapters (https://tanstack.com/blog/why-tanstack-start-is-ditching-adapters) by Tanner Linsley

Vitest vs. Jest (https://www.speakeasy.com/post/vitest-vs-jest) by Nolan Sullivan

Issue 70

Why am I writing a JavaScript toolchain in Zig? (https://injuly.in/blog/announcing-jam/index.html) by Srijan Paul

November 20, 2024 Release (https://react-spectrum.adobe.com/releases/2024-11-20.html) by React Aria

Effortless UI Spring Animations: A Two-Parameter Approach (https://www.kvin.me/posts/effortless-ui-spring-animations) by Kevin Grajeda

If Not React, Then What? (https://infrequently.org/2024/11/if-not-react-then-what/) by Alex Russell

Comparing AWS S3 with Cloudflare R2: Price, Performance and User Experience (https://kerkour.com/aws-s3-vs-cloudflare-r2-price-performance-user-experience) by Sylvain Kerkour

The Must-Have Obsidian plugins for 2025 (https://www.dsebastien.net/2022-10-19-the-must-have-obsidian-plugins/) by Sebastien Dubois

A Layered Approach to Speculation Rules (https://csswizardry.com/2024/12/a-layered-approach-to-speculation-rules/) by Harry Roberts

Nothing Is Something (https://blog.jim-nielsen.com/2024/nothing-is-something/) by Jim Nielsen

Increasing Vite's potential with the Environment API (https://green.sapphi.red/blog/increasing-vites-potential-with-the-environment-api) by sapphi-red

Existential React questions and a perfect Modal Dialog (https://www.developerway.com/posts/hard-react-questions-and-modal-dialog) by Nadia Makarevich

Conclusion

These are all outstanding articles by masterful authors. I enjoyed reading them all - I hope you did find something in there, too.

👉 Follow me on LinkedIn, Twitter, BlueSky, or here for more to come.

🙏 Thanks to all the authors and contributors for their hard work!

🤯 50 Articles to Become a Web Dev Guru

Florian Rappl — Fri, 15 Nov 2024 19:15:31 +0000

I hope you enjoy this collection. Let me know in the comments which of these articles is your favorite (and why).

Issue 61

Liskov’s Gun: The parallel evolution of React and Web Components (https://www.baldurbjarnason.com/2024/liskovs-gun/) by Baldur Bjarnason

Mozilla rebrand takes from early internet aesthetics, to move its cause to reclaim the web (https://www.itsnicethat.com/articles/jkr-mozilla-rebrand-graphic-design-project-240924) by Ellis Tree

What's New in Ruby on Rails 8 (https://blog.appsignal.com/2024/10/07/whats-new-in-ruby-on-rails-8.html) by Damilola Olantuji

A modest critique of Htmx (https://chrisdone.com/posts/htmx-critique/) by Chris Done

HTML is for people (https://htmlforpeople.com/) by Blake Watson

17 Must-know React Projects for Developers 👩‍💻 🔥 (https://dev.to/tolgee_i18n/17-must-know-react-projects-for-developers-28a2) by @anmolbaranwal

The story of web framework Hono, from the creator of Hono (https://blog.cloudflare.com/the-story-of-web-framework-hono-from-the-creator-of-hono/) by Yusuke Wada

Sites Now Become Interactive 50% Faster (https://www.framer.com/blog/sites-interactive-faster/) by Jacob Groß

Drag to Select (https://www.joshuawootonn.com/react-drag-to-select) by Joshua Wootonn

Why I’m skeptical of rewriting JavaScript tools in “faster” languages (https://nolanlawson.com/2024/10/20/why-im-skeptical-of-rewriting-javascript-tools-in-faster-languages/) by Nolan Lawson

Issue 62

Our Journey with Caching (https://nextjs.org/blog/our-journey-with-caching) by Sebastian Markbåge

Offline UX Patterns (https://github.com/Expensify/App/blob/main/contributingGuides/OFFLINE_UX.md) by Expensify

World Wide Web Foundation closes so Tim Berners-Lee can spend more time with his protocol (https://www.theregister.com/2024/09/30/world_wide_web_foundation_closes/) by Thomas Claburn

why I'm turning off Firefox ad tracking: the PPA paradox (https://blog.zgp.org/why-turn-off-firefox-ad-tracking/) by Don Marti

Hyper-Scale Activated! Ship Your Own FaaS 🤖 (https://dev.to/smapiot/hyper-scale-activated-ship-your-own-faas-40kg) by @florianrappl

Next.js 15 (https://nextjs.org/blog/next-15) by Delba de Oliveira et al

AWS Data Center Latencies - Visualized (https://benjdd.com/aws/) by Benjamin Dicken

Where web components shine (https://daverupert.com/2024/10/super-web-components-sunshine/) by Dave Rupert

Netlify joins OpenNext (https://www.netlify.com/blog/netlify-joins-opennext/) by Mathias Biilmann

New Architecture is here (https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here) by The React Team

Issue 63

Expo SDK 52 beta is now available (https://expo.dev/changelog/2024/10-24-sdk-52-beta) by Brent Vatne

That's Not an Abstraction, That's Just a Layer of Indirection (https://fhur.me/posts/2024/thats-not-an-abstraction) by Fernando Hurtado

An Early Glimpse of TanStack Start (https://www.youtube.com/watch?v=AuHqwQsf64o) by Tanner Lindsey

How we shrunk our Javascript monorepo git size by 94% (https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/) by Jonathan Creamer

Making content-aware components using CSS :has(), grid, and quantity queries (https://piccalil.li/blog/making-content-aware-components-using-css-has-grid-and-quantity-queries/) by Eric Bailey

Remix Todo App: Part 1 - Building the App Layout and Structure (https://www.udohjeremiah.com/blog/remix-todo-app-part-1-building-the-app-layout-and-structure) by Udoh Jeremiah

Using Rust in Non-Rust Servers to Improve Performance (https://github.com/pretzelhammer/rust-blog/blob/master/posts/rust-in-non-rust-servers.md) by Pretzelhammer

Interactive Select component using Phoenix LiveView and vanilla JS Hook (https://aurmartin.fr/posts/phoenix-liveview-select/) by Aurélien Martin

Unleash the Power of Scroll-Driven Animations (https://css-tricks.com/unleash-the-power-of-scroll-driven-animations/) by Geoff Graham

Incremental adoption of micro-frontends with Cloudflare Workers (https://blog.cloudflare.com/fragment-piercing/) by Peter Bacon Darwin, Dario Piotrowicz, James Culveyhouse, Igor Minar

Issue 64

Headless, boneless, skinless & lifeless UI (https://nerdy.dev/headless-boneless-and-skinless-ui) by Adam Argyle

On Crafting Painterly Shaders (https://blog.maximeheckel.com/posts/on-crafting-painterly-shaders/) by Maxime Heckel

Smarter than 'Ctrl+F': Linking Directly to Web Page Content (https://alfy.blog/2024/10/19/linking-directly-to-web-page-content.html) by Ahmad Alfy

Simplfying Islands Architecture (https://preactjs.com/blog/simplifying-islands-arch/) by Siddharth Gelera

Going through the “State of CSS” results… (https://www.joshwcomeau.com/email/2024-10-22-css-survey/) by Josh W. Comeau

Rendering Outlines with a Post-processing Shader (https://www.atomwolf.org/posts/rendering-outlines-with-a-post-processing-shader/) by Adam Wolf

Should JavaScript be split into two languages? New Google-driven proposal divides opinion (https://devclass.com/2024/10/22/should-javascript-be-split-into-two-languages-new-google-driven-proposal-divides-opinion/) by Tim Anderson

Introducing Wasmer 5.0 (https://wasmer.io/posts/introducing-wasmer-v5) by Syrus Akbary

Should masonry be part of CSS grid? (https://ishadeed.com/article/css-grid-masonry/) by Ahmad Shadeed

Recap: Next.js Conf 2024 (https://vercel.com/blog/recap-next-js-conf-2024) by Lee Robinson, Delba de Oliveira

Issue 65

How headless components became the future for building UI libraries (https://www.subframe.com/blog/how-headless-components-became-the-future-for-building-ui-libraries) by Irvin Zhan

Hyperkit (https://www.chrsgrrtt.com/hyperkit) by Chris Garrett

Converting any website to a React component (https://www.magicpatterns.com/blog/any-website-to-react-component) by Teddy Ni

HTML Form Validation is heavily underused (https://expressionstatement.com/html-form-validation-is-heavily-underused) by everdimension

Using Shadcn UI without a Tailwind Config File (https://www.luisball.com/blog/shadcn-ui-with-tailwind-v4) by Luis Ball

Debugging Microservices & Distributed Systems (https://sentry.io/resources/debugging-microservices-and-distributed-systems/) by Sarah Guthals

RFC: An updated style guide for the year 2024 (https://github.com/angular/angular/discussions/58412) by Jeremy Elbourn

My solar-powered and self-hosted website (https://dri.es/my-solar-powered-and-self-hosted-website) by Dries Buytaert

HTTP Tunnel and Proxy in JavaScript (https://dbushell.com/2024/10/22/http-tunnel-proxy/) by David Bushell

What's a Single-Page App? (https://jakelazaroff.com/words/whats-a-single-page-app/) by Jake Lazaroff

Conclusion

These are all outstanding articles by masterful authors. I enjoyed reading them all - I hope you did find something in there, too.

👉 Follow me on LinkedIn, Twitter, or here for more to come.

🙏 Thanks to all the authors and contributors for their hard work!

Hyper-Scale Activated! Ship Your Own FaaS 🤖

Florian Rappl — Fri, 18 Oct 2024 12:34:36 +0000

In the past decade I've done a lot of work on distributed web applications. In that area you definitely require processes that work implicitly - fully decoupled, with autonomy for individual teams and modules.

The key question quite often is:

How awesome would it be to just extend your application at runtime without any downtime whatsoever?!

In this article I want to look at how we can extend a Node server using Express.js to act like a FaaS provider (such as AWS Lambda or Azure Functions).

Prerequisites

To follow this article you'll need the following:

Node.js with npm installed (I recommend version 22 or higher - we'll use fetch in Node, which is available since version 18)
A code editor
If you want to clone the sample project you'll need to have git installed (but you can download it as a ZIP from GitHub)
Access to the Piral Cloud Feed Service - you can use it for free using a Microsoft or GitHub account

Architecture

Before we start to write some code let's look at the anticipated architecture:

Using the Piral Cloud Feed Service we get access to a dynamic service / module registry, which we can leverage to load a list of modules, evaluate them directly from their URLs, and then use them to populate a list of (sub-)routers.

The routers are necessary to extend the default router middleware. Let's see the whole thing in action. We start by writing the server.

Writing the Server

As server we use a pretty standard and lightweight Express.js server. It can be created by running the following commands in a new directory.

We first initialize a new npm project:

npm init -y

Now we install the required dependency:

npm i express

We add a new file (index.js) with the following content:

const express = require("express");

const port = 3000;
const app = express();

app.get("/", (req, res) => {
  res.send("Hello world!");
});

app.listen(port, () => {
  console.log(`Running at http://localhost:${port}`);
});

And we finally run the application:

node index.js

Go to localhost:3000 in the browser of your choice and see that everything is running as it should:

Great! But there is a bit more to it for making it truly dynamic...

Making the Server Dynamic

So what we are after is to run modules that we can just publish whenever we feel the need for it. The first thing to look for is to avoid having routing issues.

To prevent different modules for occupying the same route we will actually namespace the routes by their module names. In Express.js this also allows us to use dynamic Router objects, which are bound to their module names.

In code this can be done like that:

const routers = {};

app.use("/:namespace", (req, res, next) => {
  const { namespace } = req.params;
  const router = routers[namespace];

  if (router) {
    return router(req, res, next);
  }

  return next();
});

We introduce a middleware that is sensitive to a namespace parameter. In a productive setup we might want to constraint this a bit further, e.g., /api/:namespace or /apps/:namespace, to avoid clashes between in-built functionality and the modules.

The job of the middleware is to use the retrieved namespace value by looking at all available sub-routers. If a sub-router is matched we will use the sub-router as follow-up middleware. Otherwise, we continue with the next middleware. Usually, the next middleware would be the "not-found-route" from Express.js.

The question to answer now is how to populate the routers object. How can we obtain these sub-routers?

What we can do is to introduce a function to obtain the information from a discovery service. This service gets us all the relevant pieces of information - we then only need to load / run the referenced modules.

The necessary code to built something like that is:

const feed = "https://feed.piral.cloud/api/v1/pilet/express-demo";

function makeId(item) {
  return `${item.name}@${item.version}`;
}

async function loadPlugins() {
  console.log("Loading plugins ...");
  const res = await fetch(feed);
  const { items } = await res.json();

  for (const item of items) {
    const id = makeId(item);
    console.log(`Integrating plugin "${id}" ...`);
    await installPlugin(item);
    console.log(`Integrated plugin "${id}"!`);
  }

  watchPlugins();
}

loadPlugins();

What are we doing here?

We want to start loading the plugins / sub-routers as fast as possible. So we immediately run the loadPlugins function. Ideally we use the top-level await here; if it's not available (or if we want to save a bit of startup time) we just call it as shown.
The loadPlugins fetches the information from the discovery service.
Once the information is fetched we go over the contained items array. Each item is treated like the meta information of a plugin - so we just call installPlugin to use the found meta information.
Finally we also want to react when something changes - so the loadPlugins part concludes by watching for changes using the watchPlugins function.

Important Note
If you want to follow this on your own then replace https://feed.piral.cloud/api/v1/pilet/express-demo with your own discovery feed URL. Using the Piral Cloud Feed Service you can see the URL on the feed overview page.

Let's look at the installPlugin first:

const current = [];

async function installPlugin(item) {
  const { name, link } = item;
  const router = express.Router();
  const { setup } = await loadModule(link);
  typeof setup === "function" && setup(router);
  routers[name] = router;
  current.push({ id: makeId(item), name });
}

Doesn't look too complicated, does it? What's happening here?

We decompose the item - but we are only interested in the name and link (module reference / URL) of the module.
We create a new Express.js Router instance (the "sub-router").
We load the respective module - it should get us a function called setup (now this is a design choice; you could either name it differently, make it a default export, or export a Router instance directly...
If we really obtained a setup function we call it with the Router instance. This can now be modified properly.
Finally, the created router is assigned to the routers object and the current array is extended with the proper entry.

As you might have guessed the current array is for book-keeping purposes. It allows us to easily patch / change the routers in case of changes. For this, we'll need to look at the watchPlugins function:

const WebSocket = require("ws");

const changeEventTypes = ["add-pilet", "update-pilet", "remove-pilet"];

function watchPlugins() {
  console.log("Watching plugins ...");
  const ws = new WebSocket(feed.replace("http", "ws"));

  ws.on("error", console.error);

  ws.on("message", async (data) => {
    const msg = JSON.parse(Buffer.from(data).toString("utf8"));

    if (changeEventTypes.includes(msg.type)) {
      const res = await fetch(feed);
      const { items } = await res.json();
      const removeItems = current.filter(
        ({ id }) => !items.some((n) => makeId(n) === id)
      );
      const addItems = items.filter(
        (item) => !current.some(({ id }) => id === makeId(item))
      );

      for (const item of removeItems) {
        await uninstallPlugin(item);
      }

      for (const item of addItems) {
        await installPlugin(item);
      }
    }
  });
}

For this code to run we rely on the ws library. So we'll need to install it first:

npm i ws

With ws active we can have a look at what the code does:

We define some events we want to listen to. The provided events are send via the WebSocket channel in case the contained modules change.
Once a message is received we transform it (from raw bytes to a JSON object) and check if the type matches one of the events defined in (1).
We could now use the information from the event, but some events (e.g., update-pilet) don't tell us what changed. In such cases we could be in a problematic zone. So we follow the safe route and just re-load all the modules.
Finally, we need to compare the current information from the discovery service vs the stored / previous information. For the changed (removed, updated) modules we remove them using the uninstallPlugin. All the ones that are not yet instantiated we add them using the installPlugin function.

The uninstallPlugin looks as follows:

async function uninstallPlugin(item) {
  delete routers[item.name];
  current.splice(current.indexOf(item));
}

That was easy, right? But so far we avoided the most complicated topic. How are we evaluating those modules?

Evaluating Modules from URLs

In the browser you can always evaluate ESMs - they are coming from an URL by default. The same is true in runtimes such as Deno. But in Node.js this is not possible. So should we give up?

As it turns out evaluating URLs is actually not so difficult. We need 2 things:

Code to use the vm module. We need to rely on the SourceTextModule to create modules on the fly.
The experimental flag --experimental-vm-modules for running Node. This way, the SourceTextModule is available at runtime.

Using those two ways we can add the following code to our server:

const vm = require("vm");

async function linkModule(url, ctx) {
  const res = await fetch(url);
  const content = await res.text();
  const mod = new vm.SourceTextModule(content);
  mod.context = ctx;
  await mod.link((specifier) => {
    const newUrl = new URL(specifier, url);
    return linkModule(newUrl.href, ctx);
  });
  await mod.evaluate();
  return mod;
}

async function loadModule(url) {
  const ctx = vm.createContext();

  try {
    const res = await linkModule(url, ctx);
    return res.namespace;
  } catch (ex) {
    console.warn(`Failed to evaluate "${url}":`, ex);
    return {};
  }
}

Finally, we have everything together and can just run the server with the flag:

node --experimental-vm-modules index.js

We should see output like this in the console:

Loading plugins ...
Running at http://localhost:3000
Integrating plugin "app1@2.0.0" ...
Integrated plugin "app1@2.0.0"!
Integrating plugin "app2@1.0.4" ...
(node:23052) ExperimentalWarning: VM Modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Integrated plugin "app2@1.0.4"!
Integrating plugin "app3@1.0.0" ...
Integrated plugin "app3@1.0.0"!
Watching plugins ...

Here, we are already including a couple of modules (referred to as plugins). Let's see what we can do here - how we can write, deploy, and update them.

Example Functions

One Module

The first example is a really simple one; just a single function to return a constant string:

export function setup(router) {
  router.get("/foo", (req, res) => {
    res.send("Hello from app1 v2: /foo");
  });
}

Importantly, we initialize a new project and define the package.json like this:

{
  "name": "app1",
  "version": "1.0.0",
  "module": "index.js",
  "scripts": {
    "deploy": "publish-microfrontend --url https://feed.piral.cloud/api/v1/pilet/express-demo --interactive"
  },
  "devDependencies": {
    "publish-microfrontend": "^1.6.2"
  }
}

The publish-microfrontend script is used to deploy the module. This little script just packages the current project and invokes a POST against the provided discovery service URL. The --interactive flag then allows us to dynamically log into the discovery service to deploy our function.

We'll see how this process looks in a second. Let's look at another example.

Two Modules

While publishing the package with a single module works as expected the question is: Does it also work with more modules? The answer is yes.

Pretty much the same definition in the package.json:

{
  "name": "app2",
  "version": "1.0.0",
  "module": "lib/index.js",
  "scripts": {
    "deploy": "publish-microfrontend --url https://feed.dev.piral.cloud/api/v1/pilet/express-demo --interactive"
  },
  "devDependencies": {
    "publish-microfrontend": "^1.6.2"
  }
}

But now lib/index.js is different:

import { compute } from './other.js';

export function setup(router) {
  router.get("/compute", (req, res) => {
    const { a, b } = req.query;
    const c = compute(+a, +b);

    if (!isNaN(c)) {
      return res.status(200).send(`${c}`);
    }

    return res.status(400).send(`Only numbers allowed.`);
  });
}

Not only is this a bit more logic - it also uses a function from another module located at lib/other.js:

export function compute(a, b) {
  if (typeof a === "number" && typeof b === "number") {
    return (a + b) * (a - b);
  }

  return NaN;
}

As you might have guessed our ESM URL loader just works as it should. No questions asked. Great!

We won't answer the burning question: Can it do three modules? I guess we know the answer, but if you want to find out get active now!

In the meantime we go already to the complex case of having the modules written in TypeScript - and including some dependencies.

TypeScript Modules with Dependencies

Consider the code at src/index.ts:

import cors from 'cors';
import type { Router } from "express-serve-static-core";

export function setup(router: Router) {
  router.use(cors());

  router.get("/", (req, res) => {
    res.status(404).send(`NOT FOUND.`);
  });
}

Here we are using types and dependencies. This won't work - we don't do any dependency resolution and we don't transpile TypeScript. So should we be worried? Not at all!

Let's bundle it using esbuild:

esbuild --outdir=dist src/index.ts --bundle --platform=node --format=esm

Even better - we can just extend the package.json to take care of this in the deploy task:

{
  "name": "app3",
  "version": "1.0.0",
  "module": "dist/index.js",
  "scripts": {
    "build": "esbuild --outdir=dist src/index.ts --bundle --platform=node --format=esm",
    "deploy": "npm run build && publish-microfrontend --url https://feed.dev.piral.cloud/api/v1/pilet/express-demo --interactive"
  },
  "devDependencies": {
    "@types/cors": "^2.8.17",
    "@types/express": "^5.0.0",
    "esbuild": "^0.24.0",
    "publish-microfrontend": "^1.6.2"
  },
  "dependencies": {
    "cors": "^2.8.5"
  }
}

This way, we can just write anything - bundle it using esbuild and ship it with publish-microfrontend.

Now let's step back a bit and see how we actually deploy the modules:

Deployment

Maybe let's see first how it looks in the discovery service when we deployed all of our modules:

As already mentioned for deploying such a module we can use the available publish-microfrontend npm package:

npx publish-microfrontend --url <your-discovery-service-url> --api-key <your-key>

In cases such as the ones above we might swap the --api-key with an --interactive flow, where we need to use the browser for obtaining a user token instead.

npx publish-microfrontend --url <your-discovery-service-url> --interactive

Let's see how this process looks in real life:

In the end having such a powerful service registry between our server and the respective modules is not only clean, but also useful for flexibility reasons.

Advanced Dynamics

We already saw that the dynamics with respect to partial rollbacks are in place from the beginning. In general, the service registry's portal gives us the ability to control every bit of the delivery process:

The version selector in particular is quite useful. Besides the possibility of making rollbacks, we can also do feature flags, A/B testing, blue-green deployments, or canary releases.

Quite powerful stuff...

This allows us, e.g., to have multiple instances of our Express.js server, where each instance might get a different set of modules. Sounds crazy (how can this be useful?!) but if you don't consider these instances equal (i.e., meant for scaling), but rather as different sites (e.g., one for US, one for EU etc.) then backend behavior might be different - at least in some areas.

Beforehand, that was a lot of overhead. You had to produce countless variations of the same server - now you can just have one and have the different behavior qualified through the loaded modules.

Conclusion

In this article you've seen how you can easily extend your Express.js server into a FaaS platform allowing you to add, update, and remove endpoints on the fly.

Of course, the provided sample is rather simplistic and does not solve some of the issues including advanced isolation, memory footprint (unload and restrictions of modules), local module development using an emulator, and many others. But it's a very convenient start - showing what's possible with just a few lines of code.

Check out the sample code at github.com/piral-samples/piral-cloud-express-plugins-demo.

🎃 50 Articles to Avoid Web Dev Nightmares

Florian Rappl — Tue, 15 Oct 2024 13:28:34 +0000

I hope you enjoy this collection. Let me know in the comments which of these articles is your favorite (and why).

Issue 56

The CSS radial composer (https://zumerlab.github.io/orbit-docs/) by Orbit
Gravity is everywhere! For some reason I feel attracted to this.

Remix's concurrent submissions are fundamentally flawed (without causal ordering) (https://dashbit.co/blog/remix-concurrent-submissions-flawed) by José Valim
Honestly, I am not surprised.

ts-blank-space (https://bloomberg.github.io/ts-blank-space/) by Ashley Claymore
This can be really useful, but I wonder why not just esbuild is used. It's fast and can also be used for more.

date-fns v4.0 is out with first-class time zones support! (https://blog.date-fns.org/v40-with-time-zone-support/) by Sasha Koss
Well, having time zones support is one of the things I'd consider necessary for any good time library.

Fastify v5 is Now Officially Released! (https://openjsf.org/blog/fastifys-growth-and-success) by Fastify Team
Fastify is great and presumably under-appreciated in the Node.js community.

WebKit Features in Safari 18.0 (https://webkit.org/blog/15865/webkit-features-in-safari-18-0/) by Jen Simmons
Keep an eye on this - view transitions and WebXR are huge! Fantastic release!

Biome v1.9 Anniversary Release (https://biomejs.dev/blog/biome-v1-9/) by Victorien Elvinger
Alright I can happily say that finally Biome is also becoming interesting to me. Goodbye Prettier + eslint!

A milestone for TypeScript Performance in TanStack Router (https://tanstack.com/blog/tanstack-router-typescript-performance) by Christopher Horobin
Great write-up with some insights on how the type checker / TypeScript performance can be evaluated and improved.

New Values and Functions in CSS (https://dev.to/alvaromontoro/new-values-and-functions-in-css-1b9o) by @alvaromontoro
Well, some of these functions are not really new, but it's always good to be reminded about them.

Deno 2.0 Release Candidate (https://deno.com/blog/v2.0-release-candidate) by Andy Jiang and Bartek Iwańczuk
The v2 promises to be a really well-rounded release. Time for everyone to take another look at Deno!

Issue 57

How Discord Reduced Websocket Traffic by 40% (https://discord.com/blog/how-discord-reduced-websocket-traffic-by-40-percent) by Austin Whyte
A lot of micro optimizations and lazy loading (or "sending") for the win!

You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths (https://htmx.org/essays/you-cant/) by Tony Alaribe
Never heard that myth - but it's fine for me to claim that fire has been rediscovered.

Component Composition is great btw (https://tkdodo.eu/blog/component-composition-is-great-btw) by Dominik Dorfmeister
Truly. What's also great is to have the right company boundaries.

Compile and run C in JavaScript (https://bun.sh/blog/compile-and-run-c-in-js) by Jarred Sumner
More like: Compile and run C in Bun. As usual, I see the devil being in the detail.

The Nine Node Pillars (https://www.platformatichq.com/node-principles) by Matteo Collina et al.
It's great to recap those pillars, even though I did not find anything really Node.js specific (most of the points could be assigned on to any web server).

Module Federation Vite the new v1 is here 🎉 (https://www.learnbydo.ing/diary/2024-09-23-module-federation-vite-v1) by Giorgio Boa
Happy to see that progress is made! Now we only miss all the other bundlers ...

The Golden Ratio in CSS (https://dev.to/madsstoumann/the-golden-ratio-in-css-53d0) by @madsstoumann
Sweet - starts with some boxes and ends with a lot of rings. I love it!

Sticky Transitioning Veggie Hamburger 🍔 (https://dev.to/florianrappl/sticky-transitioning-veggie-hamburger-7dd) by @florianrappl
Put your web app on a diet and reduce the amount of JS - especially when not needed.

Why Typed Linting Needs TypeScript Today (https://www.joshuakgoldberg.com/blog/why-typed-linting-needs-typescript-today/) by Josh Goldberg
Every once in a while somebody tries to reimplement TypeScript - so far everyone failed. Yes, TypeScript is required.

Improving rendering performance with CSS content-visibility (https://nolanlawson.com/2024/09/18/improving-rendering-performance-with-css-content-visibility/) by Nolan Lawson
This is indeed magical. I see some difficulties here, but certainly no less than doing actual lazy loading / virtualization in JavaScript.

Issue 58

Ever faced the problem of dead space through gaps using flexbox or grid? Then read about
Sanding UI (https://blog.jim-nielsen.com/2024/sanding-ui/) by Jim Nielsen

As you are all aware Ahmad has become my favorite author for CSS related articles. Recently he gave his website some polish. Read about the
Redesign Case Study (https://ishadeed.com/article/redesign-2024/) by Ahmad Shadeed

Now that we conquered client islands it's time for server islands to become standard. One way is discussed in
Partial Prerendering for Everyone with Cloudflare Workers (https://sunilpai.dev/posts/ppr-for-everyone/) by Sunil Pai

It was quite a week for web components. We started with
Web Components Are Not the Future (https://dev.to/ryansolid/web-components-are-not-the-future-48bh) by @ryansolid

But as usual on this topic there had to be different opinions. Entering
Web Components Are Not the Future — They’re the Present (https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/) by Cory LaViska

In the end both have their points and perspectives, but like the old XKCD comic it was the job of a third person to summarize in
Web components are okay (https://nolanlawson.com/2024/09/28/web-components-are-okay/) by Nolan Lawson

Years ago we tried to introduce scoping in CSS - but without much success. Now the working group is back with power... Let's try
Understanding the Concept of Scoping in CSS (https://dev.to/bilkeesu96/understanding-the-concept-of-scoping-in-css-1m9g) by @bilkeesu96

A major downside of classic cron jobs is the failure cascade. This can be countered by some worker frameworks - for instance offering something dubbed durable functions.
What are Durable Functions? A visual JavaScript primer (https://www.inngest.com/blog/durable-functions-a-visual-javascript-primer) by Lydia Hallie

Having tests is both - a pain and necessity. Especially in the frontend things tend to become difficult - relying on the browser and user behavior for many features. Let's recap
Testing Frontend — Lessons from over a million lines of TypeScript at Palantir (https://www.meticulous.ai/blog/lessons-from-a-decade) by Quentin Spencer-Harper

Not only the web component department delivered... If you missed the excitement delivered by the WordPress community then read
The messy WordPress drama, explained (https://www.theverge.com/2024/9/27/24256361/wordpress-wp-engine-drama-explained-matt-mullenweg) by Emma Roth

Issue 59

Building a Single-Page App with htmx (https://jakelazaroff.com/words/building-a-single-page-app-with-htmx/) by Jake Lazaroff
Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

Keeping an eye on changes to MDN’s Browser Compatibility Data (https://bcd-watch.igalia.com/) by igalia
This is quite neat - not only knowing what changed, but also when it changed.

*OpenFreeMap *(https://openfreemap.org/) by Zsolt Ero
Eagerly waiting to use this with Leaflet - but the Mapbox demos look great, too.

Bridging the hard and the soft (https://wattenberger.com/thoughts/hard-and-soft) by Amelia Wattenberger
Superb read - it's all about the interface.

ESLint now officially supports linting of JSON and Markdown (https://eslint.org/blog/2024/10/eslint-json-markdown-support/) by Nicholas Zakas
I am not getting enough warnings already.

Tauri 2.0 Stable Release (https://v2.tauri.app/blog/tauri-20/) by Tillmann Weidinger
It's now just a much better DX.

Running Clang in the browser using WebAssembly (https://wasmer.io/posts/clang-in-browser) by Syrus Akbary
I need to repeat: Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

Unleash JavaScript's Potential with Functional Programming (https://janhesters.com/blog/unleash-javascripts-potential-with-functional-programming) by Jan Hesters
Personal opinion: Don't get too much into FP, but just take the best pieces and use them.

A Local-First Case Study (https://jakelazaroff.com/words/a-local-first-case-study/) by Jake Lazaroff
Local-first is underappreciated but should be a cornerstone for good DX.

Why Gumroad Didn't Choose htmx (https://htmx.org/essays/why-gumroad-didnt-choose-htmx/) by Sahil Lavingia
It's fine. No one needs to choose everything. Everything has trade-offs and I believe in choice.

Issue 60

If you look for icons to be used in your next project - then maybe start directly at
15+ Best Icon Libraries of 2024 (https://dev.to/vinishbhaskar/best-icon-libraries-28ce) by @vinishbhaskar

Ever wondered how to get or set up a great CRM for free? if so, check out
Atomic CRM (https://marmelab.com/atomic-crm/) by Marmelab

In case you missed the preview you can now enjoy the full next gen Node.js competitor;
Announcing Deno 2 (https://deno.com/blog/v2.0) by Ryan Dahl

Are you sometimes hesitant to just install npm packages? Paranoid, maybe not - here are some
Nightmares on npm: How Two Malicious Packages Facilitate Data Theft and Destruction (https://socket.dev/blog/nightmares-on-npm-how-two-malicious-packages-facilitate-data-theft-and-destruction) by Kush Pandya

I think there is a great new framework in town (no week without it!) - server-first with JSX to web components for islands of interactivity. Entering
The Web Platform Framework (https://brisa.build) by Aral Roca Gomez

Ever thought that logs can provide much more insights, but are too clumsy to work with? Maybe strict sequential logs are not the answer. One approach can be found by reading an
Introduction to Causal Logs (https://joelgustafson.com/posts/2024-09-30/introduction-to-causal-logs) by Joel Gustafson

Besides having a new framework each week there is also another attempt on explaining and visualizing how React renders (or reconciliates) your view - so let's dive into
The Interactive Guide to Rendering in React (https://ui.dev/why-react-renders) by UiDev

Do you believe that JavaScript on the server is essentially PHP? I did not - but if you did then read
React on the server is not PHP (https://www.artmann.co/articles/react-on-the-server-is-not-php) by Christoffer Artmann

Do you like mysteries? Then try solving the riddle of
Node.js, pipes, and disappearing bytes (https://sxlijin.github.io/2024-10-09-node-stdout-disappearing-bytes) by Sam Lijin

I have a feeling that the server-side story for React gets more fragmented and unnecessarily complex each day - even without talking about
Serverless servers and the challenge of new React architecture (https://bobaekang.com/blog/serverless-servers-and-the-challenge-of-new-react-architecture/) by Bobae Kang

Conclusion

These are all outstanding articles by masterful authors. I enjoyed reading them all - I hope you did find something in there, too.

👉 Follow me on LinkedIn, Twitter, or here for more to come.

🙏 Thanks to all the authors and contributors for their hard work!

Sticky Transitioning Veggie Hamburger 🍔

Florian Rappl — Wed, 25 Sep 2024 08:40:42 +0000

In our efforts to make the page faster and even faster we also explored different ways of just omitting user interactivity altogether. One place we looked at intensively was the header (or general layout). The header contained a bit of interactivity in form of a React component.

The job of the header component is:

on mobile show a persistent header bar with a hamburger instead of the normal entries
on desktop show all the menu entries, but switch the appearance once scrolling occurs (full height to less height with a shadow below)
the menu on mobile should not have any scrolling (i.e., remove scrollbar if any)

In practice this looks like the following on desktop:

And for mobile the appearance changes to this:

Let's see how we went from the original to a non-JS version that behaves the same.

Original Meat Burger

Alright, we start with the original version of our header (the "hamburger"). To stay rather generic for this article we prepared a small sample that evolves with every step.

We start with the original:

Most of the code is in the CSS-in-JS. You don't need to use the CSS-in-JS here (we actually use SASS), but it easily brings the two parts (CSS and React) that are needed for the component together.

The critical part is that within the component we need to use some hooks (i.e., interactivity) to make it work:

export const PageHeader = ({ children }) => {
  const [open, setOpen] = React.useState(false);
  const header = useStickyHeader();
  useLockBodyScroll(open);

  // ...
};

The goal is thus to reduce it. Let's start with the easy thing first: How to get the hamburger menu working without JS.

Less Meat - Same Taste

How can we toggle two states using CSS and no JS? Well, first we need to understand that CSS inherently allows us to distinguish between states. For instance, CSS allows to select based on

empty
hovered
focused

and more states directly. Among those are also special states of some form fields, e.g., if a checkbox is checked.

So instead of toggling based on a data- attribute, i.e., the following code in CSS:

header[data-open="true"] {
  display: flex;
  height: 100%;
}

we can toggle this based on another selector:

header:has(#header-hamburger-open:checked) {
  display: flex;
  height: 100%;
}

This assumes that a new element with the ID header-hamburger-open has been introduced. This is a checkbox that is hidden to the user. The effect of hiding the checkbox can be done quite easily using CSS, too:

#header-hamburger-open {
  visibility: collapse;
  height: 0;
}

Personally, I like to use visibility: collapse as it transports the meaning the best. Unfortunately, for most elements Webkit-based/derived browsers will behave for collapse like for hidden - i.e., reserving the original space but not rendering the element.

Only Firefox behaves in a way that aligns with the original meaning (but contrary to the spec - which is actually weird in this scenario). That's why we need the additional height: 0 to also prevent allocating same space on Webkit-based browsers such as Chrome.

With this in mind we replace the original button inside the navbar-toggler with the following code:

<input type="checkbox" id="header-hamburger-open" />

<div className="navbar-toggler">
  <label
    htmlFor="header-hamburger-open"
    data-toggle="collapse"
    aria-controls="navbar-menu-content"
    aria-label="Toggle navigation"
  >
    🍔
  </label>
</div>

When clicking on the label the htmlFor attribute is used by the browser. This will lead to toggling the checkbox, which - as per our CSS structure - will toggle the menu.

You can play around with this in the updated sample.

Now that the easy part is done - let's look at the final step for making the truly JS-free: Having the sticky positioning fulfilled.

Veggie Version - Original Taste

The main complication when moving the sticky header from a JS transition to a CSS one is that CSS has no idea about scrolling.

Let's see the original hook / code to trigger the transition:

function useStickyHeader() {
  const header = React.useRef(undefined);
  React.useLayoutEffect(() => {
    if (header.current) {
      const sticky = header.current.offsetTop;
      window.onscroll = () => {
        if (window.pageYOffset > sticky) {
          header.current.classList.add("sticky");
        } else {
          header.current.classList.remove("sticky");
        }
      };
    }

    return () => (window.onscroll = undefined);
  }, [header.current]);
  return header;
}

So by applying the CSS class sticky we transform the original header to the sticky one. Without JavaScript - this won't be possible.

Maybe - so the idea - it is possible to have something set from the beginning. So the idea is to have the right layout and not rely on a scrolling-based transition.

The starting point should be the CSS declaration position: sticky. Using position: sticky we can tell the browser to make the menu sticky (in relation to its scrolling container) without relying on a transition.

The problem with position: sticky is that we can only tell the browser what "position" we want to settle in. For instance, we can tell the browser top: -10px to keep moving the header bar until it's 10 pixels inside the containers hidden area, i.e., shifted to the top by 10px. There is no way to add another shadow or other things we might be interested in...

This is the point where we could call it a day, marking the task as "impossible" and move on.

Luckily, there are still some tricks we can apply in this case. Let's look at what we want:

In other words, we want to "reveal" part of the shadow when we move up. The moving up part we get covered by using position: sticky as outlined - now the shadow part could be tricked in by really introducing such layers.

What we mean specifically is that we could introduce two more "virtual" elements (using ::before and ::after pseudo selectors):

one element moving together with the sticky header (i.e., absolutely positioned) - initially "hiding" the shadow
one element as a shadow that is being fixed; thus not moving with the sticky header (initially being hidden behind the absolutely positioned element)

Note that both need to be in the foreground. This means we have a layering such as:

The real header (blue) is now shorter, but extended with the overlay element (green), which is initially hiding the shadow (purple). Once the page (red) scrolls, the header scrolls up to a certain point. Together with it the overlay is supposed to scroll, thus revealing the shadow:

In theory that should work - but in reality it will all be determined by the specific values we pick for the positioning of these elements.

In CSS the following is needed to introduce the two virtual elements:

header + *::before {
  position: fixed;
  width: 100%;
  height: 45px;
  content: '';
  background: #ccc;
  box-shadow: 0 3px 5px rgba(57, 63, 72, 0.3);
  top: 0;
  left: 0;
  z-index: 9999;
}

header + *::after {
  position: absolute;
  width: 100%;
  height: 55px;
  content: '';
  background: #ccc;
  top: 0;
  left: 0;
  z-index: 9999;
}

The header itself is positioned in a way that makes it be in front of these layers:

header {
  width: 100%;
  position: sticky;
  top: -5px;
  z-index: 10000;
}

This creates the effect we are looking for - and without requiring any JavaScript whatsoever.

Conclusion

Going to a full non-JS version of our header made the lighthouse score even better - being a full 100 on most / all pages. Now, whenever JS is needed it would be just there to enhance a certain view or give more details. There is no more JavaScript to actually enable navigation or other crucial means.

As far as the sticky header is concerned, the shown trick only works in scenarios like ours. If you need more transformations then finding a good workaround might be more difficult. In the future that may change, but for now position: sticky is quite limited and requires such tricks to also have scenarios such as ours covered.