txiki.js 23.10.0 released!

txiki.js is a small and powerful JavaScript runtime. It targets ECMAScript 2020 and implements many web platform features.

It’s built on the shoulders of giants: it uses QuickJS as its JavaScript engine, libuv as the platform layer, wasm3 as the WebAssembly engine and curl as the HTTP / WebSocket client.

After a few months of hiatus I’m happy to announce a new txiki.js release: 23.10.0, and it’s a good one!

This new release is packed with new features:

  • Faster startup time
  • New fs features
  • SQLite builtin module
  • Storage web APIs support
  • curl integration fixes
  • Added import.meta.path
  • Better CLI errors
  • Improved types documentation

Check the full changelog here!

This release is particularly exciting because I’ve been looking forward to integrating SQLite support for a while. I started implementing the Storage API support thinking I’d use a file for persistence, but at one point I thought I’d use a SQLite databse instead, so I went for it!

There is likely stuff to be improved specially in this new builtin, the SQLite module, but I’m happy it’s in now!

The last release was over 6 months ago, so please do check the full changelog, I almost didn’t remember all the things that were added in the months past…

Thinking ahead, it might be time to start bringing in Mbed TLS support. Maybe just hasing at first, then TLS sockets, then WebCrypto. Step by step…

txiki.js 23.1.0 released, and it’s a big one!

txiki.js is a small and powerful JavaScript runtime. It’s built on the shoulders of giants: it uses QuickJSas its JavaScript engine, libuv as the platform layer, wasm3 as the WebAssembly engine and curl as the HTTP client.

After a few months of more work I’m happy to announce a new txiki.js release, version 23.1.0, quite possibly the biggest release I’ve made, and one that paves the way for the future. Let’s dive right in!

Standard library refactor

I’ve actually gone back and forth on this one. The standard library modules started being importable as @tjs/ modules, but I later switched to having it all bundled together in @tjs/stdlib. While easier to work with, that was a mistake. It’s slower to load and the churn due to the bundles being in the repo is just annoying.

It’s also important to look around and see what others are doing. Both Node and Bun seem to have settled in using namespace:module naming for builtins, so that’s what I went with. All standard library modules are now imported like so: tjs:module.

These modules are now documented too, so you can see the full API at a glance.

CLI refactor

The CLI also got some much needed love on this one. Generally speaking the CLI allowed one to either launch a file or eval an expression, plus some modifiers for each. After giving it some though, the idea of using subcommands sounded the most appealing, so now you can do tjs run foo.js and tjs eval ”console.log(42)”

But there is more. There is a also a builtin test runner now so tjs test is a thing too!

Last, running WASI binaries directly was too easy not to do, so you can also tjs run foo.wasm now and it works as expected.

Top level await

Just when I was about ready to cut the release I noticed zamfofex had sent a patch adding top level await support to QuickJS to the mailing list. That was too good to pass so I quickly incorporated it, and it worked beautifully!

This makes writing simple scripts (and tests!) so much more pleasant! So off I went and migrated the test suite to use TLA, the examples too, and added some initial support to the REPL while I was at it!

There is even more!

While these are the highlights, there are a lot more fixes that went into the release. Please checkout the full release notes here.

txiki.js 22.11 released with FFI, WebSocket and more!

txiki.js is a small and powerful JavaScript runtime. It’s built on the shoulders of giants: it uses QuickJS as its JavaScript engine, libuv as the platform layer, wasm3 as the WebAssembly engine and curl as the HTTP client.

Today I’m happy to release txiki.js 22.11, which contains a bunch of improvements that have happened during the last few months. Let’s look at some of those!

Read more

Skookum JS 0.4.0 and the plan forward

Hey there! Another Skookum JS release is out and about! It’s 0.4.0 this time, slowly making progress.

This time around the release focus was on getting the module system mode Common JS compliant and similar to Node’s. This also brought __filename and __dirname, which simplified a few tests.

There are also some improvements like simple tab completion for the CLI and some new modules, check the full changelog for details.

When I started sjs I had this idea about a JS interpreter with a more “traditional” look, rather than the inherent async model Node provides. Just for the sake of exploring. Well, live and learn, I had no idea Common JS defined more stuff than modules! Somewhat randomly I also ran into Ringo JS, which looks pretty much like what I wanted to do, but built on the JVM. So I’ve decided to follow some of the Common JS specs (open issue here), and let’s see how deep the rabbit hole goes.

commonjs

Skookum JS 0.3.0 released!

Roughly three weeks after the last release, today I’m happy to announce Skookum JS 0.3.0!

What is Sookum JS?

Skookum JS, or sjs for short, is a JavaScript runtime focused on providing comprehensive POSIX APIs.

The motivation for this project comes from answering the question “how would a JavaScript runtime look like if there were no browsers?”.

This new release contains a few new modules: random, system (now non-builtin), process, pwd and uuid.

I’m specially happy about two of those modules: random and process, so let’s explore them a bit:

random

The random module implements a PRNG based on the well known Mersenne Twister PRNG. It also implements a CSPRNG by reading from the best random source available on the system: getrandom on Linux and arc4random_buf on OSX, falling back to reading from /dev/urandom.

If you are an expert in this field and have some comments about the implementation, please reach out!

process

The process module is by far what took the longest to complete for this release. It implements just two functions: daemonize and spawn, to daemonize the current process and to spawn new child processes respectively.

The challenge was that in order to implement those in JavaScript I had to add tons of new APIs to the os module (plus tests and documentation!). I can’t be happier about the result!


There are tons of other additions abd bugfixes, check the full changelog for details and the documentation for all APIs.

Last, I found some inspiration and made a new logo, what do you think?

sjs-logo-icon

Enjoy!

Skookum JS 0.2.0 released!

Hey there!

Skookum JS, the JavaScript runtime all your friends are talking about just released its 0.2.0 version.

The initial release was a couple of weeks ago, but there are improvement all across the board:

  • Better CLI experience and ability to toggle strict mode
  • Multiple fixes to the build system (I’m still learning CMake)
  • Fix building proper strack traces
  • New modules: os and refactored io
  • Buffer support for i/o operations

These are just the tip of the iceberg, check the changelog for all details.

For those wondering why sjs is so skookum, see the initial anoouncement and the design documentation.

In the next release I’ll be primarily focusing on child process support and maybe experimenting with multi-threading too. Stay tuned!

Introducing Skookum JS, a JavaScript runtime

Today I’m happy to announce the humble beginnings of a project I started a while ago: Skookum JS, a JavaScript runtime.

sjs

“A JavaScript runtime???” Yes, pretty much like Node, but with a different model. Skookum JS (sjs henceforth) uses the Duktape JavaScript engine to implement a runtime similar to Python’s CPython or Ruby’s MRI.

The runtime consists of a CLI utility called sjs which acts as the interpreter and will evaluate JavaScript code, and libsjs, the library which does the heavy lifting and can be embedded in other applications. Any project can add scripting support using JavaScript by linking with libsjs and using its C API.

The runtime model is quite different from Node: there is no builtin event-driven execution, all APIs are (for the most part) object oriented versions of POSIX APIs. Let’s see how to write a socket client which connects to a server, sends ‘hello’, waits for a reply and closes the connection:

https://gist.github.com/2ce6dc09d6d0fb54ada095ac091a912b

I started this project to have some fun (for certain definitions of fun) and learn some more stuff along the way. Even if the project is being open sourced now, the commit history shows its evolution, including all the mistakes and brainfarts, have fun going through it!

My idea is to have a large standard library, including the kitchen sink. Or at least that’s how I feel like today. This initial release contains the basics to get the project off the ground, expect to see improvements.

I’d like to finish this post by thanking its author for Duktape (the JavaScript engine used by sjs). It’s a really easy to use JavaScript engine, with outstanding documentation and great design choices, I couldn’t have done it without it. 10/10 would recommend.

Curious? Bored by Node because it just works? Head over to GitHub for the code, and here for the documentation.