> If you think that's an easy thing to do then you've either never done it or the web app your were working on didn't deserve to be called a web app.

I actually do this on a daily basis as my dayjob. If you're using a proper server-side framework, this is quite trivial.

Of course, I already expect you'll retort with some half-assed no-true-Scotsman ("well your web apps aren't real web apps!"), in which case I'd likely ask for your definition of "web app", why said definition is unattainable without creating some Javascript-only monstrosity, and why said monstrosity isn't implemented instead as a native application if it really does go beyond what a more sane use of HTML/CSS/JS/some-server-side-scripting can offer.

> if screen readers can't handle JS client-side rendering it's the readers then need to change not the web.

And how would you go about implementing that? A text-to-speech interface isn't like a visible webpage, where you can easily scroll around and jump from thing to thing and notice that some random DOM element has changed. Perhaps the screenreader could read newly-created DOM elements, but that'll become really annoying for elements that frequently change/disappear/reappear, as is often the case for web apps of the variety that you advocate.

This isn't to mention that not all screenreaders are auditory. Quite a few blind computer users use braille displays. How will your web app work with such displays? How will it work with a keyboard and no mouse (since what good is a mouse pointer if you can't see the pointer on the screen)? Or is your answer to just say "fuck them"?

> It would be like taking away C from your computer, the whole thing comes crashing down.

That's not quite true (and, in fact, is rather amusing in this day and age of C-ABI-compatible languages like Rust being the latest hot shit). Plenty of operating systems are written in languages other than C, and it's very much possible to have a computer without any C code at all. Hell, even with C, removing C won't do a whole lot; the computer is executing compiled machine code, not trying to run C directly.

---

In my opinion, rendering into the DOM exclusively is just as much an affront to the concept of a "semantic" web as using HTML tables for creating a page layout. Save the Javascript for things that actually need interaction; for everything else, plain HTML is not only sufficient, but even superior, since it's less likely to break on some confounding variable like whether I'm using Chrome or Firefox (or, god forbid, Internet Explorer) or whether I'm blind and my screen reader doesn't readily handle elements flying in and out of existence at arbitrary points in time.

That's the point of the "semantic" web, after all: HTML for content, CSS for presentation, Javascript for interaction. Just because breaking away from that is popular doesn't mean it's a smart thing to do.

This isn't to say that such behavior is always unacceptable, of course; there are web apps that do JS-only things rather well (Trello, for example). That tends to be the case when a JS-only approach is absolutely necessary. 99% of the time, however, HTML would be more than sufficient, with maybe some Javascript here and there to make things prettier. For the remaining 1%, a public API would do wonders for those seeking to build more accessible clients, in which case the web app being JS-only wouldn't be quite as much of a problem.

Of course, at least Trello has a warning in <noscript>...</noscript> tags telling users to enable Javascript. The bit of HTML my comment responded to didn't even have that courtesy.

Your viewpoint would be more acceptable if Javascript weren't the sluggish and fragile pile of shit it currently is and has been throughout the entirety of its existence. Until that core problem is fixed, the backlash will continue, and the fuck-you will be mutual.

---

EDIT: to further clarify my approach, I'd be totally fine with something like progressive enhancement [0], which is arguably much more robust than relying on JavaScript existing. Web apps do, after all, have a tendency to break rather horribly even between modern browsers, let alone slightly-outdated ones; having some defense against that is the responsible thing to do.

[0]: http://www.sitepoint.com/javascript-dependency-backlash-myth...