[elohesra]

So you've intentionally disabled a large part of your browser through NoScript and now it won't render pages that require the browser to work as intended? Isn't this rather like removing all gears but first from your car and then expecting everyone to accommodate the fact that you can only achieve 10mph?

I'm not meaning to have a go at you here, npsimons -- what you choose to do with your browser is your business, and you've not actually complained about the site -- rather I'm seeking to curb the idea that seems to crop up on HN from time to time that browsing without scripts enabled should provide a roughly equivalent experience to browsing with scripts enabled. It's not reasonable to expect developers to cater to a tiny fraction [0] of their audience when that audience wants the developer to essentially give up all client-side interaction other than POSTs.

[0] It's around < 2%: http://developer.yahoo.com/blogs/ydn/many-users-javascript-d...

[Jach]

I've yet to meet another noscript user who demands every site should provide roughly the same experience with or without scripts. Minimally we just want a webmaster to include a goddamn <noscript> telling us why we should temporarily whitelist her domain. And when something is pure text but requires JS to see any of it (as some blogspot templates tend to behave), we'll make complaints about progressive enhancement for that particular use case.

P.S. Your link is nearly four years out of date, and I bet the percent is higher for software engineers, i.e. the target audience of this page. Hell, for just Firefox users who use extensions, a quick estimate suggests 12%. (Number of users for https://addons.mozilla.org/en-US/firefox/addon/noscript/ divided by number of users of the most popular addon, AdBlockPlus https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/)

[npsimons]

My biggest complaint is that there is no context whatsoever, either in the link, or the target page. Graceful degradation or a quick overview would have helped greatly.

I'm fine with enabling JS for some things - online shopping, web apps, etc. I'm not fine with enabling JS for things that don't require it - blog posts, photo galleries, etc. This page, I closed immediately, again, because I couldn't tell what it did. I'm not about to start randomly enabling JS just to see what will happen.

As for curbing, I'm going to have to strongly disagree with you there. I think more people should be browsing with scripts and flash off by default; how many unpaid tech support calls could have been prevented by a default install of NoScript and FlashBlock? I'd like to curb the idea that people will just run random code off the web. Give us a reason, a justification, and if JS is disabled, tell the user why you need it.

[logfromblammo]

I'm going to agree with you there. The browser environment you set up for your non-technical friends and acquaintances should include a script and flash blocker that supports both whitelisting and blacklisting.

You simply shouldn't allow a script to run on your device without some amount of trust in the site that gave it to you or a thorough code inspection by multiple experts. Even then, it still might have a hidden exploit.

Because of this, there ought to at least be a landing page for script-blockers with a bit of explanation as to why they can't make use of the site without allowing scripts.

I am firmly of the opinion that scripts should strictly be an optional addition solely for the purpose of improving the user experience of visitors. HTTP 1.1 is good enough that about the only thing you do actually need scripts for is persistent and/or two-way communication channels. Almost everything else can be accomplished on the server side with a stripped-down user interface (as one might use with screen readers, text browsers, or even SMS or WAP on feature phones).

[dublinben]

Graceful degradation is important not only for users who don't run JavaScript, but users of screenreaders as well. There's no reason not to have a plain text fallback of your site's content.

[dangrossman]

This is a myth. Screen readers have no problem with ordinary sites built with JavaScript. WebAIM did a survey of screen reader users, and 98.6% have JavaScript enabled when they browse the web.

http://webaim.org/projects/screenreadersurvey4/#javascript

People that use screen readers use ordinary browsers, like IE, Firefox and Chrome. They don't use special browsers, screen readers read the whole screen.

[bphogan]

I am a person that uses screenreaders frequently.

I use Firefox and JAWS.

It is incredibly difficult for me to navigate sites that use JS to render content.

And as a developer, it's outrageous to me that people who consider themselves web developers to think it's OK to render static content (news articles, blog postings, etc) using client-side JS.

Angular, Ember, etc are all amazing tools for building applications. They are not amazing tools for web pages.

Now, I don't know if you specifically also use a screen reader, but if you do, I'd love to know what you use.

But for those of you that don't, I'd appreciate you not trivializing the issue. Accessibility of a site and how it works with screenreaders is up to the individual developer.

Did you know that Flash was accessible to screen readers? Too bad developers never paid attention to how to do that.

[logfromblammo]

Remember, the screen reader reads the entire screen. If you don't provide some thought to the user experience, people using screen readers can still use your site full of menus and sidebars and advertisements and article pagination, but they will probably be very frustrated by it, trying to find the content that they actually want to hear.

Imagine the person who essentially has to look at the world through a drinking straw, and try not to be a dick to him by adding clutter. Copying your content into pages with simple navigation--without frames or scripts, possibly with tree-hierarchy outlines and prev-next links--is not required, but is definitely a nice gesture.

[anon4]

The point for me is, if the site uses so much javascript you can't even just see the text without javascript enabled, it's probably a bullshit experience. Or a neat WebGL demo. This is the former.

Case in point - on that page ^W, ^PgUp and ^PgDn do not actually close the tab or move to the previous/next tab. And not only that, ^W doesn't even erase one word backwards. Why would you go to all the trouble of capturing all keyboard events if you're not even going to support basic commandline editing. This is not a neat use of javascript, this is an annoying use of javascript.

[elohesra]

>The point for me is, if the site uses so much javascript you can't even just see the text without javascript enabled, it's probably a bullshit experience. Or a neat WebGL demo. This is the former.

I totally agree with that, but I think it's a tangential point to the one I was making. I certainly think that developers should only use javascript where it's actually more convenient to do so than to use CSS, HTML and server-side code.

I personally find it extremely irritating navigating to sites which use javascript for something which naturally lends itself to another technique (like sites which request all text using javascript, as 'bphogan' pointed out above). When I visit sites such as these, it makes me feel like creating a parody site which draws the entire DOM in javascript just to illustrate the point that javascript is but one of the tools in the developer's toolbox.

The reason I get somewhat annoyed at noscript proselytizers (which I fully admit doesn't apply to any of the commenters in this thread), is that I've seen what happens when developers are forced to attempt to produce a stateful, interactive experience for the user without using (too much) javascript, and that thing is ASP.NET WebForms. As the line shrinks between desktop apps and web apps, we'll have to find ways to make overcome the web's shortfalls in interactive application development, namely state management and responsiveness. If the use of noscript increases, then this becomes harder to do, and makes it a lot less possible to make interactive web applications look like anything more than a poor mockery of interactive desktop applications. I truly want to see a time within the next few years where I can barely tell the difference between a desktop app and a web app, and unfortunately for noscript users, such an experience will probably require javascript.

[npsimons]

I truly want to see a time within the next few years where I can barely tell the difference between a desktop app and a web app, and unfortunately for noscript users, such an experience will probably require javascript.

That's fine; believe it or not, most NoScript users are enabling a good chunk of JS (usually for your exact example of web app). What's annoying is when one opens up a link that gives the user no clues whatsoever as to it's purpose, and all that happens is a blank page pops up. No indication, like on some sites, that hey, this site is interactive and requires JS. Just a blank page. It makes one wonder why the URL was even shared.