What en earth makes you think that? Yeah, the current way of doing SPAs without fallback for non-js clients is horrible and the alternative of a two-way site too much work.
But the solution is obvious: if what you serve is of any meaning to anyone else, you also have some sort of content consumption API. Sooner or later we'll standardize some RESTy way of doing it for apps, and for blogs and magazines RSS/Atom feeds are already good enough content-consumption pseudo-APIs.
The API will be the Javascript-less version of all sites, and all sites will have an API. Then people will make UIs for the content consumption parts of these (pseudo-)APIs, and these UIs, even if they run themselves in browsers will become the new "browsers" and gain their own scripting level features, while "old browser apps" will become today's equivalent of desktop apps.
It's not "death" of the web, just "endless, infinite pain" for us developers working in its perpetual shifting front-end... it's way worse than death! :)
Nobody used "semantic HTML" to do anything serious with cross-webpage interoperability (where nobody means less than 1% of web developers/pages). As for TBL's "semantic web" that was dead on arrival.
And that will be exactly what we end up getting back in the end; single page applications that treat a click as functionally equivalent to following a link.
> doing SPAs without fallback for non-js clients is horrible
Why? The number of customers that a) don't use javascript and b) would pay for a service only if they have a non-javascript version is incredibly small in my experience. If the service has value, non-javascript users will enable javascript to use it.
I'm ok with a SPA as long as long you also have an API. I'm also ok with a SPA as long as your app is just a content consumption app, e.g. you don't publish original content that is not accessible through other sources. But since even aggregating or re-mixing content or comments can actually be seen as creating "new content", the distinction is blurry.
My point is that we should be able to consume data on the web without having the full-browser+javascript to be the lowest level interface we have to this data.
And about the clients' interests: well, I think it is our duty as professionals to be able to see past our clients' interest too, to try and shape the future of the field we work in to the right shape, at least after we provide the clients with with good enough solutions (and yes, we should remember to stop at "good enough", because there's no point polishing a short-sighted solution, instead of working more to reshape it into a more future oriented one) and ensure short term profitability. Now, we don't all have a common notion of this "right shape" of the future of the web, but I do my best to shape it as much as I can towards "my kind of people's right shape" and push our vision up as many people's throats as we can, hopefully helping us all escape from this hell of short-sighted short-term clients' interests based decisions that brought us the current overcomplicated mess that the web is right now.
> I'm ok with a SPA as long as long you also have an API
That would be great, but I have no faith that the same developers who are today shirking responsibility for shipping their content as HTML with transcluded resources at stable URLs, will someday start shipping their content in a stable schema and API. They think nothing of turning their data and URLs upside down and changing their client to match, because they have a blind spot around the very idea that theirs is not the only client.
What en earth makes you think that? Yeah, the current way of doing SPAs without fallback for non-js clients is horrible and the alternative of a two-way site too much work.
But the solution is obvious: if what you serve is of any meaning to anyone else, you also have some sort of content consumption API. Sooner or later we'll standardize some RESTy way of doing it for apps, and for blogs and magazines RSS/Atom feeds are already good enough content-consumption pseudo-APIs.
The API will be the Javascript-less version of all sites, and all sites will have an API. Then people will make UIs for the content consumption parts of these (pseudo-)APIs, and these UIs, even if they run themselves in browsers will become the new "browsers" and gain their own scripting level features, while "old browser apps" will become today's equivalent of desktop apps.
It's not "death" of the web, just "endless, infinite pain" for us developers working in its perpetual shifting front-end... it's way worse than death! :)