javascript不可用的问题探究
我第一次遇到这个问题还是在DHTML盛行的时代. 我们对浏览器无所不用其极, 加上各种动画菜单、3D标签（我们现在已经学会不再使用这些了）, 但总有人告诉我们javascript不可用.
谁禁用了javascript
第一个要问的问题是这些javascript不可用的环境在哪里. 下面是一些可能的答案：
安全系统比如noscript或者公司代理过滤掉了javascript;
功能手机比如旧式黑莓（我还记得将旧式黑莓换到Opera Mini以获得总算还过得去的上网体验）;
在移动应用环境中, 图片和脚本有时候会被拆分处理;
在流量有限或者接入很慢的区域中;
人们因为个人原因禁用了javascript;
讨厌广告弹出等强势广告的人.
就像你所看到的那样, javascript被禁用的原因多种多样, 有被动的, 也有主动的. 所以不能说只有乱用网络的人才会遭遇这样的问题.
为什么javascript会被禁用
像上面所列举的那样, javascript被禁用的原因多种多样. 如果它是被有意禁用的, 那么我猜主要原因无非以下三点, 即安全考虑、广告疲劳以及慢速连接.
安全考虑在情理之中. 几乎每一个在客户端的攻击都是使用的javascript（大多数情形下都是利用了插件的漏洞）. Java当然是当前最大的安全漏洞, 但是通过javascript同样会对存在漏洞的网站或者不经保护或者过时的浏览器以及操作系统造成安全威胁.
慢速连接是个很有意思的原因. 非常讽刺的是, 我们使用javascript是为了加速客户端体验. 最初使用js的一个例子就是在客户端对表单进行验证从而避免服务器端不必要的工作周期.
如果你现在正处于一个很差的连接中（比如一个无线连接或者很差的3G连接）, 你想要使用Google Reader或者Gmail, 你只能得到一个不完整的页面, 这时候只有使用低版本的才能更好工作.
为了两方都好
基于环境以及连接给用户最好的体验是非常好的. 这也是渐进增强（progressive enhancement）所研究的问题. 这也并非是很高深的东西, 它很简单, 并且是处于完全的实用主义.
使用事件授权这样的技术是非常简单的. 你可以通过点击父元素的handlers来写你自己的HTML, 使用innerHTML或者其他一些更新更快的技术.
为什么是这样一个问题
坦白说, 我也不太清楚. 或许是因为我太过时了, 或许是因为我已经一次有一次对浏览器和网络连接失望了, 或许是因为我只想更安全一些. 我只是不明白为什么人们只想要js的解决方案呢, 而实际上, js只是用来提供一些增强功能的.
费解的应用边缘案例
人们时常怀有疑问的是"应用需要javascript". 如果我们足够坦诚, 我们就会发现, 这样的应用实际上是很少的. 如果一定要说出一些, 我只能想到的是浏览器中的photoshop或者其他的一些编辑器（比如视频、浏览器中的IDE）才需要依赖于javascript. 其他都可以通过重新加载和服务器端的一些部件解决.
让我们直面这样一个事实――在Node.js的时代, 服务器端也可以用javascript来写. Dav Glass of Yahoo两年前显示如果一个工具库编写成余环境独立的, 那么你就可以同时在客户端和服务器端复用这些工具.
"应用需要javascript"的真正原因似乎是其他原因, 而非技术上的.
"应用需要javascript"的真正原因
正如禁用javascript可以有很多原因, 应用需要javascript也有很多原因.
你只知道js并且认为人们就应该升级他们的浏览器. 这无可厚非, 但是这样的看法是很狭隘的, 并且很容易失败.
和你一起构建应用的团队没有服务器端的技能, 你希望能以较低的代价完成这个应用. 这或许有效, 但是这样可能让开发时间和资金都加倍. 要提前为这样的开发做好规划.
你想要尽快写出应用, 并且你知道以后你会重写这个应用的. 这是很常见的现象, 尤其是你可以因此而成功. 愿上天保佑你吧, 千万别让人知道你会待很久.
你的应用会在一个纯js的环境中运行. 这当然意味着你没必要不使用js而完成你的应用. 一个很好的例子就是Air applications. 但你要保证这个环境在将来不出问题.
你的应用确实需要js来运行. 如果真是这样的情况, 就别将它提供给没有js的用户. 向人们解释为什么以及如何做（尽量避免告诉人们他们需需要开启js因为他们可能根本做不了而更加失望）, 并利用js重定向到你的应用.
总之, javascript依赖性的问题不只是技术原因. 它对旧的技术实践提出了疑问, 并且对于可维护性有很大影响.
可以说, 如果我们能问问"我们为什么需要js"而不是问"人们为什么没有js", 关于这个问题的讨论会更有成效. 如果我们的技术能很好适应不同需求的话, 去责备人们跟不上网络发展是毫无意义的.
通过展现给用户看他们能通过开启或者关闭浏览器中部件来解决问题同样是没有意义的. 当一个普通用户卡在你的应用中了, 这并不是一个告诉用户发生了什么的做法.
或许所有这些问题在node变得成熟以及普及以后都不会再是问题. 我将很乐意看到这点.