syrusakbary

It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction).

Good work to everyone on the Deno team!

[1] https://edgejs.org/

Yeah, the strategy is literally the same

Wasmer (YC S19) | https://wasmer.io/ | Multiple Roles | Remote (EU) or Office (US) | Full-time

We are building the next generation of infrastructure for AI without Docker containers, but with a better container technology based on WebAssembly!

We are hiring for:

  * Rust Engineer (Remote, EU timezone)
  * Rust Distributed Engineer (Remote, EU timezone)
  * Developer Education Engineer (Office, San Francisco)

https://www.workatastartup.com/companies/wasmer

Well, with the help of AI now you can have Fast, Affordable, and Correct.

Just set it to MIT :)

Thanks Yuri. Keep up the good work

Actually agree with you here. It will be a good idea to add docs for the CLI and the WebAssembly sandboxing

Yet... stay tuned!

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!

Yes it can :)

Yes, this should be fully possible.

We actually believe Edge.js will a great use case for LLM-generated code.

> 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

Yes, it could run in iOS (using JavascriptCore, V8 in jitless mode, or QuickJS), although we don't have a prototype app yet.

It should probably take a few hours with AI to get a demo for it :)

Edge.js is fully compatible with Next.js

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)

It’s not a dumb question at all.

And yes, it will allow running Node.js apps fully on the browser, in a way that’s more compatible than any other alternative!

Stay tuned!

We are so deep into the weeds that sometimes is hard for us to realize that maybe we are not explaining in the best terms.

What was the most confusing thing in the blogpost? I'd like to polish a bit more to make it clearer! Thanks a lot!

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.

Hi HN!

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.

Super happy to answer any questions you may have!

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.

[1]: https://github.com/nodejs/node/pull/61478#issuecomment-40772...

Not right now but we would love to provide it.

We have been super busy lately, but when we have a chance we will work on it!

I also disagree with that.

Wasmer can run now Python server-side without any restrictions (including gevent, SQLAlchemy and native modules!) [1] [2]

Also, cool things are coming on the JS land running on Wasmer :)

[1] https://wasmer.io/posts/greenlet-support-python-wasm

[2] https://wasmer.io/posts/python-on-the-edge-powered-by-webass...

This is amazing. At Wasmer we are a bit concerned of Next.js and this replacement might come in handy!

I actually was thinking on creating something similar. Congrats to the Cloudflare team

This is super cool!

Hi HN! I'm super excited about this release. We have been working hard on the last months to enable Python greenlets in WebAssembly.

Happy to answer any questions!

Thanks for the ping, it seems our website got wrongly flagged. We are now chatting with the security providers to solve it.

We'll re-submit soon once this is solved :)

Might be worth taking a look at WASIX [1]

We implemented all the system calls necessary to make networking work (within Wasm), and dynamic linking (so you could import and run pydantic, numpy, gevent and more!)

[1] https://wasix.org/

Nice! Fork is actually already working on Wasmer thanks to WASIX :) (and sockets, subprocesses, ...).

Let me know if you need any help using it!

Browserpod is great, been following it for a bit. Keep the good work up!

The main issue that I see with Browserpod is very similar to Emscripten: it's designed to work mainly in the browser, and not outside.

In my view, where Wasm really shines, is for enabling containers that work seamlessly in any of this environments: browsers, servers, or even embedded in apps :)

> For agent tool calling, you don't really need NumPy and Pandas.

That's true, but you'll likely need sockets, pydantic or SQLAlchemy (all of of them require heavy support on the Wasm layer!)