> 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.
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.
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was. I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost? I could, given time, recreate the entire platform I code on every day to be js-free but I'd be fired for pissing off clients. I could probably even reimplement our google map that you can draw a polygon on without JS but it would take a LOT more time and it would be so painful to use that it wouldn't matter.
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost?
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
It's simply not worth the resources
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
"Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.
Comments
What framework are you using that allows you to design interactive web apps without JS?
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).
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.
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.
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.
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
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was. I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost? I could, given time, recreate the entire platform I code on every day to be js-free but I'd be fired for pissing off clients. I could probably even reimplement our google map that you can draw a polygon on without JS but it would take a LOT more time and it would be so painful to use that it wouldn't matter.
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.