I tried to bring some nuance to this. 10 years ago I would have said something more like "Fuck web browsers". I've toned back on the hate, but I still think they have serious shortcomings. (Not that native doesn't - Notice I said nothing about permissions and untrusted code)
tl;dr: I think web browsers have a Pareto problem. Building inside a web browser is pretty all-or-nothing. Their interfaces make the most common 90% of cases easy but the other 10% of interesting niche stuff totally impossible, or too slow to be useful. Just like how old PC games would play music by triggering the CD drive's "Just play this track" feature, browsers are fine for doing super-high-level stuff exactly the way most people want to do it. But if you want to do anything with that audio other than stream it unmodified straight to the speakers, suddenly the APIs let you down. And the whole time, you're taking on some of the biggest dependencies in history. There are two companies that make full-sized web browsers. One is a non-profit constantly struggling for funding while making awful PR gaffs and being hypocrites about privacy. The other is an openly evil advertising company.
Full:
I've done really basic stuff, like I learned how HTTP works, I wrote a few web apps with Rust, I made a game with TypeScript and WebGL. But it just never clicked for me.
My comment is missing a little context. There's basically two different niches:
1. If I want more than 2 or 3 people to use it, it has to run in a web browser. I don't mind doing WebGL and putting it on a static site. I can always do a native port if I feel like it. All the games I've made can be modelled as "Read keyboard input and run OpenGL commands", and browsers are enough for that.
2. If I want to really have fun with something, just for myself, web browsers are too big of a dependency and the restrictions are too tight. Sure, they'll get QUIC as WebTransport soon (IIRC), but I'm always gonna be limited by the dependencies.
I don't like Electron out of principle. It's just so big. Native development can be awful - Big C projects are not fun to build. But Rust is striving for "Just clone and `cargo build`". What's the `cargo build` for web stuff? I have to set up TypeScript or something else to shield me from JavaScript... If I were using Electron I'd have to learn all that...
I actually like local web UIs. I think because that offers flexibility. If I want to send a video stream from a browser, sure I "just" have to use WebRTC. But how do the WebRTC servers work? I haven't found satisfying documentation. What if I want to start with a webcam stream and then compose graphics into it before encoding? I know browsers have Skia, but is that exposed to me? Or is it like so many bad "Play an audio file" APIs where it breaks down as soon as I want to play a _remote_ audio file or _stream_ an audio file or _transcode_ an audio file.
So (sorry for the meandering) back to my toy IRC idea.
I can do that with HTTP and long-polling and it would kinda work. But it would just be a crappy Matrix clone. What I really want is to show off "Look, I think QUIC is going to bring back custom protocols, QUIC has not to come to abolish the word of TCP but to fulfill it, and here's how it looks."
And I could do that with Electron, but like the "Let me do everything for you and make the 10% of niche cases impossible" API that can only play audio or send a webcam stream without any compositing, Electron presumes I'm going to have a GUI, and I'm also going to run it on the same computer.
Whereas if I make the first prototype UI with curses or a local web UI, I can forward it over SSH easily or run it when a GUI isn't available.
It sounds a lot like Gemini, but I think Gemini is a little misguided. It sounds like most of its proponents think that you can control a protocol by just having very noble goals. And it sounds like they are opposed to HTTP and QUIC not because the protocols are bad or even hard to implement (In the case of HTTP. QUIC actually is hard to implement), but just because bad entities use them. I think it's dangerous to believe that powerful tools are only for bad purposes. It will leave good people de-powered.
I like the way you're thinking here, I think the limitations you mentioned with gemini may stand... for me it's kind of like the limitations generally speaking with markdown. Doesn't leave much room for doing stuff like parsing the raw data when they aren't in a hierarchical structure with xpaths you can target and stuff like that, it just throws out so much baby with the bathwater that I'm ready to scream infanticide.
Any thoughts on fast experimental protocols like warp data transfer [1] or fast and secure protocol [2] ? I know they're not exactly the most open things or wellsupported in terms of what you're looking for but I've been really wondering when we're going to start seeing pressure to relieve network congestion using stuff like this. I get that part of the idea of QUIC is generally to shift the optimization of network traffic from kernel-space (for example fq-codel or CAKE) into user space, but does it offer wider improvements on bandwidth usage outside of that?
tl;dr: I think web browsers have a Pareto problem. Building inside a web browser is pretty all-or-nothing. Their interfaces make the most common 90% of cases easy but the other 10% of interesting niche stuff totally impossible, or too slow to be useful. Just like how old PC games would play music by triggering the CD drive's "Just play this track" feature, browsers are fine for doing super-high-level stuff exactly the way most people want to do it. But if you want to do anything with that audio other than stream it unmodified straight to the speakers, suddenly the APIs let you down. And the whole time, you're taking on some of the biggest dependencies in history. There are two companies that make full-sized web browsers. One is a non-profit constantly struggling for funding while making awful PR gaffs and being hypocrites about privacy. The other is an openly evil advertising company.
Full:
I've done really basic stuff, like I learned how HTTP works, I wrote a few web apps with Rust, I made a game with TypeScript and WebGL. But it just never clicked for me.
My comment is missing a little context. There's basically two different niches:
1. If I want more than 2 or 3 people to use it, it has to run in a web browser. I don't mind doing WebGL and putting it on a static site. I can always do a native port if I feel like it. All the games I've made can be modelled as "Read keyboard input and run OpenGL commands", and browsers are enough for that.
2. If I want to really have fun with something, just for myself, web browsers are too big of a dependency and the restrictions are too tight. Sure, they'll get QUIC as WebTransport soon (IIRC), but I'm always gonna be limited by the dependencies.
I don't like Electron out of principle. It's just so big. Native development can be awful - Big C projects are not fun to build. But Rust is striving for "Just clone and `cargo build`". What's the `cargo build` for web stuff? I have to set up TypeScript or something else to shield me from JavaScript... If I were using Electron I'd have to learn all that...
I actually like local web UIs. I think because that offers flexibility. If I want to send a video stream from a browser, sure I "just" have to use WebRTC. But how do the WebRTC servers work? I haven't found satisfying documentation. What if I want to start with a webcam stream and then compose graphics into it before encoding? I know browsers have Skia, but is that exposed to me? Or is it like so many bad "Play an audio file" APIs where it breaks down as soon as I want to play a _remote_ audio file or _stream_ an audio file or _transcode_ an audio file.
So (sorry for the meandering) back to my toy IRC idea.
I can do that with HTTP and long-polling and it would kinda work. But it would just be a crappy Matrix clone. What I really want is to show off "Look, I think QUIC is going to bring back custom protocols, QUIC has not to come to abolish the word of TCP but to fulfill it, and here's how it looks."
And I could do that with Electron, but like the "Let me do everything for you and make the 10% of niche cases impossible" API that can only play audio or send a webcam stream without any compositing, Electron presumes I'm going to have a GUI, and I'm also going to run it on the same computer.
Whereas if I make the first prototype UI with curses or a local web UI, I can forward it over SSH easily or run it when a GUI isn't available.
It sounds a lot like Gemini, but I think Gemini is a little misguided. It sounds like most of its proponents think that you can control a protocol by just having very noble goals. And it sounds like they are opposed to HTTP and QUIC not because the protocols are bad or even hard to implement (In the case of HTTP. QUIC actually is hard to implement), but just because bad entities use them. I think it's dangerous to believe that powerful tools are only for bad purposes. It will leave good people de-powered.