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

31–40 of 168 posts

Re: Wasmer 1.0

#31

Post by anderspitman »

danShumway wrote: post #25
anderspitman wrote: post #13

Earlier quoted context omitted.

Yes, my point would more accurately be made by replacing "HTML5" with "HTML5 platform/ecosystem". Your point about Wasm not automatically guaranteeing this is important. But it would be much easier to build such a tool for a simple greenfield runtime than for a modern browser.

I have reasonably high hopes for WASM as a runtime, so I'm trying to thread a line between agreeing with you and disagreeing with you. I do think that compiling C code to WASM is easier than compiling C code to Javascript, and I do think that WASM is going to open some doors to sandboxed native applications that the web just can't handle. But at the same time, even forgetting about the cross-platform part, I have not…

I think we're disagreeing less than you think, mostly just focusing on different things. I'll defer to you on Flash. I've never programmed in it directly. My observations are purely from the outside. I was just using it as an example for why I see potential in app runtimes.

Re: Wasmer 1.0

#32

Post by remexre »

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…

I think proper sandboxing on a traditional Unix is hard enough that ~nobody does it right; you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them.

I don't know of a justification for removing /etc/resolv.conf, but I guess "applications' networking should be under the control of the user" is sorta necessary; I think it'd make more sense to do it with network namespaces or iptables rules or something, but /shrug.

Re: Wasmer 1.0

#33

Post by brundolf »

anderspitman wrote: post #26
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…

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).

If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more powerful platform than the alternatives.

I'm not saying we couldn't do better - the CSS API has a lot of warts and the DOM has performance issues if you don't know how to avoid them - but I am saying we had decades to do better and didn't, so there must be something very difficult about doing better and we shouldn't discount the only thing that's ever really succeeded.

Re: Wasmer 1.0

#34

Post by pjmlp »

brundolf wrote: post #33
anderspitman wrote: post #26

Earlier quoted context omitted.

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).

If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more p…

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?

Re: Wasmer 1.0

#36

Post by k__ »

anderspitman wrote: post #26
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…

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).

First, Stockholm syndrome isn't a thing.

Second, there were a bunch of alternatives and the Web won instead of them and not just because they weren't there.

I know, some people like running around telling everybody Qt, GTK, Swing or whatever were or even are better, but they are seemingly not for the points that matter for most of GUI apps.

But yes, we should make something better going forward.

Re: Wasmer 1.0

#37

Post by AnIdiotOnTheNet »

nynx wrote: post #5
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…

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. Or how about POSIX? How much software needs no special casing to run on all POSIX systems?

This is the pattern: we abstract things farther with the (mistaken) belief that it will save us from having to deal with messy reality, but as soon as you try to do anything more than simple stuff you find that reality is, in fact, a mess and you have to work around your abstraction to deal with it.

Re: Wasmer 1.0

#38

Post by charrondev »

anderspitman wrote: post #27
josephg wrote: post #18

Earlier quoted context omitted.

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.

The web is a great way to distribute native programs. Click a URL to download, then run.

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.

Re: Wasmer 1.0

#40

Post by judge2020 »

anderspitman wrote: post #30
Ajedi32 wrote: post #29

Earlier quoted context omitted.

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.

Huh? When you click the back button in your chat app, if it happens to do something intuitive it's because that behavior was hand-coded by a JS developer using the history API. And good luck even getting to back button from your news site through all the ads, lazy-load images causing reflow, and auto-play videos that wouldn't be possible in a nicely designed minimal document viewer. It might be harder for news site o…

> because that behavior was hand-coded by a JS developer using the history API.

Yes, the app developer (which happens to be using javascript and makes their app available via https://) decided how the back button works in their application. The only difference between the web and an UEFI-based OS is that the browser has defaults for the back button or ctrl-f, while the traditional OS will, at most, handle the window border + minimizing and maximizing.

Post reply on HN