Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wasmer 1.0

medium.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Wasmer 1.0

#111

Post by jillesvangurp »

kaba0 wrote: post #101
nine_k wrote: post #93

Earlier quoted context omitted.

No need to recompile means you can run the same, guaranteed known, signed, etc code everywhere. Purpose-built sandboxing means you can run untrusted code more safely — e.g. at the network edge, like a Cloudflare worker, a lambda, etc. Same for third-party plugins in apps, etc. An open standard and open implementations gives you some assurance against lock-in, licensing changes, patent suits, etc.

All of it already exists with the JVM.

The JVM is rather heavy weight and typically slow to start even when you do have enough resources to run it. That rules out edge computing. Graal AOT compilation is more similar but not a general purpose thing currently as it only works with tools and languages optimized for that.

I say this as a Kotlin/Java developer. I know and love the jvm but it's just not a lightweight option suitable for edge computing or serverless computing (it works but the jvm startup overhead + binary size is annoying).

Re: Wasmer 1.0

#112

Post by enos_feedler »

Ajedi32 wrote: post #29
anderspitman wrote: post #24

Earlier quoted context omitted.

Most of the things you listed apply to web documents more than web apps. I'm an advocate for separating the two. The UX for browsers is great for what they were designed to do. Running apps is not it.

They apply to both documents _and_ web apps, and the behavior is standard across both. When I hit "Back" or Ctrl+F in a web-based chat application the result is the same as when I do those actions while browsing a news article, and that's a good thing.

Ever tried hitting the back button in like, TurboTax web app? The web is totally broken for apps. I think what you are referring to here is the _intention_ of the web to be consistent. The reality is far from this.

Re: Wasmer 1.0

#113

Post by jillesvangurp »

coolreader18 wrote: post #46
dmitriid wrote: post #41

How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?

Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC. WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully ev…

To be more specific, there are multiple companies using this for edge computing. E.g. cloudflare has supported wasm for a while now. At this point it is increasingly widely used in the browser as a way to optimize parts of e.g. react and other popular frameworks. So, the compiler works and is being used by people. So, kind of appropriate to release a 1.0 to signal having some kind of stability.

Re: Wasmer 1.0

#114

Post by enos_feedler »

phkahler wrote: post #58
apitman wrote: post #2

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) fo…

>> Browsers are not the right tool for sandboxing applications. Browsers have been picking up the slack where OS and desktop developers have fallen down. The OS is supposed to handle process isolation and resource access, but here we are. Tabbed browsing became a thing because GUI toolkits didn't do multiple app instances (or MDI) in a way people liked.

When the browser first came out, the OS didn't even have a native TCP/IP stack! The internet was an app you installed. For a long time the core purpose of the browser was to pickup the slack/gap in the OS treating the internet as a first class thing.

Now, as the internet clams down a bit, the OS handles everything natively, including the security primitives (at least on mobile) and so the purpose of the browser is sadly diminishing. It's a less useful experimental side channel to the OS.

Re: Wasmer 1.0

#115

Post by dmitriid »

brundolf wrote: post #78
dmitriid wrote: post #75

Earlier quoted context omitted.

> Have you ever tried to play an old game on a widescreen monitor? Even a lot of modern, triple-A games have weird HUD layouts on ultrawide monitors because they have to be re-hard-coded for that aspect ratio. So if they haven't, you just get the layout they're hardcoded to for widescreen monitors. Have you ever seen any UI on the web that approaches the complexity of game UIs? I haven't [1]. Anywhere there's such co…

> Have you ever seen any UI on the web that approaches the complexity of game UIs? I have personally built tools on the web more complex than the game UIs in your link. > Anywhere there's such complexity on the web, you get lots and lots of hardcoded values: from hardcoded media breakpoints to entirely different layouts for different resolutions and screen sizes. ...and I didn't use a single media breakpoint in any o…

> I have personally built tools on the web more complex than the game UIs in your link.

Then you are a far better developer than I am, and I dare say than the vast majority of developers out there. It will take most developers no time to come up with UI of any complexity in any of the non-web toolkits. Whereas on the web even small tasks like placing a badge on an avatar reliably is a thankless gargantuan task. Can't speak for the game UIs (they are undoubtedly hard) but considering the sheer diversity in them that the web hasn't seen since the flash era...

Re: Wasmer 1.0

#116

Post by enos_feedler »

AnIdiotOnTheNet wrote: post #37
nynx wrote: post #5

Earlier quoted context omitted.

A significant point of wasm is runtime-independence. If a runtime implements the right apis, any wasm module that uses them should be able to run (performance aside).

> If a runtime implements the right apis, any wasm module that uses them should be able to run That sounds great right now, when the APIs are relatively small, but will quickly become a nightmare when they grow in complexity. I mean, technically any browser that implements the right stuff can run any web page on earth, yet somehow we still manage to have incompatibilities even when there are only 3 implementations. O…

Yes, agreed. It will be interesting to follow WASI for this kind of thing. I suspect it will try to rebuild POSIX like use case from the ground up. However, there are going to be so many use cases that fall outside the WASI boundary. Wasm is just getting started.

Re: Wasmer 1.0

#117

Post by dmitriid »

no_way wrote: post #68
dmitriid wrote: post #60

Earlier quoted context omitted.

> You're talking purely about performance. Not just about performance. > Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. Not probably, but definitely > But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. Yeah, no. Games have had UI scaling…

People are working on solving built in elements problem on the web including customizability and extensibility. https://open-ui.org/

That is one amazing project.

Re: Wasmer 1.0

#118

Post by fnord123 »

canada_dry wrote: post #69
genpfault wrote: post #20

> Wasmer is an open-source runtime for executing WebAssembly on the Server.[1] [1]: https://docs.wasmer.io/

Could someone also ELI5 and give some low-hanging use-cases for this... especially in the IoT space??

A low hanging use case would be scripts for a distributed data analysis system. e.g. You type in a function and then it compiles to wasm and is sent out to run on worker nodes. Or you write code snippets for code to run in a distributed dag.

This exists with e.g. shared file systems (how hpc works, how hadoop works) and Python can pickle code and send it over a socket (be aware that this is a security risk). WASM seems like a nice and direct solution for moving code to data.

Re: Wasmer 1.0

#119

Post by vijaybritto »

pjmlp wrote: post #109
vijaybritto wrote: post #89

Earlier quoted context omitted.

I see the main advantage in this as running a polyglot application as if its native. For example if you are making a Rust application, you can have a plugin architecture where the plugins run inside a wasm compiled python interpreter. I dont know if doing this directly and cross platform is as easy without wasmer

Just like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.

Absolutely. But I think wasmer is a lightweight VM compared to those.

Re: Wasmer 1.0

#120

Post by littlestymaar »

> Wasm also provides a lean execution environment enabling Wasmer containers to run in places where Docker containers are too heavy to work.

Can someone explain why you'd want to use a wasm runtime in that context instead of just using seccomp for that ?

Post reply on HN