Let the browser be a document viewer.
Failing that, finalize Web Assembly's design to the point that the browser is just yet another general purpose VM.
WebIDL then defines the APIs accessible to any language that gets compiled into Web Assembly.
My issue with those is, they are less sandboxed than JS is. Why would I want to put one-off things all over my disk and system? While I'm willing to install native applications from the package manager for big things I really need, I do not want to do so for simple one-off interactive things, so I really like that I can just do such things in the browser without installing them. Things like simple games, mathematical demonstrations, ...
I think the value of sandboxed self contained interactive apps that can do graphics, input, sound, that run from a link, is tremendous to humanity.
Of course on the opposite side, one problem is the usage of so much JS for simple articles of text and photos. Those would be more pleasant to read if they were just text and photos and nothing more.
QubeOS: heard of it. It's multiple isolated linuxes together essentially. Do you really think one wants to install software on QubeOS to view a mathematical demonstration or a simple game from the web? The issue is simply the effort of installing vs just opening link and viewing it.
I don't know UWP, snap or Flatpak. Do they allow you to open a link and run something interactive immediately without installation? If so, great.
We need something that allows you to open a link and have something interesting running immediately.
Again, it's sad that this same interactivity is also invading simple textual articles that should be just simple plain text, but that is a problem of those articles, not of the existance of JS.
Flatpak is a (promising) work in progress that is copying a lot from web permissions. I look forward to the point when it becomes ubiquitous and secure enough that I would feel comfortable downloading and installing a random, unverified piece of code off the internet from a sketchy looking site. Flatpak is native finally starting to catch up to the web in terms of user-accessible sandboxing. But it's not finished yet, and once it is finished it won't be cross-platform.
QubeOS is great, but nobody uses it because it's hard to use and cumbersome. Same with VMs. You can sandbox an app in a VM and be very happy about it, but your performance will be worse than it would be on the web. Nobody does it because it's not accessible.
Like it or not, the web is the best tradeoff we have right now between flexibility and security. For the most part, users don't need to be suspicious of random links. If someone shares a link on Facebook, you don't need to go look up reviews before you click on the site. It's not like native, you don't spend your entire browsing experience worried about malware.
To be sure there are problems we're still solving (user tracking, phishing, processor control), but native hasn't even gotten to the point of trying to solve those problems yet. Any app you download to your Android phone is going to be able to track you better than a website can - it's just that you'll be so worried about malware that you won't notice. Website operators are arguing about how to prevent phishing for full-screen apps. Linux, Windows, and Mac aren't thinking about stuff like a zone of death yet - a full-screen app in Linux can easily spoof your desktop. Heck, it doesn't even need to be full-screen, just copy the interface and icon of another app including its title-bar if you want to phish someone's email or banking client.
The simple test is this: suppose I paste a completely randomized link to an Android APK, and a completely randomized link to a website. You might have some reservations about clicking/installing them -- but, be honest, which one are you more frightened to interact with?
How many people here would feel comfortable installing a random program that was linked on "Show HN" if they couldn't get access to the source code or verification about what it did beyond 2 or 3 sentences? How many of those same people are fine clicking on a "Show HN" website? The difference is that for the most part web sandboxing actually works.
As someone that develops both native and Web, I feel the pain of catching up with native.
Web Components are finally around the corner, pity it took 20 years to offer what is a mostly a commodity in native UI development since Visual Basic and VBX were designed.
https://amexio.tech/amexio-canvas
Regarding clicking links, those that install anything outside of the store don't have anyone to blame but themselves, and zero day exploits of browsers is a thing.
If you have to worry about a moderator, it isn't sandboxed well enough. Platform moderators are a security failing - you bring them out when you haven't solved the underlying problem. A version of Android with acceptable sandboxing wouldn't need a Play Store. There'd be no downside to just running an APK.
I agree that both native and web applications have a point. But that is the point - both of them are filling in different gaps. In some cases, they're targeting mutually exclusive gaps -- people develop for native to get around browser restrictions. But getting rid of those restrictions makes it easier for native applications to phish and abuse users. And while efforts are being made to introduce sandboxes to native platforms, they are miles behind where they should be -- as evidenced by user's hesitance to venture outside of official sources for software, a problem that most users don't have on the web.
Because of those differing strengths and goals, it's very naive to say that Javascript on the web doesn't play an important, vital role in modern application development. No, it isn't a perfect sandbox. It's just way, way, better than everybody else's.
Maybe that will change in the future. But in the meantime, if you're a user, and you're paranoid about untrusted or proprietary code, you should be encouraging devs to develop web applications instead of native ones. If you're not worried about security, and instead your biggest thing is that you don't like the toolchain, or you don't think the app looks pretty because it doesn't use your GTK theme, then fine. Those are very different concerns. I don't think whether or not someone is fond of web components has anything to do with application security.
That would require deploying on at least five wildly incompatible native platforms, and break when they change architecture.
The web is not so much an integration layer as the no-mans-land of the platform lockin wars; it's a space that doesn't "belong" to any one platform owner, which is both its great benefit and great disadvantage.
My C++, JavaScript, Python, Java, .NET code doesn't care which OS it runs on, and the parts that do are very small modules.
If it was easy, we'd be seeing a lot more apps available with Windows/Android/Linux/iOS native ports.
It is easy, just not for those brought up coding for the browser.
Or do you want to imply Electron is more native than even Gtk+?!
With unblockable banners, uninspectable unmodifiable code and other garbage.
The current state of affairs is just perfect balance, webassembly can seriously hurt the user if it ever gets good-enough direct access to DOM.
It is only a matter of having the right tools at hand.
https://www.hex-rays.com/products/ida/
Code might not be 1:1 mappable to original source code, but it is in any case reversible to an higher level description, specially nowadays that re-writable code is no longer allowed due to security exploits.