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

71–80 of 168 posts

Re: Wasmer 1.0

#71

Post by cortesoft »

dmitriid wrote: post #62
coolreader18 wrote: post #46

Earlier quoted context omitted.

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…

> Because the "MVP" stage is itself production ready > some non-MVP features are almost stable > the posix-like system interface ABI, is still technically a "snapshot" So... It's not production ready.

'Production ready' doesn't mean it has all the features you would ever want. It means it is stable and tested enough to run critical workloads.

They are saying the core is production ready (if your needs are met by the features included in the MVP), but that planned additional features are not yet production ready.

Re: Wasmer 1.0

#72

Post by josephg »

anderspitman wrote: post #49
charrondev wrote: post #38

Earlier quoted context omitted.

I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.

That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.

Thats still way more awkward than what the web provides.

- I don't need to uninstall / delete a website when I'm done with it

- I don't need to pick an executable format. (Portable or installed? windows mac or linux? dpkg or rpm? From the dev's website or through homebrew/apt? Is a portable executable even available for this application?)

- I don't need to give the author of the webpage access to all my local files.

Native programs are also often 10x+ as large as websites. (Eg the facebook iOS app is somehow 488mb)

These problems are all solvable. Wasm alone will go a long way to solving the sandboxing and app format problems. But we still need to build the platform, whatever it is.

Re: Wasmer 1.0

#73

Post by anderspitman »

cortesoft wrote: post #70
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…

It seems like your argument is the opposite of the point made in the essay you linked. You say a browser is unnecessary, but the essay says that WASM won because it integrates with the rest of the browser.

Ha, you're actually kind of right. That article doesn't quite say what I remembered it saying. Been a while since I read it. I'd say about half the points are still applicable, but it is more pro-browser than me for sure.

Too late to edit, but Steve's previous blog post probably presents my point better, though with less focus on the vs Java argument:

https://steveklabnik.com/writing/webassembly-is-more-than-ju...

Re: Wasmer 1.0

#74

Post by orionblastar »

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??

Running the code at the server means it is less likely to be seen by the user. I used to program in ASP 3.0 with VBscript. The user sees HTML code as the script is run on the server and Html code is rendered for the user. Also the user is less likely to hack the code if it is on the server.

Re: Wasmer 1.0

#75

Post by dmitriid »

brundolf wrote: post #65
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…

> Games have had UI scaling since monitors got more resolutions than 640x480 Scaling is different from resizing. Maybe it was my fault for using the wrong word. 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…

> 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 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.

> I don't have time to read more than the first part of your reply right now; maybe I will later.

Now worries, I got carried away a bit. As Stephen King calls it, "diarrhoea of the word processor" :)

[1] https://twitter.com/dmitriid/status/1309777901483634689

Re: Wasmer 1.0

#76

Post by tasogare »

nicoburns wrote: post #42
pjmlp wrote: post #34

Earlier quoted context omitted.

Houdini is still barely capable comparable with native drawing. Layout managers were already a thing in Motif. Where is the great web tooling capable to beat Delphi/VB workflows?

Canvas isn't far off. The web is excellent for the types of UI that people often want to build for application: nestings of boxes interspersed with text.

So excellent it didn’t have a grid layout until 2018, flexbox landed 2016 and before that there was heated debate for years between table and div to properly align things.

Re: Wasmer 1.0

#77

Post by tasogare »

josephg wrote: post #18
brundolf wrote: post #15

Earlier quoted context omitted.

As others are pointing out here: the cross-platform value-add of browser based apps is the GUI layer, not the code runtime. We've had the JVM for decades, and it even has a GUI layer, it's just a much less powerful GUI layer than today's web. People have been trying to create a simple, native, platform-agnostic GUI layer for as long as GUIs have existed. Nothing but the web has ever come close to succeeding. It may b…

The other big thing the web provides a standard way to do distribution. Unlike JVM apps, I don’t need to install Gmail to use it on my computer.

Biaised reasoning: a JVM app requires the JVM and and a web app requires a browser. None of those app are executable y themselves. The only difference is that one of those runtimes is shipped in most OSes (the browser) while the other is not.

Re: Wasmer 1.0

#78

Post by brundolf »

dmitriid wrote: post #75
brundolf wrote: post #65

Earlier quoted context omitted.

> Games have had UI scaling since monitors got more resolutions than 640x480 Scaling is different from resizing. Maybe it was my fault for using the wrong word. 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…

> 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 of them, and very rarely hardcoded any positions or sizes.

The only time I've ever needed an explicit device-size breakpoint, it was for a site that needed to toggle from a laid-out navigation menu to a hamburger menu when the user was on a phone-sized device (or had their window narrowed to that size! the web doesn't care what device you're actually on, just how much space is available). There was a single breakpoint for "phone-ish" sizes, and that was that. It was necessary in this case because, unlike most values in CSS/the DOM, it was a discrete change and not a continuum. In most cases media-queries are a code smell.

Re: Wasmer 1.0

#80

Post by coldtea »

anderspitman wrote: post #22
hctaw wrote: post #16

Earlier quoted context omitted.

The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know…

IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications, and force developers into locked-in practices. Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground ser…

>IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications

That's a good thing. We should break "decades of convention in how to write POSIX-like applications" if we want to get any further than POSIX-like OSes and programming models...

Post reply on HN