I know this is a vanishingly unpopular opinion these days, but personally I think that if your content can only be rendered by a user-agent with full JavaScript support, your content isn't a fully formed citizen of the Web.
Your content can't be archived properly by the Internet Archive.
Your content can't be accessed by anything user-agent less sophisticated than a full-blown browser.
Your content can't be indexed by a search engine that doesn't have the resources to crawl using full headless browsers.
Your content won't work with tools that attempt to scrape and expand content (think URL expansion on Slack, Twitter, Facebook etc).
(There's a very high chance that your content sucks in widely used screen readers as well)
HTML for content, CSS for presentation, JavaScript for behavior enhancement. Not everything has to be built like Trello.
This whole debate comes down to knowing whether you're building a content-focused site or a behavior-focused application. If you're building something like the New York Times or Wikipedia, then you are building a content-focused site, and you definitely shouldn't require javascript to render that content, for all the reasons you list (and probably more). If you're building something like (to use your example) Trello or (to use the author's) Basecamp, then you are building a behavior-focused application, and you can choose your approach based on other trade-offs, some of which are discussed in the article.
It definitely gets interesting in the middle. Something like Discourse is a content-focused site with a lot of app-like behavior, so they've built it as an app, but made sure to enable server-side rendering. Tons of things fall into this gray zone. I tend to think that "Universal JavaScript" would be a really good default go-to, and I'm hoping the tooling for it will continue to improve to the point that it's a no-brainer.
JavaScript became the browser language because it was originally intended to do so much less than it did. If the intention had been, from the beginning, to do, in the browser, all we are now doing with JavaScript, a much different language would have been used. And now people learn JavaScript as a first language and use it extensively server-side...
It definitely is a super interesting progression. It's fairly pointless to theorize about counterfactuals, but I'm of the belief that if somebody had attempted to design a system with the intention, from the beginning, to do, in the browser, all we are now doing with JavaScript, that the result would have likely been an over-engineered failure, solving the wrong problems in the wrong ways. I think the utter failure of applets written in Java (a "proper" language) gives some credence to that hypothesis.
It's an interesting full circle, in some ways, as JavaScript was originally envisaged as "LiveScript" to run server side systems and quickly finished/renamed in a rush to capitalize on a quick need for browser capabilities.
LiveScript was always a client-side language – Brendan Eich was hired to do “Scheme in the browser“, and it was called Mocha. They renamed it to LiveScript during the Netscape Navigator 2 beta cycle and, shortly later, to JavaScript as Sun's Java campaign started to get traction. At the time, the argument was that most of your app would run Java on your burly servers and the lighter-weight JavaScript in the browser for things like form validation.
Netscape's server product did add server-side JS but that was released later and neither their webserver in general or server-side JS were anywhere near as influential as the browser. Think about how many years it took JavaScript to become usable for apps even now and try to imagine what it was like back in 1996.
Haha not to be confused with the later LiveScript made in 2011. And the JavaScript Wikipedia page also mentions two different languages named C-- (and I heard a bad joke today "what was this programmed in? C--?" that apparently was ignorant of either).
if your content can only be rendered by a user-agent with full JavaScript support, your content isn't a fully formed citizen of the Web.
I actually agree, in a sense, but without the pejorativeness that I infer from your comment. The web apps that are reasonable to build in Angular/React/etc. without server-side rendering support are not traditional hypertext documents that would be archived by IA, indexed by a search engine, or viewed from Lynx. These are things like GMail or complex interactive dashboards (e.g. CRMs). In that sense they're not "fully formed citizens of the Web," if you believe that only traditional hypertext documents satisfy that requirement.
There are types of web sites that are a hybrid of the two, like a NYT or Medium article that is mostly text but also contains some interactive data visualizations. Those interactive components can reasonable be built in React or similar, and I don't see that as a problem, since you inherently need JavaScript to use those anyway, plus search engines will have no trouble indexing the text on the page.
At the end of the day though, tooling ought to be good enough to allow server-side rendering for UAs without JavaScript support.
By "vanishgly unpopular", you mean "always upvoted to the top of hackernews"?
The internet archive seems to do fine with JavaScript. As does most search engines.
Also, I know a blind person who tells me the best browser to use is.. safari on Mac. Full blown JS, everything works great.
At this point, javascript is a full part of the web. Making good quality, disable and accessible pages is hard enough, without having to effectively do it twice (with and without JavaScript), for an increasingly small set of use cases.
I'm not exactly trying to attain the platonic ideal of a web page, here. My goal is to build something that people find valuable, quickly. I don't care if it requires js to render, because it's not worth the tradeoff to try to get it to show up for that one guy trying to render a web page on his TRS-80.
Your content can't be archived properly by the Internet Archive.
IA doesn't factor into 99.999% of what I build.
Your content can't be accessed by anything user-agent less sophisticated than a full-blown browser.
I build things for browsers.
Your content can't be indexed by a search engine that doesn't have the resources to crawl using full headless browsers.
I can barely be arsed to submit sitemaps to Bing.
Your content won't work with tools that attempt to scrape and expand content
When supporting those things becomes a priority, I'll do so.
----
RMS looks at a microwave and writes an essay about whether or not the software that drives it needs to be FOSS.
Great, so your advice is if I can use a device that is a few years old, I just have to buy the latest version of $BRANDED_PRODUCT. Developers can actively support or resist this wasteful practice. It seems pretty clear where you stand on this.
I have no idea what you're trying to say. I'm not offering advice, I'm saying I build applications to be useful, not to conform to a set of abstract ideals. If 1% of visitors can't use it, I need to weigh the value of serving those 1% vs the value of spending my time building features.
I'm not Google or Facebook. My team at work is me and two co-ops. I'm not going to triple our development time just so I can get some Internet back pats from purists.
This is a valid argument for also providing a useable non-script version of your side, i.e. doing graceful degradation. I absolutely agree that this is still an important thing to do in 2016.
However, I don't see how this is an argument for building only pure-HTML pages. Why can't I use scripting with client-side templates, so I get an its advantages for clients that support it and use a server-rendered version (ideally using the same templates) for clients that don't?
If anything I would see this as an argument for client-side templates, at least if you still want to use scripts for certain parts of your site. Because the other alternative - generating snippets of html on the server, then monkey-patching them into the current page via script - seems like the worst of both worlds to me.
It's less development work to do progressive enhancement than it is to do graceful degradation[0], because you don't duplicate effort. And IMO, the outcome is usually better, as well.
So you're countering one extreme position with another? The truth is that not every web app is meant to be a "fully formed citizen of the web". Users want their LOB app to be slick and responsive, and the time you spend making it accessible to a text-based browser is time you're not spending on features your customers actually want.
The relevant question is: Why do user agents without JavaScript support still exist?
I don't care what kind of agents they are - bots from some sucky search engine like yandex, outdated screen readers or lynx installed on some freaky geeky nerd's Pentium 3.
Everything must be ES5-compliant these days. Period.
If my website cannot be archived by the Internet Archive (like anyone gave them a permission to do so, anyway), it's entirely their fault, not mine. And if I want to present my info to some link scrapers or aggregators, I'd rather generate an RSS feed. Or it would be much better if some JSON-based feed standard already existed for this purpose.
JavaScript doesn't just serve behaviour enhancement any more. It is a full-blown platform for the modern Web citizens.
Also, some browsers like Dillo or w3m do not support Javascript at all. I used to to use Dillo a lot on my old desktop computer (which only had 1 GB of RAM), because it could have 30-40 tabs open and still remain below 100MB of RAM. These days, more and more often, all Dillo or w3m will show me is a blank page.
I completely agree with these points when you're writing hypertext.
But much of the web has gone beyond hypertext. Many sites are now using the web as device-independent application environment, that executes without having to install a runtime (Java, Flash) or runs in a proprietary ecosystem (iOS, Android).
Since you mentioned it in your post. What benefit is there to Slack if the internet archive can load the chat page? Is there any value to Google to indexing the slack app? There's nothing of value there to anything other than logged in users so why would they build for anything with the access level similar to an unregistered user?
On the other end, their home page should be accessible and some I can't check right now, I can only guess that it is.
I make sure all of my personal web projects are usable and visually appealing in Lynx. While I doubt many people are using the text-only browser these days, this approach does go quite a ways in making your site accessible to all.
Comments
I know this is a vanishingly unpopular opinion these days, but personally I think that if your content can only be rendered by a user-agent with full JavaScript support, your content isn't a fully formed citizen of the Web.
Your content can't be archived properly by the Internet Archive.
Your content can't be accessed by anything user-agent less sophisticated than a full-blown browser.
Your content can't be indexed by a search engine that doesn't have the resources to crawl using full headless browsers.
Your content won't work with tools that attempt to scrape and expand content (think URL expansion on Slack, Twitter, Facebook etc).
(There's a very high chance that your content sucks in widely used screen readers as well)
HTML for content, CSS for presentation, JavaScript for behavior enhancement. Not everything has to be built like Trello.
This whole debate comes down to knowing whether you're building a content-focused site or a behavior-focused application. If you're building something like the New York Times or Wikipedia, then you are building a content-focused site, and you definitely shouldn't require javascript to render that content, for all the reasons you list (and probably more). If you're building something like (to use your example) Trello or (to use the author's) Basecamp, then you are building a behavior-focused application, and you can choose your approach based on other trade-offs, some of which are discussed in the article.
It definitely gets interesting in the middle. Something like Discourse is a content-focused site with a lot of app-like behavior, so they've built it as an app, but made sure to enable server-side rendering. Tons of things fall into this gray zone. I tend to think that "Universal JavaScript" would be a really good default go-to, and I'm hoping the tooling for it will continue to improve to the point that it's a no-brainer.
JavaScript became the browser language because it was originally intended to do so much less than it did. If the intention had been, from the beginning, to do, in the browser, all we are now doing with JavaScript, a much different language would have been used. And now people learn JavaScript as a first language and use it extensively server-side...
Such a bizarre progression to me.
It definitely is a super interesting progression. It's fairly pointless to theorize about counterfactuals, but I'm of the belief that if somebody had attempted to design a system with the intention, from the beginning, to do, in the browser, all we are now doing with JavaScript, that the result would have likely been an over-engineered failure, solving the wrong problems in the wrong ways. I think the utter failure of applets written in Java (a "proper" language) gives some credence to that hypothesis.
It's an interesting full circle, in some ways, as JavaScript was originally envisaged as "LiveScript" to run server side systems and quickly finished/renamed in a rush to capitalize on a quick need for browser capabilities.
LiveScript was always a client-side language – Brendan Eich was hired to do “Scheme in the browser“, and it was called Mocha. They renamed it to LiveScript during the Netscape Navigator 2 beta cycle and, shortly later, to JavaScript as Sun's Java campaign started to get traction. At the time, the argument was that most of your app would run Java on your burly servers and the lighter-weight JavaScript in the browser for things like form validation.
Netscape's server product did add server-side JS but that was released later and neither their webserver in general or server-side JS were anywhere near as influential as the browser. Think about how many years it took JavaScript to become usable for apps even now and try to imagine what it was like back in 1996.
Sources:
https://brendaneich.com/2008/04/popularity/
https://www.computer.org/csdl/mags/co/2012/02/mco2012020007....
https://www.w3.org/community/webed/wiki/A_Short_History_of_J...
Haha not to be confused with the later LiveScript made in 2011. And the JavaScript Wikipedia page also mentions two different languages named C-- (and I heard a bad joke today "what was this programmed in? C--?" that apparently was ignorant of either).
I actually agree, in a sense, but without the pejorativeness that I infer from your comment. The web apps that are reasonable to build in Angular/React/etc. without server-side rendering support are not traditional hypertext documents that would be archived by IA, indexed by a search engine, or viewed from Lynx. These are things like GMail or complex interactive dashboards (e.g. CRMs). In that sense they're not "fully formed citizens of the Web," if you believe that only traditional hypertext documents satisfy that requirement.
There are types of web sites that are a hybrid of the two, like a NYT or Medium article that is mostly text but also contains some interactive data visualizations. Those interactive components can reasonable be built in React or similar, and I don't see that as a problem, since you inherently need JavaScript to use those anyway, plus search engines will have no trouble indexing the text on the page.
At the end of the day though, tooling ought to be good enough to allow server-side rendering for UAs without JavaScript support.
By "vanishgly unpopular", you mean "always upvoted to the top of hackernews"?
The internet archive seems to do fine with JavaScript. As does most search engines.
Also, I know a blind person who tells me the best browser to use is.. safari on Mac. Full blown JS, everything works great.
At this point, javascript is a full part of the web. Making good quality, disable and accessible pages is hard enough, without having to effectively do it twice (with and without JavaScript), for an increasingly small set of use cases.
I'm not exactly trying to attain the platonic ideal of a web page, here. My goal is to build something that people find valuable, quickly. I don't care if it requires js to render, because it's not worth the tradeoff to try to get it to show up for that one guy trying to render a web page on his TRS-80.
IA doesn't factor into 99.999% of what I build.
I build things for browsers.
I can barely be arsed to submit sitemaps to Bing.
When supporting those things becomes a priority, I'll do so.
----
RMS looks at a microwave and writes an essay about whether or not the software that drives it needs to be FOSS.
I make my food hot.
Great, so your advice is if I can use a device that is a few years old, I just have to buy the latest version of $BRANDED_PRODUCT. Developers can actively support or resist this wasteful practice. It seems pretty clear where you stand on this.
I have no idea what you're trying to say. I'm not offering advice, I'm saying I build applications to be useful, not to conform to a set of abstract ideals. If 1% of visitors can't use it, I need to weigh the value of serving those 1% vs the value of spending my time building features.
I'm not Google or Facebook. My team at work is me and two co-ops. I'm not going to triple our development time just so I can get some Internet back pats from purists.
So true and yet so sad.
This is a valid argument for also providing a useable non-script version of your side, i.e. doing graceful degradation. I absolutely agree that this is still an important thing to do in 2016.
However, I don't see how this is an argument for building only pure-HTML pages. Why can't I use scripting with client-side templates, so I get an its advantages for clients that support it and use a server-rendered version (ideally using the same templates) for clients that don't?
If anything I would see this as an argument for client-side templates, at least if you still want to use scripts for certain parts of your site. Because the other alternative - generating snippets of html on the server, then monkey-patching them into the current page via script - seems like the worst of both worlds to me.
It's less development work to do progressive enhancement than it is to do graceful degradation[0], because you don't duplicate effort. And IMO, the outcome is usually better, as well.
[0]: https://www.w3.org/wiki/Graceful_degradation_versus_progress...
So you're countering one extreme position with another? The truth is that not every web app is meant to be a "fully formed citizen of the web". Users want their LOB app to be slick and responsive, and the time you spend making it accessible to a text-based browser is time you're not spending on features your customers actually want.
The relevant question is: Why do user agents without JavaScript support still exist?
I don't care what kind of agents they are - bots from some sucky search engine like yandex, outdated screen readers or lynx installed on some freaky geeky nerd's Pentium 3.
Everything must be ES5-compliant these days. Period.
If my website cannot be archived by the Internet Archive (like anyone gave them a permission to do so, anyway), it's entirely their fault, not mine. And if I want to present my info to some link scrapers or aggregators, I'd rather generate an RSS feed. Or it would be much better if some JSON-based feed standard already existed for this purpose.
JavaScript doesn't just serve behaviour enhancement any more. It is a full-blown platform for the modern Web citizens.
Also, some browsers like Dillo or w3m do not support Javascript at all. I used to to use Dillo a lot on my old desktop computer (which only had 1 GB of RAM), because it could have 30-40 tabs open and still remain below 100MB of RAM. These days, more and more often, all Dillo or w3m will show me is a blank page.
Hello from Firefox 44 (sic!) running on an old laptop which only has 1 GB of RAM. Probably eats more than 100 MB but still doesn't slow down anything.
Two days ago I killed a Firefox 44 instance that bloated to 3 gigs.
WebGL?
I completely agree with these points when you're writing hypertext.
But much of the web has gone beyond hypertext. Many sites are now using the web as device-independent application environment, that executes without having to install a runtime (Java, Flash) or runs in a proprietary ecosystem (iOS, Android).
Since you mentioned it in your post. What benefit is there to Slack if the internet archive can load the chat page? Is there any value to Google to indexing the slack app? There's nothing of value there to anything other than logged in users so why would they build for anything with the access level similar to an unregistered user?
On the other end, their home page should be accessible and some I can't check right now, I can only guess that it is.
I make sure all of my personal web projects are usable and visually appealing in Lynx. While I doubt many people are using the text-only browser these days, this approach does go quite a ways in making your site accessible to all.