I have many issues with what the web is today, but removing all interactive features from web browsers would be a very negative change in my opinion.
Think about this scenario. You boot your machine, and it boots to a beautiful environment, with all the software you need to do the things you want to do. But most of it is useless because you have to start this other piece of software that's a blank rectangle, and in that software you must type the name of the application you want to run, and it will fetch the application over the network and render it. This blank rectangle must constantly be updated with new features in order to continue fetching software to run over the network properly. Whole teams need to be employed by non profits to keep this blank rectangle up to date. An operating system inside of an operating system. You don't think this is senseless?
Now imagine this scenario: you click a link to a video, the stream opens in VLC. You click subscribe, the link opens in thunderbird. If a company wants to have some interactive service they have to give you a client, they can't just externalize that workload on a browser maintainer. Isn't that the web we wanted?
A solution on other operating systems would be to use Electron, but I've seen many people on here also cry foul about that.
Did you know that electron apps basically bundle the entire chrome browser in with every application you use it to make? Have you ever tried running more than a couple of electron apps at once?
You build a system, the web app is supposed to be a demo of what your system can do. But since the days of Facebook, YouTube, reddit, the web app is the product itself. This is why these companies always break third party apps that connect to their API.
So you're in one of a few situations. You have to build a web app because precedent, and you don't want cost overruns. Also use case comes second to business case. And we end up where we are. It's a mess for the user, and I don't think it's sustainable, which means this problem won't exist long term.
Also your last paragraph doesn't follow to me because the whole reason these apps exist is because they are web apps. They wouldn't exist otherwise. That's the whole reason they are sustainable now in the first place. They're the default because it's the cheapest and easiest way to deliver a product for billions of users.
OS vendors could have prevented this madness, but chose the path of deliberate incompatibility with each other, so we're left with the world as it is rather than as it should be.
How about this: you try turning JS off and go to HN and realize it works just fine without the bloat.
So you're fine with web pages that function as applications, you just want the user experience to be stuck in 1995.
I'll give you an example of a web app that I like: github. It is built as a web app because it makes sense as a web app, it works really well, there's no cruft. It could be better if it were an API with user built clients, something git is designed for anyway, but it's not bad.
I would be fine theoretically with web apps, if there were some way to ensure actual web apps that need interactive functionality were the only ones that could use it. The situation we are in now every document is a web app, every piece of content you try to see online loads it's own application just to render. I have a video player on my machine, I shouldn't have to download and render a video player onto a one size fits all abstraction layer every time I want to play a video. I shouldn't have to download an entire rendering framework just to display a CNN article.
The right way to do the web is with APIs, client applications and protocols. If you're delivering a document, I should use a client applications to render documents, which is what browsers are supposed to be. If you're building an interactive service, give your community an API to build a client or build a client yourself. An instant messaging application should not be rendered in a document delivery program delivered over HTTP. If there's some use case that requires a standard, a standalone application that implements that standard is the way to go. Think XMPP and pidgin. How terrible would it have been if XMPP could only be used in a web app?
These design decisions are not about the user, they're deliberately designed badly because incentives are misaligned. Can't find what the user bought on the internet and sell that info to marketing companies if you just deliver content and let the user choose what software they execute.
The future is what I'm looking at, not the past. To deliver a truly useful web you have to determine it's shortcomings and rethink the architecture that led to those shortcomings. Saying "this was a bad design decision and look at where it led us" is not the same as saying "let's go back to 1995."
> Isn't that the web we wanted?
No, because you just described the world we're actually in, where everything from Starbucks to the laundromat exhorts you to install their app (going so far as to nag you about it e.g. when looking then up on a map and clicking through to their website). Despite your framing it in a positive light, we know this isn't the case.
Let me try the same reframing trick to make the Web sound like the best option:
If a company wants to offer you something, whether a physical item or informational content, then they have a way for you to fill out a form and get it. There's a way to deliver digital forms in a universally understood format, and you can use a software agent to deal with them for you and handle them in whatever way you think is best.
This includes all the web forums, blogs, and even sites like YouTube and Twitter which used to actually work without JS (and were much faster too).