You can't build apps without turing complete code. We would be back to downloading and executing applications/programs.
Sure you can. None of these things should require me to run your arbitrary Turing-complete code in my browser:
* Reading an article
* Writing an article
* Shopping online
* Searching for things online
* Reading social media posts/comments
* Submitting social media posts/comments
* Browsing a code repo
* Submitting issues / PRs / etc. to a code repo
* Reading documentation
That (non-exhaustive) category accounts for a solid 80% of everything I do online (and the other 20% are things which I'd rather be doing through native apps). All of these things should be possible (and indeed are possible) entirely with HTML (and optionally CSS) + a server somewhere handling the backend logic. If they're not, then your "app" is over-engineered, or it is indeed better off as something I explicitly download and install, which brings me to...
> We would be back to downloading and executing applications/programs.
Good. That's the direction the mobile world has already been going for a decade now. Native apps actually integrate with the platform. Web pages don't (or at least don't do so well). At least in that situation I'm explicitly "downloading and executing those applications/programs" by my own choice.
We even have things like WebAssembly now, with experiments and effort toward making it usable as a general-purpose compilation target/runtime outside a web browser. No reason why it'd take more than a decade for someone to figure out how to wire a WebAssembly module into some sort of Qt-based (or whatever) runtime + UI and get the best of both worlds.
I genuinely don't understand this argument at all -- either you understand something about native platforms that I don't, or you're working under the assumption that all of your native apps:
a) aren't already vacuuming your data at the same rate as web apps.
b) wouldn't get considerably worse if they replaced the web ecosystem.
On the first point, native sandboxing is almost universally terrible. There's some promising stuff happening (notably with MacOS and with Flatpak/Wayland) but it's all just playing catch-up to where the web was years ago.
Pick just about any company that maintains both a website and a native version of the same app -- almost universally, the web version is safer to use. Nobody should be installing Facebook, Twitter, or Reddit on their phone. In fact, I would say the single best piece of advice I can give to anyone to improve their privacy/security on their phone is to stop installing things.
On the desktop, the situation is better, mainly because the desktop is very slowly turning into a niche platform and the web is a much more attractive place to put skuzzy, privacy-violating software. But this is a bit like the old argument that MacOS was more secure than Windows because no one was targeting Mac with viruses at the time. Get rid of the web and all of those skuzzy developers you hate aren't going to go away, they're just going to start making native apps. Where, again, the current sandboxing for most users and OSes is completely inadequate.
If your security model on the desktop is, "I'll only run code I trust", you can already do that on the web today. You can already turn off Javascript. And if you don't feel like the modern web-app ecosystem accommodates that decision, then what makes you think a theoretical, purely native world would accommodate you running a small, tight system that only includes code you trust? I can run a beautiful, tight Linux system because I don't have to install much software on it.
The unfortunate, horrible problem, is that running code we don't trust is gonna be necessary, no matter what world we move to. Sandboxing and permission systems are something we are going to have to figure out. Web or not, there is never going to be a world where you'll be able to trust all of the code you run on your computer. And currently, despite the many problems that browsers have, they're still still the best consumer-accessible solution for sandboxing code.
Of course integration and app performance suffers on the web. But frankly, neither of those are more important than sandboxing.
> almost universally, the web version is safer to use. Nobody should be installing Facebook, Twitter, or Reddit on their phone.
Not only is this true, this would be even more true without JavaScript—if those sites were still usable, which they definitely could be, they just choose not to be. (Well, maybe except Facebook Live, but that could be an optional standalone app.)
> you can already do that on the web today. You can already turn off Javascript.
Of course, this isn't really true, precisely because so many websites that could function fine without JS (including things like news sites that should just be static content!) instead choose not to.
Which of course is the real problem with yellowapple's idea. Lots of services cripple their mobile website and push you to install their app instead; if we removed JS from the Web, everyone who could would just start doing the same on desktop too, right? Upstarts trying to maximize growth probably will work great on the Web, but as they get more established they'll start pushing people more and more towards their native apps, and existing established players will do that from Day 1 (of the new, JS-less world), including everyone mentioned so far—Facebook, Twitter, Reddit, GitHub, major news sites, because people will deal with the one-time friction of installing the app in order to access the network or content.
And in the proposed 10 years being discussed here, there's no reason to believe locally-installed applications won't have exceeded browser sandboxing capabilities, let alone caught up.
Meanwhile, the web sandbox is actively deteriorating specifically because frontend developers want to do the things locally-installed applications can do.
> Nobody should be installing Facebook, Twitter, or Reddit on their phone.
Not at the current state of native app deployment, no, but that's improving rapidly and substantially, especially in the mobile space. Also: the vast majority of users are doing that anyway, so it's worth investing the time and energy into being able to sandbox apps without needing an entire HTML + CSS + JS engine/stack to do it (and indeed, both Google and Apple have made significant strides on that front in the last 10 years, though there's certainly still room for improvement).
> The unfortunate, horrible problem, is that running code we don't trust is gonna be necessary, no matter what world we move to.
Yes, but at least with a locally-installed app, I'm explicitly opting into that app existing and running on my device. This on its own will at least somewhat cut down on the amount of untrustworthy code running on my system.
Yes, I can do the same thing for a website's JS code (and indeed do so), but it's asinine that I need Javascript enabled to read a blog post or post to social media or do the myriad number of other things that are theoretically and practically possible with server-side processing exclusively.
> Of course integration and app performance suffers on the web. But frankly, neither of those are more important than sandboxing.
No, but sandboxing - again - is a problem that can (and almost certainly will) be solved within the next decade, at which point integration and performance benefits will make local app installation even more attractive than it already is.
