Amazon has announced the availability, albeit for experimental purposes, of a new JavaScript based runtime called Low Latency Runtime or LLRT for short, to bring JavaScript up to the performance throughput of low-level languages like Rust or C++.

I hear you saying? "What? Yet another Javascript runtime?". And you would be right since the Javascript ecosystem is not just fragmented with regard to frameworks but with regard to runtimes too. There's already, Node. js, Deno, and Bun. So why a new runtime in the form of LLRT? Aren't those already enough?

That might be true but LLRT is totally optimized for Lamda use. It really doesn't try to compete with the rest; it's just made for a single purpose only, in the context of Lambda. This also means that its size is tiny, in the order of a few kilobytes in contrast to the 20+MB required by its counterparts.

This is very important because it minimizes the cold start required by AWS to bootstrap the Lamda environment in order to run your functions. This cold start property of course pertains to other languages and runtimes too. We've recently examined how Java goes about it in "AWS Lambda Updated With SnapStart" which succinctly explains the issues:

The problem SnapStart is designed to solve is that of initialization. For a Lambda function, this involves downloading the function’s code, starting the runtime and any external dependencies, and running the function’s initialization code. Ordinarily, for a Lambda function, this initialization happens every time your application scales up to create a new execution environment.

With SnapStart, the function’s initialization is done ahead of time when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access. When your application starts up and scales to handle traffic, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup performance.

LLRT might follow an other path from that of SnapStart, but the concept of the cold startup time which both try to tackle remains the same. Therefore the path that LLRT takes is that of the lesser size, since the bigger the runtime package the more time is required for AWS to bootstrap the Lambda environment and as such the longer the cold start takes.

The small size carries a limitation though. It throws a lot of stuff out so your code might not be able to function as-is. For instance if your code relies on a Node.js library or API, these might not be included in the runtime therefore your code will break. This is of course is reflected in the big neon sign of "for experimental use only". Therefore you must check your code against it first before you deploy.

Performance aside, the other advantage LLRT carries is that of porting the Javascript language to Serverless so that devs with knowledge in the language can feel right at home. Of course that could be done already going Node.js but not with the performance advantages LLRT heralds.

Another novelty of LLRT is that it's using a non standard Javascript engine. Yet another fragmented landscape here as well;Bun uses the JavaScriptCore Engine while runtimes like Node.js and Deno use the JavaScript V8 Engine. Well LLRT uses the QuickJS engine.

As a refresher and to take the steam off the terminology, a runtime (LLRT in this case) is a place or environment where your code executes. It is not the thing running the code itself (this is the engine, QuickJS in this case) but rather an environment that provides access to certain parts of the outside world.

QuickJS then is a small and embeddable Javascript engine. It supports most of the ES2023 specification 1 including modules, asynchronous generators, proxies and BigInt. Its main features at a glance:

• Small and easily embeddable
• Fast interpreter with very low startup time
• Almost complete ES2023 support including modules, asynchronous generators and full Annex B support (legacy web compatibility).
• Compile Javascript sources to executables with no external dependency.
• Garbage collection using reference counting (to reduce memory usage and have deterministic behavior) with cycle removal.
• Small built-in standard library with C library wrappers.

In summary it enhances a high level language such has Javascript with the performance benefits arising from the use of a low-level one like C, C++, Rust, or Go, without having to have knowledge in such a language.

The project is of course open source, and looking actively for contributors. If enough contributions are made, it might reach production standard. Maybe chip in?

More Information

LLRT

Related Articles

AWS Lambda Updated With SnapStart

AWS Lambda Adopts Java 21

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info