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.
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.
Such a bizarre progression to me.
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.
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.
>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.
I make my food hot.
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.
[0]: https://www.w3.org/wiki/Graceful_degradation_versus_progress...
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.
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).
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.
> Notably, neither of these pages has any external resources. I wanted to control for that variable and understand the best you could do theoretically with either approach.
That's not the theoretical best in any way. The theoretical best is script tag pointing to a popular CDN, which has been loaded by this or another site before and is already in browser memory when you open this page. Then your page can be basic template+data with no code inlined.
In reality you're likely to have the templates already cached from previous requests and the templates rendering framework available from a CDN. What you end up transferring to the user is actually the data + tiny part of the script that gets rendering started.
I've used both approaches over the years and they both seemed to work pretty well. The only differentiator I really noticed was that the single-page-app style (client) seemed to be more elegant on mobile, while the server rendering was easier to split into tabs on desktop browser.
I'm really a tab fanatic so have disliked the last few years of javascript everything on the client, where middle click stops working. Are there any solutions for that, that I've missed?
Of course, some links don't actually represent navigation, so for them this isn't really applicable (e.g. a button to collapse an accordion-style view).
I don't understand why, as an application developer, we wouldn't want to offload some of the computational load to clients instead of our own servers. That is a resource that scales far better with the number of users.
If servers only handled data instead of page rendering and so on, we'd need fewer of them to handle larger loads and also be a lot more robust to getting posted on HN or Reddit, etc.
Because obviously your goal is not to lighten your web servers, but to make your webpage faster to load and hence more appealing.
If offloading to the client is at odds with the page being faster (and at least in the previous years that had been the case with mobile and JS-heavy pages), then you should don't.
And whether this offloading to the client scales better with the number of users is besides the point it -- as you need to please each particular user.
Especially these two article's make really really awful assumptions. There are use cases for client-side frameworks. There are even website's or i would call it applications that running behind firewalls that make good usages of such tools.
Also he mentioned two server-side template engine's in the linked article. JSP and ASP especially these two are the worst thing you could do. Mixing Code within your Template is by far worse than using the AngularJS template engine wisely.
I would rather prefer everybody to use mustache (even) on the server. Performance in a template engine is also the least thing you should consider.
I prefer server-side templates and rendering hands-down. This makes it absolutely trivial to build HTML for anything just by hitting a URL that represents it. It also makes it trivial to add caching of those fully rendered HTML blobs if desired/needed.
I prefer to keep my JS focused on interactions and behavior, not turning JSON data into UI components. I build most apps with a skeletal JS layer that knows how to grab the right item at the right URL when triggered by a user action, and what part of the page to place the returned HTML into. I find it pretty fun and challenging to see how dumb I can keep JS.
I despise the idea of building dual validation in the client and on the server. Fuck that noise. With a forms library that is tied to my models (something that exists in most mature frameworks), the server near-instantly validates and sends back HTML with errors marked if the form is invalid. Again, JS just has to know to PUT/POST the form, and display the response in the right spot. And those forms still work when you hit them by URL instead of through a fancy JS-ified UI. Makes it damn trivial to build dumb versions of an app that aren't broken and unusable. And I like the idea of being able to replace a backend that only has to keep the contract of returning HTML from an endpoint. Don't even need to modify the client-side JS that responds to user actions if I don't want to. Maybe, at worst, I update some ids and classes if I decide to modify the markup.
I've never joined the bandwagon of server-side JS and Node. Ultimately, I simply can't bring myself to want to use JS as the primary language for my work. Not to mention that JS tooling, npm, and different versions of ES is an abysmal headache that creates way too much mental overhead just to get started. It's nice to be able to pick a language that just runs on its runtime without needing to know or setup whatever the flavor-of-the-month transpiler is that lets me use classes and shit.
JSON is cool as a means of exchanging data with an API. I like that. It's predictable, standardized, and a helluva lot better than SOAP ever was. But I find working with APIs programmatically and providing UIs to humans are wholly different interaction models, and can't help but feel that we keep making presenting UIs to humans increasingly more complex than necessary. APIs provide a predictable interface for exchanging structured data. UIs are meant for interacting with that data.
Client-side templating comes with its own problems and advantages. You might not need or want it. A lot of times though you do.
But the original guy who is against it is so far behind.. give it a year or two when people are taking desktop apps and compiling them to web assembly and running them in web browsers. Then the advantages will be obvious. But that is almost a reality today and that person probably doesn't even know that web assembly exists.
Sorry but people need to try harder not to fall behind.
The test case used text in a table, which is an extremely poor example. Modern designs use a lot of images and CSS, where presenting a complete document and stylesheets allows much faster time to render than client-side rendering followed by fetching all those assets and applying styles.
The pain for your users is multiplied by the slowness of mobile devices/networks and the complexity of your UI's layout to render.
