The weekend before a holiday always brings out the interesting side projects. This Saturday gave us a TypeScript compiler that outputs actual executables, a major rethink of how Zig handles builds, and a compelling argument for ditching your orchestration platform.

Perry compiles TypeScript to native binaries

Perry is trying to do something that sounds impossible: compile TypeScript directly to executables using SWC and LLVM. Not transpile-then-bundle-then-wrap-in-Node. Actually compile it.

The project uses SWC to parse TypeScript, then generates LLVM IR that gets compiled to native code. This is the same basic approach that serious systems languages take. The difference is that TypeScript wasn’t designed for this. It’s a type system bolted onto JavaScript, which is a dynamic language that makes very few compile-time guarantees.

Perry is early. The GitHub repo doesn’t show broad standard library coverage yet. But the core idea is interesting: if you can constrain TypeScript enough (no eval, no runtime type coercion, no prototype manipulation), you might be able to compile it. Whether anyone wants that constrained version of TypeScript is another question.

The real test will be whether Perry can run actual applications without requiring you to rewrite them. Every language that tries to be “JavaScript but compiled” runs into this problem. You either support enough of JavaScript’s weirdness to be useful, which makes compilation nearly impossible, or you don’t, which means nobody can run their existing code.

Still, watching someone try to bend LLVM to JavaScript’s semantics is worth following.

Zig reworks its build system

The Zig team posted a devlog about reworking the build system. This isn’t adding features. It’s rethinking how the build system works at all.

Zig’s build system is written in Zig, which sounds obvious but is actually unusual. Most languages use Make, CMake, or some DSL. Zig treats build scripts as real programs with proper type checking and error handling. The problem is that the API has accumulated complexity as the language evolved.

The rework simplifies how you declare build steps and dependencies. Instead of manually managing the dependency graph, you describe what you want and let the build system figure out the order. This is the same shift that happened with React (describe the UI, don’t manage DOM updates) and Terraform (declare infrastructure, don’t write deployment scripts).

For developers using Zig, this means breaking changes to build scripts. For everyone else, it’s another data point that even young languages with clean-slate designs still need to rework their foundations. The first version of anything gets some things wrong.

SQLite as workflow infrastructure

Over on the Obelisk blog, there’s a detailed argument that SQLite is all you need for durable workflows. Not Temporal, not Kafka, not your event sourcing framework. Just SQLite.

The core insight is that most workflow systems are just state machines with persistence. You need to track what step you’re on, what data you have, and what to do next. SQLite gives you ACID transactions, which means you can update state and queue the next action in a single atomic operation. If the process crashes, you restart and check the database to see what was in flight.

This works surprisingly well for anything that fits on one machine. You can handle thousands of workflows per second with WAL mode and careful indexing. The article walks through actual implementation patterns: how to structure the schema, how to handle retries, how to do distributed locking if you really need it.

The limitation is scale. Once you need to distribute work across machines, you need a real message queue and distributed locking. But that’s the point: most applications never hit that scale. They add Kafka and Temporal because that’s what you’re supposed to use, not because SQLite couldn’t handle it.

It’s a good reminder that boring technology often works better than the stuff on the front page of Hacker News.

Elsewhere

A few other things worth checking out: Tiny-vLLM is a C++ implementation of vLLM for running LLMs locally. The Quandri engineering blog declared that MCP is dead, which is either prescient or premature depending on whether Anthropic keeps pushing it. And someone built an open-source home security camera with end-to-end encryption, because Ring probably doesn’t need more footage of your front porch.

Happy Saturday. Go compile something weird.