Would I complain if I could run a full version of Word or Excel in the browser? The browser would become a universal interface in another way and decrease our reliance on particular operating systems.
I for one would, because the browser is an absolutely shitty interface. You're still forced into "there are tabs, which contain sandboxed documents" model of use. Interoperability is nonexistant, integration with machine capabilities is superficial and completely opaque to the user, the data model is hidden (where is my localStorage equivalent of the file browser again?), everything assumes you're constantly connected - it's a corporate wet dream, but for individuals, it's a nightmare.
Creating mobile and/or offline first exoeriences for individuals isn't a pipe dream, it was possible and happened in the 90's when connectivity (dialup) informed content (largely offline or downloaded).
I'm not looking at replacement, only reasonable substitutes, which I think will become useful similar to using Google docs on mobile and web.
The Firefox developer tools have a "storage" tab that lets you inspect the content of various databases associated with a website.
Perhaps Web Assembly will drive this power usage down. But as it stands now, I actively avoid more than one of these app-on-browser products at a time.
In half cases like that, stuff like sorting, list comparison, deduplication are done in a way that will score low mark even by standards of first year university program.
This is telling of web development industry's approach to doing business.
The most horrid examples of "LAMP sweatshops" of 10 years ago pale in comparison to what the industry has devolved into these days.
My own experience being an involuntary webdev for 3 years left me with following impressions:
1. Webdev is the largest commercial development niche in the whole tech industry. Everything else pales in comparison. It is also about making money quickly. A webapp or even a promo page SPA for a major consumer brand these days can cost up to $100k easily. $100k does not seem a lot to most people here, but such money can be well offered for a 1 month project for a team of of 6-8 professionals.
2. The industry is dominated by shops with 20 to 30 people headcount. Web dev studios generally don't scale much above that because of talent flight. Loss of a single senior dev who supervises hordes of lowest tier mule coders is often the end of a business for most of companies.
3. People from "big dotcom" world are near oblivious to ways of small web dev shops. For people who began their careers at 60k a year internships, getting into shoes of a person who does coding for 30k a year is impossible.
4. Talent flight and turnover is real.
5. This is all about really expensive quick and dirty code.
6. "The big dotcom" type of companies tried time and time again to tap into the market to extract rents, and with exception of Macrovision nobody ever succeeded. This is the reason Adobe is lobbying for unusable, unwieldy APIs in hopes of selling tooling for it.
Quit webdev a year ago, now working in engineering consultancy.
Right now my mobile device is often tapped by Javascript that insists on running in the background.
By replacing it with a poor simulacrum of an operating system. Browser APIs are an inefficient subset of libc and bsd sockets offer.
And they provide near-zero interoperability with native applications. No filesystem access (beyond the clunky save-one-file dialog), no CLI, no IPC, nothing. That means browsers are building on top of operating systems while not interoperating with them.
This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing.
There are some use cases that are hard to support (like being able to open all the files in a folder). But people are working on a solution.[1]
> No IPC
WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. And there is nothing stopping a process running in a different browser (or even no browser at all) to connect to a webapp using WebRTC locally.
Additionally, if a new window is opened by Javascript and both pages are in the same domain + port (or subdomains of the same domain and you have access to the parent domain) you can communicate between the windows with simple Javascript function calls. And since browsers are moving towards a 1 process per window setup this is essentially IPC.
> That means browsers are building on top of operating systems while not interoperating with them.
While I can't argue with that. So is X Window. The abstraction between app and OS is a thick gray line not a thin black one.
[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemD...
Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.
I'd also love it if they gave that ability.
But that's been true for almost all users, and not just webapp users, forever.
SaaS and web kill that.
Given the ubiquity of Word document and Powerpoint presentation files and the like, most users I'll grant you are aware of the files themselves, and the fact that they can be attached to an email. I'll even grant that a large fraction of those same users could answer 'yes' to the question 'Could these files be opened by another application?'. But almost none would be capable of doing anything with those files without an application that handles everything for them.
I don't dispute tho that an awareness of, let alone existence of, files in a filesystem is a significant benefit and not having access to them is a (relatively) significant loss.
Your are neglecting the option of exposing a limited subview of the filesystem like containers do.
> But people are working on a solution.[1]
The big red box on top says it's not on standards-track.
> WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC.
Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes?
> So is X Window.
Maybe if you're remoting X, few people do that these days. In practice X applications have access to the same machine that they are drawing on.
No I'm not. I said the limitation is a step forward. I didn't intend to imply it is perfect. It is not at all perfect.
> The big red box on top says it's not on standards-track.
Correct, but most standards started as experiments by the browsers. I think it qualifies as "people are working on it" but means it is probably far from being standardized.
> Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes?
No. But you already knew that. But it does allow for data communication which in my opinion solves the 80% use case for IPC. From my experience (YMMV) the features you described while useful are not needed for most consumer apps.
Don't let perfect be the enemy of good.
The problem isn't perfectionism, but that at least some of us believe that things are moving in the wrong direction - towards making vendors own everything, and end-users in control of nothing.
I'm still optimistic that new forms of applications will emerge from this. There are serious pieces needing fleshing out, like file access.
The insecure interoperation between browsers and operating systems perhaps can be reimplemented through a newer more secure interface like wasm or the api.