3 ms·
Seems easy to define such a fork: disable JavaScript, and load all resources immediately and unconditionally to disable tracking based on what is visible. To p
by devit 6y ago
Seems easy to define such a fork: disable JavaScript, and load all resources immediately and unconditionally to disable tracking based on what is visible.
To prevent custom UI, also disable CSS and use a decent default stylesheet (e.g. the reader mode one or a Markdown one).
- badsectoracula 6y agoYes, the post says exactly that - forking the HTML is easy, the hard part is convincing developers to use that fork instead of the more featureful "mainstream" version. Consider that these are the same devs complaining about the feature differences between Chrome and Firefox, let alone the vast majority of developers would consider targeting something like Internet Explorer 11 (which already contains A TON of functionality, WAY more than you'd need for a "trimmed down fork" and is still a VERY complex project if you wanted to make a full clone from scratch, despite it being a few years out of date) as something they'd do only in their worst nightmares. This is why such propositions are hard. Well, that and all the existing web sites that use the existing tech, most of them not being made by huge corporations with big pockets and often are left alone to work with barely any modifications (web development is often made fun of for being too brittle, but this brittleness exists at the framework level, not the web browser level that has very strong backward compatibility).
- tobr 6y agoYou don’t need to convince existing developers to adopt it. Remember the early web spirit, where people imagined that everyone would run their own server and publish their own homepage? Turns out it was way too complicated to do, and required you to be a tech enthusiast. Largely, I would say, because HTML was not designed to accommodate for a lot of the things people immediately wanted to do. Even a basic thing like keeping navigation consistent across the multiple pages is impossible. I think if you designed a document language that took advantage of 30 years of experience of what people actually want to do on the web, you could find an entirely new set of users. People who want to feel ownership of what they publish, want to be able to be creative and improvise, but don’t have the technical skills to create a site in the current web stack. It would probably look more like a social media service, so it could run on top of the web as it is now, or have dedicated native clients.
- badsectoracula 6y agoHonestly, this 'entirely new set of users' sounds like wishful thinking for a problem that does not exist as you describe it. Back in the early web people couldn't run their own server not because HTML was hard (WYSIWYG editors not only existed since the Windows 3.1 days, but they were very widespread at the time - Netscape Gold even came with one included and that could do pretty much everything you'd see in most pages) but because it was hard to have and maintain the necessary hardware and internet connection. This still exists and is still an issue today if you want the full ownership down to running your own server. But if you do not care about running your own server and you are fine with shared hosting (which existed even in the 90s, see geocities) or a VPS, then outside of a basic setup you do not need to be much of a technical user (and many hosting and VPS providers have tools to do that setup for you, often for free). For the slightly more technical users, there are tools like Publii (stupid name, but the tool works) that can do mostly full WYSIWYG site editing, management, syncing, etc. And a dedicated native client? From a user's perspective there is nothing to win here, they already have a browser (and the less technical users are confused by even that), why would they run another browser that wont even work with the majority of the content they want to access? Really, these are not practical solutions for practical problems. That doesn't mean you shouldn't try to make something like this, but they'll just be toys for fun, not real solutions to real problems and if you expect them to be anything like that you'd be disappointed. After all Gopher, for example, exists and can be targeted and used, but all of its users are using it for fun and because they can, not because they expect it to compete with the web (well, outside of edgy "the web sux, gopher is the future" comments that are at the same level as "M$ suxx0rz, linux rulez" you'd see not so long ago).
- tobr 6y agoI think we are imagining very different things! For what I tried to describe, I think a dedicated native mobile client would be the most natural way to use it. I don’t think it’s a strange idea at all - consider how popular dedicated apps like Instagram, TikTok, YouTube, Facebook etc are. It’s not confusing or a burden in any way. Publii or anything you could one-click-install on a web host is nowhere near fully featured for what people actually want to do on the web. Again, look at the type of activity that happen on most social networks - liking, sharing, commenting, replying, bookmarking, retweeting, remixing, curating playlists and galleries, etc. Those communal space-building activities have become as foundational concepts for the internet as linking, but are exceptionally difficult to implement on the current web.
- tannhaeuser 6y agoA browser doesn't have to win a beauty contest in front of developers; that would be futile anyway, given how inherently generational web development is. It only needs to win over users (let's call them readers, because that's what a browser is for in the end).