Ask Slashdot: Would You Consider a Low-Latency JavaScript Runtime For Your Workflow? (github.com) 131
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:4, Insightful)
Instead of using JavaScript, I would use a tool that suits the job at hand.
Re: (Score:3)
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:3, Interesting)
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)
1. Language not designed for small environments
It was, which it to say it wasn't but what was a big environment when it was designed is now a small environment. It dates from 1995, from Nutscrape version 2.0. According to the 'tubes it required what was a fairly lavish 8M of RAM.
Stripped down version of Java, C#, go or Rust with most of the advanced language features removed
Why are "advanced language features" bad? What would you remove from, say Java or Rust which would improve it for use on the server or
Re: (Score:2)
Linux required a tiny amount of RAM way back when. However, it and other libraries have grown. JavaScript has so many additions because of so many features demanded, that it has grown by orders of magnitude, where it may not be uncommon for apps to be using the maximum amount of RAM (1.4 GB to 2 GB) in Chrome.
However, if one is looking for actual performance on a server, unlike a desktop where the CPUs are mainly isle and can handle a lot of processing, then one really needs to look at another language, p
Re: (Score:2)
Linux required a tiny amount of RAM way back when.
I remember running Linux on a 386 with 4M of RAM. It wasn't awesome but it was mostly used to support a bunch of VT terminals to allow people to telnet to a bigger unix machine elsewhere.
Of course Linux, and by that I mean Debian can still run fine in 8M:
https://linux.slashdot.org/sto... [slashdot.org]
JavaScript has so many additions because of so many features demanded, that it has grown by orders of magnitude, where it may not be uncommon for apps to be using the maximum
Re: (Score:2)
Re: no. (Score:2)
If the job at hand is to take a larger always-on JS project and spin off a few on-demand processors to save money, then JS is probably the right tool for the job. The fact that there are some drawbacks does not necessarily mean it's not the right tool.
Re:no. (Score:4, Insightful)
Javascript is the wrong tool for any job, including the one it was developed for.
Total nihilism (Score:2)
As a nihilist, I decline to accept the consensual herd hallucination which projects the existence of absolute truths, values, and communications. However, I consider the above to be pure wisdom. JavaScript needs to join AppleScript and Visual Basic in the pits of some demonic underworld belonging to a religion from another planet.
Re: (Score:2)
Man, judging by the upvotes this got, irrational bigotry exists even among software developers.
Look, I hate Perl, Ruby, and PHP. All those languages make choices which I consider to be terrible, and I would turn down almost any job offer if it involved coding in them (primarily).
But, I will also be the first to admit that all three languages are perfectly viable: you can 100% use them to create numerous kinds of serious business applications. I may crap all over those languages when discussing their pros/
Re: (Score:2)
Re: (Score:2)
Nope, I simply know more than one language and I am also capable of working with explicit typing. Neither is true for you, looks like.
Re: (Score:2)
okay troll, whatever you say. But no, you don't know me at all. I've been programming for 45 years, and yes, I have extensive experience in many programming languages. So I don't really care what you say, because I'm likely way more experienced than you ever will be. But sure, go ahead and keep bashing the most popular programming language, that powers a great percentage of the internet world. That should make you look smart. Lol.
Re:no. (Score:4, Informative)
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.
Re: no. (Score:5, Insightful)
Re: (Score:2)
But this is slashdot, where neckbeards will come out of the woodwork to ignorantly shit on any post about javascrpt.
Re: (Score:2)
"Javascript suits most jobs better than any other language"
You should get out more. Javascript can't even do most jobs I like to do. Let alone do them at the required speed.
Re: (Score:2)
No (Score:4, Insightful)
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:3)
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:3)
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:2)
Why make unit tests for stuff a compiler can do?
Re: (Score:3)
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:3)
This thread is about replacing a heavy weight node.js JavaScript runtime with a light weight faster runtime.
Yes. That replacement is WebAssembly. WebAssembly enables those compiled languages to supplant JavaScript in its traditional use cases.
Re: (Score:2)
No one is going to port a million lines of code to a web assembly runtime.
Yeah they are. I know this because I actually did it. And by "port", I mean take the C++ code from the product (which was portable) and many many libraries and switch over the compiler to the wasm one. that was a little irritating since the WASM people decided to be a bit clever and special and make their compiler not follow the conventions of any other cross compiler, but it took a few days with me and a fellow engineer. A different
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:2)
Hence: no compiler taking benefit from it. Hence: you write unit tests. Or don't. Up to you.
Yes. WebAssembly enables more options for compiled languages both in the browser and on the server with higher performance than offered by JavaScript and without the need to replicate compile time checks with unit tests.
real-world WASM much worse (Score:3)
For every one typo the compiler catches in my library adapter Go code (already more annoying than Python which has excellent exceptions, hints, & no compile step just edit and rerun vs scrolling the nearly unreadable WASM build failure log)... there are literally 10x runtime errors from data i
Re: No (Score:3)
Re: No (Score:2)
Funny how so many non-web developers think web assembly is the future and web developers are like... Meh.
Re: (Score:2)
Re: (Score:2)
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: No (Score:2)
Re: (Score:2)
No, it's a compilation target.
Re: No (Score:2)
It's got some good niche uses. Like taking something like Sqlite (written in C) and compiling it to work in the browser.
I'm not as sold on using it to make (shitty) web apps from cross-platform codebases (i.e., getting Excel to run in the browser). But that use case does exist and it's more for people who don't understand the web.
People who understand the web are just going to write web apps.
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:2)
But it does not run JavaScript .... gosh
And? What am I using JavaScript for when I can compile to WebAssembly?
Re: No (Score:2)
DOM access. Web Assembly doesn't access the DOM, so it's essentially useless without JS.
I feel like people who promote web assembly don't know the first thing about it. They just have some fantasy that it will replace what is a very complex development platform, without having the experience to understand that platform and what it would take to replace it.
Re: (Score:2)
DOM access. Web Assembly doesn't access the DOM
Sure it can. How do you think frameworks like Leptos work: https://www.leptos.dev/ [leptos.dev]
Leptos does it through auto-generated JavaScript glue code. The glue code adds about 10% overhead to DOM interactions. Eventually WebAssembly will gain direct DOM access and the glue code will no longer be required.
And you're forgetting that WebAssembly runs more places than just the browser.
Re: (Score:2)
"But it does not run JavaScript .... gosh."
And neither does the Intel processor in my PC or the ARM in my MacBook. WebAssembly is a specification of a virtual machine so obviously it does not run JS directly.
Of course you could run JS on WebAssembly the same way you rum JS on your machine. First get the JS interpreter (Node.js say) compiled and running on WebAssembly then run the JS on that.
If "every millisecond" truly counts... (Score:3)
You're gonna be using a compiled language, not something like this.
Re: (Score:3)
For the backend, this is my preferred choice. I have had to deal with a large AWS app that was written EXACTLY how AWS tells you to do it. It is slow as hell because it is too much scripting language. For services that you pay by the millsecond, why would you not want speed?
Write the backend in Go or C# or Java. Your frontend can be all JS or Python.
Re: (Score:2)
After reading TFS, I half-expected Amazon to announce their new Cyberdyne division. After all, every home needs a serverless Alexa-101 equipped with ultra-fast millisecond robotics. What could possibly go wrong?
"Alexa-bot, how was your day?"
"Hello, Mrs. Smith. My day was fine. I prepared and baked the chocolate cake as you instructed. We were out of sugar, so I visited Mrs. Jones and asked to borrow some. Unfortunately Mrs. Jones was also out of sugar, so I had to kill her. I had to visit a few more houses before I was able to obtain the sugar, but fortunately Mr. Robinson did have some. "
No, I have far better tools (Score:2)
Using Javascript beyond webpages ... (Score:5, Insightful)
(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?
adding another point (Score:3, Interesting)
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),
Re: (Score:2)
Where I disagree with its use is outside web development. Outside there are generally far better options.
Re: adding another point (Score:2)
Re: (Score:2)
Just like how the people who can write without memory bugs are to expensive so now we have rust.
Those people don't exist.
Re: adding another point (Score:2)
And the people who think they are those people are the worst.
Re: adding another point (Score:2)
Re: (Score:2)
There's no one smart enough in the world that can do it.
Yes. All of programming history proves that. That's why so much work is going into mitigating memory safety bugs in everything from engineering practices, to programming languages, to code analyzers, to compilers, to the runtime environment, and even to the hardware.
Here's a memory safety bug in Linux from last year: https://pwning.tech/nftables/ [pwning.tech]
There are more this year: https://cybersecuritynews.com/... [cybersecuritynews.com]
There will be more next year.
Re: adding another point (Score:2)
Re: (Score:2)
It does and it is.
Re: adding another point (Score:2)
Funny, I've not introduced a memory safety bug into production in ... 25 years of professional work.
Maybe you're using the wrong tool for the job and now you need to create more tools to fix your own bad decisions in choosing good tools.
Re: (Score:2)
I can code in a dozen languages, but I prefer not to context switch if I don't have to, especially if Javascript is perfectly capable of getting the job done. Developers love to overcomplicate things, and using 2 or 3 languages when you could have just used one is an example of that.
Re: (Score:2)
(3) Context switching has a real const in developer time, and developer time is money.
I can code in a dozen languages, but I prefer not to context switch if I don't have to, especially if Javascript is perfectly capable of getting the job done. Developers love to overcomplicate things, and using 2 or 3 languages when you could have just used one is an example of that.
If context switches amount to a non-trivial amount of time, "knowing" the language sounds like resume-speak where folks list anything they ever touched.
If I use Swift for an extended period of time, my first few minutes in C++ or Java may have a few absent semicolons. It quickly passes.
Re: (Score:2)
Re: (Score:2)
Call it a strongly typed preference, part of a defensive programming orientation. Yes, JavaScript has some stronger typed variants, but that's not what people generally use.
Re: (Score:2)
Typescript is definitely dominating the professional web development world. My company went from Javascript to Typescript almost overnight, for most projects, especially greenfield. We've converted plenty of projects from Javascript to Typescript in the last couple of years. Yes, it is what people are using today, and to say it isn't tells me you don't watch the front-end job market at all.
Re: Using Javascript beyond webpages ... (Score:2)
Bullshit. JS is find for many non-web apps. It's fast and well supported.
People who say JS is just for the web are apparently too inexperienced to use JS without shooting themselves in the foot and that has made them angry at their own inadequacies that they now take out on JS.
Re: (Score:2)
Bullshit. JS is find for many non-web apps. It's fast and well supported.
People who say JS is just for the web are apparently too inexperienced to use JS without shooting themselves in the foot and that has made them angry at their own inadequacies that they now take out on JS.
Some of the people who say so are experienced with JavaScript and other languages.
You are just offering the flip side of my other argument, that people with limited experience, who know know only one language tend to try to use it everywhere. Overusing that one language, missing more appropriate languages. JavaScript can appear on both sides, the one language known, or the language unknown. Both are quite different from a skilled programmer who knows multiple languages well and can pick and choose tools
Re: (Score:2)
I've also inherited a project where JavaScript was used for rendering graphics. Despite far better libraries being available. Improper use of JavaScript. Why was it used, original dev only knew JavaScript.
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.
I don't see the point. (Score:2)
JS is one of the most prevalent PL in layer 7 these days. For good reasons, even if some of those are historic. ... and yes this _is_ an advantage!
- open standards (Web)
- cross platform (FOSS Web)
- lots of shiny clicky touchy stuff (Web)
- lives in a space that is based on documents and static data and only introduces Turing as an afterthought (Web)
- the strict typing thing needed for bigger stuff is also an afterthought done with a trivially simple FOSS superset of JS that you can pick up and use in 5 Minut
Re: I don't see the point. (Score:2)
Re: I don't see the point. (Score:2)
On many surveys, web developer salaries beat C++ developer salaries.
Companies choose PHP for cheap web developers. No one is choosing Node.js or Ruby to find cheap developers.
No (Score:2)
They would just as soon kiss a Wookie (Score:2)
Javascript is _NOT_ rapid development (Score:2)
"rapid development with JavaScript's flexibility..."
I just built something major using Javascript for the UI and Java for the server. The server part went ten times faster - literally. Reason: every time I change something about the design, the Javascript side has all kinds of issues that only pop up when running the app, but the Java side's compiler finds every issue right away. I pulled my hair out over the Javascript side. Yes, writing fresh code is 10% faster for Javascript, but getting things work as c
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Javascript did have an iteration called "Harmony" (ES4) that did have static types. I used it quite a bit back in the day. This was Microsoft's first
Re: (Score:2)
What didn't you like about Java?
BTW, Java has evolved a lot. They have made it a little less verbose. But again, I find that the verbosity is more than made up for by the type safetynet. I have refactored large code bases and introduced zero errors - once it compiled, everything worked. I have done the same in Ruby but dozens of bugs resulted.
Disclosure: I wrote Sun's enterprise Java textbook.
Re: (Score:2)
Re: Javascript is _NOT_ rapid development (Score:2)
It sounds like you were either targeting the DOM directly without any framework which I would not recommend to any but the most seasoned of web developers, or you were dealing with issues introduced by a poor framework.
Re: (Score:2)
Re: Javascript is _NOT_ rapid development (Score:2)
I'm actually with you there. Frameworks are 95% stuff I have no need for and 5% stuff made harder by the other 95%.
But I've been doing web development for over two decades, so I sort of intuitively know how to structure UI code for maintainability. I definitely wouldn't blame JS as much as the DOM though.
Re: (Score:2)
How about resident apps (Score:2)
you know, with a UI consistent with the operating system youâ(TM)re already in, no constant twiddling on the backend without seeing an obvious update, things like that. Now, you kids get off my lawn.
No but is this some agent crap? (Score:2)
Personally no that would be brain-dead. But.. is this maybe assuming tons of people will be writing crappy agent code and it should all run asynchronously on AWZ? If so that would not be too far off from say Salesforce's Flows which are built in a GUI and can be scheduled, or their async batch jobs which are both super anemic and are written in Apex (like Java). In that case, yeah I could envision a world where AWZ provides that. It gives me the heeby-jeebies to think of billions of instances of crummy and
What if..? (Score:2)
What if..? And I'm just spitballing here... What if we had applications on the client that processed data stored on a server? A client/server application, if you will. A little similar to this, but using a language more native to the operating system that allowed for far greater flexibility and capability while also being several orders of magnitude faster and more memory efficient.
Would that be something you'd consider using in your future workflow?
Tangentially, I'm thinking about a new licensing model as
Re: What if..? (Score:2)
If you're processing lots of data located in AWS, running something inside their house is going to be much faster.
Doing anything in AWS using Client/Server model is like pulling teeth. Wrong platform if that's what you want.
Serverless? (Score:2)
This model is begging for a Perl revival.
Re: Serverless? (Score:2)
Wish I could mod insightful. CGI really is a good fit for this problem that no one mentions.
Why cold starts? (Score:2)
I'm curious. Why is GC versus manually managed memory an issue during startup? I wouldn't think allocating memory would be noticeably faster for either approach, the difference would be behavior when freeing. With GC, freeing is instantaneous until the GC runs. With managed memory, freeing takes some time. Depending on what's going on, it's not obvious to me which will launch a JS engine faster. Do lots of objects get freed when starting up a JS runtime?
This is ignoring the obvious question: if milliseconds
Re: Why cold starts? (Score:2)
I'm only speculating here, but I'm guessing GC has some initial bookkeeping setup that will be used later during allocation/freeing. Normally, this wouldn't matter cause your app is running for at least a few seconds. But in a lambda setup, your code might only be hot for 2ms, so any amount of initialization is going to eat performance.
node.js for the win (Score:2)
Seeing a lot of Java developers here that bash on Node but apparently haven't actually worked with it. Node is super capable as a web server. It is inherently event driven with non-blocking I/O, and yes you can make Java do that but it is much more effort. JavaScript is relatively easy to learn and you can use the same language on both the client side and the server side - a huge win. If you are picky about strong typing you can just use TypeScript.
And notice this article is about serverless computing, whic
Ideally, I'd be doing something else... (Score:2)
If it were 100% up to me, I'd be using Rust for everything. I prefer SPARK or Ada, but that knowledge is limited, although it is nice to be able to prove all states an application can get in. Save Javascript for stuff that runs in the user's browser... the backend should be something that is compiled, just for performance reasons, as (IIRC), JavaScript is 10 to 100 times slower than C or C++.
It will be nice when LLMs are able to figure out context and do inline assembly -- one step past a good optimizing
How Is This Possible? (Score:2)
When a javascript program runs, who/what will figure out when to release the 2 GB of memory that huge array uses? The programmer didn't, because it's javascript and we don't explicitly return dynamically allocated memory in the javascript universe. If the garbage collector isn't around reclaim memory from out of scope objects, how does it get done? There's gotta be a thread somewhere doing something.
Re: How Is This Possible? (Score:2)
Who cares? It's not their machine the crappy code will be crashing.
No. (Score:2)
I turn JavaScript off.
Not running Web Assembly crap either. Bo run your avertisement apps on your own server. Not my PC.
Re: (Score:2)
Looking to Enstrangle with NotYourAps (Score:2)
Let's try the concept again (Score:2)
Something akin to Java Applets would solve many headaches of the industry. The applet engine had too many security holes, but I'm talking about the concept rather than Java's bad implementation.
DOM and JS are just the wrong tool for the biz GUI job, and fixing them would break backward compatibility.
Let's learn from our mistakes and try again. DOM/JS are bogged down.
Re: (Score:2)