看到这里的一些观点与我自己的观点一致，我其实很欣慰：作为模板语言的 ASP.NET 很差。
我只想反驳这里提出的几个优点（穿上火焰服！）：
Dave Ward 提到了 ID 冲突——这是真的，但我的处理很糟糕。我更愿意看到由 xpath 或深度 css 选择器引用的节点，而不是让 ID 有效地无用，除非推迟到像 clientID 这样的 ASP.NET 内部 - 它只会让编写 CSS 和 JS 变得毫无意义地变得更加困难。
Rob Cooper 谈到了控件如何替代 HTML，所以一切都很好（解释一下，原谅我 Rob）——这不好，因为他们采用了一种现有且易于理解的语言并说“不，你必须按照我们的方式做事现在”，他们的方式实施得很差。例如，asp:panel 在一个浏览器中呈现一个表格，在另一个浏览器中呈现一个 div！如果没有文档或执行，登录控件（以及许多其他）的标记是不可预测的。你将如何让设计师为此编写 CSS？
Espo 写道，如果平台更改了 html，控件如何为您提供抽象的好处——这显然是循环的（它只是因为平台在变化，而如果我在那里只有自己的 HTML 就不需要了）和实际上会产生问题。如果控件将再次随着更新而改变，我的 CSS 应该如何应对？
辩护者会说“是的，但您可以在配置中更改它”或谈论覆盖控件和自定义控件。那么我为什么要这样做？旨在解决其中一些问题的 css 友好控件包是任何东西，但它是无语义的标记，它不能解决 ID 问题。
使用 webform 应用程序开箱即用地实现 MVC（抽象概念，而不是 3.5 实现）是不可能的，因为这些控件将视图和控件紧密地绑定在一起。现在对于传统的网页设计师来说有一个进入障碍，因为他必须参与服务器端代码来实现过去是分开的 CSS 和 JS 领域。我很同情这些人。
我非常同意 Kiwi 的观点，即控件允许对特定配置文件的应用程序进行一些非常快速的开发，并且我接受无论出于何种原因，一些程序员会觉得 HTML 令人不快，而且 ASP.NET 的其他部分给您带来的优势，这需要这些控制，可能是值得的。
然而，我对失去控制感到不满，我觉得在代码隐藏上处理类、样式和脚本等事情的模型是一个错误的倒退，我进一步觉得有更好的模板模型（微格式和 xslt 的实现）这个平台）虽然用这些替换控件并非易事。
我认为 ASP.NET 可以从 LAMP 和 Rails 世界的相关技术中学到很多东西，在此之前我希望尽可能使用 3.5 MVC。
（抱歉这么久了</rant>）