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 really important issue
This could be an historical moment. I love this project, it’s very important IMHO.
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!
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!
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.
-
I didn’t actually know this was an issue. Thanks for bringing it to my attention.
XMLite first draft
Alex Martin submitted the first draft of the XMLite spec on Codeberg. Check it out and give your feedback in the issue tracker.
This is awesome. Good luck to #weblite @alcinnz@floss.social @alexandra@mk.nixnet.social
HTMLite first draft
Adrian Cochrane submitted a first draft of HTMLite specification on Codeberg. Check it out and give your feedback in the issue tracker.
Weblite naming brainstorm
The name ‘Weblite’ is not yet final. There may be clashes and trademark issues. Before the name becomes too widespread, and a change leads to confusion we want to brainstorm cool alternatives. And you can help with that, by adding to the following issue on Codeberg:
I don’t have a codeberg account but how about OpWeb. Stands for Open Web but could also use the gaming term to get Overpowered Web. The Document Web and DocWeb are also cool.
I can add it to the issue, if you want. But to me the term also has negative connotation with eg. “Operative Web” as in “BlackOps” where we are secretly surveilled. It sounds foreboding, and not ‘refreshing’ and streamlined as ‘lite’ in weblite conveys, imho.
Hm, that’s true, I didn’t think of that, that still sounds kinda cool if I’m being honest. Would appreciate it if you could add it to the suggestions thread either way.
I don’t have a codeberg account but how about OpWeb. Stands for Open Web but could also use the gaming term to get Overpowered Web. The Document Web and DocWeb are also cool.
Consider it Done! 🤗
deleted by creator
Are you sure that this is by Adrian? I don’t see that in Contributors list (or do you mean another project?): https://github.com/sveltejs/kit/graphs/contributors
If his name isn’t there, then I made a mistake. Thanks for pointing that out:)
I’m curious where do you see the ballast to drop? Javasript?
Yes, dropping JavaScript made a massive difference to the spec! Which is appropriate to drop anyways because all other browser engines than the big 3 (Gecko/Firefox, WebKit/Safari, and Blink/Chrome) barely support it if at all.
As a carry-on from dropping JavaScript, HTMLite no longer needs to describe how to handle edge cases when altering the DOM. Or even how to expose the DOM to any scripts!
The other main thing is WHATWG’s error recovery algorithm. That gets better support, but in my view isn’t fully used enough to be worth implementing.
HTMLite specifically discourages use of <div>, <span>, and image maps to better cater towards non-visual browsers.
Beyond that, to allow for specialization, HTMLite is currently very lenient towards how webpages are rendered: no element, attribute, or even CSS is described as being required.
I’m no expert, but I guess that will be a big part of it. Browser implementers will be most aware of gains to be made, as rendering enginges are humongous beasts with millions of lines of code to them. A ton of API’s, edge cases and being forgiving to formatting mistakes, etc. Browsers have become like OS’es. I dunno if Adrian is on Lemmy, but he can probably explain best.
