Modern web browsers are massively complex beasts, implementing an evergrowing mountain of supposedly-open standards few can keep up with. So why do I think I can do better whilst adhering to the same standards? Why do I think that's valuable?
XML, XHTML, & HTTP are all very trivial to parse, with numerous parsers implemented in just about every programming language. HTML wouldn't be much worse if it weren't for WHATWG's error recovery specification most webdevs don't seem to take advantage of anyways. CSS should be optional for web browsers to support, and most of the complexity there is better considered an inherent part of rendering international, resizable, formatted text. Even if your OS is hiding this complexity from applications.
If it's not there, where is the complexity? Richtext layout in arbitrarily-sized windows is one answer, which I think is disrespectful to want to do away with. But unlike what some browser devs suggest it isn't the full answer.
Expecting JavaScript to be fast yet secure so you can reshape a beautiful document publishing system into the application distribution platform you're upset your proprietary OS doesn't deliver is a massive source of (intellectually-stimulating) complexity. The 1990's-era over-engineered object-oriented representation of parsed HTML which leaves nobody (including JavaScript optimizers) happy is almost 200,000 lines of code in WebKit, which CSS barely cares about. The videoconferencing backend they embed for Google Hangouts takes almost as much code as the rest of the browser!
I can back up these claims both qualitatively & quantitatively.
So yes, dropping JavaScript support makes a huge difference! Not worrying about parsing long-invalid HTML correctly makes a difference, not that we shouldn't recover from errors. Even moving webforms out-of-line from their embedding webpages to simplify the user interaction, to the point they can be accessed via the unusual human input devices that interests me, makes a difference. Whilst stopping webdevs from complaining about OS-native controls clashing with their designs.
There's lots and lots of feature bloat we can remove from web browsers before we jump ship to something new.
To many the web is now just a handful of Silicon Valley giants, surrounded by newssites, etc begging you to accept numerous popups before you can start reading. It's no wonder they want to burn it to the ground!
But beneath all the skyscrapers and commercialization there's already a vast beautiful underbelly of knowledge and entertainment. Writing that deserves that deserves to be preserved. Pages that, for the most part, works perfectly fine in Rhapsode as validated by manual testing.
It is for this "longtail" I develop Rhapsode. I couldn't care less that I broke the "fat head".
A common argument in favour of jumping ship to, say, Gemini (not that I dislike Gemini) is that on the existing web readers are bound to frequently encounter links to, say, JavaScript-reliant sites. I think such arguments underestimate how few sites are actually broken in browsers like Rhapsode, Lynx, & Dillo. This damage is easily repairable with a little automation, which has already been done via content mirrors like Nitter & Invidious.
Rhapsode supports URL redirection/blocking extensions for this very reason, and I hope that it's novelty leads people to forgive any other brokenness they encounter. Rightfully blaming the website instead.
To be clear, I do not wish to demean anyone for using JavaScript. There are valid use cases you can't yet achieve any other way, some of which has enhanced the document web and we should find alternative more declarative ways to preserve. I always like a good visualization! And there is a need for interactive apps to let people do more with computers than read what others have written.
What I want long term is for JavaScript to leave the document web. For the browsers' feature set (like payments & videocalls) to be split between more apps. If this means websites & webapps split into their own separate platforms, I'll be happy. Though personally I'd prefer to oneclick-install beautiful consistently-designed apps from the elementary AppCenter! And I want it to be reasonable to audit any software running on my computer.
In part my complaint with JavaScript is that it's where most of the web's recent feature bloat has been landing. But I do think it was a mistake to allow websites to run arbitrary computation on the client. Sure that computation is "sandboxed" but that sandbox isn't as secure (eBay's been able to determine which ports you have open [citation needed]) as we thought especially given hardware vulnerabilities, it's restrictions are loosening, & there's plenty of antifeatures you can add well within it's bounds. JavaScript degrades my experience on the web far more often than it enhances it.
I want standards that give implementers UI leeway. JavaScript is not that!
Even if I did implement JavaScript in Rhapsode all that would accomplish is raise expectations impossibly high, practically none of those JavaScript-reliant websites (where they don't block me outright) will deliver a decent auditory UX. JavaScript isn't necessary for delivering a great auditory UX, only for repairing the damage from focusing exclusively on sighted readers.
Webdevs harm the readability of their websites via CSS frequently enough that most browsers offer a button to replace those stylesheets. So why do I want to let them continue?
I don't. I want a working CSS engine for my own sake in designing Rhapsode's auditory experience, and to allow readers to repair broken websites in a familiar language. I think I can expose it to webdevs whilst minimizing the damage they can do, by e.g. not supporting overlays & enforcing minimum text contrast in visual browsers. For Rhapsode I prevent websites from overriding the "dading" used to indicate links you can repeat back for it to follow.
Regardless I believe CSS should be optional. Web browsers shouldn't have to implement CSS. Websites shouldn't have to provide CSS for their pages to be legible on modern monitors. And users must be able to switch stylesheets if the current one doesn't work for them.