[nine_k]

What would make such a platform less of a compromise than a web browser?

How would programming in C++ be less pain than programming in JS / HTML / CSS? At the very least, JS code won't write past array bounds, or smash the stack.

From relevant olden times, Lisp and Smalltalk environments were closest to the ideal. They were expensive though, and nobody distributed them for free, as Netscape did with the browser. They also notably lacked any protections against untrusted code. But worst of all, they'd likely run even more poorly on consumer PCs circa 1995.

So, enjoy Typescript, V8, flexbox, canvas, web workers, etc. You could end up having a worse deal.

[lmm]

> How would programming in C++ be less pain than programming in JS / HTML / CSS? At the very least, JS code won't write past array bounds, or smash the stack.

A native ABI doesn't mean you have to use C++ though. I can use Qt from Python if I like, or even from the JVM (slightly fiddlier, but doable). I can't do that with the browser.

> nobody distributed them for free, as Netscape did with the browser. They also notably lacked any protections against untrusted code.

The JVM avoids both those problems though - it had a robust security model and was distributed for free. What killed it was that corporations refused to install Java Web Start on their computers because it's a scary "application runtime". But they would happily install web browsers because that's just a "document viewer". Even though they both do the same thing!

[manwe150]

I believe that aforementioned “robust security model” was removed several years ago due to issues with its actual robustness https://openjdk.org/jeps/411

[lmm]

If you read your link, it was removed largely because the things that used it (such as Java Web Start) had been removed, which was more because they failed in the market than because its actual security record was particularly poor.

(Yes, there were occasional sandbox escapes, but there are occasional sandbox escapes in web browsers too. Few security mechanisms are perfect)

[YetAnotherNick]

> A native ABI doesn't mean you have to use C++ though. I can use Qt from Python if I like, or even from the JVM (slightly fiddlier, but doable). I can't do that with the browser.

wasm is that ABI for browser. Yes it would make everything bit slower, but I am fine given a lot more added security.

[lmm]

If we reach the point where a WASM-only app is a first-class citizen and I can write an app that doesn't have to touch HTML/CSS/JS (doing the UI with canvas or whatever), I'll be happy. We're not there yet though.

[nine_k]

See where Google Flutter is heading.

[nine_k]

Funnily, if you look at memory consumption of a Qt app, especially a PyQT app, sometimes it can easily compare to that of an Electron app.

(No, not all of them, of course.)

[AgentME]

I think people really underrate browsers. The browser standards are open and have multiple open source implementations. People associate browsers too much with annoying trashy ad-based and other questionable websites to see how good they are themselves.

Electron has an annoyingly heavy download size but it's not the only option for native releases of web-based apps. Windows and some other OSes have built-in browser widgets that can be used with Tauri.

[loup-vaillant]

> The browser standards are open and have multiple open source implementations.

The browser standards are open only in name. The sad fact is, implementing those standards are flat out impossible if you’re not a megacorp. They’re just too damn big: I recall someone counted like more than a hundred million words.

Now using those standards is easy, you can implement a subset. But the number of browser engines that actually supports enough of those standards will only decrease.

[forty]

I'm not really sure for how long we will have multiple implementations. And we won't have for sure any new implementation, we are stuck with the 3 we have and can only hope the 2 non chrome ones will survive.

[tobyjsullivan]

That's exactly what people said about IE over 20 years ago. History has proven this reasoning untrue. Web isn't going anywhere. If there's an opportunity to build something 10x better than Chrome, it'll be shipped.

[loup-vaillant]

> If there's an opportunity to build something 10x better than Chrome, it'll be shipped.

There won’t be. Since IE6 the standards have grown to inhuman proportions, and implementing a new browser engine is even more difficult than it was then.

[pas]

there's no need to do it from scratch, nor to do it all really.

if there's some great innovation it can be introduced in a fork of Firefox/Chrome/etc.

[loup-vaillant]

But then you’ll be tide to how your engine of choice did things. There’s no true independence if you don’t have the means to rewrite it.

[pjerem]

It happened because both Firefox and Chrome were baked by Google.

So yeah, maybe we’ll get another engine somehow, but if we need again another agressive tech giant to pay for that, thanks but no thanks.

[daemin]

I'm sure with enough dedicated and enthusiastic people something better than Chrome can be implemented. Though will it survive at all is another question. Chrome has an effective stranglehold on the market, so for anything else to succeed it will take political will rather than development effort.

[nine_k]

Browsers are absurdly well-optimized for performance. If you know how to tap it, you can make screaming-fast apps of various kinds, with top-notch graphics, font rendering, accessibility support, audio, video, etc. They also have really solid networking capabilities, as long as you don't need raw TCP or UDP. In particular, HTTP/2, HTTP/3, WebSockets, and WebRTC allow for a lot of advanced things.

By now, you also have WebGL and WASM, if JS's JIT is not fast enough for you.

[PH95VuimJjqBqy]

I love how people use hyperbole such as "screaming fast" and yet a native application that's not even all that optimized will tend to run absolute circles around these "screaming fast" solutions.

How are we supposed to describe these native apps? What's faster than screaming fast? ear shatteringly quick?

[wiseowise]

> I love how people use hyperbole such as "screaming fast" and yet a native application that's not even all that optimized will tend to run absolute circles around these "screaming fast" solutions.

And you of course have nontrivial examples to prove that? Or as always source: trust me, bro?

[glimshe]

This is like asking to prove the sky is blue in a sunny day. Walk outside and you'll see it. I was talking to friends about how we've forgotten how fast computers are because all we see are web pages and Electron applications. People don't even remember the wonder of native applications.

Try building an operating system or browser engine in Javascript and you'll see what the parent is saying. I'm just giving you these examples because these are some of the last remaining native applications everybody still uses, but pretty much any native application will be much faster than the Javascript version. The reason browser wins is that we got to a point where the performance is "good enough" and the development cost is significantly lower.

[ClimaxGravely]

I've definitely seen some really well optimized web targets. Unfortunately that is not the common case in my experience currently.

That said the WebGL/WASM stuff is generally very nice in my experience and is very much changing my opinion. I'm interested to see what comes in the future!

[reactordev]

WebGPU is that future.

[chpatrick]

No idea why you're being downvoted, you're completely right. And all that runs on every phone and computer from the last 10 years or so