题记：此篇文章没有什么特殊的意思，只是希望大家能从中悟出些什么，我们没有最终决定哪个对，哪个错。这个辩论由我引起，从
老赵的Blog开始，欢迎大家提出观点和意见。
2007-03-29 02:20 by Jeffrey Zhao
@Bing
您第一段对于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其中之一。但是导致滥用并非表明这个技术是不好的。不好的，做错的，都只是开发人员而已。
因此，说到底，还是我一直强调的东西，开发人员的培训非常的重要。
还有，您的最后的PS，我非常赞同，我希望有机会能够和您好好的聊一下。:)
2007-03-29 08:08 by 怪怪
@Bing
呵呵，我最在乎的就是这个尊重，尊重，还是尊重。我也说过类似于你说过的话去说别人，一般是我真确认对方有明显的倾向性，或者是对方有商业意图；即使这样，最近我说的也比以前少多了，这给别人带来愉快的同时，很重要的是让自己也能避免不愉快。另外一点是，无论是技术，还是其他网上的讨论，或者是一些其他方面的博客什么的，很常出现的就是臆测其它人的水平如何，比如说大多数人都怎么怎么样，把目标读者当成了什么什么样。这个我特别反感，因为实在是无利于讨论，如果每个人尽量把其他人都当成自己师傅一个级别，比较能够让大家顺利进行下去。技术以外的不讨论了。
你用FireBug看看Atlas的真正传输量吧，如果只有核心的话，大概是24KB，如果加上UpdatePanel所需的，大概是32KB。但实际上即使核心还能精简。比如PageFlakes精简过的Atlas核心文件，不超过18KB，而PageFlakes最大的JS，全都是与Atlas无关的，它自己业务需求的JS，相比全部JS的大小，这18KB哪怕32KB，无关痛痒。说到PageFlakes，对于其作者Omar来说，这点JS小意思了，就是我上贴所说，其实你自己做，随着需求的增加，也要做这些东西，所以不如直接拿来，如果水平达到像你一样，也绝对不存在什么扩展性、维护性的问题，恰恰相反，由于JS的特性，微软的分类和扩展方式在很多时候仅是一个整理事物的指导。
再说回ASP.NET本身，一些问题首先澄清一下，以你的水平，页面生命周期一定是不在话下了，大多数控件在打开ViewState的情况下，实际上相同的数据不需要第二次取数据库；当然这导致ViewState过大，问题是ViewState也不见得一定要传输到客户端。(以上这些话是给不了解生命周期的人看的，防止别人对你的话断章取义。)关键的问题是怎么灵活应用上，在我看来，所有的问题都是咱们如何认识事物的问题，该不该维护状态，用什么方式怎么维护状态。这个对事物的认识是普遍的，比如现在Java社区讨论高深OO知识的很多，甚至更超前的也大把抓，但诸如“两个类有相互联系，但到底是A has B合理还是B has A合理”这样的问题，我想都不是每个人都很清楚的。问题是就这种简单的认识，对日后的扩展、维护，带来的影响要远远大于咱们是不是能把23种设计模式用全。
不过，即使我的论调有一半是老赵说的，不是东西的问题、是你怎么用的问题，在ASP.NET的结构上，我比你还激进，我对目前的状况看法是，对开发者的限制、负担大于帮助。不过ASP.NET设计师的出发点是好的，每一个概念在目前的业界的认识水平上可以说也是绝对正确的，主要问题是组合的不正确；这种不正确一方面来自于很多东西是新的他们在一些方面也欠缺经验，另一方面，他们的工作量不足以用正确的方式去组织，因为组织本身要耗费的精力远远大于实现一个Web框架。但只要微软的人、SUN的人没一直睡觉，总会进步的。
效率问题，你可以参照php5和php4大概几倍的差距。到底什么时候效率重要？效率重要到什么程度？ 我想这帮子大师未必永远正确一贯正确，但他们做出的决定有时候可以作为一种参考。比如博客园的.Text吧，比你说的那种情况按理说效率还低，也承载了这么多人。影响效率的有多种因素，改进效率也可以从不同的点切入。一个简单的输出20行Html代码方法，在.NET里确实很可能一个调一个，叠了甚至好几十层，这个很可怕，但很多时候并非不能接受的，因为在其他方面的益处抵消了这种开销。
不知道你做过压力测试没有，静态文件在PD 2.8G，普通SATA硬盘上大概是1500个请求每秒，一个复杂的页面如果没有OutputCache大概是300多个，加上OutputCache就是1000个不到。而且我们还有静态化的手段，提到静态化，又得考虑静态化的方式和时机。我说这些东西是表明一点，效率是一个很大的问题，如果联系起来看就变得一环扣一环，不是简简单单考虑我程序执行快慢即可的。可每考虑一个环节，又引出其它问题。但综观所有解决效率问题的手段，最有效的永远也论不到页面执行效率上，因为可改进的方式，根本性的方式太多了。比如我举个反面教材，象DELL的开发人员应该不至于水平太差，他们的网站也运行了很多年了，你看他们的页面，看不到ViewState，看不到传统的由大大小小一堆INamingContainer起的名字，可不照样慢？
我有一个基调就是，先尽可能的学习，而不是着急否定现有的东西，在自己生涯的很早的阶段就着急怎么样，志要立，但过于快速总是不能长好，中国技术人员前进的道路，实际上就是柏拉图讲的那个挑最大的麦穗的故事，前1/3看，中间1/3验证，在最后1/3，我们就能更有把握的把事情做成。说到这里，觉得我说的都是反对的话，其实不是这样，你的工作和努力非常的有意义，如果没有你这样热情的人和老赵这样的宣讲者，国内的进步肯定要变慢。我只是尽我所能的多那出些“他山之石”，希望对你能有点帮助。
你的控件动态加载部分，能不能说个大概的步骤？ 我在这方面过去也做过一些工作，所以感兴趣是不是有所不同，另外也许我能提供一些经验 :)。我最近为了防止过多地聊天(因为快没饭吃了)，不太方便留联系方式，你如果愿意简单介绍一下，可以直接在这里回复我，老赵这里现在就是我的大本营了 :P。