News: 0177598723

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Ask Slashdot: Would You Consider a Low-Latency JavaScript Runtime For Your Workflow? (github.com)

(Saturday May 17, 2025 @11:34PM (EditorDavid) from the (L)ow-(L)atency-(R)un(T)ime dept.)


Amazon's AWS Labs has created [1]LLRT an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient serverless applications.

Slashdot reader [2]BitterEpic wants to know what you think of it:

> Traditional JavaScript runtimes like Node.js rely on garbage collection, which can introduce unpredictable pauses and slow down performance, especially during cold starts in serverless environments like AWS Lambda. [3]LLRT 's manual memory management, courtesy of Rust, eliminates this issue, leading to smoother, more predictable performance. LLRT also has a runtime under 2MB, a huge reduction compared to the 100MB+ typically required by Node.js. This lightweight design means lower memory usage, better scalability, and reduced operational costs. Without the overhead of garbage collection, LLRT has faster cold start times and can initialize in milliseconds—perfect for latency-sensitive applications where every millisecond counts.

>

> For JavaScript developers, LLRT offers the best of both worlds: rapid development with JavaScript's flexibility, combined with Rust's performance. This means faster, more scalable applications without the usual memory bloat and cold start issues. Still in beta, LLRT promises to be a major step forward for serverless JavaScript applications. By combining Rust's performance with JavaScript's flexibility, it opens new possibilities for building high-performance, low-latency applications. If it continues to evolve, LLRT could become a core offering in AWS Lambda, potentially changing how we approach serverless JavaScript development.

>

> Would you consider Javascript as the core of your future workflow? Or maybe you would prefer to go lower level with [4]quckjs ?



[1] https://github.com/awslabs/llrt

[2] https://slashdot.org/~BitterEpic

[3] https://github.com/awslabs/llrt

[4] https://bellard.org/quickjs/



no. (Score:2)

by snowshovelboy ( 242280 )

Instead of using JavaScript, I would use a tool that suits the job at hand.

Re: (Score:2)

by sg_oneill ( 159032 )

Exactly. Where I work we do a lot of datascience. Mostly Python. Its battletested and has some great libraries for handling huge datasets. We'd use R or julia, but nobody knows it, and thats fine. For our IOT telemetry we use a combination of Go (*excellent for servers, and absolutely nothing else) and C++ (excellent for almost everything but an absolute bitch to debug when things go wrong, and they *will* go wrong). Web shit, combination of python and js depending on the team, for back end and some nasty v

No (Score:2)

by theweatherelectric ( 2007596 )

Use WebAssembly instead. It's higher performance than JavaScript and it brings every language to the web. Write in your language of choice and compile to WebAssembly.

WebAssembly is the future for application development on the web. JavaScript should just stick to being a scripting language.

If you need to do some scripting, use JavaScript. If you're developing an application, compile to WebAssembly.

no. (Score:1)

by Reckoning ( 10502566 )

No.

<hoponpop> the difference between netbsd, freebsd, and openbsd, as an
insider is freebsd is interested in getting things done, and
doesn't mind hurting people who get in their way.
<hoponpop> netbsd is interested in making sure nothing gets done, and
doesn't mind hurting people who try to accomplish things.
<hoponpop> openbsd is interested in looking good, and doesn't hurt anyone
in their own little community, but look out everybody else!