Hacker News Reader

Comment by phkahler | Hacker News Reader

So when will servo become a webapp so we can run it inside firefox?

To clarify, this is sarcasm. What I really want to say is when can we run firefox inside firefox? But it's not entirely written in Rust. The point of that question is to illuminate some of the absurdity of web apps. i.e. what function does the outer browser serve in this scenario and why do we need it?

Edit: All the answers point to the outer browser as providing a sandbox. I contend that is supposed to be an OS function. I also think that tabs in the browser came about because OSes didn't provide a decent way to handle multiple instances of applications. See what's happening here?

View on HN

Your question is related to the technical aspects of the ecosystem, but not to the way that people use computers in general.

A good rhetorical question in response is, why is the web so much more popular when using computers than installed applications?

The implication you've made is that there is no benefit to the web, but that is obviously not true, as web usage far outstrips installed applications (besides the browser) at this point. Given this, it becomes necessary to have common tooling to target the different browsers out there.

Getting back to the core of your question, if there was a framework for which you could target all users on the internet (with a single codebase), it ran natively on all platforms, was easily run by everyone merely by clicking on an icon, which then cleans itself up after running... then maybe native apps would be a good avenue for delivering all applications.

What is the advantage of wasm over Java and Flash? I don't really see technical advantages. There is only the social/legal aspect: wasm is not controlled by a single corporation.

wasm is more baked into the web platform than either are; flash wasn't as bad as java in this regard, but still. Nobody wrote flash libraries that your JS code could use, they used it for the equivalent of a big old <canvas>.

It also does not require a second runtime; integrating wasm support into existing JS VMs took very little code compared to an entire JVM or flash runtime.

> Nobody wrote flash libraries that your JS code could use

This isn't precisely true. Before widespread availability of similar HTML 5 features, Flash was used for file upload (especially multiple files w/ progress bars), clipboard access, and pre-websockets network push. Client-side image processing, too, although you might consider that as part of the "big old <canvas>" usage. Your overall point is right on, of course.

Ah that is fair! I forgot about those, but you're right.

There is an immense technical advantage: wasm doesn't enforce a high-level memory model like the JVM's classes or Flash's ActionScript. It allows straightforward use as a compiler target for low level languages which do not use a bytecode verifier for safety.

Any attempt to use those languages or their existing ecosystems of code on the JVM, Flash, or Javascript will be incredibly fragile and convoluted.

The WASM memory is just a Uint8Array in the JS VM. You can use a big byte array and du manual memory management in JVM too. It's a well known pattern on the JVM.

That's entirely unhelpful for the call stack, values stored in registers, loading and storing other sizes, atomics, etc...

Wasm solves that because it's aware of what it's doing. Java et al do not.

Isolation. WASM is a target that allows users to effortlessly download and run arbitrary code from the web on all platforms with a modern web browser; an environment that is sandboxed such that arbitrary file system access or other system access is relatively safe and limited even without knowing the intentions of the author.

This is why javascript is so popular with its current monopoly on the web. No other language can do that, but with WASM other languages, such as Rust, can be part of the picture.

I don't want to attack Rust or WASM, as I am pretty excited about this, but it's not that easy.

That anything that runs into the browser is isolated sandboxed and whatnot is irrelevant. It's still arbitrary code running on often unwilling clients.

Don't believe me? Think about ad-blockers.

It's no different than the existing JS here.

Absolutely, not different at all. I am just saying that is naive to think that the web platform is safer than other platforms. Many "attacks" happen completely inside the sandbox.

Oh yeah, it's not a panacea for sure.

The web platform is not completely safe, but it is far safer than, say, an unsandboxed exe running on Windows.

Most JS is unwanted code running in the browser. Seriously, the web devs are the ones that want it, not the user.

That's why I qualifed with "relatively safe". Arbitrary code from potentially malicious/incompetent sources is arbitrary code, but its a platform on which its relatively safe to run arbitrary code.

You can already run ff in ff:

https://bellard.org/jslinux/vm.html?url=https://bellard.org/...

Windows 2000? Then you can only run up to Firefox 12. (And Rust code came to Firefox a few years later.)

> I contend that is supposed to be an OS function

Different sandboxes for different needs. Processes, Jails, Docker, Hypervisors/VMs, Interpreters, they virtualise different resources with different levels of abstraction, and they all have pro's and cons.

It still serves as a sandboxed interpreter/GUI framework and as a frontend for finding and loading apps, regardless of how complex the apps are.

It would certainly become interesting if Firefox was largely just a WASM interpreter with OS extension in which a Browser Engine runs, written in Rust, compiled to WASM. Though I imagine to get proper sandboxing I'd probably implement a Ring System similar to x86 Rings for privilege seperation.

It serves the same purpose as the outer kernel on a VM host: isolation between fully-featured inner environments using a solid, featureful platform. There are tinier platforms you can use for isolation, and yes, they're more secure, but they don't get you the wide real-world deployability that full-featured kernels or browsers get you.

I would genuinely like to be able to run Servo inside my un-jailbroken Chromebook. I already run an SSH client in the browser (using Google's Native Client instead of wasm, but same difference), and I don't see why Servo needs access to my SSH private keys. To me, the fact that the only way I can run Servo is to give it access to my entire user profile is the absurd thing.

It's in active development. https://github.com/browserhtml/browserhtml This way you don't have to depend on the browser including certain functionality because you can fall back to downloading a whole rendering engine.

I feel like the direction web and applications in general are heading is that of near-native performance in a sand-boxed execution environment managed by something like a browser. This potential is what excites me the most about webassembly, even more so than enabling the transition away from Javascript.

Reply on news.ycombinator.com