>> 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.

What framework are you using that allows you to design interactive web apps without JS?

>> 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"?

So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).

>> 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.

When I saw "C" I just meant "basic building block" of which rust is. JS is the only "language" of the web other than something like NPAPI which google is phasing out. Now there is P/NaCL but that's not widely used AFAIK or at least it's not used for building something like a web app, it's more for games. Pretty much: yes you can get by without C but it's because you can always fall back to assembly, the same is not true for the web.

----

Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS. This is what I'm advocating JS framework use for. As for a blog/news it's fine if they use a JS framework as long as they can fall back to a non-js page or render the js page on the server side (this only works for non-interactive sites).

Just to give you an idea of where I'm coming from, at my $dayJob I work on a large non-public web app that uses popups, sortable tables, live-updating tables of data, interactive google maps, interactive calendars, and more. For this it's simply not possible to not use JS (even though some people still pretend it is because "We didn't use JS from the start and it worked fine" ... no, it didn't. In fact we had to add JS because clients complained and they keep asking for higher and higher levels of interactivity with the web app which require more and more JS.