Hacker News Reader

Comment by Layke1123 | Hacker News Reader

Is there a specific advantage to running in the browser versus running in everything at the OS level? I've always been a little confused why are abstractions went all the way up to the browsers. It seems that you could push a lot of browser functionality down the stack and simplify a lot or architectures and remove a lot of cruft we don't need.

View on HN

Deployment is easier. Upgrade is easier. Access control, restrictions, permissions; you don’t have to add a user account to namespace/sandbox a process in browser tab.

The facilities provided by a browser are almost (but not quite) a complete superset of those provided by an OS. file io, peripheral io, etc. Can all be done via the browser. Additional facilities are provided too (security/sandboxing).

Right, but you could implement all of that at the OS level too, which to a large part of my understanding is what things like docker is built on. Changes to the kernel to allow sandboxing at the kernel level for instance versus doing it in user space (which browsers could theoretically implement with syscalls now?), and would reduce a lot of overhead no? Or are browsers faster because they stay in user space and avoid context switching?

I don’t think so - OS’s have been around much longer than browsers. People have been trying (without anywhere near the success of browsers) to do cross platform deploys for almost as long as OS’s have existed.

Now a common model has arrived (dom + js) allowing multiple browsers to just run your app.

I’m not sure browsers are faster (there was a thing called pepper api in chrome and nacpi or something in firefox - i’m not familiar with the space) that allowed native code to run.

I’m not sure browsers are generally faster than native OS binaries, but they are an easy to deploy to environment that doesn’t need syscall emulation like freebsd can do for running linux binaries.

Say not browsers, but linux becomes the dominant OS in existence on all platforms, not just embedded and server. Does that move the most targetable platform back to the OS level instead of the browser level if we are going off the metric that human interaction and ease of use is more heavily weighted than all possible machine interactions?

Yeah probably, but there would still be the open question of distribution and update (inc dependencies).

You still have to click on the update button for a browser, and as far as apps on your machine go, they could just check for updates next time the application is launched like current web apps/web sites do. What you are saying is not impossible for the OS to take back. It seems more like there just isn't momentum to push browser features down the stack back into the OS and I'm not sure why other than browsers already do it, so why backport it.

I think the point is more to use it instead of javascript.

What do you mean by it? The browser itself? In that case, everything done in the browser could theoretically be pushed down a level from user space into kernel space, potentially saving a lot of overhead, no? The only trade of I imagine is the context switch you hit from doing everything in userspace, but as far as I'm aware, even browsers have to eventually hit the kernel for at least raw input output on the network.

Why not let the OS do more and more of the complicated technical stuff, simplifying the deployment of web apps because now we don't have to know a thousand different bloated libraries, just a slowly updating set of OS APIs.

Reply on news.ycombinator.com