Recent searches
Search options
State of the Web, circa 2023:
“Would you like to use the browser by Company X, or the browser by the company that survives on half-a-billion dollars a year from Company X, or the browser by the company that gets paid an estimated $20 billion a year by Company X even though it can survive without it?”
We desperately need a web browser by an independent organisation funded by EU taxpayer money and maintained for the common good.
@aral The problem with the modern web is the utter complexity that causes hundreds of millions of dollars being spent on its development. We the community must ignore the "open web" specifications dictated by trillion-dollar corporations, and focus on a sane and stable subset that can be easily implemented by the community.
I had already suggested this very same proposal some time ago: https://xavi.privatedns.org/blog/small-web-browser/
@xavi92 I like this. My only addition would be that the browser manages “identities” for people so that Small Web places can communicate with each other via end-to-end encrypted messages.
Without controlling the browser that functionality requires JavaScript currently.
Otherwise, without JavaScript how do you propose ajax-style updates? With a declarative extension to HTML (eg., the functionality of htmx baked in, perhaps?)
…
@xavi92 … Although there are lots of tiny experience improvements that are currently only available via JS: eg., a chat window scrolling to the bottom when new messages are received, etc.
I guess you could similarly extend HTML to bake common behaviors in but I do feel having a client-side scripting language is a feature, not a bug. Especially since it can be used by the community to create the cow paths that get paved declaratively layer on.
So, yeah, I love the idea, though.
@aral OTOH I feel a lot can be already accomplished with HTML5 and CSS. Extensions are interesting, but I think compatibility with existing web browsers (i.e., small web sites are still accessible from common web browsers) is key for adoption. Otherwise, it might face a similar situation to Gemini, which made itself effectively incompatible with everything else, now becoming a niche protocol.
@xavi92 Thing is, unless we have identities (e.g. you have your own secret key that you can use to communicate with other Small Web places privately), we’re not solving the issue of privacy on the web. So if we want to attempt to solve that (which I do), we either need JavaScript (so secrets can be generated on the client) or extensions. I agree with you that compatibility with existing browsers is essential (or else, like you said, there’s Gemini) so I feel we need (a subset of, at least) JS.
@aral We can then look at this from a different perspective: instead of bundling a JavaScript interpreter into a small web browser, features such as identities could be implemented by the browsers themselves, natively. Then, servers can still serve JavaScript to common web browsers to maintain compatibility.
This would avoid the need for JavaScript on small web browsers, and it should considerably easier (and more secure) to implement such features individually than relying on JavaScript.