The Weblite project

The Weblite project (name preliminary, suggestions appreciated) is a family of specifications for a lighter-weight Web without JavaScript and other embedded executable code and focused on being simple enough to implement relatively easily, but still mostly compatible with existing simple sites.

Why?

The current modern Web, as implemented by Web browsers like Google Chrome and Mozilla Firefox, is extremely complicated, to the point that it requires the resources of a multi-national corporation to effectively develop and maintain an independent Web browser. Most Web browsers like Vivaldi and Brave are based on Chrome, relying on its existing support and continuing development to actually make Web sites work in them. We think it should be possible for one or two people to write a usable Web browser in a few months. We think Web sites shouldn't be able to run up your electrical bill running complex code, or track everything you hover your mouse on; JavaScript makes both of these things possible, and is responsible for most of the complexity of modern browsers.

Weblite takes a different approach: We recommend that "user agents" (the software that acts as your "agent" on the Web, such as a browser, a virtual assistant, or a search engine) don't support JavaScript, instead sticking to a simplified version of the HTML standard. This still makes it possible to publish sites with rich multimedia content, links, and everything the Web ought to be without allowing sites to load you down with complicated and slow tracking and dynamic ads.

What about Gemini?

Gemini is another effort to build something lighter than the Web, and one we like a lot; in fact, we're probably going to recommend that Web user agents support the Gemini protocol! Gemini's gemtext format is extremely simple and incredibly easy to work with, but in our opinion it's often better to have something more sophisticated that can include multimedia, some styling like emphasis, more detailed metadata like marking the main content of a page so search engines can index it and not the comments section, and some interactivity like forms to send feedback or sign up for something.

How do I get involved?

The Git source control repositories meant to hold draft Weblite specifications are part of the Weblite Codeberg organization. Currently, there are repositories for shared common work, HTMLite, our simplified version of HTML, XMLite, our simplified version of the XML meta-language, which is meant to underlie HTMLite, CSSLite, our simplified version of the optional CSS style-sheet language, and the Fetch recommendations for how user agents should get pages and other resources from the Web.

This Web page is also kept in a Codeberg repository, so if you'd like to improve it, go right ahead!

If you have a Codeberg account, you can jump right in and open an issue on whichever repository seems most appropriate. We're currently looking for people to take lead of CSSLite and Fetch, so open an issue on those repositories if you're interested in getting them started. If you have some contributions to the specifications themselves, feel free to fork the repository and open a pull request.

If you don't have a Codeberg account, we're planning to support contributions by email as well, but it may be easier for you to create an account. There's lots of other projects on Codeberg, so hopefully it won't be a waste!

The main hubs for conversation are currently the #Weblite tag on the Fediverse (Mastodon, Pleroma, Misskey, and others) and the ##weblite channel on Libera Chat. We'd like to set up a more permanent place for conversation, but this is what we've got for the moment.

What are you currently planning to do?

  1. Solidify leadership for the project as a whole and each of the "phase 1" specifications: XMLite, HTMLite, CSSLite, and Fetch.
  2. Establish a process for non-Codeberg contributors.
  3. Set up some kind of project communication, whether chat or email. Preferably using an open protocol (so not Discord).
  4. Nail down outlines for each phase 1 specification.
  5. Draft the phase 1 specifications and go through a review period to address any problems.
  6. Release "revision 1" versions of phase 1!
  7. Make a plan for what belongs in "phase 2", possibly including standardizing HTMX or other options for replacing JavaScript as the tool for dynamic Web content.
  8. On from there.