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