Gemini seems like a reaction to the incredible difficulty of building a web browser from scratch, but I think it goes too far towards minimalism. In particular, it's not difficult to find...
Gemini seems like a reaction to the incredible difficulty of building a web browser from scratch, but I think it goes too far towards minimalism. In particular, it's not difficult to find libraries that handle https, so the networking layer doesn't seem like the problem?
A less radical approach would be to just replace HTML with a different content type. Maybe it would be fun to build a browser that uses Markdown documents?
No, that's another thing entirely. Gemini is a response to the current state of the Web. If you look at the FAQ on that page you can see that it was made with the help of Gopher fans. The...
No, that's another thing entirely. Gemini is a response to the current state of the Web. If you look at the FAQ on that page you can see that it was made with the help of Gopher fans. The inspiration is pretty clear if you're familliar with Gopher, though personally speaking I have no clue why they really needed a new protocol.
They go into that on the site. Gopher does too little, just serving up menus. The current web stack does too much, serving up megabytes of resources just to load the app that loads the document....
They go into that on the site. Gopher does too little, just serving up menus. The current web stack does too much, serving up megabytes of resources just to load the app that loads the document. Gemini aims for the middle, serving up plain text documents in a format that's a bit similar to Markdown.
They also mention this in the FAQ item about their name:
It's a reference to the pre-shuttle era of US manned spaceflight, which consisted of three projects. The first was Project Mercury, which was a fairly minimalist "proof of concept" ... The last was Project Apollo, which was large, heavy, complicated and expensive but could, of course, fly three men to the moon and back.
Less well known to the modern public, Project Gemini was the "middle child" ... In terms of size, weight and cost Gemini was much closer to Mercury than to Apollo, but in terms of capabilities it was the other way around ...
Hopefully the analogy is obvious: Gopher is akin to Mercury, and the web is akin to Apollo. Gemini hopes to sit between the two, doing more with less.
A strongly expressed point of Gemini is to be deliberately not extendable, hence the hard break from HTTP / HTML / existing web standards, and to be deliberately impossible to build...
A strongly expressed point of Gemini is to be deliberately not extendable, hence the hard break from HTTP / HTML / existing web standards, and to be deliberately impossible to build webapp-websites on top of.
I don't really think this is too valuable: the "early web" vibe that they're going for to me was all about creativity and presentation of content, not just the content itself. I also don't really buy into the whole "no embedded images will stop surveillance capitalism" schtick they've got going on, but I suppose it's worked thus far.
I'm also strictly in favor of no executable code. Javascript was mostly to cover for HTML's and CSS's deficiencies, and frankly has been a bit of a disaster ever since. I swear about 90% of...
I'm also strictly in favor of no executable code. Javascript was mostly to cover for HTML's and CSS's deficiencies, and frankly has been a bit of a disaster ever since. I swear about 90% of security problems since 1995 boil down to 'Javascript is impossible to secure.' Who thought that letting every stranger run whatever code they want on your computer was gonna turn out fine?
Want to share a program on the web? Great, provide source code with compilation instructions.
Downloading and compiling arbitrary source code off the Internet is worse than running code in a sandbox written by paranoid software engineers. Yes, we do it, but we should be trying to get away...
Downloading and compiling arbitrary source code off the Internet is worse than running code in a sandbox written by paranoid software engineers. Yes, we do it, but we should be trying to get away from it, and it's a good thing only software developers do it routinely anymore.
Mobile OS's and web browsers and other sandboxes are steps in the right direction. I also like that Deno is sandboxed by default, but it's too easy to use 'deno run -A'.
You might not remember that for about the first 20ish years of its existence, Javascript was not heavily sandboxed. And then for the next 5 was not exactly well sandboxed. And there's a world of...
You might not remember that for about the first 20ish years of its existence, Javascript was not heavily sandboxed. And then for the next 5 was not exactly well sandboxed.
And there's a world of difference between me needing to download 10-20 apps one time to do my work, and me needing to download code 100 times a day because I clicked a few links.
The web would be a far better place if no code ran in browsers.
it's a good thing only software developers do it routinely anymore.
Windows users regularly just download and run arbitrary binaries all the time. I'd argue thats far worse. At least source has the potential to be audited.
In the end, the scope of entities I need to have an app for is much, much, smaller than almost every web site. For me to run an app, there needs to be a genuine need, typically involving some sort of work relationship. Not because some random clickbait article's ad hijacked the browser with a 0day.
Yes, it certainly took many years of engineering effort, but as a result, the sandboxes are quite good. Many sophisticated attackers have found vulnerabilities and the bugs have been fixed. We...
Yes, it certainly took many years of engineering effort, but as a result, the sandboxes are quite good. Many sophisticated attackers have found vulnerabilities and the bugs have been fixed. We probably haven't seen the end of them and that's why security updates are important. But this security will be better than your ability to audit source code. How could you possibly review every library in a medium-sized software utility's dependencies?
Nobody has time for that. We rely on reputation and hope, and often there's little rational basis for it; we don't even know the names of all the libraries we're using, let alone what their authors have changed recently. Protection against supply chain attacks is in its early stages.
Desktop OSes are architecturally pretty far behind mobile phone OS's and web browsers, but there is code signing and some sandboxing. When better security is important, I recommend a Chromebook.
Not just run code, but code with all sorts of horrible gotcha's. Base JS has got to be one of the easiest languages to cause major problem with that doesn't actually require you to manage memory....
Not just run code, but code with all sorts of horrible gotcha's. Base JS has got to be one of the easiest languages to cause major problem with that doesn't actually require you to manage memory.
It's gotten "better" by piling framework after framework on it, and is oddly one of the funniest ironies that JS has become the pinnacle of the coder nightmare. Namely "look we got it out quickly, but we'll fix it later, it certainly won't sit in production like this FOREVER"
How many JS vulnerabilities are there that are actively exploited? Honestly, most of them are zero days that are fixed way sooner than anyone would be able to take advantage of them, or they might...
How many JS vulnerabilities are there that are actively exploited? Honestly, most of them are zero days that are fixed way sooner than anyone would be able to take advantage of them, or they might even be just theoretical attacks - which doesn’t make them practical to exploit, though even those are getting fixed fast.
I would be honestly be surprised if web browsers would be a significant attack vector, it is definitely way down the list compared to social engineering and running random exes.
Well, JailBreakMe comes to mind. Many Pwn2Own winners exploited browsers. XSS is a major problem. Here's an example where it was used as part of an attack on Apache.
IMO it's the other way around: every native app should be downloadable+installable within literally a second or two, like a webpage is. If there's less code client side, then there's usually more...
IMO it's the other way around: every native app should be downloadable+installable within literally a second or two, like a webpage is. If there's less code client side, then there's usually more code server side.
I agree that we should be able to both review and verify the code we install, but that's a solved problem (albeit not used) - just use checksums and AGPL.
This is a good thing. Servers can be trusted (and trust more easily revoked). Clients can not. And when it comes to Javascript in particular, I can't think of any use case that couldn't be...
If there's less code client side, then there's usually more code server side.
This is a good thing. Servers can be trusted (and trust more easily revoked). Clients can not.
And when it comes to Javascript in particular, I can't think of any use case that couldn't be addressed with better HTML/CSS specs, or is better relagated to a non-browser application.
Theoretically you can inspect things client-side, but you would need to do that on every page load and would need to inspect all scripts fully to make sure that there's nothing that could load in...
Theoretically you can inspect things client-side, but you would need to do that on every page load and would need to inspect all scripts fully to make sure that there's nothing that could load in additional code after the load. But unless you set up a system where your browser refuses to execute scripts that you haven't reviewed, there's really no difference.
And thats why I said at the top: No executable code in browser. If its server-side code, it's not sending me exploits that are de-facto unauditable. Plus, the whole reason adblockers were easily a...
And thats why I said at the top: No executable code in browser.
If its server-side code, it's not sending me exploits that are de-facto unauditable.
Plus, the whole reason adblockers were easily a thing is that when the entire site is passed in one go, it becomes trivially easy for the client to modify.
Yeah, they're both the same. You have to get your programs somewhere. People will provide pre-compiled binaries because it's convenient. If you trust the source, why bother handling dependencies...
Yeah, they're both the same. You have to get your programs somewhere.
People will provide pre-compiled binaries because it's convenient. If you trust the source, why bother handling dependencies and compile errors? If this is something done frequently, for every service that wants an app, even today it only requires a single click to run on desktop platforms. And it's very easy to train users into making one click.
There's no real difference between a single trained, thoughtless click and truly automatic execution, except that the automatic execution is sandboxed and at least mostly prevented from doing real harm. People by and large don't audit their own source code, even when they're capable. And on Windows where autoupdaters are ubiquitous, even if you do check the source code, that binary can change at any moment. Nobody has the time to be reviewing the code for every app for every update. Whether it's downloaded and executed automatically or pseudoautomatically.
If you're talking about trust in the security sense, then sure. But in the context of "what if this company disappears and takes their software with them", then it's far better to have a local...
If you're talking about trust in the security sense, then sure. But in the context of "what if this company disappears and takes their software with them", then it's far better to have a local page cache or .exe than to rely on someone else's server, because then you can at least reverse-engineer the binary or bytecode.
I feel like "for the sake of security, just export the code you rely on to the vendor's server" echoes Linus Torvald's comment that the only secure computer is one that's had it's power cord/battery removed.
I am talking in the security sense, particularily in the sense of web browsing. You get linked to a random blog? Wouldn't it be nice to know that random site you've never been to before can't...
I am talking in the security sense, particularily in the sense of web browsing.
You get linked to a random blog? Wouldn't it be nice to know that random site you've never been to before can't execute code on your machine?
Disabling Javascript used to do this, but damn near everything is gated behind it now.
I find that Gemini makes a lot more sense when viewed through the lens of a specific, single design constraint: Gemini is designed to be non-extensible. There are clear reasons for this design...
I find that Gemini makes a lot more sense when viewed through the lens of a specific, single design constraint:
Gemini is designed to be non-extensible.
There are clear reasons for this design goal¹ and almost everything that seems weird about the design of both the protocol and markup format suddenly makes sense with that context. But it does mean that, by design, the whole thing is permanently locked at the level of capability the designers baked in, which of course is not going to be exactly what nearly anyone wants, and will be seriously deficient in some way to a not insignificant number of people.
¹ It's pretty clear that the extensibility of HTML is how the Web went from "basically a quick hack on top of SGML" through "clunky but essentially functional hypertext document format" into "horrifying abomination of an online application platform". Browser vendors one-upped each other with additional features until Netscape added Javascript, and that was the beginning of the end of the Web as a reasonable platform.
Is it doom? Or is it knowing, targeting, and cultivating an intended audience? To me that's like saying Tildes' careful approach to its userbase and lack of image posts is dooming it. Or like...
Is it doom? Or is it knowing, targeting, and cultivating an intended audience? To me that's like saying Tildes' careful approach to its userbase and lack of image posts is dooming it. Or like saying uxn's weird approach is dooming it. Maybe they are, in a certain sense, but that's by design.
Eh, it's not that horrifying of an online application platform. I do find that it is both a website platform and an application platform a bit horrifying: but I do think that new web standards...
Eh, it's not that horrifying of an online application platform. I do find that it is both a website platform and an application platform a bit horrifying: but I do think that new web standards like WASM are massive strides forwards for something more aesthetic.
Like Akir mentioned, I think the identity of Gemini makes more sense in the context of Gopher (and also the world of pubnices, where people like to play not just with computers, but in the shell...
Like Akir mentioned, I think the identity of Gemini makes more sense in the context of Gopher (and also the world of pubnices, where people like to play not just with computers, but in the shell specifically). It seems that many people discover it in the context of the Web and expect it to be a better-but-simpler version of it; which apparently disappoints many. The fact that it is a protocol also leads some to expect something a little more technologically ambitious or innovative like IPFS or something. But as you said, it is very minimal. I understand why it seems too much so, but the intention is to make it easy and fun to hack around with. That's actually how I got into programming; writing random "SSGs" and bespoke clients! I think that is more the spirit of it rather than trying to ameliorate the Web experience. And now it has grown such that it is home to lots of little groups of enthusiasts, and people seem content to just have fun with it.
I feel like we need something in the middle. A web browser spec that a team could implement in a year, shaving down everything that isn't necessary anymore and limiting scope. So only flexbox...
I feel like we need something in the middle. A web browser spec that a team could implement in a year, shaving down everything that isn't necessary anymore and limiting scope. So only flexbox layout, limited or no scripting, limited file-format support, no need for backwards compat, et cetera. Ideally something like HTMX syntax built-in.
I mean, the web functions by progressive enhancement: old sites will continue to work til kingdom come, and old browsers (although they will likely need to update their root certs) will continue...
I mean, the web functions by progressive enhancement: old sites will continue to work til kingdom come, and old browsers (although they will likely need to update their root certs) will continue to render and view websites, albeit worse as websites adopt new CSS standards and JavaScript APIs. I don't think cruft surrounding web specs is worth getting rid of at the expense of breaking backwards compatibility, and this shapes my dislike of Gemini.
I hold that HTML + CSS + HTTP 1.1 is a very reasonable spec for such a purpose.
HTTP 1.1 is dead simple. I really do like the HTTP protocols, I think they have maybe one or two technical flaws (Content-Length and Transfer-Encoding overlap) and maybe one or two social flaws (DNT).
HTTP/2 and HTTP/3 offer better performance but that's it - and all servers will fall back to HTTP/1.1.
HTTP is maybe a bit gross and maybe a bit verbose: but it's extendible, and I'm perfectly satisfied with compiling such formats like Markdown to it.
CSS is hard to implement but endlessly expressive. And if you're going for "a team could implement in a year", doable.
JavaScript is a source of massive complexity, and indeed, not or hardly needed at all for most noncommercial websites.
I don't think there are enough file formats out there to need to worry about overimplementation. There's, what, jpg/png/svg/webp, gif/mp4/webm, txt/md/html?
The web is popular because of its interactivity and complexity, not in spite of it. Gemini is interesting in a hobby sense but offers very little in terms of practicality. I get it, you hate...
The web is popular because of its interactivity and complexity, not in spite of it. Gemini is interesting in a hobby sense but offers very little in terms of practicality. I get it, you hate JavaScript, HTML, and CSS. This isn't a step in the right direction and will always be incredibly niche.
I disagree. The massive uptake of the web predates webapps. Most of the reasons people use the internet today were happening without Javascript being required. There are very few things that exist...
I disagree. The massive uptake of the web predates webapps. Most of the reasons people use the internet today were happening without Javascript being required.
There are very few things that exist in a browser that didn't have (often better) dedicated apps.
Video? Easily replaced with a list of thumbnails that offloads the video streaming to a dedicated player. As was the case prior to integrating it with HTML5.
Music? Napster.
Chat? Skype, AIM, MSN.
Games? Downloaded binaries. Flash was a thing....but mostly because it was easier to bypass restrictions on locked down computers.
Google Docs, namely real-time collaboratice editing, was in fact a true gamechanger. But was one that probably would have still come about even without interactivity in the browser.
The fact that most users prefer native apps on their pocket computers speaks volumes to me about whether people really like browser apps or merely tolerate them.
I think your argument is working against your thesis. The fact that people preferred web apps (once they were capable) to desktop apps is proof that the web's popularity grew because of those...
I think your argument is working against your thesis. The fact that people preferred web apps (once they were capable) to desktop apps is proof that the web's popularity grew because of those interactions. Yes, the internet was gaining users, but it would've been a weird and quirky way to do your own thing rather than what it has become where the browser is basically an entire operating system that people don't leave.
The fact that people download phone apps instead of web apps has more to do with the initial immaturity of mobile browsers and the locked down nature that doesn't give them native access to phone hardware. That's changing over time, and I'm sure it'll happen where phone apps go the way of desktop apps. Some big ones will still be there, but most people will just use their browser. This already happens with tons of apps being wrapped HTML/JS that aren't visibly "web."
Flash took off not because it was a "workaround," but because it was easy to make games and the web was an easy distribution platform.
This is the real reason people gravitated to webapps. On a locked down system, like at work or school, it let people bypass restrictions so long as the web itself wasn't blocked. They were handy...
the locked down nature that doesn't give them native access to phone hardware.
This is the real reason people gravitated to webapps. On a locked down system, like at work or school, it let people bypass restrictions so long as the web itself wasn't blocked. They were handy when you were in an environment where you needed to hop between devices.
A lot of the reason for adoption of webapps was also due to the sorry state of package management outside the *NIXes. If Windows had a proper package manager the way RedHat does I doubt Java would have had half the uptake it did.
But now everyone has a cellphone. The number of people clamboring for a native Tildes app despite the website being fine speaks volumes. The people who complain about having an app for everything are such a tiny, tiny minority.
Every app that is in a browser would be 10x better as a native app. Compare Discord's official app to Swiftcord on Mac or Abbadon.
I don't use Outlook in the browser...I use Thunderbird. Email as a proper client/server means rich clients can be built independent of the provider... which is probably the real reason that everything walls off now.
If banks didn't have their own (web)apps, made easy with code in the browser, there would probably better API support, and then I could properly manage my finances and pay my bills with one program, of my choosing.
Gemini seems like a reaction to the incredible difficulty of building a web browser from scratch, but I think it goes too far towards minimalism. In particular, it's not difficult to find libraries that handle https, so the networking layer doesn't seem like the problem?
A less radical approach would be to just replace HTML with a different content type. Maybe it would be fun to build a browser that uses Markdown documents?
No, that's another thing entirely. Gemini is a response to the current state of the Web. If you look at the FAQ on that page you can see that it was made with the help of Gopher fans. The inspiration is pretty clear if you're familliar with Gopher, though personally speaking I have no clue why they really needed a new protocol.
They go into that on the site. Gopher does too little, just serving up menus. The current web stack does too much, serving up megabytes of resources just to load the app that loads the document. Gemini aims for the middle, serving up plain text documents in a format that's a bit similar to Markdown.
They also mention this in the FAQ item about their name:
A strongly expressed point of Gemini is to be deliberately not extendable, hence the hard break from HTTP / HTML / existing web standards, and to be deliberately impossible to build webapp-websites on top of.
I don't really think this is too valuable: the "early web" vibe that they're going for to me was all about creativity and presentation of content, not just the content itself. I also don't really buy into the whole "no embedded images will stop surveillance capitalism" schtick they've got going on, but I suppose it's worked thus far.
I'm also strictly in favor of no executable code. Javascript was mostly to cover for HTML's and CSS's deficiencies, and frankly has been a bit of a disaster ever since. I swear about 90% of security problems since 1995 boil down to 'Javascript is impossible to secure.' Who thought that letting every stranger run whatever code they want on your computer was gonna turn out fine?
Want to share a program on the web? Great, provide source code with compilation instructions.
Downloading and compiling arbitrary source code off the Internet is worse than running code in a sandbox written by paranoid software engineers. Yes, we do it, but we should be trying to get away from it, and it's a good thing only software developers do it routinely anymore.
Mobile OS's and web browsers and other sandboxes are steps in the right direction. I also like that Deno is sandboxed by default, but it's too easy to use 'deno run -A'.
You might not remember that for about the first 20ish years of its existence, Javascript was not heavily sandboxed. And then for the next 5 was not exactly well sandboxed.
And there's a world of difference between me needing to download 10-20 apps one time to do my work, and me needing to download code 100 times a day because I clicked a few links.
The web would be a far better place if no code ran in browsers.
Windows users regularly just download and run arbitrary binaries all the time. I'd argue thats far worse. At least source has the potential to be audited.
In the end, the scope of entities I need to have an app for is much, much, smaller than almost every web site. For me to run an app, there needs to be a genuine need, typically involving some sort of work relationship. Not because some random clickbait article's ad hijacked the browser with a 0day.
Yes, it certainly took many years of engineering effort, but as a result, the sandboxes are quite good. Many sophisticated attackers have found vulnerabilities and the bugs have been fixed. We probably haven't seen the end of them and that's why security updates are important. But this security will be better than your ability to audit source code. How could you possibly review every library in a medium-sized software utility's dependencies?
Nobody has time for that. We rely on reputation and hope, and often there's little rational basis for it; we don't even know the names of all the libraries we're using, let alone what their authors have changed recently. Protection against supply chain attacks is in its early stages.
Desktop OSes are architecturally pretty far behind mobile phone OS's and web browsers, but there is code signing and some sandboxing. When better security is important, I recommend a Chromebook.
Not just run code, but code with all sorts of horrible gotcha's. Base JS has got to be one of the easiest languages to cause major problem with that doesn't actually require you to manage memory.
It's gotten "better" by piling framework after framework on it, and is oddly one of the funniest ironies that JS has become the pinnacle of the coder nightmare. Namely "look we got it out quickly, but we'll fix it later, it certainly won't sit in production like this FOREVER"
How many JS vulnerabilities are there that are actively exploited? Honestly, most of them are zero days that are fixed way sooner than anyone would be able to take advantage of them, or they might even be just theoretical attacks - which doesn’t make them practical to exploit, though even those are getting fixed fast.
I would be honestly be surprised if web browsers would be a significant attack vector, it is definitely way down the list compared to social engineering and running random exes.
Well, JailBreakMe comes to mind.
Many Pwn2Own winners exploited browsers.
XSS is a major problem. Here's an example where it was used as part of an attack on Apache.
IMO it's the other way around: every native app should be downloadable+installable within literally a second or two, like a webpage is. If there's less code client side, then there's usually more code server side.
I agree that we should be able to both review and verify the code we install, but that's a solved problem (albeit not used) - just use checksums and AGPL.
This is a good thing. Servers can be trusted (and trust more easily revoked). Clients can not.
And when it comes to Javascript in particular, I can't think of any use case that couldn't be addressed with better HTML/CSS specs, or is better relagated to a non-browser application.
Only if you're running the server. If it's someone else's server, then more control client-side is better.
Howso? If you don't trust the server, how do you trust that the client they're handing you doesn't have a keylogger or cryptominer?
Theoretically you can inspect things client-side, but you would need to do that on every page load and would need to inspect all scripts fully to make sure that there's nothing that could load in additional code after the load. But unless you set up a system where your browser refuses to execute scripts that you haven't reviewed, there's really no difference.
And thats why I said at the top: No executable code in browser.
If its server-side code, it's not sending me exploits that are de-facto unauditable.
Plus, the whole reason adblockers were easily a thing is that when the entire site is passed in one go, it becomes trivially easy for the client to modify.
Yeah, they're both the same. You have to get your programs somewhere.
People will provide pre-compiled binaries because it's convenient. If you trust the source, why bother handling dependencies and compile errors? If this is something done frequently, for every service that wants an app, even today it only requires a single click to run on desktop platforms. And it's very easy to train users into making one click.
There's no real difference between a single trained, thoughtless click and truly automatic execution, except that the automatic execution is sandboxed and at least mostly prevented from doing real harm. People by and large don't audit their own source code, even when they're capable. And on Windows where autoupdaters are ubiquitous, even if you do check the source code, that binary can change at any moment. Nobody has the time to be reviewing the code for every app for every update. Whether it's downloaded and executed automatically or pseudoautomatically.
If you're talking about trust in the security sense, then sure. But in the context of "what if this company disappears and takes their software with them", then it's far better to have a local page cache or .exe than to rely on someone else's server, because then you can at least reverse-engineer the binary or bytecode.
I feel like "for the sake of security, just export the code you rely on to the vendor's server" echoes Linus Torvald's comment that the only secure computer is one that's had it's power cord/battery removed.
I am talking in the security sense, particularily in the sense of web browsing.
You get linked to a random blog? Wouldn't it be nice to know that random site you've never been to before can't execute code on your machine?
Disabling Javascript used to do this, but damn near everything is gated behind it now.
I find that Gemini makes a lot more sense when viewed through the lens of a specific, single design constraint:
There are clear reasons for this design goal¹ and almost everything that seems weird about the design of both the protocol and markup format suddenly makes sense with that context. But it does mean that, by design, the whole thing is permanently locked at the level of capability the designers baked in, which of course is not going to be exactly what nearly anyone wants, and will be seriously deficient in some way to a not insignificant number of people.
¹ It's pretty clear that the extensibility of HTML is how the Web went from "basically a quick hack on top of SGML" through "clunky but essentially functional hypertext document format" into "horrifying abomination of an online application platform". Browser vendors one-upped each other with additional features until Netscape added Javascript, and that was the beginning of the end of the Web as a reasonable platform.
Yes, I've read their design and know they have their reasons, but I think they're dooming Gemini to a small number of hobbyists.
Is it doom? Or is it knowing, targeting, and cultivating an intended audience? To me that's like saying Tildes' careful approach to its userbase and lack of image posts is dooming it. Or like saying uxn's weird approach is dooming it. Maybe they are, in a certain sense, but that's by design.
It’s a fair point. Maybe a better way to put it is that I can imagine a somewhat similar project that I’d be more interested in.
Eh, it's not that horrifying of an online application platform. I do find that it is both a website platform and an application platform a bit horrifying: but I do think that new web standards like WASM are massive strides forwards for something more aesthetic.
Like Akir mentioned, I think the identity of Gemini makes more sense in the context of Gopher (and also the world of pubnices, where people like to play not just with computers, but in the shell specifically). It seems that many people discover it in the context of the Web and expect it to be a better-but-simpler version of it; which apparently disappoints many. The fact that it is a protocol also leads some to expect something a little more technologically ambitious or innovative like IPFS or something. But as you said, it is very minimal. I understand why it seems too much so, but the intention is to make it easy and fun to hack around with. That's actually how I got into programming; writing random "SSGs" and bespoke clients! I think that is more the spirit of it rather than trying to ameliorate the Web experience. And now it has grown such that it is home to lots of little groups of enthusiasts, and people seem content to just have fun with it.
I feel like we need something in the middle. A web browser spec that a team could implement in a year, shaving down everything that isn't necessary anymore and limiting scope. So only flexbox layout, limited or no scripting, limited file-format support, no need for backwards compat, et cetera. Ideally something like HTMX syntax built-in.
I mean, the web functions by progressive enhancement: old sites will continue to work til kingdom come, and old browsers (although they will likely need to update their root certs) will continue to render and view websites, albeit worse as websites adopt new CSS standards and JavaScript APIs. I don't think cruft surrounding web specs is worth getting rid of at the expense of breaking backwards compatibility, and this shapes my dislike of Gemini.
I hold that HTML + CSS + HTTP 1.1 is a very reasonable spec for such a purpose.
Any Gemini fans: what are some interesting websites hosted on there?
The web is popular because of its interactivity and complexity, not in spite of it. Gemini is interesting in a hobby sense but offers very little in terms of practicality. I get it, you hate JavaScript, HTML, and CSS. This isn't a step in the right direction and will always be incredibly niche.
I disagree. The massive uptake of the web predates webapps. Most of the reasons people use the internet today were happening without Javascript being required.
There are very few things that exist in a browser that didn't have (often better) dedicated apps.
Video? Easily replaced with a list of thumbnails that offloads the video streaming to a dedicated player. As was the case prior to integrating it with HTML5.
Music? Napster.
Chat? Skype, AIM, MSN.
Games? Downloaded binaries. Flash was a thing....but mostly because it was easier to bypass restrictions on locked down computers.
Google Docs, namely real-time collaboratice editing, was in fact a true gamechanger. But was one that probably would have still come about even without interactivity in the browser.
The fact that most users prefer native apps on their pocket computers speaks volumes to me about whether people really like browser apps or merely tolerate them.
I think your argument is working against your thesis. The fact that people preferred web apps (once they were capable) to desktop apps is proof that the web's popularity grew because of those interactions. Yes, the internet was gaining users, but it would've been a weird and quirky way to do your own thing rather than what it has become where the browser is basically an entire operating system that people don't leave.
The fact that people download phone apps instead of web apps has more to do with the initial immaturity of mobile browsers and the locked down nature that doesn't give them native access to phone hardware. That's changing over time, and I'm sure it'll happen where phone apps go the way of desktop apps. Some big ones will still be there, but most people will just use their browser. This already happens with tons of apps being wrapped HTML/JS that aren't visibly "web."
Flash took off not because it was a "workaround," but because it was easy to make games and the web was an easy distribution platform.
This is the real reason people gravitated to webapps. On a locked down system, like at work or school, it let people bypass restrictions so long as the web itself wasn't blocked. They were handy when you were in an environment where you needed to hop between devices.
A lot of the reason for adoption of webapps was also due to the sorry state of package management outside the *NIXes. If Windows had a proper package manager the way RedHat does I doubt Java would have had half the uptake it did.
But now everyone has a cellphone. The number of people clamboring for a native Tildes app despite the website being fine speaks volumes. The people who complain about having an app for everything are such a tiny, tiny minority.
Every app that is in a browser would be 10x better as a native app. Compare Discord's official app to Swiftcord on Mac or Abbadon.
I don't use Outlook in the browser...I use Thunderbird. Email as a proper client/server means rich clients can be built independent of the provider... which is probably the real reason that everything walls off now.
If banks didn't have their own (web)apps, made easy with code in the browser, there would probably better API support, and then I could properly manage my finances and pay my bills with one program, of my choosing.
Flash was a thing because the world wide web is an amazing package manager, and Windows didn't have a package manager.