Telerik UI 控件与使用 jQuery 的客户端 UI

StackOverflow https://stackoverflow.com/questions/428376

  •  06-07-2019
  •  | 
  •  

题

我正在尝试决定如何处理面向外部的 Web 应用程序的 UI。由于它是外部的，因此页面膨胀引起的延迟可能是一个问题。

我过去使用过一些 jQuery，现在正在评估 Telerik 控件。我在 Telerik 控件上看到了很多好的推荐，包括 StackOverflow 上的一些。事实上，它们看起来确实功能相当齐全。我也毫不怀疑，使用这些控件比使用 jQuery 开发应用程序要快得多。但是，我担心它们会导致我的页面过于臃肿。

你们中有人有将这些控件的性能与纯 jQuery 实现进行比较的经验吗？具体来说，

  • Telerik 的 RadScriptManager 真的比 MS Ajax ScriptManager 更好吗？
  • Telerik 控件是否存在总体性能问题？
  • 是否有任何类似于 RadGrid 网格功能的 jQuery 插件？

任何其他相关信息也很有用。

有帮助吗？

解决方案

我已经使用 Telerik 和 JQuery 多年了。“功能齐全”通常意味着大量的臃肿、不需要的功能以及难以（或不可能）优化的最终页面。放弃 Telerik 并使用 JQuery 等裸机框架。您会发现它将允许您构建您需要的特定功能，并且您将永远不会回头。许多功能齐全的 UI 套件（如 Telerik 或 ComponentArt）非常诱人，但我认为它们鼓励了很多糟糕的编程。

例如....您真的需要在网格上添加可拖放的列吗？可能不会。最好有一个设计区域，用户可以在其中布局他们的列首选项，然后是网格快速且轻量级的主视图。不要渲染用户在每次页面视图中永远不会（或很少）使用的兆字节附加功能。

其他提示

这里讨论得很好。一些澄清：

  • Telerik 确实在内部使用 jQuery（并且现在 MS 支持它，将会越来越多）来增强许多控件的客户端功能（并减少客户端代码）
  • jQuery 是一个非常适合 JavaScript 开发的客户端库。但是，如果您需要解决可访问性问题，那么您就会对 jQuery UI 实现感到困惑，因为它们的所有功能都依赖于 JavaScript。Telerik 的独特优势是您可以在客户端和服务器端进行渲染，这意味着您可以支持未启用 JavaScript 的客户端。
  • 对于许多 Telerik 控件，您可以 A) 通过禁用功能（由于内部按需加载脚本逻辑）来消除页面上的额外代码，或者 B) 通过使用提供的脚本组合器和压缩机。

不过，作为一名资深的网络开发人员，我总是鼓励人们使用正确的工具来完成工作。如果您不需要 RadControls 的强大功能、辅助功能支持或广泛的文档（以帮助将继承您的应用程序的人），请不要将它们用于您的站点。如果您只需要基本的 UI，那么 jQuery 可能就可以了。不过，我倾向于发现，当开发人员可以向用户提供高级功能（我们有时认为是“膨胀”）而不需要做额外的工作时，用户会对最终产品印象更深刻，并且发现它更容易使用。

最重要的是，请记住，在大多数情况下，您可以通过构建 应用- 不是 UI 组件。因此，除非有充分的理由重新发明轮子，否则通常最好使用已经构建和测试的东西来解决您面临的问题。

希望有帮助。-托德

关于 Brian C（等人）面临的“错误”和其他挑战，我认为这里有必要进行一些额外的澄清。作为一名开发者倡导者，我不会假装 Telerik 控件是完美的——凡人编写的软件从来都不是完美的。那么重要的是如何解决这些错误。

人们常常忽视公司（或开源项目）如何解决错误，直到为时已晚。无论您使用什么工具（jQuery、Telerik，甚至 Microsoft），您最终都会遇到错误。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 实现更臃肿。

我们的 Intranet 产品使用 Telerik Editor，我不得不说它的使用、定制、升级等都更加方便。比我们以前使用的任何编辑器都要好。

如果您需要一些高级功能和/或更复杂的控件 和 Telerik 提供了这一点，我想说现在注销它们还为时过早。如果您只需要 jQuery UI 可以提供的基本 UI 功能，那么对这些特定部分使用 jQuery。

没有必要选择其中之一；使用多种工具来完成工作。

RadScriptManager 与 MS Ajax 脚本管理器不同，因为它具有一个 EnableScriptCombine="true" 属性，您可以设置该属性来将 telerik 控件使用的所有 javascript 文件合并到一个 .js 文件中，以提高性能。

最初 rad 编辑器运行得很慢。但最新版本要快得多。此外，他们还聘请了不断努力改进控制的员工。

我不知道有什么东西可以接近 RadGrid。它非常强大。我现在正在 Intranet 应用程序上使用它，到目前为止它运行得很快。我正在使用它的所有功能，分组依据、导出到 Excel 等。

也就是说，如果我要创建一个供外部使用的 Internet 应用程序，我会使用 JQuery 而不是 telerik。这样你就有更多的控制权。

我认为 Telerik 宣布他们将在客户端使用 JQuery。

Telerik 现在刚刚开始投入更多时间为其 RadGrid 提供客户端支持。到目前为止，我对网格感到失望。我为他们感到难过，因为他们必须维护两个基本代码库：一种用于服务器控件，它根据回发和 ViewState 重绘 C# 中的所有内容，另一种用于客户端控件，用于重绘 javascript 中的部分控件（有点像将 C# 代码移植到 javascript）。这对他们来说是一项艰巨的工作，到目前为止我觉得还没有完成。

例如 客户端 对当前版本网格（ASP.nET AJAX 2008.3.1105.35）的支持不包括：

  1. 分组表达式
  2. 增加页面大小
  3. 除寻呼机样式外 NextPrev
  4. 隐藏/显示列
  5. AllowNaturalSort="false"
  6. 纯客户端排序（即在浏览器中）

话虽如此，如果您愿意将 Telerik 控件与传统的 Postback/Viewstate 渲染一起使用，那么我想说没有任何 jQuery 网格可以与之竞争。

我通常不会在这些事情上发帖——但我无法抗拒这一点。我通过 Telerik 使用 jQuery / jQuery UI。我真的很喜欢他们在演示页面上的内容——然后我尝试让它发挥作用。我在功能区栏上遇到了困难，并向他们展示了一两个错误。他们以为很快就会修好......不是……然后是下一个版本……事实并非如此。最后他们有了一个测试版，并要求我为他们进行测试——天哪。他们的东西确实看起来很漂亮，但我无法处理那些不起作用的东西。

我已经使用 jQuery / jQuery UI 大约 6 个月了，我喜欢它。便于使用。轻的。照它说的做。也许不像 Telerik 那样功能齐全，但可以理解，并且只需几个脚本就可以放入您的项目中。我也非常喜欢 Themeroller。

我使用 Telerik 进行控制已有 3 年了。我终于意识到我爱上了这个想法，但控件本身有很多错误，实施起来很烦人，最终花费了我更多的时间，而不是我自己构建。我绝对建议不要使用 Telerik。

我和两者都工作过 jQuery 和 Telerik. Telerik 官方网站的演示非常精美，但使用时却感觉很重且缓慢。和 jQuery 您可以编写轻量且高效的代码来满足您的需求，但需要更多时间。在性能方面，我建议在服务器而不是客户端浏览器上呈现初始的大量 HTML 结果。（前任。大网格）

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top