Browsers aren't stopping you or Wikipedia or Youtube from sticking to HTML and minimal CSS.
Your problem isn't with browsers, it's with Web developers who don't share your priorities.
You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site.
Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.
True, general web layout is a hard problem. But there are a lot of knobs to turn. What if we removed CSS layout altogether, and only allowed linear pages, a la reader mode? That's a big tradeoff, but maybe it would work. If that's too much, maybe only allowing flexbox would be enough. As for editing, at that point you're making a web app.
Are you getting rid of Web forms now? Also, remember that at the very beginning Berners-Lee's WorldWideWeb browser supported HTML editing, so it's definitely part of some vision of the "good old days".
Yes, if you cut down or eliminate CSS, or just redesign it, you could build a faster renderer.
But these questions point to one of major defects of the "cut-down Web" vision: lots of people have a limited set of Web features that they like, but they tend not to agree on what that set is. You like flexbox. Some people really like grid. Some people really need ruby, or floats, or columns, or editing, or vertical breaking (pagination). Pretty soon you've got something nearly as complicated as real CSS.
Democracy to the rescue:
1. Start a FLOSS mailing list thread to get as much input as possible on the best starting point for this reduced set of functionality. Gopher, resurrecting Xanadu, revisiting Hypercard, and so on. Let the conversation flow.
2. Invite the people who chose Firefox Reader View to private gitlab instance and get to work.
The browser you describe already exists, it's one with JS disabled, and you ignore the sites which don't work without it. This is how I browse every day.
I don't feel like I'm missing much.
I enable JS for reddit because I have to mod things, but I find myself visiting that site less and less now. HN works. Facebook works (good enough.) Gmail works. Google Search and DDG work. GitHub... meh.
I seriously hope this will never happen.
But the demand isn't that big, and the effort wouldn't have much return.
This is sort of like saying: Just because the computer doesn't have a password doesn't stop you from simply not using computers you're not supposed to. So your problem is not with the lack of passwords but with people who use computers they aren't supposed to.
You can get most of the security benefits by disabling JS in the browser.
Moving the software into the browser improved latency, but questions like "Is this webpage doing something dangerous/annoying?" became undecidable. If we provably cannot determine if a webpage will halt without running it, we obviously cannot as any more complicated questions about the webpage's behavior. As long as webpages have access to a Turing complete language, the browser will be de facto an OS. Unfortunately, returning to a web of documents isn't going to happen anytime soon; too many people profit from this ability to run programs on other people's computers.
(Gary Bernhardt's amazing (and terrifying) talk "The Birth & Death of JavaScript"[1] was absurdist comedy, not a guide to future browser designs)
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Yes, I've resigned myself to this truth long ago. Since then, I've been watching the web get smaller and smaller as more and more websites break unless they're allowed to run code client side.
I fully expect that the majority of the web will become inaccessible to me within my lifetime. Alas, the future does not always bring wonderful things!
I mean, behaviour of a website may be undecideable. Behaviour over the 5 minutes you're viewing it is. I dont think notions from computability theory are particularly enlightening here.
Eg. Node.js doesn't have WebUSB either :)
Well, I don't think that's how it should be, but that's certainly how it's turning out.
How it should be is that websites degrade gracefully, and remain usable (if more limited in terms of geewhizzery) without client-side scripting.
No, the ship has sailed. Just activate JavaScript and block ads/trackers.
It absolutely has. That's a fundamental design goal for HTML.
> For example a simple auto complete field that loads things from the database as you type. There is no way "graceful" way to implement this without JavaScript.
True, so if the user doesn't have JS enabled, you don't do that. Omitting that functionality doesn't remove the ability to make use of the website.
You're arguing that making proper websites is too expensive to justify. That's your call, of course, but that's a different argument than "it can't be done".
> Just activate JavaScript and block ads/trackers.
No, that's too risky. What I'll do instead is not use the website.
A simple browser that only implemented a subset of HTML and the good parts of CSS (ie flexbox) could be implemented easily by a small team.
Most things that look like conspiracies are in fact unplanned outcomes that result from an unintentional alignment of multiple perverse incentives. A different way of saying the same is that most things that appear to be conspiracies are actually "emergent" behaviors in complex systems.
A different example of something similar is real estate hyperinflation. I don't think somebody sat down and said "lets make housing impossible for any family making less than 5X the local median income to reasonably afford." What happened instead was that multiple decisions made for independent and unrelated reasons created an aligned set of perverse incentives that drove the price of housing nuts. There is no one cause or one responsible party.
And thats ok in my opinion. The IETF describes itself as "rough consensus and running code" and it seems to work well. I dont have a problem with the web following that model.
EDIT: But that can also be explained by incentives+emergent behavior. So at the end of the day, you're simply correct.
The difference is they have much more aggressive automatic upgrade processes than Flash or Java did, so bugs remain usable for way less time. And Chrome did sandboxing.
But Firefox doesn't/didn't. It got a free pass from the community because Mozilla is somehow seen as "not a corporation" and did a lot of drum beating about openess/webbyness/etc. So people gave it a break although the architecture wasn't really any different to something like Java applets and if anything was much worse.
Example: Table sorting. Hell, maybe table pagination, too.
This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript.
Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that.
Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources.
There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening.
I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".
You say that, and then you disprove your point by going on to list a bunch of extra features that that tag would have to have. And even with those features, major map sites wouldn't use it because they render map content client-side using vectors, not map tile images, and have lots of other features your tag wouldn't support.
Implementing your vision would mean a massive increase in the API surface of browsers, with concomitant increase in browser bloat, and browser and standards development effort ... while there's a strong argument that browsers are already too complicated.
Even so, when we've tried to implement declarative features on the Web we've seen over and over again that it's impossible to satisfy everyone's needs without scripting. (See e.g. HTML5 form validation, SVG vs canvas, VRML vs WebGL, ...) That is why stuff like the Extensible Web Manifesto emerged.
Feature interaction complexity between CSS features is a huge problem. Some of that could have been avoided if CSS had been designed differently, but some of it seems unavoidable (e.g. laying out text with mixed directions, mixed writing modes, ruby, font substitution, modern font features, etc etc --- at speed --- is just really complex).
Modern high-performance JS is really complicated to implement.
The plethora of APIs exposed to JS --- WebXYZ --- is incredibly complicated.
HTML is pretty complicated, e.g. HTML forms.
But if you take away JS, CSS/HTML don't get a whole lot easier, assuming you're still supporting interaction in some way. I mean, for your proposed map API, if the user can manipulate the functionality and you have lots of features that can be customized declaratively, it's not much more complicated to expose those controls to JS.
If you can simplify the problem so that CSS and HTML don't need to support incremental relayout/DOM changes, that would help a lot, but removing JS isn't enough for that. Things like zooming, window resizing, incremental loading, and any kind of editing put a lot of the same requirements on the engine.
Safari is still relevant due to iOS and iPad not macOS, and although I mostly use FF privatly, it is seldom a project acceptance requirement to also validate against it.
Ironically it were the IE haters that kind of helped this to happen.
I wish we separated the browser application from the VM application. ie, let us make simple, secure content with HTML and minimal CSS. For things like Wikipedia and even a lot of YouTube that's all you need. People can use an extremely simple (and private/secure!) program to access this kind of content. A text version of my personal site is browsable with cURL or even netcat[0].
Make the VM a separate program that people use for fancy web apps.
[0]: https://anderspitman.net/19/#netcatable