Ajax忧虑与启发
对Ajax的研究有了一段时间了，从最初的远观，到近看，再到实际动手实现，认识越来越深，想法也越来越多。特别是曾经有一阵子跑去研究web2.0，更是体会到Ajax背后的伟大，暗自为其庆幸，也越来越看好Web。
不过Ajax在我心中却有些怎么也摆脱不了的阴影。
忽如一夜春风来，Ajax就这么很突兀的就突然流行起来。同时流行的还有Web2.0，这些词汇现在都无比的有鼓动力，任何事物，只要沾上这两者的边，便变得神秘无比，无法遏制。
但也有人说Ajax是噱头，因为他是新瓶装旧酒。
其实Ajax之所以风行，就在于它新瓶装旧酒。Ajax所代表的3个概念，异步、Javascript、XML，应该说都不是新东西。
异步？在操作系统中我们早已经学过，那时的名字叫多线程。
Javascript？想当年的DHTML他就已经红遍大江南北。
XML？瞧瞧那些名词，SOAP、RSS、WAP等，这些名词哪个离开得了XML？
这些名词结合在一起之所以产生强大的力量，就在于他们的设计不同，而隐藏在设计背后的思想不同。
而这些名词之所以可以红火，就在于他们本身已经应用非常普遍，已经深入到世界中的每个角落。
即便是Ajax中稍微新鲜点的XMLHttpRequest，之前也不是没有替代品。IFrame时代我们就已经实现了同样的功能，只是XMLHttpRequest可以比我们做的更好，帮助我们做的更多而已。
Javascript是将Ajax所有技术糅合在一起的黏着剂。所谓的Ajax应用程序，其实就是一个运行在客户端浏览器环境中的应用程序。这个应用程序通过DOM操作HTML将信息展示给用户，通过事件机制相应用户操作，通过XMLHttpRequest与服务器沟通，使用的协议是HTTP，数据的载体是XML，而这个应用程序就是由Javascript构成的。
Javascript是一种非常强大的语言，换句术语，是通用语言（general language）。Javascript有很多方便的并且强大的特性，使得我们可以开发功能丰富的产品。不过Javascript是脚本，还是脚本，这是他永远逃不开的厄运。
脚本有很多的问题，比如本身不够严格，执行缓慢的特点等，这里只讨论一下代码重用问题。
当应用越来越复杂，代码越来越多时，代码重用就会变得很重要。最低级的代码重用就是源代码级的代码重用，灵活，但却代价很高。比较先进的平台，比如java和.net都已经提供了更高级的代码重用，中间代码级的，甚至目标代码级的。甚至，在.net平台，按照微软的伟大设想，不同语言的代码都可以统一起来，一起运行。可想而知，这会为.net平台带来多大的战斗力。不同语言，不同的平台的代码都可以在这里施展拳脚。整合是现在的主旋律，.net有着更美好的未来（按照设想）。
相比之下，作为脚本的Javascript这方面就要差距好多。在我们之前应用程序规模不大时，没有人会在意。但是，当我们实现大量的Ajax应用时，当我们逐渐丰富我们的客户端时，我们就会发现Javascript的硬伤，也就是脚本的硬伤。当然，我们可以改造Javascript，让他适应我们的需求，但是那时，你会突然发现，Javascript（如果那个时候还叫这个名字的话）已经不再是脚本了。
换句话说，脚本的特点就是灵活，所以它是用来处理一些灵活，但是开发成本低的情况。而传统的程序语言比较严格，开发成本高，但是他的运行和维护成本会低。
于是，当我们意识到Ajax背后是一种客户段能力的提高，服务器端相应功能向客户端转移之时，我们便不得不重新审视一下Javascript在其中的尴尬位置。Javascript之所以在Ajax应用中如此受宠，便在于它的灵活。灵活的Javascript获得大众的喜爱，逐渐成为标准。Ajax采用Javascript才能迅速的得以应用，成为今天的宠儿。反过来说，正式因为Javascript的灵活，决定它注定无法大型化，也就决定了Ajax的明天不会乐观。（如果他还依靠Javascript，还叫Ajax，而不是AC（#）ax的话。）
看看Ajax背后的竞争者，micromedia的flash，java的web start，甚至.net都有可能成为他的强大敌人。微软在宣传它下一代操作系统的时候，着重讲到了他的表现层。想象一下，当所有的IE都支持微软最新的表现层技术时，谁还用Javascript？谁还用Ajax？
不过即使Ajax倒下，不过不要紧，它本身就是一个过渡性技术。不过，Ajax所要做的，就是给我们洗脑：
Ajax告诉我们，重视脚本，因为他们灵活。
Ajax告诉我们，重视用户，因为他们掏钱。
Ajax告诉我们，重视交互，因为软件就是服务。
Ajax告诉我们，重视Web，因为方便比什么都重要。
Ajax告诉我们，摘下眼罩，换种方式思考问题吧。当你背过脸无视世界的变化时，是世界抛弃了你，而不是你以为的掩耳盗铃。
