That might be true. But my point was that instead of coming up with a restricted technology we can simply make our web pages less sh****y and bloated. That’s a different kind of a simple protocol
Right, nowadays it isn’t the browser that you have to change but the device.
If sites that have been designed for PC have difficulties to render well on a mobile, the opposite is often just a complete disaster. Some are trying to optimize for both and are choosing worst of both worlds, I can’t even find a name for that. I can’t wait for sites designed for cars, refrigerators or watches. ![]()
That brings back memories of the good old internet days.
When smartphones were still new and not that common,sites often had a separate version for phones,often on another subdomain (m.domain.tld) that was specifically optimized for phones,and the desktop version was unchanged.
That was a pretty good solution actually,as it allowed optimizing for both worlds.
Then came the trend for “responsive design” so that you only have to design one site that works everywhere,but now you have big touch elements also on the desktop.
I miss the good old webdesign trends.
The small links,the multi-column layouts that put much stuff in sidebars,the early-2000-aesthetics.
There are still some very cool sites (Have a look at https://ytoo.org) but the majority is awful and soulless now,most stuff looks the same,and optimized for phones with desktops being a second-class citizen.
I think it was the WAP technology. I really don’t understand why a new protocol is invented (be it WAP or Gemini) when you can simply have a little restriction on multimedia, CSS, Javascript and such and come to the same result. Imagine how many different and cool browsers (that already exist) can be used if you simply make your website less “flashy”.
Long ago, I saw someone suggest that phone manufacturers could have simply adopted Gopher instead of inventing WAP. Talk about roads not taken! There were also special browsers like Opera Mini, that took a regular website and scrunched it down into a reflowed, simplified version. Google also had a proxy that did something similar. It worked even on very limited feature phones. That’s the power of the web. Part of why it was designed the way it was. But the Not Invented Here syndrome is too strong.
That said, WAP tools are still available in Debian, and the format has some interesting traits. For one, you don’t make individual pages, but entire minisites in one file that can be as small as a few kilobytes. It’s very similar to the web template I made before the holidays, and could still be useful for microcontrollers or other embedded systems.
No,I wasn’t talking about WAP but separate sites using regular web technologies (HTML+CSS+JS) with a simplified layout for phones which often only had the most important features of the website and a lot less bloat,so that it hopefully runs somewhat acceptable on the underpowered hardware (most times it didn’t).
I was talking about early Android phones,those already had a WebKit-based browser.
It wasn’t always nice to use,but at least the Desktop version of the site hadn’t become a touchy nightmare to please smartphones.
WAP technology and Opera Mini are also interesting ideas to make the web less bloated.
WAP had only what’s really required to read content,no heavy JS content.
Sure,you can also design a website so that it’s lightweight,but having a separate protocol that only supports a small subset of the features allows you to develop a special browser for that protocol that can be a lot more lightweight.
Thinking of the specs of the phones back then,I assume a fully-featured WAP browser can be implemented with only a few KB of code.
Modern web browsers are often bigger than the whole operating system,and I don’t like that.
Opera Mini is a very clever solution to bloat: It moves all the heavy rendering work to a server and delivers only a compressed version of the result to the client using a custom heavily-optimized binary format.
Unfortunately it’s completely closed-source.
Having something like that as a open-source solution you can self-host on a vServer and access using a lightweight open-source client (that can probably easily implemented as Haiku-native app,easier than a full browser) would be really nice.
Sure,you can’t use it for all use-cases of a modern webbrowser,but it’s good enough to read some newspages without letting their JS bloat slow down your whole computer.
That actually sounds a bit like frogfind, have you ever used that?
I found it some time ago and gave it a quick test,but never used it to actually get stuff done.
It absolutely goes into the right direction,but it’s maybe a bit too much.
I don’t mind having images and maybe a basic page layout,think of the web around 2000 up to maximum 2010.
On the news page I read most,it removes the whole comment section (that shows fine in Opera Mini,for example).
But Frogfind used in Netsurf browser can really make the internet usable on retro hardware,that’s a good step in the right direction ![]()
You just need a subset of the existing protocol, not an entirely new protocol. In fact, disabling javascript would get you most of the way, and the rest you can get by going to html4 and period-matching css.
However, it also depends what you want to optimize. Javascript used wisely would need a bit more cpu and ram, but could drastically cut down on network usage. Which is, actually, how we ended up where we are: after the late 2000s, we started having quite powerful CPUs in mobile devices (palm/pocketpc and then later mobile phones), but with a network that didn’t quite match. So running apps on the device or loading a bit of javascript to do processing locally was a good idea and made sense.
Now we are in another situation, but what we get today is built on these technologies, and more powerful hardware. The result is that economically, it is not worth spending developers time on optimizing for cpu use or bandwidth (especially if younr competition also doesn’t care). Frustrating for users, maybe, but since the web is funded by advertising and not by people paying subsriptions, that won’t help.
I think that was my point earlier: the issue is not technical, and these problems will not be solved by using another protocol. They can however be solved for specific websites and apps by using the existing protocols more carefully, and NetSurf is a good example of that.
Disabling Javascript makes the web more lightweigt,but not lightweight enough to quickly build a browser from scratch that displays content just fine.
CSS is also continously growing,always adding more random features that probably less than 1% of websites need,but they need to be implemented in browsers.
I really like Netsurf,but it often has rendering issues that are not related to the lack of Javascript.
Same for other small browsers.
Hell,even QtWebKit,that is a major engine,but a bit outdated,has a hard time rendering a lot of content.
I think that shouldn’t be the case.
I think we remember the late 2000s quite differently,because CPU and RAM was much more the bottleneck for me than the network speed.
My first Android tablet had something like 256 or 512MB RAM,2GB internal storage and I think the 32bit ARM cpu was dual-core.
Add to that that Adblockers on Android weren’t really a thing back then.
Websites with too much bloat (too many ads mostly) would either crash the page,or even crash the whole browser,or just hang like forever.
Loading a mostly text-focused site fresh at each navigation step was never a issue (had Wifi with 6Mbit/s DSL back then),but loading megabytes of JS stuff and executing that was.
What I absolutely agree with is the fact that the big companies don’t care and won’t optimize for faster load times.
Users are addicted to their bullshit,so they live with the load times.
Many are frustrated,but they still use it and make the companies money.
That’s part of why I think a fresh start on a different protocol that isn’t focused on making money but small users sharing information,building personal sites and being creative would be a good idea to break free from bad habits.
You can’t adapt only the browser of course. You also have to adapt the website you’re visiting.
You are still missing my point.
You can’t fix this with protocols. You can’t fix this with software, even. You have to fix how people design websites. And that’s not a technical issue.
Sure, you can try to build an isolated island like Gemini, but if you don’t change the environment, I don’t think this has any chance of having major success. It will be something people play with for a while, and then move on.
Sure, but by adding Gemini we just have one more way to distribute and render content. So in the end it just made things more complex overall.
Unless you decide to ignore all of the existing web. But I don’t think that is realistic, and even if Gemini was very succesful, there are a lot of things that Gemini simply can’t do (by design). So the web will still be around.
I was talking more about Palm organizers and maybe Symbian phones. In this case it was no connectivity at all, or maybe a very slow and expensive 2G connection. Sure, the CPU and RAM weren’t huge, but downloading even a few hundred kilobytes would be unbearably slow, if possible at all. On the Palm it was daily sync with a PC through a serial port. A very different way to conside things indeed.
Android reached me a bit later, in the 2010s already. And I didn’t get an Android device for myself until much later (although I did some Android and iPhone development at the time).
I know you weren’t talking about WAP. The point is maybe learning from the past. Not to try and revive proprietary tech, but to figure out what we’ve lost. When Lynx in Termux lets you read a site that crashes your native Android browser, the web has a problem, and it’s not one of technology.
You’re right that this can’t be fixed with protocols and software alone.
I just think that the current form of the web is so broken that it can’t be fixed at all,instead I suggest starting over with a new protocol,new software that limits the possibilities of what you can do,and new websites that are well made.
A isolated island is exactly the solution I propose (and what we have with Gemini).
The big majority isn’t going to leave the awfully bloated platforms that treat them like products,we can’t change that,but we can have that little space isolated from the usual web where we’re safe.
I spent the whole day researching (more or less) usable alternatives for the usual web.
The WAP/WML technology is very interesting actually,what a shame that it’s basically dead nowadays.
WML is similar to HTML and with WMLScript there’s even a Javascript alternative,but it’s a lot more limited in functionality.
You can make creative unique sites with it,but not bloated monsters such as webapps.
I’m surprised that there appears to be no other replacement of the HTML+CSS+JS combination.
I found quite a few projects that tried replacing the HTTP protocol with custom protocol implementations (P2P,distributed and such stuff) but they all still need a normal browser for their content,no custom viewer application.
Yes, but we can have our own thing without enforcing a new protocol. Why a new, isolated island? We won’t force simplicity on the majority this way, no matter how hard we try.
We can’t and I think we shouldn’t force anything on users and people browsing the web.
I make websites that are simple and work in light browsers like NetSurf. People can visit and enjoy them, or go elsewhere. They don’t need special software, but they can use NetSurf or Lynx if they want to. If more people do that, eventually people will complain about bloated browsers that serve no purpose anymore.
Because it’s actually quite good. Even in the 1990s when CPU speed was counted in 10s of MHz, and RAM in 10s of MB, people were browsing the web with that tech stack, and it worked fine on these machines. The reason this doesn’t work today isn’t HTML, CSS or even Javascript. So why would you replace those?
If we keep talking down to them in a moralizing way, no, they won’t. If we keep asking them to give up their entire tech stack and everything they already know, of course they’ll think it’s too much trouble… and they’ll be absolutely right! We’ve been through this already with Linux, and clearly we haven’t learned a thing. This is up there with the recent topic about the importance of porting non-native apps to Haiku.
Luckily with the web people don’t have to suffer any such wrenching change because we already have the miracle transitional tech: it’s called a text-based browser, and already works with a surprising number of existing websites, instead of throwing out the baby with the bathwater. We only have to step back for a moment and remember why we write software, instead of rushing to make yet another shiny toy because we can.
I’m often suprised when I hear how bloated new css is. Most “new” features are stuff I rely on every day. The web would be unusable for me without a dark mode for example. Gemini leaves this all in the domain of the UA, but that doesn’t help much if the Ua decides to recoler each website in unreadable color schemes… ![]()
In fairness, the new features being added in CSS are mostly allowing for making more kinds of websites without JS at all.
On the one hand, this shifts the complexity towards CSS engines (and web browsers in turn). On the other hand, it also means faster, leaner, and less fragile websites with minimal feature tradeoffs. I for one, welcome lessening reliance on whatever The Trendy JS Framework of Today is.
I can’t speak for everyone else, but I personally like Gemini since it represented a departure from the “big web”. Sometimes you just want access to information, quickly and directly.
LaGrange is pretty, and accomplishes this in a “retro future” kind of way. No local javascript, no tracking, no cookies, tls everywhere.
However, Gemdoc is difficult to convert sites to.. it offers some cool ideas, but i personally feel choosing Markdown (maybe an extended version of the spec) over gemdoc would have given gemini more legs.
My ex- was a web designer and we had quite a “holy war” going about why I thought web technology was no longer necessary with the advent of WASI standards within WebAssembly. She thought that the web browser was complex, but not needlessly so.
Ironically, just before we divorced, I suggested that something like ChromeOS but better, that would route the redundant OS functionality through the browser instead of the other way around would be acceptable. It would be a solution that is almost as elegant and efficient and less obtrusive than trying to eliminate the worst of the duplication within Internet standardization, while making the whole system lighter and streamlined in the process.
As an Aside
My relationship with Teresa was basically ruined by the fact that we were spouses. We honestly should have been quirky coworkers that played pranks on each other, argued about our favorite programming languages and then went home to significant others (other than EACH-OTHER) when the workday ended.