The problem with targeting a subset is there's a ratchet effect with web APIs, once support reaches critical mass in the major browsers sites will start unconditionally relying on those features and there's no going back from there, any new browser has to also support those features or be considered broken.

I suppose anything that's gated behind a permission prompt in Chrome/Firefox/Safari could be culled without too much trouble at least.

This is so wildly wrong it hurts. As soon as that one important website (to your user) breaks, they will switch browsers.

Just deciding that you don't want to implement >50% of web specs "for simplicity" and expecting that to be a winning strategy is very HN.

I think this is a great point. The majority of my browsing uses text oriented sites (some think they are more, but I read them in reader mode). As I user, I rarely want more. I'd use a slim, secure browser if I could.

Sometimes I play games, or use "web apps" and using a different tool in those instances would be fine. Back in the early 2000s I remember using Firefox with an "open in IE" extension that allowed me to primarily use FF and fall back to IE when sites were broken. As websites modernized I used the extension less and less.

Also consider desktop apps that use election. Bundling a simpler browser and building the app to the capabilities of that browser could greatly reduce install size and memory usage.

Given that a browser is not practically a virtual machine and/or an OS, it is not too surprising that an OS developer is not scared by the task. At the same time, it seems to me that multimedia is a whole different beast.

> For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis

IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).

I really don't want to drop the all too common negative comment - in particular since I already use an alternative web browser - but the initial investment required just for an MVP seems mind-boggling to me.

I think a basic HTML browser that can automatically delegate all it cannot handle to other apps - PDF viewing to a PDF viewer, video playback to a video player, and JS-requiring things to a big browser - would be interesting (if it already exists, please let me know).

If it only does 70% of what a regular browser does would anyone (seriously not as an experiment) use it on a daily basis? Most people just want to get on the web and go. They don’t care how big their is on disk or how much ram it uses (within reason of course), but the first time it doesn’t render their bank page or Jira page, they will drop it. Obviously I’m not talking about beta testers here or curious web devs.

The conversation regarding restrictions on the feature set within the browser always focuses on the browser itself, but there is definitely an opportunity to rally website makers. If Google or Apple came out and said we have a reduced feature set you can use that makes our browser render your website faster it would be a good opportunity, and I think many website makers would jump at the opportunity. A sort of Google AMP, but good! Let's call it Strict HTML.

> Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas

Alternative idea: go the other extreme and stop pretending modern browsers are anything else than virtual machines. Turn browsers into sandboxed VMs that only run Wasm, with backwards compatibility ensured by shared wasm libraries that render HTML and run JS.

This is what Sciter, Lexbor or litehtml are aiming for.