Some very early announcement of something very noteworthy that is happening on the Fediverse right this moment. Currently most of the discussion still takes place under the #weblite hashtag only.
As you know the current Web specifications have become very bloated. They serve established browser vendors, which operate monopolistically and dominate the (corporate) internet. For new FOSS browser projects it is nigh impossible to start from scratch and implement crisp and modern web rendering engines. The complexity and scope is just too high.
Existing standard bodies such as WhatWG, W3C and IETF move slowly and are beholden to Big Tech lobbying and influences, who want to keep this the status quo.
But there’s nothing that withholds the free software community to derive their own open standards that are lightweight and intuitive. So it happened, only yesterday 15 October, that some fedizens decided to pick up that glove.
Adrian Cochrane and Alexandra kicked off the Weblite initiative. Adrian has been working for a long time on two very cool greenfield browser projects, Odysseus and Rhapsode, an auditory browser. From this many insights on what #weblite specifications should and should not contain was gleaned and hopefully and with collaboration from many others this will be transcribed into Unicode chars in some initial drafts. So, if you are interested, then don’t hesitate and lend your helping hand.
You’ll notice that the linked repositories on Codeberg are still mostly emtpy as of now. Yep, it is indeed that early. On Fediverse you always learn the cool things first 😜
As posted by Adrian these are the principles of Weblite:
- Simplicity
- Vendor, platform, and device independence
- Forwards and backwards compatibility
- Maintainability
- Flexibility
- Richness
- Accessibility
Note too that with these principles Weblite is somewhhat different than what ProjectGemini aims to achieve. Gemini strips to absolute essentials and has more in common to Gopher, that came before the current web.
Join forces, Lemmy people! Let’s bring lite where now darkness rules… (Don’t forget to add a #weblite hashtags to your fedi toots)
This is a great intiative!
But it begs the questions
What’s the plan for this to not become just some niche solution? A browser made for HTMLite will not be compatible with most websites because it won’t run javascript, making the WorldWideWeb unusable for most (average) users.
Why would I build an HTMLite website if I have the option to do more things with HTML and give it some functionality with js? It’s not like size or bandwidth is a problem for most website providers, otherwise they’d already be making lighter websites.
Don’t get me wrong, I have a website with a very minimalist design and no JavaScript and I’d probably build an HTMLite compatible website but by trying to solve the browser problem you run into another one which is complex websites built around javascript and the convenience for most users.
This is just my quick 2 cents based on your question, so far from a definitive answer and certainly don’t consider it one.
So while you definitely have a point there are many webapps which have complicated functionality, let’s face it there are also substantial portions of the modern web which really only need something like Weblite to perform their primary task: basically all news sites, any form of articles, recipes, non/partially-interactive tutorials etc.
In order to perform their primary function, they don’t really need js at all. So then we get to the darker side of it, almost all of them use enormous amounts of js, not to perform their primary purpose but to basically snoop on their users. There’s a largish chunk of the modern web which doesn’t need js for anything other than doing nasty things!
Great observations. Especially the first one…
I think those browsers will be for a niche audience mostly, similar to how people are still using e.g. Lynx. They may offer some fallback to a ‘Reader-mode’-alike representation of richer sites, such as Firefox offers. Depending on how successful the initiative will be more ways will be shaped for new browser implementations to enter the market over time. With new basic engines, who knows, full-blown browser may evolve from that in the long run.
As for the second point. You may get an easier development experience, while the site you develop is accessible to the broadest possible audience. Size and bandwidth are getting to be more important from an energy usage perspective.
My personal view (not connected to the project) is that most of the functionality that JS provides that is in the interest of the user could be provided in a declarative manner (dynamic fetching / displaying of data, menus, tabs, etc) without the need for a scripting engine. Something akin to Phoenix’ Liveview or Laravel Livewire (those can do a lot of things without writing any custom javascript). If we could keep at least parts of those but drop all the malfeatures that JS is used for (scams, tracking, fingerprinting, pop-overs, modifying existing UI behaviour like scrollsbars, cryptominers, autoplaying music/videos, etc.) I think we could have majority of the good parts and minority of the bad. I’ll keep my eyes on the project :)
But don’t a lot of big companies make a lot of use of JS malfeatures such that this direction wouldn’t be able to gain mass adoption? (Though I wish it would)
They certainly do. That’s how they extract value from every visitor, by gathering information, showing targeted ads, gamifying the experience to try to hook the visitors. Therefore every attempt to give more power to the end users and diminish the power of the companies will be opposed by them. The only hope would be for the devs and end users to understand this problem and push the adoption at the grassroots level.
The other side of the answer for HTMLite (other specs we write might differ here) is that it explicitly aims to be a more legible alternative the WHATWG spec which better describes the HTML most web developers (like yourself) are writing and most browser engines are implementing. Except ofcourse for the popular few sites and browsers.
Which could be useful documentation today for those who care about e.g. Lynx users. Certainly allowing browsers to specialize to the commandline, voice, etc is a big motivator for me!