我正在尝试决定如何处理面向外部的 Web 应用程序的 UI。因为它是外部的，所以由页面膨胀引起的延迟可能是一个问题。
我过去使用过一些 jQuery，现在我正在评估 Telerik 控件。我看到了很多关于 Telerik 控件的好建议，包括 StackOverflow 上的一些建议。事实上，它们看起来确实功能齐全。我也毫不怀疑使用这些控件可以比使用 jQuery 更快地开发应用程序。但是，我担心它们会在我的页面上造成过多的膨胀。
你们中的任何人都有将这些控件的性能与纯粹的 jQuery 实现进行比较的经验吗？具体来说，
任何其他相关信息也将是有用的。
我已经使用 Telerik 和 JQuery 多年了。“全功能”通常等同于大量臃肿、您不需要的功能以及难以（或不可能）优化的最终页面。放弃 Telerik 并使用像 JQuery 这样的裸机框架。你会发现它可以让你构建你需要的特定功能，而且你永远不会回头。许多功能齐全的 UI 套件（如 Telerik 或 ComponentArt）非常诱人，但我认为它们鼓励了很多糟糕的编程。
例如....您真的需要在您的网格上放置可拖放的列吗？可能不是。最好有一个设计区域，您的用户可以在其中布置他们的列首选项，然后是网格活泼和轻量级的主视图。不要渲染用户永远不会（或很少）在每次页面视图中使用的兆字节的附加功能。
很好的讨论在这里。一些澄清：
不过，作为一名长期的 Web 开发人员，我总是鼓励人们使用正确的工具来完成这项工作。如果您不需要 RadControls 的强大功能、可访问性支持或大量文档（以帮助将继承您的应用程序的人），请不要将它们用于您的站点。如果您只需要基本的 UI，jQuery 可能就可以了。不过，我倾向于发现，当开发人员可以为用户提供高级功能（我们有时认为是“臃肿”）而不做额外的工作时，用户对最终产品的印象要好得多，并且发现它更容易使用。
最重要的是，请记住，在大多数情况下，您通过构建应用程序而不是 UI 组件为您的公司/客户创造价值。因此，除非有充分的理由重新发明轮子，否则通常最好使用已经构建和测试的东西来解决您面临的问题。
希望有帮助。-托德
关于 Brian C (et al) 面临的“错误”和其他挑战，我认为这里值得进一步澄清。作为开发人员的拥护者，我不会假装 Telerik 控件是完美的——凡人编写的任何软件都不完美。那么重要的是如何解决这些错误。
人们常常忽视公司（或开源项目）如何解决错误，直到为时已晚。无论你使用什么工具——jQuery、Telerik，甚至是微软——你最终都会遇到错误。Telerik 擅长的地方在于为这些问题提供快速修复和非常全面的支持，以帮助您尽可能提高工作效率。如果您有问题，Telerik - 将 - 帮助您解决问题。对于其他公司，尤其是开源公司，这并不总是保证。
所以请记住：无论您使用什么工具，您都会遇到错误。确保您选择具有支持的工具，这些工具可以响应您的问题并快速修复它们。因为我知道我的观点不可避免地存在偏见，所以我会让 StackOverflow 上的其他人确认或否认 Telerik 的支持质量。
Telerik 控件确实看起来有点臃肿，但我怀疑您是否能够在 JQuery 中实现类似的功能而无需付出很多努力。
这真的取决于你能忍受多少膨胀。如果它是用于 Intranet 应用程序，那么这并不重要，但是当您指定面向外部时，这可能是一个问题，这实际上取决于用户的平均连接速度以及他们的计算机/浏览器的速度最终将运行控件。
另一个重要的问题是：您是否想在一个使用量远低于 JQuery 的专有工具集中标准化您的 Web 应用程序？我怀疑 JQuery 会很快倒闭。
万一以后它对任何人有帮助，我已经抛弃了 Telerik 工具，现在只使用 jQuery。我们会看看我是否遇到了我不能做的事情。我对 Telerik 工具感到失望。我听说过很多关于它们的好东西，但它们对我来说效果并不好。这是我在评估 Telerik 工具时发现的。
Telerik Ajax 工具在处理主页面/内容页面设置时存在问题。他们在他们的论坛中承认这一点，我猜他们正在努力。不过对我来说很成问题。
我看到了许多似乎没有任何文档的意外行为和怪癖。例如，当使用 Web20 皮肤和表单装饰器时，在执行 Ajax 时，字段集上的圆角会变得糟糕透顶。
Telerik 工具大大降低了我的开发机器的速度，并且似乎导致我的环境出现问题。我几乎从未遇到过崩溃或内存违规的情况，而且在使用这些工具时，我在两天内遇到了四次。距离我之前的上一次可能已经一个月了。
因此，将所有这些与 jQuery 是免费且轻量级的事实结合起来，选择很容易。最初可能需要我更长的时间，但最终结果会好得多。
您的 UI 要求将对这个决定产生最大的影响。我不认为 Telerik 控件在功能方面可以与 jQuery 相提并论。如果您需要服务器端控件来显示数据，请根据其他竞争控件评估 Telerik。
我使用 Telerik 控件并且还为源代码付费，因此对于它们的停业，考虑到源代码，这不是一个大问题。我没有在面向公众的网站上使用 Telerik 控件的具体经验，但我毫不犹豫。有时我被指示使用 JQuery 来实现控件没有的附加功能。
我遇到的一个问题是，由于您自己没有使用控件（不仅仅是 Telerik 的）来编写所有这些功能，因此将各种有趣的东西拖放到您的页面上真的很容易，这将为每一页添加处理。话虽如此，请尽量减少对它们的使用，我认为它们不会比手动编码的 JQuery 实现更臃肿。
RadScriptManager 与 MS Ajax 脚本管理器不同，因为它有一个 EnableScriptCombine="true" 属性，您可以设置该属性，以便将 Telerik 控件使用的所有 javascript 文件合并到一个 .js 文件中以提高性能。
最初，rad 编辑器运行得很慢。但是最新版本要快得多。此外，他们还聘请了不断努力改善控制的员工。
我不知道任何接近 RadGrid 的东西。它非常强大。我现在在一个 Intranet 应用程序上使用它，到目前为止它运行得很快。我正在使用它的所有功能，Group By、Export to excel 等。
也就是说，如果我正在创建一个供外部使用的 Internet 应用程序，我会使用 JQuery 而不是 Telerik。这样你就有更多的控制权。
我们将 Telerik Editor 用于我们的 Intranet 产品，我不得不说它在使用、自定义、升级等方面比我们以前使用的任何编辑器都好得多。
如果您需要一些高级功能和/或更复杂的控件，而Telerik 提供了这些，我会说现在将它们注销还为时过早。如果您只需要 jQuery UI 可以提供的基本 UI 功能，那么将 jQuery 用于这些特定部分。
没有必要选择其中一个。使用多种工具来完成工作。
我认为 Telerik 宣布他们将在客户端使用 JQuery。
Telerik 刚刚开始将更多时间投入到对其 RadGrid 的客户端支持上。到目前为止，我对网格感到失望。我为他们感到难过，因为他们基本上必须维护 2 个代码库：一个用于他们的服务器控件，它基于 Postbacks 和 ViewState 在 C# 中重绘所有内容，另一个用于客户端控件，它在 javascript 中重绘控件的一部分（有点像他们的 C# 代码到 javascript 的端口）。这对他们来说是一大堆工作，到目前为止我觉得它是不完整的。
例如，对其网格当前版本 (ASP.nET AJAX 2008.3.1105.35) 的客户端支持不包括：
NextPrevAllowNaturalSort="false"话虽如此，如果您愿意将 Telerik 控件与传统的 Postback/Viewstate 渲染一起使用，那么我会说没有 jQuery 网格可以与之竞争。
我通常不会在这些事情上发帖——但我无法抗拒这一点。我在 Telerik 上使用了 jQuery / jQuery UI。我真的很喜欢他们在演示页面上的内容——然后我试图让它发挥作用。我在丝带栏上挣扎，并向他们展示了一两个错误。他们是它很快就会被修复......它不是......然后下一个版本......它不是。最后他们有一个测试版，并让我为他们测试它——真遗憾。他们的东西确实很漂亮，但我无法处理那些无法正常工作的东西。
我已经使用 jQuery / jQuery UI 大约 6 个月了，我喜欢它。便于使用。轻的。做它所说的。也许不像 Telerik 那样功能齐全，但可以理解，只需几个脚本即可放入您的项目中。我也很喜欢Themeroller。
我已经使用 Telerik 进行控件 3 年了。我终于意识到我爱上了这个想法，但控件本身非常有问题，实施起来很烦人，最终花费了我更多的时间来构建自己。我绝对建议不要使用 Telerik。
我与jQuery和一起工作过Telerik。Telerik官网的demo看的很花哨，但是使用的时候感觉很重很慢。有了jQuery您，您就可以编写轻巧高效的代码来满足您的需求，但需要更多时间。在性能方面，我建议在服务器而不是客户端浏览器上呈现最初的繁重 HTML 结果。（例如大网格）