Marijke Luttekes: Why light-weight websites may one day save your life. “Sites should load on crappy internet connections and on older devices, and respect browser and system-wide accessibility settings, and several device input methods (mouse, keyboard, voice, among others). I do not see as much talk about website performance and size as I would.”
https://rbfirehose.com/2026/01/23/marijke-luttekes-why-light-weight-websites-may-one-day-save-your-life/#LightWeightWeb
@Viss @jplebreton agreed...
The amount of #Bloatware is just absurd these days.
- In fact, I hate #JavaScript because all it does in shove #Malware like #CryptoJacking, #Tracking and #AdblockerBlockers onto my devices and fucks with #accessibility by discriminating against my #browser choice!
What we need is a #LightWeightWeb that refuses all that #Bloat and #Junk.
- Something that delivers #accessible, #private and functional #Internet again, without "#AIslop", #ads and tracking.
Something like #FrogFind by @ActionRetro, but instead of a #WebProxy just good #Websites that provide said information without demanding literal megabytes in bloat!
@neil Have a wee look at my #LightWeightWeb proposal. If I can get even just a small working group around it, I think something useful can be built.
https://www.journeyman.cc/blog/posts-output/2025-02-24-light-weight-web/
@sheephorse @craignicol @mc so it may be that you could not buy things from Etsy or EBay or your favourite web store with a #LightWeightWeb browser because of this restriction, and that consequently you'd need to transfer to a full-fat browser to do so. I don't see that as a reason for relaxing this restriction, since switching to a full fat browser will remain possible -- but it is a conscious choice which the user has to make.
@craignicol My view is that the user's contract is with one host, and that any resource fetched from a different host is a violation of that contract; so separate host for (e.g.) API would be a violation.
I think that has to be so, because otherwise it would be easy to CNAME `api.my.domain` to (e.g.) `googleapis.com`, which would drive a coach and horses through tracking protection.
My apologies! The #LightWeightWeb proposal is here:
https://www.journeyman.cc/blog/posts-output/2025-02-24-light-weight-web/
I'd prefer replies to votes at this stage, but here's a poll:
I'm inclined to discard option ii because it would privilege the language(s) in which the set of names were written; I'm inclined to discard option iii because it privileges languages written in the Roman alphabet. I'm willing to listen to arguments about why I'm wrong.
I'm also willing to listen to alternative proposals, such as allowing additional cookies/larger storage for the duration of an active session.
/continued
In all cases the 'at most 30 days; still applies.
In all cases, names are stored within the 'total storage'; the actual value storage I intend is not more than 1024 bytes in any case.
/continued
Options:
i. one cookie, up to 256 bytes value;
ii. up to four cookies, names chosen from a small 'well known' set, up to 1072 bytes total storage;
iii. up to four cookies, names UTF8, up to twelve bytes, up to 1072 bytes total storage;
iv. up to four cookies, names UTF, up to eight characters, up to 1152 total storage but each name character counted as 32 bits;
/continued
People interested in the #LightWeightWeb proposal, I'm thinking about relaxing the cookie restrictions.
@aral @david_chisnall @emanuele @holdenweb @Khrys @sheephorse
/short thread, please repost
@sarahjamielewis It's yet another reason I should push ahead with the #LightWeightWeb proposal.
https://www.journeyman.cc/blog/posts-output/2025-02-24-light-weight-web/
@dan @aral OK, Dillo is not useful for the #LightWeightWeb proposal; it doesn't support client-side scripting.
Netsurf, now... 1.25 million lines of code (following the same slightly dodgy metric as I've used for the others) Builds cleanly from sources just by following the build instructions. CSS implementation seems fragile, JavaScript similarly.
As someone who did a lot of work on Acorn ARM machines, I appreciate the RISC OS support!
I've now added references to all these essays, and an acknowledgement of @holdenweb's comment regarding root servers, to the #LightWeightWeb essay at
https://www.journeyman.cc/blog/posts-output/2025-02-24-light-weight-web/
Reading around, thinking about my #LightWeightWeb proposal, I found this wonderful essay by @johnallsopp, which I greatly commend to your worships. It provides a rich, well referenced introduction to other essays about how we recover a non-corporate (or less-corporate) web:
(h/t @egeth for the link)
@holdenweb @aral @Khrys @david_chisnall excellent question!
Particularly in times when jurisdictions which we have unthinkingly assumed would continue to be reliably sane may suddenly not be.
@david_chisnall has also challenged my 64 bit restriction, with solid argument. It should certainly be possible to store a session id which would be impractically hard to spoof, and I'll listen to advice on how large that needs to be.
@david_chisnall Thinking about this further, would you think that allowing the user to lift this restriction **for specific, trusted, sites** ameliorate your concerns?
Frankly I would prefer that a user who wanted to use offline apps should do so in a separate, full fat, browser than loosen the restrictions of the #LightWeightWeb browser, but I'm open to being persuaded on this.
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst