> What framework are you using that allows you to design interactive web apps without JS?
This is a Rails consultancy, so... Rails. We use Foundation for most things view-side (which, admittedly, involves some Javascript, but only for certain parts; said parts aren't used very often), but pretty much all the heavy lifting is done controller-side. We do like using AJAX here and there, mind you, but only when actually necessary.
Sure, it ain't Trello with its drag-and-drop doodads and such, but we've built plenty of rather excellent web apps without such gizmos. That degree of interactivity isn't strictly necessary, and - in fact - can often be a distraction.
For my personal projects, I've mostly been using Elixir lately (with the Sugar framework), and Pure instead of Foundation for CSS-related things.
> 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).
Not as well as you'd think.
Screenreaders do read the DOM rather than directly from HTML documents, so a JS-only site that's otherwise static wouldn't have very many problems in all likelihood. The problems arise when the DOM is manipulated; screenreaders (including Aria) have tended to have rather pessimal behavior when encountering things like JQuery popups (for example), whether that means failing to read the popup entirely, reading only part of it, reading only an "OK" button, reading it but then reading everything after it even if said everything has already been read, etc. I mentioned these things in another comment on this thread [0].
This isn't to mention that JS-only apps tend to be very mouse and touch heavy. This is a non-starter for most blind users, who AFAIK tend to be very keyboard-centric.
> Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS.
Maybe not exactly, but all its functionality is arguably possible without any Javascript whatsoever.
Let's start with moving cards between lists. Currently, one has to drag-and-drop. There's little reason why that can't instead be implemented as left/right arrow buttons on each card, each resulting in a POST to the server telling it to move the card with the specified ID to the next list in whichever direction. The server then updates the card on its end and sends back the updated HTML.
Then, there's the reordering of cards. Again, totally possible; just put up/down arrow buttons on each card. Same deal as before; server performs the reorder and sends back the result.
For adding cards to lists (and adding new lists to boards), there are already links present to do those things; making them do the same thing as above (leave all the processing to the server, which then sends back the updated HTML) would work quite alright.
You then have the side menu. The pop-out would indeed be impossible without Javascript, but its functionality wouldn't; the "Add Members..." button could point to a separate member add page (or be replaced with the current result of clicking that button, which is simply a text box prompting for an email address to search for), while the member list and the activity feed can easily be rendered server-side.
Same story for the individual list menus; the pop-out requires Javascript, but the rest is trivial to render server-side as part of the list's div.
Then we have the card screen, which can easily be its own page. Like above, pretty much everything here can be done without Javascript with very little workflow difference - comments, labels, checklists, attachments, you name it. All the buttons you see on the right of the card window in current Trello can easily direct to screens for creating each thing.
Now, perhaps the above hypothetical no-JS Trello isn't as "interactive" as you'd like, but it would already be far more accessible, relying less on DOM updates and drag-and-drop operations while being much friendlier to keyboard users and - in all likelihood - performing just as well if not better (even with page loads factored in). And, of course, this would be a perfect candidate for progressive enhancement, layering Javascript on top of the HTML-only layer in order to add the more "interactive" things like drag-and-drop and popout menus and working as a "single-page" app.
[0]: https://news.ycombinator.com/item?id=9815655