For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, process management (workers), networking (including peer-to-peer), and a number of persistence mechanisms. But before it takes over completely, it has to interoperate with the host OS a bit, too, by exposing the filesystem.
(A decade more, and maybe the vision of Inferno [1] will sort of kind of be implemented.)
[1]: https://en.wikipedia.org/wiki/Inferno_(operating_system)
I worry the next talented generation of developers is being alienated from the desktop, and as a result my computing experience will degrade as Chrome's piecemeal attempts to reinvent the OS leave me with an inferior selection of browser-based toys that are awkward and clunky compared to their native counterparts.
I grant the browser fixes a couple things my OS got wrong: installation/uninstallation and updates. But it feels like it does everything else worse.
And it goes without saying that, for your own safety, none of these platforms will run code that hasn't been delivered by a trusted and approved corporate appstore.
The future of computing is very grim.
I think the main driving forces on this are:
1. It's easier for computer illiterate people to use web services, since they don't have to go through an installation process.
2. It's easier for developers to support their users because they don't have to worry about their users' computer environments, which is largely out of their control.
3. It's also harder/impossible for their users to pirate their software, since they it never runs in their machines.
I think the biggest reason (and the one harder to fix) is the piracy one.
I think your second point is actually the dominant one, but you're not wrong about this either. In some sense, we get the computing landscape that we (collectively) asked for.
I'm excited about things like WASM that will allow browser-based experiences to close the gap more and more with native apps. The web infrastructure is extremely powerful and has a fairly low barrier to entry so lots of people throw crappy experiences up, granted, but it's generally a good thing to have the resources so accessible.
WASM solves certain problems like arithmetic being slow. This doesn't fix the web's problems; it merely enables a new class of bad apps to be written on the web.
The best streaming video services are not web based. Thank goodness Netflix and Hulu have native iPad apps to spare me their websites.
As not everyone even has a network connection, I find this kind of viewpoint outright dangerous because it leaves out hundreds of millions of people. Streaming video, in particular, seems to choke if you don't if you don't have the absolutely best connection.
It doesn't matter that it's clunky and bad, CS people love working with hard to use systems, it just matters that it works.
google.com doesn't try to search my local drive. faceboook.com doesn't offer to share my local photos. Their usage of "browser as an OS" is extremely limited.
I worry about the other problem: the browser becomes so ubiquitous the OS disappears, along with any platform conventions and application interop.
I also get to pick native development over Web whenever possible.
However many of the gigs happen to be Web based, thus here we are.
Nah, replacing the desktop OS has been the goal of browser-makers since the founding of Netscape nearly 25 years ago.
There was a bit of a lull in progress in the mid-2000s, after the fall of Netscape Inc, until the rise of the mobile app threat you mention.
The entire point of ChromeOS is aggressive sandboxing, not breaking out of the sandbox.
Yes the user needs to install it, and then it is free reign for $HOME.
So it isn't Download location only.
It feels like 5 years later this will come to bite us in the ass as another way of exploiting access to our computer and data.
What if websites start requiring specific files to exist before allowing access?
This is certainly going to be immediately abused for encrypted storage of persistent cookies and tracking identifiers.
- If my site generates cat pics, I'll put identifiers in the metadata fields of the image format.
- If my site generates markdown, I'll put identifiers in an alternate data stream (Windows) or encoded in the whitespace.
Since the files exist outside of the sandbox, they'll be outside of the scope of privacy features like clearing the cache or cookies, and outside of the reach of adblocker extensions.
Also, why would they be outside the reach of adblockers? WebExtensions can already intercept and manipulate the use of certain APIs by sites, the same can easily apply here.
This isn't just unrestricted filesystem access. The site would need to request file system permission first, _and_ get the user to select the file in a file picker.
In short, that's not a serious concern.
Suppose an app which does not really needs file permission to work, like Facebook, but asks anyhow. If you opt out, you cannot access the app.
That pattern does not need to exist.
I wonder about ulterior motives too.
But in a world where even local apps increasingly try to make me store files in the cloud, I can only consider this as a move in the right direction.
All web apps can offer today is either (1) re-download the file (as the article mentions) or (2) save to GDrive/iCloud /OneDrive.
Working with local files is a win for user freedom.
Like session cookies, or SSL certificates?
Anyway, more interoperability with the native environment is a good thing. Right now browsers are an alien implant in every operating system that can't communicate with anything else.
Congrats, you're two clicks away from having your entire machine bricked & held for ransom.