The web started that way because static documents are relatively easy to represent, but the future (and present, for that matter) is rich experiences that can be distributed in the same way.
But there are many steps left to get there, so either buckle up and help build that future, or get used to an ever-shrinking ecosystem of the purely textual Web.
I'm personally very excited by the convergence of mobile and web development, PWAs, improved functionality for layouts, self-hosted app architectures (like Tent and Sandstorm, language-agnostic runtime via Web Assembly, better serving performance via HTTP/2, low level multimedia APIs, encapsulation of rich UX via Web Components, and so on and so on.
Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.
Why? Because language is a hell of an abstraction. More, it is approachable and can often be bounded. Consider, I am not even remotely skilled in art. However, I can adequately describe, for me, a picture by saying who is in it and the event. Try doing the same without language. Often "quaint and uninspiring textual" language.
Do I opine for the what we had in the 90s? Not necessarily. But I do grow weary of folks reinventing frameworks that merely further complicate the very abstractions that they created and now require these frameworks.
Could have said those same words literally a decade ago when we were all struggling to figure out all this Rails and MVC stuff and how automated ORMs worked above MySQL. Seven or eight paradigm shifts later, we're all still confused and I see no cohesive knitting.
You'll get over that optimism when 20 years passes and it's a worse mess than it is now; that's what going to happen.
The truth is that "rich experiences" are mostly made by enhancing the basic experience of reading rich documents. If you want an inspiring vision of a document-centered future, look at IndieWeb.org. And/or roca-style.org. It's a vision of how the web can be knit together into a cohesive whole based on URLs, rather than segmented into a bunch of unaddressable silos.
I'm not sure why you'd expect the web to be a. Mostly text and b. able to render easily on obsolete devices.
The web is becoming a robust application delivery platform. That is so, so awesome. Most people do not want to be stuck with shitty looking, text only websites. Moving the platform forwards necessitates that it will use more resources. Increased resources availability and consumption over time is fairly consistent across most aspects consumer computing.
If you can convey what your trying to convey with a JS-less (or even just JS-lite) 2-page website, then don't build a monolithic, scroll-hijacking, background-parallaxing fireworks show of a website, tied together with the most tenuous of Javascript libraries.
I'm all for the web as an application delivery platform, but not every website, or application, needs so much bulk.
Don't run two ad blockers, they will just use more resources for no benefit.
4.5 GHz 4670k, 16Gb of tight timings ram.
Worth remembering this is the case for people interested in tech. The local library still runs Vista on a 10yo system. My parents will use Android 2.x until the phone does not turn on anymore. Bandwidth updates don't apply to many people living outside of towns. Etc. It's been a long time since we've reached a point where an average person shouldn't need more bandwidth and power to look for information online.
And BTW, you can have beautiful text-only websites. These 2 properties are not related.
This was our mistake. I don't want garbage shoved in my face. I want to read. And that's it.
Bundling the entire website inside a single js file, that needs to be re-downloaded everytime you add a div or change a single css class is stupid, sorry.
Your website doesn't need to be pure text. It can be beautiful, modern and responsive. And it doesn't need much js for that.
The world has become mobile first, not js-centric. Pushing spa everywhere is just wrong.
Citing only one side of any architectural trade-offs isn't particularly interesting either. The other side is that we can now easily build sites using Universal JS (serverside-rendered combined with SPA).
Delivering a website with seemingly instantaneous repaints even on flaky internet connections is just a superior end-user experience.
Just click through the primary nav of a Universal JS site vs an old-school one, and it feels like we've been putting up with the equivalent of the old 300 ms tap delay, but for all websites and website links.
Not engineering away that latency penalty will tend towards foolish for website properties that want to remain competitive.
Users will become increasingly accustomed to very responsive sites and the latency penalty that is currently normalised will become more glaring and unacceptable.
SEO shouldn't be a problem, especially as the initial page is serverside rendered.
The only slight complexity is in returning sitemap.xml I believe, which requires a little bit more configuration currently. If you search the Github repo for 'SEO' you should find some tickets (open and / or closed) that discuss this.
Because business models are composed on the web, it's just harder to settle on unified design standards. It takes time for everyone to agree on a separation of responsibilities on the page. This is compounded by the sheer newness of the business models. My webcomic about fancy cheeses has a segment marketing a line of tractors now to industrial buyers at a conference in Wisconsin this week? OK. That's an opportunity I probably wouldn't have had selling Java apps.
meanwhile, I don't know how FB or Twitter are nice user experiences when you operate on a "paginate 20 tweets at a time" philosophy.
The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be a JS-app" thingie) have practically destroyed how most of the websites are displayed by the 2 devices I own. Sites like Hacker News or Wikipedia, which still work perfectly fine, are very far and few between. I sincerely deplore this.