~alcinnz/rhapsode

ref: d57e119d70319c7a6ae80b9d0f18cdb74dd26833 rhapsode/docs/Why?.md -rw-r--r-- 3.8 KiB
d57e119d — Adrian Cochrane Refactor to use GLib event-based input. 3 years ago

#Why am I creating Rhapsode?

I started creating my first browser because I wanted to explore new ways to (re)discover useful/interesting/entertaining/etc webpages without relying on central services. I am still actively exploring that, but in the process I got fed up with the state of browser engines and wanted to push The Web to be better!

#Privacy & Security

The world is waking up to the privacy problems of The Web, and mainstream browsers are tackling them in ways that are inherantly whack-a-mole. Because they cannot afford to break popular webpages, for which I cannot begrudge them.

I'd argue that the only true way a web browser can properly protect a user's privacy, especially in the age of Meltdown & Spectre, is by having websites describe their communication ends, rather than the means to achieve it. JavaScript, or any Turing Complete language, should be considered a threat and eventually deprecated from The Web standards!

Because even without escaping it's sandbox, it regularly does great harm to users' bandwidth, battery, and privacy.

#Accessibility & Coolness

The Web's foundations in "hypertext" has an incredible advantage that has by now been lost due to extensive use of JavaScript event handlers: it can work practically anywhere!

Text can be read through visuals, audio, or (e.g. Braille) touch. And any input device with at least two or three buttons (in some vague sense of the word) can select a link within that text to navigate to.

I'm exploring these possibilities not just because it lends some current hype to my cause, but also because e.g. blind people deserve to have a first-class Web experience like the rest of us. They shouldn't be an afterthought!

And if I can create them an interface that anyone enjoy would using, I'd think I had succeeded.

#Feature/Code Bloat

As Drew DeVault found, the combined word count of all 1,217 W3C specifications (which nominally defines The Web) at the time of his writing is greater than that of C11, C++17, UEFI, USB 3.2, and POSIX specifications, all 8,754 published RFCs, everything on Wikipedia's list of longest novels, and 6 copies of the Intel x86 manual combined!

Note: Not all of those specifications actually apply to browsers, but vice versa not all specifications that defines The Web Platform are created/published via The W3C. I'm not sure how quite much those numbers reflect reality, but I've seen their consequences.

The only people who can possibly implement enough of The Web to compete are those who already have, and even that's no guarantee. Furthermore these efforts, despite being open source, cannot be effectively audited nor (unless you're the size of Google) forked. I've tried auditting Apple's "WebKit"!

The Web cannot continue adding backwards JavaScript API after backwards API to better emulate native apps. For so much valuable writing to continue surviving we need to deprecate the vast majority of those W3C specifications, and let The Web feel comfortable in it's own skin.

For the reasons discussed above, deprecating JavaScript is a great starting point!

#The Web's Potential

As much as I complain about the state of The Web, the truth is I think there's a lot of beauty there. I like HTML & CSS as declarative programming languages, and I love the vast breadth of knowledge and entertainment published there!

If I didn't I wouldn't care so much about saving it.

#Bibliography