传统的Web应用程序通过在客户端脚本生成算法里嵌入逻辑来减少服务器的加载，同时增加用户参与。表单验证、数据排序和分页功能通常都是在客户端使用用户信息框、动态文本元素和弹出菜单完成的。这样的客户端脚本需要用户相当多的参与，却几乎不需要和服务器交互操作。通过向客户发布特定功能的计算需要，传统的Web系统能轻易获得一些东西——不需要额外服务器加载的动态功能。大多数流量巨大的公众Web网站，在没有相当数量的客户端脚本的情况下，无法调整其用户库（或者实现期望的交互操作）。
微软的.NET为Web应用程序提供了更加广泛的功能集。对于习惯于生成大量客户端脚本的人来说，.NET对服务器端编程的侧重可能让他们觉得不太适应。在适应新模型以前，开发人员不得不学习：如何在不牺牲应用程序的反应能力或者可伸缩性的条件下，对服务器上最佳事件处理周全地应用回传（postback）。在对生成的服务器控件分派事件驱动的、基于浏览器的功能时其他的挑战又出现了。
微软的.NET努力减轻和大量客户端脚本编写相关联的开发和维护工作。使用Visual Studio .NET Designer及其拖放功能，开发人员甚至可以不编辑任何实际的表示脚本就能基本开发出整个ASP.NET应用程序。Visual Studio .NET能让客户脚本的生成自动化。虽然在一个更加通常的开发场景中，既会用到拖放操作，又会使用Visual Studio .NET Code Editor进行的手工脚本编辑，开发人员仍被局限在编辑任何Web控件的服务器标签。这样开发人员就完全从它隐含的JavaScript或者HTML中脱离出来了。
传统的客户端开发人员也许会对自动生成JavaScript的概念耿耿于怀，但是Web控件在消除跨浏览器开发的困难上走过了一条很长的路。ASP.NET在生成和大多数浏览器和浏览器各种版本兼容的浏览器代码上采用了复杂的算法。而且，ASP.NET为浏览器生成的HTML （而非DHTML）并不支持DHTML。
Web控件能减少自定义表示代码编写工作的强度，这不光是通过自动生成JavaScript代码实现的。Web控件事件模型能激活复杂的、详细的、基于事件的服务器处理，这对客户／服务器或者独立的应用程序提出了挑战。当然这里的关键是基于服务器事件模型里的服务器。为了利用Calendar、DataGrid、Button，或者其他任何Web控件的强大功能，所有重要的处理都必须在服务器上完成。微软的.NET减轻了维护和开发客户端脚本的工作——但是这样做会极大地改变传统Web编程的客户／服务器平衡。.NET应用程序的成功实现需要这个新的侧重点。
