I fully agree with this. SPAs are for webapps, not websites.
For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for.
Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.
> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.
Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the Internet.
> Sure there is, if you care about interactivity, responsiveness, and general user experience.
And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs.
> The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small.
Your use of the term 'probably' suggests to me that you have not run any actual metrics. Here's a short list of some examples:
- Bots and spiders
- Low-powered mobile devices
- Privacy-conscious users who use NoScript
- Terminal-based browser users
- Literally every single one of your users until the .js blob has completed downloading
- ...
Requiring JS for a website is not okay, end of story. We all collectively understood this 10 years ago, and I'm not really sure where along the way this understanding has gotten lost.
EDIT: Forgot that HN has a neutered version of Markdown. Fixed.
> Your use of the term 'probably' suggests to me that you have not run any actual metrics.
What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers.
> Requiring JS for a website is not okay, end of story.
It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."
> We all collectively understood this 10 years ago
Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."
> JavaScript is an integral part of the platform that is the web, just like HTML and CSS
I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument.
By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.
This isn't a news flash to everyone, but even those already aware of this seem to think the main reason you'd do this is ADA accommodations and those are some kind of minority afterthought. My experience is that this is misguided -- accommodations for unusual visitors is important, but I think the biggest benefit might be that the simpler you make things for the client, the less complicated the engineering tends be, even if you can't import your Java-imitation-of-smalltalk-inspired application paradigm of choice.
And "too bad if you didn't have JS!" position seems to basically boil down to the idea that serving a custom client that consumes JSON instead of HTML as the media type for a given URI is Real Progress™.
Keep things as simple as possible. Don't require JS unless what the application needs to do can't be done without it.
The problem is that arguments from both sides are often generalized and it's not necessarily wrong. If you have a wide audience e-commerce enterprise you should probably keep JS use as limited as possible. If you build tools for programmers or highly dynamic projects, JS everywhere is probably fine.
If you build tools for programmers, give me some way of interacting with it other than running your JS in my browser. Otherwise, I'm likely to find it horribly awkward to integrate with my preferred workflows, and I'm unlikely to use your project.
> By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.
I think that is just an outdated idea that does not apply to highly interactive, long-lived web applications. The user agent is well within its rights to ignore anything it wants, of course, but the user agent is not owed anything by the server. With CSS, or JavaScript, the app may just not work.
> With CSS, or JavaScript, the app may just not work.
When it comes to CSS, generally most apps will continue to work even if the CSS is simply ignored.
Because that was one big point of CSS. Separation of presentation from content and function.
It's funny. That kind of separation of concerns is something developers talk about valuing, but the SPA/webapp craze erodes the user-facing aspect of it, even while developers are very proud to demonstrate they're thinking hard about which specific kind of separated-concern architecture they're working with well away from the boundary where an outside user or UA would care.
It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."
The comparison between JavaScript and a browser is very weak as a web app absolutely requires a browser, but JavaScript is most certainly not required. But, that aside, requiring JavaScript with absolutely no workarounds is a very bad idea.
Consider people who are sight impaired. Screen readers and heavy JavaScript really are not friends, but there is legislation in many countries that makes this basic kind of accessibility a legal necessity.
Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."
First, this is rude. Second, your comparison between JavaScript and click-only commerce is even weaker than your previous comparison between a web browser and JavaScript.
But, those points aside, the web was a lot different ten years ago. Ten years ago, I could browse the web with JavaScript turned off and I rarely came across sites that didn't work for me. When I came across sites that didn't work, they always politely had a <noscript> that told me that the site needs .js. Today, my experience is the exact opposite and basic accessibility has faded.
Change is not necessarily positive - no website should require JavaScript. And, I'd argue that most applications should work without JavaScript.
Screen readers a JavaScript get along just fine if a site is coded well. A SPA can be perfectly accessible. The Section 508 refresh is well underway and will essentially be WCAG 2.0 AA [1]
> What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers.
I was refering specifically to websites, not webapps.
> It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."
That analogy makes absolutely no sense, nor does your comparison to CSS. JS is an entirely different class of dependency than either CSS or web browsers.
JS is turing-complete, has a significantly bigger attack surface (both in terms of vulnerabilities and in terms of tracking), is much, much harder to optimize for a low-powered device than HTML and CSS, and so on.
Further, the web browser is a necessity to view something on the web. It is well understood, it is easy to optimize, and it is widely deployed. JS is no such 'required dependency' - and you should not make it one, when it can be done just fine without.
> Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."
The support/compatibility landscape for JS has not changed in those 10 years. The types of non-JS clients are still the same, the reasons for progressive enhancement are still the same. The only thing that has changed is standardization.
"Old" is not the same as "obsoleted". Unless you can come up with a concrete reason as to why this knowledge has been obsoleted throughout the past 10 years, it still applies.
And I'm getting a little tired of these poorly fitting analogies, you're using them as a crutch.
> I was refering specifically to websites, not webapps.
Okay, then yes, we were using terms differently. I consider web apps to be a subset of web sites (which is the standard usage as far as I knew), and thus I thought you were claiming that JavaScript should not be a requirement for any web site, including web apps. But you're using "web site" to mean web sites which aren't web apps, and in that case, I do agree.
I disagree with several claims you make later in that comment, but since I think I've addressed our primary disagreement I will leave it at that.
Thank you for making these points, I'm just disappointed at how often they need repeating for some people, do you know of a website that explains the reasoning behind not relying 100% on JavaScript for your website?
There's motherfuckingwebsite.com but the tone of that site is very adversarial, I think one that lays out the reasoning in a noncombative way would be more successful at reaching some of these people.
Hmm. None in particular, though you could just look around for some of the older resources on progressive enhancement - that's what it's called, and it used to be a recommended practice everywhere.
There is a difference between a web site and a web app (although there is blur in the middle obviously). A web site (e.g. this site, a news paper, a blog, a search page, a job application form etc) should not need JS - and frankly if you put it in there then you're over-engineering things. Meanwhile web apps like e.g. Google docs/Office 365, a webmail client etc are clearly going to need specific JS.
Come on, really? Some of those are legit (although manageable if you do things right), but how many web Apps truly need to worry about accommodating terminal based browser users?
Unless Stallman is in your target market that's probably something you don't need to consider for any longer than fifteen seconds.
There is a simple argument for making sure that a web site looks good in a terminal based browser (note: web site, not web app).
This is how Google sees your web site.
Sure, there are lots of meta data enhancements and Google is probably much smarter than it was 10 years in extracting data from your js gobbled up web page (as we know, they even try to interpret javascript to some extent).
But it still boils down to this: The easier you make it for Google to get at the text of your web site, the better for your page rank.
You should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.
Just out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.
"if you care about interactivity, responsiveness, and general user experience"
A simple web page (no-js) in a browser covers these three things to a highly acceptable standard. It's when you start to add the other junk that these three become compromised.
For example:
Interactivity: Hyperlinks work great from HTML 1.0 onwards
Responsiveness: Without additional items like JavaScript or even CSS, web pages are incredibly responsive.
General User Experience: The basic web page user experience is EXCELLENT for web pages because it is incredibly basic. Even date pickers can consist of 3 select drop downs (or even a text box; there are plenty of human-date-to-ISO-3306 convertors out there)
I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.
"Graceful fallback" is what came before progressive enhancement, and is considered obsoleted for good reason.
Graceful fallbacks tend to be maintained as a separate version, and neglected over time. Progressive enhancement means taking a basic page and adding snazzy functionality to it - eg. ajaxified page loads. The latter is what you want.
It does, however, require a potentially large amount of work for a SPA. Granted, server-side rendering for JavaScript libraries like Ember and React is doable now.
First page load can be totally server side generated. Once loaded on client side, you can check using modernizer or something if your user's browser supports the features that you need for SPA if yes then you can replace server side generated HTML structure with a client side version. Now, you can proceed with all of your server and client communication via your favorite SPA framework.
Maybe not all my clients support javascript, but substantially all I care about do.
I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it.
> I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it.
That is a reverse CAPTCHA, it works very well, and has absolutely nothing to do with Javascript. They are typically implemented using CSS.
I enable JS for sites I feel are valueable for me. The first impression is always without JS. If navigation-buttons dont work without JS - I just leave.
I am too small a group to be cared about. But in my opinion only poor designed websites use JS for layout or navigation. And the way back to the search-engine is always just one mouse gesture away.
JS = code written by someone with not neccessarily my best interests in mind running on my computer.
I doubt she tries to prove anything. It is probably rather the peace of mind of not having ads stabbing in your eyes, subscribe popups appearing as you scroll, things wiggling around, images fading up in a popup instead of loading directly, protection against exploits and saving bandwidth just to name a few benefits.
I didn't even use a SPA for a webapp on my main work project I wrote a lightweight base and send down the page specific stuff and that model (so in a way it's lots of little SPA's not sure if that has a name) which means I get most of the advantages with few of the downsides.
For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for.
Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.