Guessing you don't use facebook, twitter or any major webmail provider like 99.99% of the users online do. For over 99% of users this is a feature that shouldn't be visible.. for the other 0.0x% there is about:config ... I don't bitch about having to go into about:config to change my cache settings for when I am testing...

Lots of the Web does not do graceful degradation to fully functional sites without JS. That ship has sailed, that battle has been lost. JavaScript is a required, not optional, part of a lot of the Web.

Strongly disagree. Lots of the web may not degrade gracefully, but then also lots of it does.

Further, the notion of it as a lost battle is unfortunate because we're not discussing a binary choice between two opposing sides here. As an approach, progressive enhancement of JavaScript UIs enables developers to deliver an experience that degrades sanely in non-JS environments.

However, I will concede that your opinion appears to be the most commonly-held one, even among some developers. And it's probably not going to change for the better with news like this Firefox development... :-/

There is something to be said about the expectation when js is on and off. A lot of sites will have a notion of javascript is off == old mobile phones or low level device, and will assume that when js is off most css will be too. Simple sites won't see this as a problem, but for mildly complex sites, you'll have a matrix of "is js on ? off ? " "is css on ? off ?" "does it accept cookies?" "is this html5 thing available ?" "is there enough memory for this or that?" , and you'll add to the mix screen sizes and the availability of a keyboard or not, etc.

There's already so many moving parts, saying "this browser handles cookies, every newest features of css, html5 and everything. Except js won't run." is just a recipe for ugly user experiences.

Slightly OT, IMO blacklisting specific js (e.g facebook, twitter etc), or having browser giving an option to kill scripts that take too much time or too many resources should be healthier for the devs and the user than just turning js off on the whole site.

> "failure to handle disabled js gracefully."

How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve the goal of their visit? Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is.

Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"? If so, what exactly is your problem with removing the option which we only ask users to re-enable anyway?

As many others have pointed out, you can still disable JS if you really need to. It's average non-technical users who don't require that option.

Let's not forget that not every page is meant for humans to read, and not every reader is attempting to consume information the same high-bandwidth (visual) way.

You might think AJAX is amazing, but I call it an accessibility nightmare.

I know exactly what you mean by AJAX being an accessibility nightmare, and perhaps my own recent over-indulgence in using AJAX to populate the website I made will come back to bite. Time will tell, and I'm willing to eat humble pie over it. But in my defense the client's requirement was to get that content on the page, and AJAX was the only method available to me.

> How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve the goal of their visit?

Make the request from your server, parse it on your server, template it on your server, and deliver the HTML result to your user.

> Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is.

Perhaps the developers of these modern, rich content-heavy sites can learn how to do their jobs properly?

> Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"?

No. It goes far deeper than that, naturally. Progressive enhancement ( https://www.gov.uk/service-manual/making-software/progressiv... ) is about defining what is considered the core experience, defining the true value your site offers to your users, identifying the use cases that are utterly essential. It's these features that should be _implemented_ in a way that doesn't depend on JavaScript. So you build this layer first, and get it working. Then, you identify the enhancements, user experience improvements, the bells & whistles, and use JavaScript to fill in those gaps. Confident in the knowledge that should the JavaScript fail (for a plethora of different and uncontrollable reasons) the core experience will continue working. Then you consider the nice-to-have features, and decide how much of that is appropriate to incorporate as a core-experience level, and what improvements can be made with JavaScript.

Sounds cool, but speaking from recent experience, the option to make the request from the server, parse it on the server, template it and deliver it was not available to me for the job I was asked to do (as a frontend developer).

Sometimes it comes down to doing it with client side AJAX, or not doing it at all.

With developers learning to do their jobs properly, sure when the luxury of time and starting a new site from scratch is on your side. And with backend developers and engineers ready to configure the ultimate content delivery mechanisms. But what of when you don't have that luxury? What then? Just decline the job? Maybe, but then someone else will come along and do the AJAX, and get paid because the content appears when the site loads every single time (provided JS is enabled ;-).

How would you have Firefox "handle" this, exactly?

You can blame the web at large for moving in a direction that assumes JS is enabled, but that doesn't make the UX better.

One thing that surprised me a lot recently, is I started a rewrite of my personal website using Bootstrap as a base, where the old one used jQueryUI... iirc, I included the kitchen sink in the old version.. however, the new one came in a bit heavier on the download/overhead... even with a better min/merge plan.

I can say the new version I am working on looks better, and is actually usable on a phone, just the same, I am not sure I'd like to see the UX on a bandwidth constrained mobile connection.. it's still well under 1MB total, but it seems that we should be working towards being under 100K for an initial load, and given all the targets for different browsers, and work arounds, and libraries, tools etc.. I just don't know where we are going.

We have more target browsers and size constraints than ever, and it's more complicated than ever. I don't miss the V4 browser wars (IE4/NN4) but it seems that targeting a 700px wide or 960px wide site was way easier than the rules today, mobile first or not.