nsh*_*haw 20 asp.net jquery telerik
我正在尝试决定如何处理面向外部的Web应用程序的UI.因为它是外部的,所以由页面膨胀引起的延迟可能是个问题.
我过去曾经使用过jQuery,现在正在评估Telerik控件.我在Telerik控件上看到了很多很好的建议,包括一些关于StackOverflow的建议.事实上,他们看起来确实功能齐全.我也毫不怀疑我可以使用这些控件比使用jQuery更快地开发应用程序.但是,我担心它们会在我的页面上造成太大的膨胀.
你们有没有经验比较这些控件的性能与纯粹的jQuery实现？特别,
任何其他相关信息也是有用的.
小智 44
我已经使用Telerik和JQuery多年了."全功能"通常等同于大量的膨胀,您不需要的功能以及难以(或不可能)优化的最终页面.删除Telerik并使用像JQuery这样的裸机框架.你会发现它将允许你构建你需要的特定功能,你永远不会回去.许多功能齐全的UI套件(如Telerik或ComponentArt)非常诱人,但我认为它们会鼓励大量糟糕的编程.
例如....你真的需要在你的网格上有可拖放的列吗？可能不是.最好有一个设计区域,用户可以在其中布置列首选项,然后是主视图,网格是活泼轻巧的.不要渲染用户永远(或很少)在每个页面视图中使用的兆字节添加的功能.
Tod*_*odd 24
这里讨论很好.一些澄清:
作为一个长期的Web开发人员,我总是鼓励人们使用正确的工具来完成这项工作.如果您不需要RadControls的强大功能,或者accessiblitity支持,或者大量文档(以帮助那些将继承您的应用程序的人),请不要将它们用于您的站点.如果您只需要基本UI,那么jQuery可能就好了.然而,我倾向于发现,当开发人员可以向用户提供高级功能(我们有时认为"膨胀")没有额外的工作时,用户对最终产品印象更深刻,并且发现它更容易使用.
最重要的是,请记住,在大多数情况下,您通过构建应用程序而不是UI组件为您的公司/客户创造价值.因此,除非有充分的理由重新发明轮子,否则通常最好使用已经构建和测试的东西来解决您所面临的问题.
希望有所帮助.-Todd
关于Brian C(等人)所面临的"慌乱"和其他挑战,我认为这里应该进行一些额外的澄清.作为开发人员的倡导者,我不会假装Telerik控件是完美的 - 没有任何软件由凡人编写.那么重要的是如何解决这些错误.
人们常常忽视公司(或开源项目)如何解决错误,直到为时已晚.无论你使用什么工具--jQuery,Telerik,甚至微软 - 你最终都会遇到错误.Telerik倾向于擅长的地方是为这些问题提供快速修复,并提供非常全面的支持,帮助您尽可能提高工作效率.如果您遇到问题,Telerik会帮助您解决问题.对于其他公司,特别是开源,这并不总是保证.
所以请记住:无论你使用什么工具,你都会遇到错误.确保选择具有支持的工具,以便快速解决问题并进行修复.由于我知道我的观点不可避免地有偏见,我会让其他人在StackOverflow上确认或否认Telerik的支持质量.
Telerik控件似乎有点臃肿,但我怀疑你能够在没有太多努力的情况下在JQuery中实现类似的东西.
这真的取决于你可以容忍多少臃肿.如果它是用于Intranet应用程序,那么它并不重要,但是当你指定面向外部时,这可能是一个问题,它实际上取决于用户的平均连接速度和他们的计算机/浏览器的速度这将最终运行控件.
另一个重要问题是:您是否希望使用远低于JQuery的专有工具集来标准化您的Web应用程序？我怀疑JQuery很快就会破产.
如果它以后帮助了任何人,我已经抛弃了Telerik工具并且现在只使用jQuery.我们会看到我遇到了一些我不能做的事情.我对Telerik工具感到失望.我听说过很多关于它们的好东西,但它们对我来说并不是那么好用.这是我在评估Telerik工具时发现的.
Telerik Ajax工具在处理主页/内容页面设置时遇到问题.他们在论坛上承认这一点,我猜他们正在努力.虽然对我来说很成问题.
我看到很多意外的行为和怪癖似乎没有任何文件.例如,当使用Web20皮肤和表单装饰器时,字段集上的圆角在执行Ajax时会变得很糟糕.
Telerik工具减慢了我的开发机器的速度,似乎导致我的环境出现问题.我几乎从来没有崩溃或内存违规,我在使用这些工具的两天内有四天.自那之前我可能已经过了一个月了.
因此,将所有这些与jQuery免费且轻量级的事实相结合,选择很简单.最初可能需要一点时间,但最终结果会好得多.