Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does.

But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete implementations exist. (Such as in browsers and operating systems.) And they need to keep moving as the culture changes; you want to support the latest emojis, right? Well maybe you don't, but your users will.

Furthermore, these implementations are at least partially specific to particular programming languages. If you want something portable, you might build on the Skia graphics library but that won't give you a way to build an app on its own.



Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg.

For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential management, etc; the list goes on.

That isn't to say there couldn't some day be a simpler alternative to the web offering similar features; but it has some pretty stiff competition. The only thing that even comes close today are modern operating systems like iOS and Android; and none of those are open standards like the web is.


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.


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 operators to fill their sites with junk if they had to explain to their users why it needs to run in an app browser with 20 privileges rather than in their default document browser.


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


The same goes for hitting the back button in an Android app. Just because it's _possible_ for apps to misbehave doesn't mean it isn't good for those standard OS features to exist.


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.


I think Flutter is getting there. That's at least open source, thought not an open standard.


Docker doesn't provide a strong security boundary. It's a sandbox only in the sense that it separates the container from the host from inadvertent entanglement (mostly).

(And the nonportability of images is another thing)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: