我其实并不觉得我在推崇ASP.NET AJAX，我只是觉得这是ASP.NET平台下最好的AJAX解决方案，再加上感兴趣，因此一直再对它进行研究和推广。
“实际开发中真的需要这个东西吗？”关于这个问题，我想说的是，如果您的应用需要使用AJAX，那么ASP.NET AJAX框架应该是ASP.NET平台下最先考虑的框架，它能极大地简化AJAX开发。
“它过于庞大，对效率的大打折扣”庞大，我想应该您指的是客户端吧？服务器端的程序集再庞大也不会影响什么，而且其实它也不庞大。至于客户端，可能只是添加了一个100K左右的JS文件吧，加上缓存，它不会对性能造成很大影响的。
“扩充性、维护性的贬值”。其实ASP.NET AJAX对于AJAX功能的良好封装已经大大提高了可维护性了，我在真实项目中使用的经验来看，它并没有带来什么维护性方面的损伤，反而它比其他的AJAX解决方案要好很多。至于扩充性，您是指什么呢？
不过我可能的确需要强调一下，什么时候应该用AJAX，什么时候不该用，这并不是框架本身的问题，而是整个AJAX技术应该探讨的。
至于我说的这个“UpdatePanel的AJAX上传”，这里的AJAX的确只是指“AJAX形式”。:)
但是我认为这个扩展是很有必要的。现在我做的，并不是“为了无刷新形式上传”而作的组件，而是“为了让UpdatePanel兼容上传组件”。这是使用UpdatePanel时的一个扩展，为了让UpdatePanel更好地工作，方面大家的开发。
老赵说的我就不重复了。我说说我的想法，PageFlakes，虽然没有用ASP.NET AJAX框架，也用了AJAX的客户端文件，如果你有一种需要，你就免不了要承担这种需要的开销，区别只是到底是prototype.js还是其它的。关于框架本身，前一阵子我回老赵一个贴，说感觉ScriptService没有必要，我都是自己写Handler自己封装。但是对我来说，有这么一个理解：面向对象式的抽取，对于JS比对于C#还重要。抽取出来的共同部分越多，代表着发送到客户端的代码越少。最后我的做法导致，如果我不抽取，我的代码体积就会很大，我自己封装，写出来的东西字节数比ASP.NET AJAX小不到哪儿去，可工作量却明显的增加。
对于老赵搞得这个上传，我个人也持保留态度，UpdatePanel，就如Omar所说，在一个非AJAX应用到AJAX应用的提升，我赞成这种方式，因为反正也是那些开销，多些脚本就少些刷新。但对于复杂一些的应用，肯定还是单独开发的好，因为UpdatePanel主要是两点，服务器端开销大，可扩充性有限。前阵子下了个R.A.D还是谁的带进度条的上传，打算无耻一些，等闲下来Reflector之，简化后实现一个控件，并把客户端移植到基于Atlas(减小同样功能的代码的体积)。
对于Cat Chen同志的RoR论，我也持怀疑态度。我不相信比如说我实现一个无刷新、带进度条的上传，用RoR还是使用Atlas能有什么区别，工作量能有什么差异，如果真为了追求编写客户端的效率，那一定是Orcas，甚至Script#，RoR能给我做什么？当然除非RoR那边已经有这样的东西，我白拿过来用，但同样的，我实现一个这个，也照样可以白给别人用。也许我说的不对，但确实没时间细了解，如果你现在确实在RoR的认识上超前大家一截，不妨说说这样一个应用，ASP.NET怎么做，RoR怎么做，一对比，实事面前谁不服都不服行不是:) ?向我这样的现实主义这立马倒戈投诚，毕竟现在我看到的事实就像Scott说的，二月份第三方统计的全球六大网站，4个用的ASP.NET，其中MySpace和Ebay也不是微软的站，甚至一些部分是从其他技术移植到ASP.NET + SQL Server，并获得了改进的。哪怕把这4个网站用Alexa那种不靠谱的排名，也都是前20，这前20还得加上Google的Orkut等好几个ASP.NET站。对于我这种人浅薄的见识来说，即使微软给了相当优厚的条件，这些公司也不想搞砸他们的根本，所以显然ASP.NET还是靠的住的玩意儿~ 不过得重申一点，我不认为RoR不好，因为我不了解，但我相信ASP.NET或JSP都能变得更好，而且我自己在快速开发上找到自己的方式的话，使用ASP.NET也能做到RoR表面上看所能带来的一切，至于我看不到的非表面的东西，这就需要先行者带路了 :)。
返回到Bing身上，我开始以为你没有深入这一块才会说出一些话。比如异步提交之类的，你用Atlas，完全可以只用它的这一部分，你自己写的不会比它有什么不同，只要你敢于随便用，Atlas比你自己写也不会有什么不灵活，最终就变为一堆素材(你的也罢，微软的也罢，其它的也罢)，如何组织的问题。至于老赵的本意只是方便那些目前需要UpdatePanel提高工作效率的人。幸亏我发帖前开了你的站，真是有眼不识金镶玉，原来你有自己的玩意儿后头藏着呢 :)。不过最后还是要说，Atlas的效率未必像你说的的那么低，至于跟不跟风这种问题，无论跟Prototype.js还是AtlasCompact.js还是自己构建，都不是太难的、影响个人竞争力的核心技术，不愿意自己费劲琢磨和当年选取方向时的随机性罢了，也不必把大家都看成傻乎乎老外说什么是什么的傻子。
首先我要给您道歉一下，上次说话我没有注意分寸，也没有认真准备好我的言词，说话鲁莽了，真的很不好意思！这次我想理性的和您交流一下（可能以我的辈分和身份完全及不上您，但是请允许我现在的所知和浅薄，谢谢了啊）。首先是对效率的理解，很不好意思，这个东西我上次并没有讲清楚，从效率上看，主要是一个在服务器端还有一个在客户端，两者兼而顾之应该才称的上效率。ASP.NET目前的问题不是效率上的问题，而是实际开发的问题。我不是把别人都当成傻子（我从来也未曾这样想过），而是对ASP.NET的一些做法提出自己的一些想法，ASP.NET目前将表现层、逻辑层甚至实体层都进行了从头到尾的封装，这个做法很好，并且极大的减低了学习者的门槛，可以直接进入事件机制的开发模式。然而给开发者（尤其是初学者）带来的问题是：如何深入？ASP.NET通过UniqueID、ViewState、Session等等数据格式提供了一个很好的保持状态的机制，然而是以损耗资源为前提的，于是我们很容易看到ASP.NET开发出来的网站的速度往往很慢，如果看看源码，会发现里面有很多的ViewState，各种奇怪的名字，各种奇异的Javascitp，并且回传一次是回传的整个页面的数据，因而回传的数据量比较大。另外由于很多数据都是动态读取的，并且喜欢使用DataSet，很多并不需要刷新的数据也要从数据库里再读一次（当然缓存是另一种解决方式）。因而一般情况下ASP.NET的网站速度慢，这个不足为奇。
好了，觉得扯远了。我并不是要否认掉ASP.NET的东西，事实上我对ASP.NET这样一个东西相当的热衷，它的理念、模式、设计方法让人很着迷。问题嘛，只是它封装的过于好了，对于初学者来说既是一件好事也是一件坏事，当然会有一个逐步深入的过程。那么对于ASP.NET Ajax，我深入分析过它的源码，很让人震撼，微软居然能将Javascript变成像C#一样的功能，如果说要使用Ajax库的话，我的感觉是没有什么比得上ASP.NET Ajax，当然是否需要这样做，这是一个问题。另外就是ASP.NET Ajax这个东西的效率问题，出了上面一段的ASP.NET 本身就存在的问题外，我们还可以继续下去 。如果仅仅只是在传统的页面上加入几个UpdatePanel，然后实现一个分页、排序什么的功能，我想这个就达不到Ajax真正的功能。实际上我想的更多的是如何将整个网站桌面化，于是我们传统的所有页面最终都要归到一个页面，对于把握不太准确的人来说，这个无疑会对服务器端的效率造成影响，事实上我所知道的管理服务器的人，也都说ASP.NET的网页的确很耗服务器的资源。另外一点就是客户端这样一个效率，Javascript在客户端运行并没有什么效率问题，问题在于回传，首先是JS文件大小的问题，一般情况下，压缩过的JS文件，就核心部分是100多K，这个数据不小，我只能这样说。其次当你使用一个组件的时候，就会加上相应的Javascript文件，这个文件虽然一般只有三四百行，但是也绝对不少，因为我们要使用的组件往往不只一个。另外，据我分析，ASP.NET Ajax 并没有做到该回传的回传，不该回传的不回传，而是传统的将客户端的所有数据传递到服务器端。然后从服务器端渲染的组件不是一个UpdatePanel里面的组件，而是所有组件，只是传递给客户端的是UpdatePanel里面所有的字符串，如果组件过多，特别是桌面式的开发，毫无疑问，是不必要的损耗。因而会发现这样一些问题：ASP.NET Ajax并没有怎么改变传统的开发，而是改变了某一个页面的一个局部的开发；ASP.NET Ajax并没有使速度快多少，而是没有刷新；ASP.NET Ajax并没有使页面的打开速度加快，而是减慢，服务器越是不好，越是慢。这些是我实际开发当中的体会，空穴来风。当然也有可能能力有限，并不能掌握其中的精髓。
另外说说我对“扩充性、维护性”的理解，对不起，我只是一个业余的爱好者，对这个词的使用并不专业。通过我的开发经验，如果所有的开发都让微软给我们的一套开发模式来看，实际上我们能发现所有的逻辑和代码可以全部放置到表现层，开发速度很快，也并不需要掌握太多，只是我发现的问题是：当开发的产品需要升级怎么办？我往往只能重新来一次。因而这样一种方式对我所理解
“扩充性、维护性”是相当低下的，实际上在以后的开发中我更喜欢将不同的开发归结到不同的层次，这样的好处是我花了一个通宵+两个下午的时间就将我的Blog系统从Access移植到了SQLServer上。ASP.NET Ajax虽然封装的很好，但是由于组件过多，往往使得逻辑层过度依赖于其组件，而导致自己维护起来的问题有点大。
最后我还是想表示一下道歉，我并非有意攻击任何人，请您原谅我的话语。此外，我想和您探讨一下Ajax本质的东西，Javascript这一门脚本语言本身并不是用来搞开发的，而是用来实现客户端的一些功能，比如验证、交互，其初衷是为了提高交互性和用户体验。目前Ajax可以说是对逐步被人们所重视的交互Web的一种想法，这个想法基于数据本身的膨胀和不比要的数据垃圾而提出的，同时没有什么新的东西，一种纯粹的理念，因而很快被人们所接受，同时它减少了回传、减少带宽的占有、减少了服务器的压力，最终达到的效果是提高用户体验，因而我十分的赞同这种做法。然而人们逐渐发现Javascript能做的东西比人们最初认识的要多，于是出现了不少Javascript原本所不能及的事情，比如模仿软件操作、模仿桌面操作，甚至直接将MVC模式照搬到Ajax上来。我的感觉是“无聊”。Ajax并不擅长这些，也并不需要这些，Ajax只是一种用来提高用户体验的工具，而不是人们所畅想的万能的上帝。我希望在Ajax风气逐渐在国内蔓延的时候能认识这一点，开发不是停顿在客户端，更多的依旧是在服务器端。当然如果您不同意，还请多多指教。
@怪怪
看了您在我blog上的留言，还真怕找不到您呢！呵呵，别以为我是来找茬的，我是来道谢的，您让我认识到了自己的潜在的毛病，十分感谢。同时有几点我想答复您一下，当然这不是什么攻击，而是一种交流，希望我的言语没有什么让您看到了不舒服的地方，对于像您这样有着许多开发经验的人来说，我往往抱着无限的敬仰。
首先我想说的是，我并没有什么值得炫耀的地方，无论是经验上还是资格上，我并没有“老王买瓜”的任何想法，因为我分析过ASP.NET Ajax和Magic Ajax源码，并不是稍微研究了一下，而是整体的研究过，认真阅读过源码，并尝试去理解它对整个回传、渲染机制的把握。因而我说的那些话并不是为了突出自己的好，而胡说一通，而是通过我的实际开发而验证过的，我想我的Blog系统应该是个不错的例子，如果您细入的了解一下的话。当然如果您有兴趣的话，可以让您分析我的源码。我也并没有特意说明自己的无组件模式是一件什么大不了的事，更没有完全否定掉控件的意思，要不然这么多天才做的开发工作不就白费了。虽然您的理解可能与我的本意不太符合，我只是想说明一下ASP.NET 控件的实质，以及增加人们对控件的认识，控件从何而来。如果您看过一些别的介绍，实际上我非常清楚的说明了它的弊端和不好，但是我的确发现将整个网站当成一个页面考虑的话，控件会变得异常的多，把握不好的确会产生很大的浪费，无组件只是一种思想而已，更没有认为任何人都是采鸟的意思。我更倾向于动态加载组件，不可能摈弃组件而回到ASP的时代。
另外，对于您其他的几点观点，我虽然不赞成，但是也没有反驳的理由，因为您和我站在两个完全不同的观点看待问题，我是站在自己开发的立场上而看待的，而您是站在整体上来看待整个问题的，自然我的目光可能不及您的视野。ASP.NET Ajax的确是很完备，这是任何一个大型框架所应该考虑的问题和应该的实现的，只是我觉得可以从另一个层次来了解完备，完备的.NET Framework的确可以在服务器端有非常出色的表现，但是并不意味着客户端也应该需要承受同样的压力，Ajax TXT的正式版只有十几K？这个我不敢想象，据我所知，最基本的框架就有100多K吧？这个不是个小数目。同时还有很多控件都有各自对应的Javascript代码，并且代码量都不是一个小到可以忽略不计的数目。于是我想的是，对于小中型的开发，Ajax TXT过于臃肿了一些，还有其他关于回传和渲染机制方面的问题对@Jeffrey Zhao 的回答中我已经阐明了。如果对于大型开发，特别是当速度和效率对本身开发没有什么影响的情况下，我当然乐意选择Ajax TXT，因为微软做的的确很棒。
最后嘛，得谢谢您，我为我上次的评论而表示抱歉，您指出的很好，也很深刻，的确，人们需要尊重。在现在这个时代，我想需要的更多的是对技术本身的把握，而不是一味的追求技术，更应该认识到技术本身的艺术和问题，因而人与人之间需要的更多的是讨论，而不是一味的强调什么对，什么不对。对于您这点，我非常赞同。
PS：Ajax是激起了人们内心深处和机器交流的愿望，Adbe、Microsoft、Sun等公司都在为这个外来的市场而针相提出相应的解决方案，当然对于一个中国人，我也非常希望能有一批异常优秀的年轻人站出来，站在技术的前端，充分认识已有的和没有的，过去的和将来的，开发出一套属于国人自己的技术，虽然很难，但是我们一直努力着，拼搏着。
您第一段对于ASP.NET的评价很正确，的确ASP.NET的门槛很低，导致了很多粗制滥造的项目，这个我也深恶痛绝。但是其实合理使用ASP.NET的话，性能其实也不会差的。
不过您第二段的说法，我不能同意。我不是不同意您的评价，您的评价完全正确，但是我觉得只是没有理解UpdatePanel这么做的原因。UpdatePanel这么做，它并不是为了降低传输量，而是为了让AJAX体验可以很方便地使用。例如，您已经有了一个页面，您几乎不需要动什么代码，就可以使用UpdatePanel把AJAX效果带入您的应用。这就是UpdatePanel的优势，这也是为什么UpdatePanel会把页面上所有的信息传回服务器端的原因，因为它的确需要所有的信息来重建整个页面。它其实就是等同于普通页面PostBack的状况，唯一的区别只是输出。所以UpdatePanel的初衷就不是利用AJAX提高性能（当然Response数据量是降低的），而是为了更好地使用AJAX。
还有，ASP.NET AJAX不会“扩充性、维护性”方面的问题啊，使用ASP.NET（注意不是ASP.NET AJAJX），的确容易把所有的逻辑之类的内容都放在表现层（我这里的理解就是aspx/aspx.cs），这的确是不好的做法，但是这还是开发人员的毛病。我认为这和ASP.NET本身无关（或者说还是ASP.NET的易用性导致的问题），与ASP.NET AJAX就更加无关了。至于您说的“微软给我们的一套开发模式”导致了“逻辑和代码可以全部放置到表现层”可能是您接触了很多官方提供的“演示功能”所致，它们的确只能用来“演示”。微软对于使用ASP.NET开发企业级项目从来没有建议把“逻辑和代码”都放在“表现层”过，您可以关心一下MSDN Patterns & Practices上提供的内容，微软提供了企业级应用架构的很多实践。至于如果您说现在AJAX应用导致JavaScript代码增多，从而导致了“扩充性、维护性”降低，那么……其实还是“使用”方式问题。JavaScript语言本身完全不应该，也不会带来维护性的问题。
至于您最后一段对于JavaScript的评价，我只能说我同意一小部分。我认为JavaScript完全可以用于开发一个大型的应用，有的应用也必须大量使用JavaScript进行开发，否则用户体验无法提高。既然需要用到大量的JavaScript开发，为了增加可维护性可扩展性，引入一些模式例如MVC是再正常不过的事情了。您觉得“无聊”可能是因为您对于JavaScript有些“偏见”。当然，就像ASP.NET AJAX的一个初衷一样，就是尽可能的在服务器端进行编程，而JavaScript都是自动生成的——这是最理想的状况。JavaScript不是玩具，它是真正可以用于开发的语言。它的确不是万能的上帝，但是有什么是呢？JavaScript也只是在它最合适的领域产生最大的价值。任何技术都会导致“滥用”，AJAX其中之一。但是导致滥用并非表明这个技术是不好的。不好的，做错的，都只是开发人员而已。
因此，说到底，还是我一直强调的东西，开发人员的培训非常的重要。
