My question is then: where's the hackabale power user browser implemented in something like Common Lisp with a REPL, hot swap debugging, and built in disassembly tools?
And this is also why (disingenuous as they often are), some of the "web is too complicated" arguments can't be completely dismissed, because it is true that building a secure browser that's safe to use is a gargantuan task.
And this is also why it stinks that the Servo team got gutted, because Servo was shaping up to be an interesting new low-level embedded engine in that space.
Both sides are true. I understand completely why Mozilla went the route they did, and I agree with their decision to do so, and I also sympathize completely with the people who want to be able to live-hack on their browser in their browser. I want the ability to do that too.
But I think the only way to solve that is to have more browser diversity... somehow. I also don't want Firefox to be unusable for nontechnical users. I need a secure, reasonably private browser that's not based on Chrome that I can recommend to nontechnical friends and family.
Apple works around that by not really trying to keep up. It implements features in its own time (or else some third party contributes code to WebKit). But iOS gives Apple a captive audience which means it has much more freedom to be "slow" compared to Google. As much as I might philosophically dislike their policy of only allowing their own web engine on iOS, it is the only thing keeping WebKit alive as a major alternative.
My sister uses Firefox just fine, she doesn't know how to mess with addons.
That's an entirely separate conversation.
My opinion is that it ends up being simpler and safer at the end of the day to just wrap the entire Firefox application in an Emacs buffer and then intercept keypresses to that buffer. But you do lose out on a lot of stuff by doing that; I'd love to have tighter integration.
eww doesn't work very well yet. Try it for fun only. And it's slow. Pretty certain it does cookies but not js.
I think there's an emacs web browser which delegates the actual mechanics to something external, and only acts as a front end for display/interaction. Never tried it.
In the latter EAF isn't a web browser despite what it says. Have a look at the others. Piggyback browsers aren't going to be sophisticated, that's just how it is.
I don't think switching from C++ to Lisp would work out so well.
I'm willing to accept a Fortran implementation via FFI for the truly performance sensitive bits though. /s