I think frameworks have inverted things: the easiest approach these days is to load the default config of some framework/CMS, which will make heavy use of Javascript/images/CSS/etc. in order to entice developers to use it (otherwise, why use a framework at all ;) ). In this world, turning off a feature takes more effort than leaving it on, and we end up with ideas like special "text only" alternatives.

I think there's definitely a burden on the developers of frameworks to make them degrade as gracefully as possible. Of course, this isn't always possible (especially those designed to be completely in client-side JS), but in those instances where it is possible, it can have a large impact. For example, if the developer of some popular Wordpress theme spent a little extra effort on graceful fallbacks, it would improve the situation for all sites using that theme.

Disclaimer: I used to develop a CMS with crazy-strict adherence to, among other things, accessibility standards ;)

I always browse with cookies and Javascript disabled. There are very few sites I'll enable one or both to use. Most of the time, the first time I browse a site that requires Javascript to show anything useful I just leave. If you can't make your pitch with text, I'm pretty sure I'm not going to be interested.

I know, I know...I'm not the typical market for those kinds of sites.

Well, except for the SWF animation at the top, and the dropdown menus, but meh.

Model 1: ecommerce. The website exists to sell your product. Having an alternate version is a simple cost/benefit decision: will people buy your thing from a low-overhead site? This may be combined with a mobile-friendly rendition.

Model 2: advertising. The website exists to catch attention long enough to show ads. You need seven tracking systems and eleven ad networks; all of them need JS and graphics and won't make money for you otherwise.

Model 3: public service. The focus is on providing information, not on making a sale or showing ads. The benefit of a low-overhead version is clear, but you need to keep the costs low, so you can't spend much extra time or money on it.

Model 4: SAAS. The website is the service, so user satisfaction is the top concern. Understand how your users want to use your service, and provide that for them.

I know that sounds a little heartless and "not caring about the web", but it's the reality.

Sites with lots of text content invariably use a CMS to manage that content. It's not hard to build a text-only template, and in fact many sites actually do this - if you browse on mobile Safari, it's called "Reader Mode". I don't know if Android has an equivalent, but I would assume so.

Reader Mode and the Readable and Readability bookmarklets fail often even on "text-centric" pages such as blog posts.

I think good design should include designing for the those with impairments or those who don't live in a big city with uncapped broadband.

Another thing is even if the effort of enabling is small, people responsible for the website are not even aware of the problem.

As an experiment I would drop a note to a few websites broken with JS disabled about a problem, providing a reasoning why it should be fixed and check how many respond.

JS is an open standard, highly performant, and implemented well by almost every single browser out there. The only people I know who regularly browse without JS are old-timers who got into the habit 10 years ago, before Spidermonkey, V8, Nitro, JavascriptCore etc. revolutionized performance, and before AJAX revolutionized architectures.

Let me propose a different way of looking at things. The concerns you actually expressed are performance, download size, and CLI browser compatibility.

Performance - I don't know of a reason that javascript apps cannot be performant enough, even on low-bandwidth connections. AJAX was invented to improve performance over static websites, by reducing network traffic to just the bits that change with each user action.

Download size - Javascript obviously has nothing to do with how many images or videos a site embeds.

CLI browser - Why can't the CLI browsers implement a javascript engine, and then render the results, just like any other browser? There is nothing about JS that requires a GUI.

edit- speling

W.r.t. "old-timers who got into the habit 10 years ago". A decade ago I was 11. Not exactly an old-timer.

W.r.t. performance, in an ideal world, you'd be absolutely right. But this is not an ideal world. There are far too many websites that are substantially less performant with JS. (Case in point: Gmail.). There are far too many websites that kill my battery life on my laptop via sloppy coding. There are far too many websites that don't stop downloading in the background to refresh things that I don't need refreshed, and in the process kill my bandwidth cap on my home connection. There are far too many websites that take multiple seconds before they even begin to render, because they are waiting on some library to load before they parse things clientside. Looking at you, client-side markdown. There are far too many websites that are less responsive on the "responsive" version with JS than with the fallback without JS.

W.r.t. download size, again, in an ideal world, you'd be absolutely right. But this is, again, not an ideal world. There are far too many websites that pull down multiple MB of libraries before they even start to load. Sometimes they are cached, but far too often they aren't. There are far too many websites, again, that refresh things that I don't need refreshed and as such continue to use bandwidth.

And you're missing two other things: the two concerns that I consider most important. One is security. The majority of browser exploits require JS, especially the nastier ones. As you say, JS engines focus heavily on performance. And trying to get high performance out of a JITted language goes intrinsically against security. For a certain amount of dev time, you can get decent security and decent performance, great performance and weak security, or great security and weak performance. It's an intrinsic trade-off. (The other one is user tracking, but I'm not going to get into that one here.)

And one other thing: with JS disabled, most of the time if a webpage is loaded it's actually loaded. I can keep it up and sit in a bus or something and read it, without an internet connection. With JS enabled, far too many websites end up breaking nastily some time down the line when they go to update something and fail. Again: not an intrinsic, but something far too many websites do anyways.

> To me, any website implementing good accessibility (http://www.w3.org/WAI/) is likely to be perfectly viewable and browsable per what you said. But most webmasters don't know about WAI.

I'd add "or don't care".

EDIT: A bit of online searching mainly shows people *complaining8 about print sheets, so perhaps I'm completely out of the loop and simply haven't printed anything in a long time.

It's not much - just stripping out menu bars and other stuff that makes no sense in print, plus a few typographical changes, such as a change in font from sans serif (screen) to serif (paper).

Similar to the other comment, there isn't a clear business case for it very often, but whenever there's a website with a "print version"-link to their articles I don't see why they wouldn't do this instead. Well, aside from the fact that nobody would expect this functionality to be there, which isn't minor I guess.

[0] http://alistapart.com/article/goingtoprint

at least before chrome web-inspector got the handy checkbox.

The better answer is that unless you think about it from the start, providing a no-JS fallback can be hard to do well and may require a fair bit of re-architecturing of your website or web app - something that you probably won't bother doing to do for a single digit percentage of your visitors (text-only support probably has a lower priority than supporting <IE9 and Opera Mini). Finding out that images won't work is also pretty hard - they're no way that I know of finding out if images are enabled or not without using JavaScript, which is probably disabled as well.

I've actually been creating a reasonably complex web-based application recently, and for fun every few weeks I test it using Lynx[0]. Technically, using forms and very basic CSS results in a fairly usable service. I managed to get a working CSS3-only (no JS) fallback for tabs, some toggle buttons and some other UI goodies. The only problem is that I end up duplicating a lot of stuff on the backend of the app (because I have to deal with both form submissions AND ajax), and there are a lot of things that you can only really do with JavaScript and images (e.g. games, most interactive stuff without reloads, anything to do with images obviously).

EDIT: regarding advertising, rarely do (effective) advertisers online want the largest audience specifically, they want the most engaged audience. Is this no-JS and no-images user interested in downloading an app or a pop album? Probably not, so it's not worth putting in the effort to make them see your ads.

[0] http://lynx.isc.org/

It's mostly because the website owner/responsible believes that the cost of producing a "text only" version would be bigger than the benefits achieved. If the decision is right or not, I wouldn't know - and, frankly, neither most of people who make the decision (albeit being "confident"). I seriously doubt that any thorough analysis is done on the subject, people just believe that almost everyone uses JS and images. And they might be right, or not.

Sometimes it might also be a matter of ignorance. It might happen that the responsible is not aware of this question (and neither is "made aware" by the technical people).

It's not text-only versions we need, but sensible use of progressive enhancement. I'm totally fine with 'web apps' requiring Javascript and CSS (but please, at least give me a message to that effect, and don't leave me with an infinite spinner!) but simple web pages are increasingly broken without scripting.

It's frustrating, because it's not like progressive enhancement is hard, either.

1) they make it intentional for whatever purpose - stop scrappers, prevent search engine indexing, pull in ads etc.

2) they make it out of incompetence - probably somebody with insufficient web development skills just used some popular JavaScript framework to quickly cook up a site

Now the majority of the customers won't care, but if you're targeting a professional audience, this will not score you any points. If you were a software development company hiring and I were to reply to your invitation, I would first go to your website. If I saw a blank screen in my browser, my first question to you would be why a serious company does have a broken site. Depending on what I heard I might skip you altogether.

Personally, I don't think there are any difficulties in doing a "text-only" version as you call it. That's how I always approach things - do a classic version then add some gradual enhancements. I can't imagine doing it the other way around actually.

And yes, you can call me out of touch with the times, but text pages rank higher and more credible in my eyes then all of the JavaScript toys I see around.

every website has a target audience and it simply doesn't make sense to spend time and effort for this support. It's just not worth it.

I think down deep, the author is looking for the web to go back to the http://www.csszengarden.com days. I really wish web designers would put forth the effort.

Current trends aside, from a pragmatic perspective, I would anticipate something like this increasing development costs (labor & money) between 10-50%, and would likely have a very low ROI.

- Most sites contain static content and are not interactive. Things like simple forms don't really count, in my opinion. - Sites which load static content are in my experience slower as a result of using AJAX, not faster

In fact, I'd argue that there is essentially no additional cost in building a site that uses progressive enhancement for loading content. If anything, my experience is it encourages a much more sensible architecture.

Of course, the value proposition changes when we're looking at interactive web apps, and I agree it's not clear that there's value there.

Because most people never turn javascript off OR use links to browser the web.

Of course javascript-less websites have many advantages: easier end to end testing, speed of execution, loading speed,work on a wider range of browsers without hacks...

(Any takers?)

https://readability.com/

Thinking about it, I would be ready to use such a site for the "unreadable" sites.

I've just tried it with JS, actually it's a very little of the whole content.

GMail still has a special "basic HTML" version. It behaves much better over the bandwidth limited or very remote connections. Even at my home, with otherwise high speed internet, as I had some transient transmission problems the "full" version wasn't usable, but HTML one worked.

At least GMail has the real "html-backup version" the OP asked for.

SPA designs can actually make CRUD apps significantly more useable on slow or unreliable connections.

I've run across far too many "mobile-friendly" websites that start by loading many MBs of JS libraries. And just flat-out fail to load if any of said libraries fail to load.

A text only version like the one described would be far worse than a JS heavy one. JS free forms are naturally synchronous. So each edit would kill the ui for a full refresh cycle.

On the other hand a SPA type page can send data in the background white you're doing other work in the app.

Sure there are crappy mobile friendly sites, but that doesn't invalidate the idea.

On a side note I'm not really sold on the whole CDN idea, it just looks like another HTTP request and another point of failure. Concatenate / uglify seems like the better solution.

ps. "citation needed" is kind of obnoxious when it's something you can think through for yourself.

which is obvious from your question ;)