在关于Ajax.net上一篇文章中我提及到一个概念-两分化编程模式。我们从这个开始说起，传统的web编程都是服务器端编程，我们多和服务器开发技术工作在一起。也许你会说不是这样呀，我们都在使用javascript来完成一些必要的客户端功能呀（ASP.NET中的客户端验证烟支持客户端的很多功能）！但不是使用javascript并不表示它的地位和服务器编程的地位是一样的。服务器端开发中我们会涉及到的概念在客户端中都是没有比如：Application的概念，通常只是为了弥补一些服务器编程模式中无法很好完成的功能，我们分解到客户端来完成而已。
Ajax的出现改变了现有的认识。客户端可以和服务器端开发技术一样的重要吗？服务器通常被称为"程序"而客户端被称为"脚本"。在Ajax出现前几乎很少有人愿意承认客户端开发能当作"程序"来看待，现在事情已经发生了改变，Ajax使得我们认识到客户端需要被提升为"程序"来看待，至少要作为web程序的一个部件，而不再是控制一下DOM元素，做个绚丽的界面操作而已。在利用ajax技术的基础上它一样可以和数据管理、界面操作、程序级别管理功能一样。Ajax.net 的客户端类库（library）为我们做到上面描述的概念。
"曾经的页面现在的Application。"
我先来描述一下传统的web开发模式中经典的过程（无论是什么技术作为web开发基础其实都一样）。
- 通常是发起一个请求，这个请求被浏览器发送到服务器。
- 服务器接受到这个请求执行服务器上的预先编写的代码。（它通常会启动或复用一个服务器端的"Application"）。
- 最后将执行后的结果作为响应发送到客户端，（通常响应的内容就是广义的HTML）。
- 浏览器在接收到响应后负责将其呈现出来（显示）。此时我们就可以在浏览器中看见结果（页面）。
在上面描述的模式中，你能体会到什么吗？如果是上面的那种模式我们确实只需要关心服务器端发生了什么，反正你给我请求我就给你一个响应。还需要我做什么吗？最多我在客户端用JAVASCRIPT做一下满足客户视觉的功能。没有什么不妥的。Ajax改变了什么？在最初我接触Ajax的时候我觉得它不过是JAVASCRIPT的一种极限用法，不会对Web编程产生什么"深远"的影响。然而事情却不是我想的那样简单。
再来看看Ajax工作方式吧。
- 假设页面已经载入，页面中充满了HTML代码、javascript代码、CSS样式。
- 用户对页面进行操作，不小心触发了一个对服务器的提交。
- 在Ajax下，页面不再被刷新，也见不到浏览器的进度条的指示，Ajax悄然的发起一个请求（异步）。
- 服务器接收到请求开始执行服务器端代码，产生结果发送回浏览器。发送的内容是什么？不再是HTML了，而是数据。
- 数据返回到浏览器，浏览器只能自动呈现HTML，它不知道所谓的“数据”是什么？你说它怎么知道如何呈现它呢。茫然的地方也许就在这里。
- 数据其实被javascript代码接收并进行处理。记得DOM吗？我们可以使用JAVASCRIPT来控制DOM对吗？可以想象以下。javascript接收到数据同时操作DOM将数据呈现。这也是ajax和传统的web不同的地方。浏览器在传统的web下会自动的呈现HTML，而在AJAX的环境中不会这样。所有呈现的工作只能依赖JAVASCRIPT来处理了。
- 然后我们神秘的发现内容被更新了。
如果你是个很细心的人，你就会从这两种描述中得到一些关键性的东西。我来指明一下，请求都是一样的（本质上是不是，当我们暂时认为他们是一样的）然后是响应。两者都会给出响应，但内容却不同，前者给出的一定是浏览器可以解读的内容如HTML文本，而后者得到的响应却是所谓的"数据"，它不能被浏览器得到，只能依赖javascript来处理。
两个关键的不同：
- 传统方式中，发起请求就意味着浏览器的内容要被刷新。而后者导致的请求是偷偷的。
- 传统模式中，接受到的响应会被浏览器自动呈现在界面中。而后者是不会的。因为他得到的只是数据，呈现功能不再由浏览器帮你完成而是自己。
以上的两点导致了这两种开发模式注定是不一样的。虽然不是很不一样但一定不能坚持原有的开发模式了。
Ajax开发模式注定需要开发者更多的关注客户端的功能，甚至会将更多原本在服务器做的事情移动到客户端来做。如果你需要在客户端开发可靠的、高效的、受控的代码仅仅使用原有的javascript的编程方式（我们常使用的）能行的通吗？
