txiki.js is a small and powerful JavaScript runtime. It targets the latest ECMAScript spec and implements many web platform features.
Following the (now) usual monthly cadence, I just released txiki.js 26.6.0, and this one comes with a bunch of great changes, many of them contributions from the community!
Simpler ways to install it
For the longest time, I have provided binary packages for txiki.js for macOS and Windows, directly on the GitHub releases page. Linux users probably already have the tools to build it easily I guess 🙂
Even then, there are package managers to help install third-party packages. @bangseongbeom opened an issue asking what it would take to have txiki.js in Homebrew, WinGet and Scoop. Not only that, but they did all the work, and now it’s available on all three!
In the same issue @lukasMega chimed in and provided a recipe for using Mise, so that also works now!
The installation guide has been updated with all new installation methods, check it out!
FFI improvements
FFI support originally landed via a contribution, and it has gotten some more love in that few releases. On this one we have zero-copy pointer views, and improved types!
When getting a NativePointer instance you can now call toUint8Array() and get a view of it, without needing to copy the contents. This helps manipulate buffers passed by libraries, and since they are bound to the underlying size, it’s safe to do so.
QuickJS update
I pretty much update to the latest QuickJS version on every release, but this one contains a couple of interesting features I just landed in QuickJS: fixes for immutable ArrayBuffers and typed arrays, and support for the “non-extensible applies to private” proposal.
How small can we make it?
This is the fun one, and what inspired this blog post’s title.
When I started txiki.js my goal was always to strike a balance between size and features, leaning towards a small size.
Years ago I was talking about a project with an acquaintance and when discussing scalability they asked me “ok, but how does that scale down? how small can I run it?”. It stuck with me I keep coming back to it often.
Once again, @lukasMega made some great contributions here. They proposed build flags to disable certain runtime components (WASM support, SQLite) aimed at making the build smaller, but also LTO and some cool compilations I didn’t know about: GC sections.
Not all their work landed because I still think some of it is not general purpose enough, but most of it did. In their experiments they managed to get the runtime down to 1.6MB! That is an impressive feat!
See you on the next one!