Ask Slashdot: Would You Consider a Low-Latency JavaScript Runtime For Your Workflow? (github.com) 33
Amazon's AWS Labs has created LLRT an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient serverless applications.
Slashdot reader 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. 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 quckjs?
Slashdot reader 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. 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 quckjs?
no. (Score:3, Insightful)
Instead of using JavaScript, I would use a tool that suits the job at hand.
Re: (Score:2)
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. Use something else (Score:1)
I do not want to use JavaScript on the server-side or embedded for these reasons:
1. Language not designed for small environments
2. Language defects - white space sometimes ending statements and sometimes not, modularity as an afterthought, lack of enforced at compile-time type checking, lax language syntax (parameters without a type declared), everything can have dynamic properties
3. Single threaded by default
4. Reliance on HTTP for communications instead of a connection oriented, type checked protocol
5. Ov
Re: (Score:2)
Javascript suits most jobs better than any other language, and Amazon just added an option that increases its suitableness. AWS Lambda's two most popular languages are NodeJS Javascript and Python.
Python is in general slower. And this update in theory gives JS an even more massive edge, since Python too is a language that uses garbage collection.
Re: (Score:2)
Javascript is the wrong tool for any job, including the one it was developed for.
Re: (Score:2)
Javascript suits most jobs better than any other language
It doesn't. JavaScript's main advantage was that it was the privileged scripting language in the browser. That advantage is disappearing now that runtime and toolchain support is increasing for WebAssembly.
WebAssembly enables higher performance and lets you use your choice of language.
No (Score:2)
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.
Re: (Score:2)
Or just use C++ and a good desktop UI toolkit like QT (you can even let the graphic designer play along with that QML goodness).
Oh yeah....... I know, nobody wants desktop apps anymore. Jesus wept...
Re: (Score:2)
Or use C# and a UI toolkit like Avalonia and compile to both desktop and WebAssembly: https://avaloniaui.net/ [avaloniaui.net]
Re: No (Score:2)
I'd go with C# or Java, compiling languages with strong typing.
I hate runtime errors that a compiler should have caught. Script languages are especially sensitive to code rot, especially if you have many files. Change one, find two that are impacted by the change. Then at runtime around new year you'll find the one you missed.
Re: (Score:1)
That is why one long ago invented "unit tests", and why you have "linters" ...
Brogrammer very much?
Re: (Score:2)
Why make unit tests for stuff a compiler can do?
Re: (Score:1)
Because you are working with a language that has not such a compiler?
Not sure about what you want nitpick.
In JavaScript, SmallTalk and whatever, -- ah Python comes to mind -- you can do stuff you can not do in a static typed language. So: your decision which way you go. And while both ways benefit from unit tests, one way NEEDs them, the other not so much.
Re: (Score:2)
Because you are working with a language that has not such a compiler? Not sure about what you want nitpick.
This thread is precisely talking about JavaScript versus compiled languages. An advantage of a compile language is that you can cut down on the unit tests you need to write. WebAssembly enables compiled languages to run on what has traditionally been JavaScript only territory such as in the browser.
you can do stuff you can not do in a static typed language.
You can do any and all stuff in a statically typed language. There are no limitations.
Re: (Score:2)
Unit tests never cover all the cases that a compiler can discover. They are a poor excuse for problems that can be solved at compile time.
Even linters have their shortcomings.
With a compiled code it won't execute until it's properly and consistently built. With a linter you can choose to ignore warnings, and a lot of people just says "It's just a warning, nothing serious" and delivers what they have and then at a later time something goes wrong.
Re: (Score:1)
Yes, and?
About what do you want to nitpick?
JavaScript, SmallTalk, Python: have no static types system. Hence: no compiler taking benefit from it. Hence: you write unit tests. Or don't. Up to you.
Re: (Score:1)
Re: (Score:1)
WebAssembly is for running code in a web browser, or similar.
That is not the use case for a faster JavaScript engine that is supposed to run on a backen, or be the runtime core of your desktop application.
However WebAssembly "runtimes" do exist. But if you use that for your backen or as "main()" for your desktop app: why not write in a decent language then?
Re: (Score:3)
WebAssembly runs wherever you want it to run: browser, desktop, or server. It's an ideal fit for serverless environments like AWS Lambda.
Amazon made the switch to WebAssembly for Prime Video. WebAssembly makes it go faster while also giving them the flexibility to roll out updates to 8,000 device types: https://www.amazon.science/blo... [www.amazon.science]
Re: (Score:1)
WebAssembly is a portable bytecode specification.
It runs _nowhere_.
If you want to say, you can have execution platforms for it everywhere, sure why not.
Then you only need a toolchain to compile all your JS to that execution platform. Which on the other hand: the light weight JS VM would do for you for free.
I guess people who have to make such decisions: are aware about that.
Re: (Score:2)
the light weight JS VM would do for you for free
The WebAssembly runtime is lighter weight than JavaScript's runtime. It's one of the reasons why WebAssembly achieve higher performance than JavaScript.
Re: (Score:1)
But it does not run JavaScript .... gosh.
To much nitpicking makes you daft.
I know what web assembly is.
Re: (Score:2)
But it does not run JavaScript .... gosh
And? What am I using JavaScript for when I can compile to WebAssembly?
no. (Score:1)
If "every millisecond" truly counts... (Score:3)
You're gonna be using a compiled language, not something like this.
Something is missing here (Score:1)
It's built in Rust, utilizing QuickJS as JavaScript engine, ensuring efficient memory usage and swift startup.
QuickJS is written in C, not Rust
It's slow to execute, but fast to start and low memory overhead.
So there's no unpredictable slowdowns, it's predictably slow.
It'll scale well, because it's low overhead and quick to start, but it'll need to scale more because it's a slow interpreted JavaScript engine.
No, I have far better tools (Score:1)
Using Javascript beyond webpages ... (Score:2)
(1) The only programming language I know is Javascript.
(2) My idiot boss made me use Javascript, would you like a copy of my Resume?
Re: (Score:1)
Why so dismissive?
In lines of code written JS is most certainly one of the most prominent ones.
If you look for job requirements on Linkedin: nearly every job at least has JavaScript as nice to have.
If you are a hater: JavaScript from 1995 that had problems in every browser, is not ECMAScript 15 from 2024.
Never met a JS hater you could give a 10 sentence summary about the language. And then a 3 sentence summary what he hates.
(P.S. I do not use JS ... but I probably can write a decent runtime/compiler for it
adding another point (Score:3)
None of the major organizations are interested in replacing the technology what is the plumbing.
Browser makers - Nope - The want to keep going JavaScript with its defects, HTML with its defects (magic string matching of id values), and patches which keep perpetuating the bad parts (Typescript)
ECMA - Nope - Spent too long fighting to make incremental JavaScript standards changes without addressing the fundamental problems with JavaScript
W3C - Nope - Same with keep going with XML based web standards (HTML),
No (Score:2)
The time of developers and infra admins cost way more than running the hardware.
The extra complexity that this introduces either directly by configuration or indirectly by incompatibilities or even worse security vulnerabilities is not worth it.
Once you get big enough that the HW cost become a significant factor, you should have enough capital to switch.
Yes (Score:1)