I don't know how you enforce it exactly, and maybe it's redundant with pastebin.
It still nags at me that sometimes I want to go to the web to just read a thing, measured in the tens of kilobytes, and all this other nonsense just gets in the way.
It's my kooky nostalgia probably. Old man yells at cloud. But other times, for fleeting moments, I think about applying for that TLD and feel just a bit like Ray Kinsella...
That would be great -- I'm imagining a whole TLD full of sites like http://text.npr.org and http://lite.cnn.io/en.
There's no reason I should be required to go through the "app" web (Flash, JS, Silverlight) to get something off the "document" web.
... and most use cases don't require an "app" web.
Or allows only the minimal subset required to implement AJAX type functionality.
The argument for expanding web standards has always been "if we don't, then they'll just appify it and we won't have any say" (see DRM debate).
An explicit decoupling of information from interactivity would lessen the pressure for that.
In my experience, of all the websites that don't work without JS, only a minority actually need it. Most of the time it's silly things like articles and blog posts that just show a blank screen without JS, or drop-down menus that rely on JS even though there are perfectly fine non-JS ways to do it, etc.
What does make sense to me is a new platform based on WASM, with related tooling. Photoshop in the browser or something running the Unreal Engine or .Net is not the web enough to maybe deserve its own thing. But a new platform based on what are essentially complaints about complexity or efficiency would be too messy.
Right now there's next to zero incentive not to use JavaScript. And only slightly more to engineer a working fallback page.
Bifurcating the web would provide one.
Or to put it another way, extrapolated down this path README.txt files on the web in the future will only be accessible with a pair of VR goggles.
The web as we know it is much better suited to applications, where websites have behavior as well as content. Whether the rendering is server-side like HN or client-side like Facebook is irrelevant.
I once had a site beg me to enable JS "for a better user experience", one which didn't need it to work. I did, and promptly turned it off again when I realised what the "better" actually meant (see above). Not going to fall for that one again...
Yet for some reason (hint: money) newspaper websites load megabytes worth of scripts to display kilobytes of text.
Just make a separate "document web", with a standard that isn't utterly lovecraftian and has all the functionality that current ostensibly "document-only" sites (i.e news, forums, etc) rely on JS for. Then, disguise it inside some hip web framework where the client end just acts as a viewer, client-side rendering to boot (with a fallback for users with JS disabled). Make sure an independent implementation can access the underlying "document" through the endpoints the clientside rendering uses. Now you're able to essentially fool people into supporting it.
Also, you could choose to represent your document sites as a pile of data and non-Turing-complete "scripts" that do the presentation, with state that can only change upon user interaction. That may seem like a really backwards way of doing it, but if done right, it would give you a really good bang for the buck in terms of functionality/UX vs implementation complexity.