Do you have any specific test case that you would consider "very challenging" on the compatibility side? I'd be curious to check if BrowserPod can support that already.
Hi Syrusakbary, I have to admit I still do not fully understand what this is.
First, I could not find usage examples on the edgejs.org page and the docs link points to the node docs, why?
If I head to github, there are some usage examples, but they confuse me more.
The first example: $ edge server.js
led me to think that this is a node replacement that runs in a webassembly sandbox, so completely isolated. But why the need of --safe then? What's the difference between using it and not using it?
But the next examples creates more confusion to me: $ edge node myfile.js
$ edge npm install
$ edge pnpm run dev
What is this doing? I thought that edge was a node replacement, interpreting and running javascript files, but it's now running executables (node, npm)... what is that? What happens when I run npm install... where does it install files? What's the difference between running edge node myfile.js and edge myfile.js?
> I could not find usage examples on the edgejs.org page and the docs link points to the node docs, why?
This was intentional, as a demonstration that Edge and Node should not diverge a bit. You should be able to replace `node` with `edge` in your terminal and have things running, so that's why we point to the Node.js docs.
> But why the need of --safe then? What's the difference between using it and not using it?
Edge.js currently runs without a sandbox by default. The main reason for this is two fold: native currently performs a bit better than with the Wasm sandbox (about 10-20% better), and because we wanted to polish more the Wasm integration before offering it as default.
> $ edge pnpm run dev
> What is this doing?
This is making the `node` alias available for anything that you put after edge.
This allows pnpm to use the edge `node` alias instead of your platform node.
Things will be installed as usual, in your `node_modules` directory
I'm Syrus, from Wasmer. We built Edge.js in a few weeks after different trials trying to bring Node.js to the Edge. We used AI and Codex heavily for this project, as otherwise the timeline would have spanned to a year plus to develop.
The summary of this announcement is that Edge.js:
* Runs using WebAssembly when in `--safe` mode
* It's fully compatible with Node.js (passing all their spec tests for non-VM modules)
* It has a pluggable JS engine architecture: can work with V8, Javascript, SpiderMonkey, QuickJS, Hermes, etc.
Just wanted to chime in to say this is really cool. I dreamed of building something like this for the Extism ecosystem but it was a huge lift to unlock all the pieces. This looks like lots of innovation all the way down the stack. Kudos!
Thanks Ben! Took us a bit to figure out the best architecture for it, but once it became clear then it was just a matter of implementing the missing bits.
I think the fact that WASIX is much more mature now have helped to increase development speeds quite a bit!
Only the current working directory will be exposed/mounted to the runtime (we do this to facilitate the DX when running local files without requiring the user to add extra flags).
As a fun exercise, you can try reading process.cwd() from edge in --safe mode and without it.
Fully disagree with this take. Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.
Note aside, OpenJS executive director mentioned it's ok to use AI assistance on Node.js contributions:
I checked with legal and the foundation is fine with the DCO on AI-assisted contributions. We’ll work on getting this documented.
I appreciate hearing your point of view on this. In my opinion the future of Open Source and AI assisted coding is a much bigger issue, and different people have different levels of confidence in both positive and negative outcomes of LLM impact on our industry.
It is great to have a legal perspective on compliance of LLM generated code with DCO terms, and I feel safer knowing that at least it doesn't expose Node.js to legal risk. However it doesn't address the well known unresolved ethical concerns over the sourcing of the code produced by LLM tooling.
AI coding is great, but iteration speed is absolutely not a desirable trait for a runtime. Stability is everything.
Speed code all your SaaS apps, but slow iteration speeds are better for a runtime because once you add something, you can basically never remove it. You can't iterate. You get literally one shot, and if you add a awkward or trappy API, everyone is now stuck with it forever. And what if this "must have" feature turns out to be kind of a dud, because everyone converged on a much more elegant solution a few years later? Congratulations, we now have to maintain this legacy feature forever and everyone has to migrate their codebase to some new solution.
Much better to let dependencies and competing platforms like bun or deno do all the innovating. Once everyone has tried and refined all the different ways of solving this particular problem, and all the kinks have been worked out, and all the different ways to structure the API have been tried, you can take just the best of the best ideas and add it into the runtime. It was late, but because of that it will be stable and not a train wreck.
But I know what you're thinking. "You can't do that. Just look at what happens to platforms that iterate slowly, like C or C++ or Java. They're toast." Oh wait, never mind, they're among the most popular platforms out there.
Since when we accepted that we can’t go fast and offer stability at the same time?
Time is highly correlated with expertise. When you don’t have expertise, you may go fast at expense of stability because you lack the experience to make good decisions to really save speed.
This doesn’t hold true for any projects where you rely on experts, good processes and tight timelines (aka: Apollo mission)
IME there's a reason it's "move fast and break things" and not "move fast and don't break anything," because if the second was generally possible, we wouldn't even need this little aphorism.
And again, I'm not making a claim that the slow and steady tradeoff is best for all situations. Just that it is a great tradeoff for foundational platforms like a runtime. On a platform like postgresql or the JVM, the time from initial proposal to being released as a stable feature is generally years, and this pace I think has served those platforms well.
But I'm open to updating my priors. Do you think there are foundational platforms out there that iterate quickly and do a good job of it?
"Correct" usually means "exactly matches the specification" .... these systems do not do that based on what's been indicated on a bunch of articles, HN discussions, etc. etc. documenting people's collective experiences. It often doesn't one-shot tasks, it requires hand-holding. Oftentimes to a significant degree. Especially if not working on a CRUD webapp with a lot of boilerplate which heavily skew the training data. LLMs return the most likely sequence of individual elements of code, not the most correct code.
So, it's fast if you get lucky and are able to one-shot it, affordable-ish if you get lucky and are able to one-shot it and correct if you get lucky.
And that tends to happen if you're working on a specific set of codebases which are close to the most commonly occurring codebases in the training data set -- i.e. CRUD webapps / heavy boilerplate usage. Most FOSS projects probably don't fit in that camp (i have no data to support this, it's just my gut experience).
Allowing AI contributions results in lower quality contributions and allows wild things to come in and disrupt it, making it an unreliable dependency. We have seen big tech experience constant outages due to AI contributions as is...
Your comment is why advertisers say that you should repeat your core call to action at least a few times to make it stick.
You’ve read people saying the same thing hundreds of times and have somehow taken that as meaning that it’s credible.
Neither you nor I nor anyone else here knows what the “effects” are, because this is brand new tech, and it’s constantly changing. Yet you’re speaking with absolute confidence.
“Big tech” has downtime all the time, and LLMs did not change that fact. The only difference is that the peanut gallery that is already worked up about AI for philosophical / cultural reasons is suddenly ready to blame AI for every issue under the sun.
You think that you’re making a technical argument but you’re just repeating the same taking points I see teenagers regurgitating on TikTok. There’s nothing intelligent or credible about it.
> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.
It's not an AI issue. Node.js itself is lots of legacy code and many projects depend on that code. When Deno and Bun were in early development, AI wasn't involved.
Yes, you can speed up the development a bit but it will never reach the quality of newer runtimes.
It's like comparing C to C++. Those languages are from different eras (relatively to each other).
> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.
If and when there is evidence that AI is actually increasing the speed of improvement (and not just churn), it would make sense to permit it. Unless and until such evidence emerges, the risks greatly outweigh the benefits, at least for a foundational codebase like this.
Not allowing AI assistance on PRs will likely decimate the project in the future,
I can't help but wonder if this matter could result in an io.js-like fork, splitting Node into two safe-but-slow-moving and AI-all-the-things worlds. It would be historically interesting as the GP poster was, I seem to recall, the initial creator of the io.js fork.
> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.
That sort of statement might also be sarcasm in another context: I personally use AI a lot, but also recognize that there are a lot of projects out there that are suffering from low quality slop pull requests, devs that kinda sign out and don't care much about the actual code as long as it appears to be running, alongside most LLMs struggling a lot with longer term maintenance if not carefully managed. So I guess it depends a lot on how AI is used and how much ideological opposition to that there is. In a really testable codebase it could actually work out pretty well, though.
reply