Contrôles de l'interface utilisateur Telerik vs interface utilisateur côté client avec jQuery

https://stackoverflow.com/questions/428376

06-07-2019
|

Question

J'essaie de décider de la façon dont je veux gérer l'interface utilisateur pour une application Web externe. En raison de son caractère externe, le temps de latence provoqué par une page volumineuse peut poser problème.

J'en ai utilisé jQuery par le passé et j'évalue les commandes Telerik maintenant. J'ai vu beaucoup de bonnes recommandations sur les commandes Telerik, y compris certaines sur StackOverflow. En effet, ils semblent assez complets. Je n'ai également aucun doute sur le fait que je peux développer l'application beaucoup plus rapidement à l'aide de ces contrôles qu'avec jQuery. Cependant, je crains qu’ils ne causent trop d’engorgement dans mes pages.

Avez-vous de l'expérience dans la comparaison des performances de ces contrôles avec une implémentation purement jQuery? Plus précisément,

RadScriptManager de Telerik est-il vraiment meilleur que le MS Ajax ScriptManager?
Existe-t-il des problèmes de performances en général avec les commandes Telerik?
Existe-t-il un plug-in pour jQuery proche de la fonctionnalité de grille de RadGrid?

Toute autre information connexe serait également utile.

La solution

J'ai utilisé Telerik et JQuery pendant des années. "Complet en vedette" équivaut généralement à des tonnes de ballonnement, à des fonctionnalités inutiles et à une dernière page difficile (voire impossible) à optimiser. Supprimez Telerik et utilisez un cadre en métal nu comme JQuery. Vous constaterez que cela vous permettra de créer la fonctionnalité spécifique dont vous avez besoin et que vous ne reviendrez jamais en arrière. De nombreuses suites d’interface utilisateur complètes telles que Telerik ou ComponentArt sont très séduisantes, mais je pense qu’elles encouragent beaucoup de mauvaise programmation.

Par exemple ... Avez-vous vraiment besoin d’avoir des colonnes glissables sur votre grille? Probablement pas. Il est probablement préférable d'avoir une zone de conception où vos utilisateurs peuvent mettre en forme leurs préférences de colonne, puis la vue principale où la grille est légère et accrocheuse. Ne rendez pas les mégaoctets de fonctionnalités ajoutées que vos utilisateurs n'utiliseront jamais (ou rarement) avec chaque affichage de page.

Autres conseils

Bonne discussion ici. Quelques clarifications:

Telerik utilise jQuery en interne (et de plus en plus maintenant que MS le prend en charge) pour améliorer les fonctionnalités côté client (et réduire le code côté client) pour de nombreux contrôles
jQuery est une bibliothèque côté client idéale pour le développement JavaScript. Toutefois, si vous devez vous préoccuper de l'accessibilité, vous êtes dans une crique avec des implémentations d'interface utilisateur jQuery, car elles dépendent de JavaScript pour toutes les fonctionnalités. L'avantage unique de Telerik est que vous pouvez effectuer un rendu à la fois côté client et côté serveur, ce qui signifie que vous pouvez prendre en charge les clients sur lesquels JavaScript n'est pas activé.
Pour de nombreux contrôles Telerik, vous pouvez soit A) éliminer le code supplémentaire sur la page en désactivant des fonctionnalités (en raison de la logique de script de chargement selon les besoins), soit B) réduire considérablement l'impact du code côté client en utilisant combineurs de script et compresseurs.

En tant que développeur Web de longue date, j’encourage toujours les gens à utiliser le bon outil. Si vous n'avez pas besoin des puissantes fonctionnalités de RadControls, ni du support d'accessibilité, ni de la documentation complète (pour aider le gars qui héritera de votre application), ne les utilisez pas pour votre site. Si tout ce dont vous avez besoin est une interface utilisateur de base, jQuery peut très bien vous convenir. Ce que j’ai tendance à penser, c’est que quand un développeur peut offrir des fonctionnalités avancées aux utilisateurs (ce que nous appelons parfois "gonflement") sans faire de travail supplémentaire, les utilisateurs sont beaucoup plus impressionnés par le produit final et le trouvent beaucoup plus facile à utiliser.

Et surtout, souvenez-vous que dans la plupart des cas, vous créez de la valeur pour votre entreprise / vos clients en créant des applications - et non des composants d'interface utilisateur. Donc, à moins qu'il n'y ait de bonnes raisons de réinventer la roue, il vaut généralement mieux utiliser quelque chose qui a déjà été construit et testé pour résoudre le problème auquel vous êtes confronté.

J'espère que ça aide. -Todd

En ce qui concerne le " bugginess " et d’autres défis auxquels Brian C (et al.) sont confrontés, je pense que des éclaircissements supplémentaires sont mérités ici. En tant que défenseur des développeurs, je ne prétends pas que les contrôles Telerik sont parfaits - aucun logiciel écrit par de simples mortels ne l’a jamais été. Ce qui est important, c’est la manière dont ces bugs sont traités.

Trop souvent, les gens ignorent comment une entreprise (ou un projet open source) traite les bogues jusqu'à ce qu'il soit trop tard. Quels que soient les outils que vous utilisez (jQuery, Telerik ou même Microsoft), vous finirez par rencontrer des bogues. Là où Telerik a tendance à exceller, il propose des solutions rapides à ces problèmes et un support très complet pour vous aider à être aussi productif que possible. Si vous avez un problème, Telerik vous aidera à le résoudre. Avec d’autres sociétés, et en particulier avec l’Open Source, ce n’est pas toujours la garantie.

Rappelez-vous: quels que soient les outils que vous utilisez, vous allez être confronté à des bugs. Assurez-vous de choisir des outils d'assistance pouvant répondre à vos problèmes et corrigez-les très rapidement. Et comme je sais que mon point de vue est inévitablement biaisé, je laisserai les autres utilisateurs de StackOverflow confirmer ou nier la qualité du support de Telerik.

Les commandes de Telerik semblent un peu fades, mais je doute que vous puissiez obtenir quelque chose de similaire dans JQuery sans beaucoup d’efforts.

Cela dépend vraiment de la quantité de ballonnement que vous pouvez tolérer. Si c'est pour une application Intranet, alors cela n'a pas vraiment d'importance, mais comme vous avez spécifié le côté externe, cela peut être un problème, cela dépend vraiment de la vitesse de connexion moyenne de vos utilisateurs et de la vitesse de leur ordinateur / navigateur. qui exécutera finalement les contrôles.

L'autre question importante est la suivante: souhaitez-vous normaliser votre application Web dans un ensemble d'outils propriétaires beaucoup moins utilisé que JQuery? Je doute que JQuery cessera bientôt ses activités.

Si cela peut aider plus tard, j’ai vidé les outils de Telerik et j’utilise exclusivement jQuery pour le moment. Nous verrons si je rencontre quelque chose que je ne peux pas faire. J'ai été déçu par les outils Telerik. J'avais entendu tant de bonnes choses à leur sujet, mais cela ne fonctionnait pas très bien pour moi. Voici ce que j’ai trouvé lors de l’évaluation des outils Telerik.

Les outils Telerik Ajax rencontrent des problèmes pour gérer les configurations de page maître / contenu. Ils le reconnaissent dans leurs forums et j'imagine qu'ils y travaillent. Très problématique pour moi cependant.
J'ai vu beaucoup de comportements inattendus et de bizarreries qui ne semblent pas avoir de documentation. Par exemple, lorsqu’on utilise l’habillage Web20 et le décorateur de formulaires, les coins arrondis d’un jeu de champs s’en vont à l’enfer en utilisant Ajax.
Les outils de Telerik ont ??ralenti un peu ma machine de développement et semblent causer des problèmes avec mon environnement. Je n'ai presque jamais eu de crash ou de violation de la mémoire, et j'en ai eu quatre en deux jours en utilisant ces outils. Cela faisait probablement un mois depuis le dernier jour avant.
Combinez donc tout cela avec le fait que jQuery est gratuit et léger, et le choix était facile. Cela peut prendre un peu plus longtemps au début, mais le résultat sera bien meilleur à la fin.

Vos exigences en matière d’UI auront le plus grand impact sur cette décision. Je ne pense pas que les contrôles de Telerik puissent être comparés à jQuery en termes de fonctionnalité. Si vous avez besoin de contrôles côté serveur pour afficher les données, évaluez Telerik par rapport aux autres contrôles concurrents.

J’utilise les commandes Telerik et paie également le code source, de sorte qu’elles cessent leurs activités, ce qui n’est pas une préoccupation majeure compte tenu du code source. Je n'ai aucune expérience spécifique de l'utilisation des commandes Telerik sur un site Web destiné au public, mais n'hésiterais pas du tout. On m'a parfois demandé d'utiliser JQuery pour des fonctionnalités supplémentaires que les contrôles n'avaient pas.

Le problème que j’ai avec vous est que, comme vous ne codez pas vous-même toutes ces fonctionnalités avec l’utilisation de commandes (pas uniquement celles de Telerik), il est très facile de glisser-déposer toutes sortes de choses amusantes sur votre page. va ajouter le traitement à chaque page. Cela dit, limitez-en l'utilisation au minimum et je ne pense pas qu'ils seront plus gonflés que les implémentations JQuery codées à la main.

Nous utilisons l'éditeur Telerik pour notre produit intranet, et je dois dire qu'il était beaucoup plus agréable de travailler, personnaliser, mettre à niveau, etc. que tous les éditeurs précédents que nous utilisions.

Si vous avez besoin de fonctionnalités avancées et / ou de commandes plus complexes, et , Telerik fournit cette fonctionnalité, je dirais qu'il est prématuré de les supprimer. Si vous avez juste besoin des fonctionnalités de base de l'interface utilisateur que jQuery UI peut fournir, utilisez jQuery pour ces éléments spécifiques.

Inutile d’aller avec l’un ou l’autre; utilisez un mélange d’outils pour faire le travail.

RadScriptManager est différent du gestionnaire de scripts MS Ajax car il est associé à EnableScriptCombine = " true " propriété que vous pouvez définir pour permettre à tous les fichiers javascript utilisés par les commandes telerik d'être combinés en un seul fichier .js afin d'améliorer les performances.

À l'origine, l'éditeur de rad fonctionnait assez lentement. Mais la dernière version est beaucoup plus rapide. De plus, ils ont un personnel rémunéré qui travaille constamment à améliorer leurs contrôles.

Je ne suis au courant de rien qui se rapproche de RadGrid. C'est assez puissant. Je l'utilise actuellement sur une application intranet, et elle tourne vite jusqu'à présent. J'utilise toutes ses fonctionnalités, groupe par, exportation pour exceller, etc.

Cela dit, si je créais une application Internet à usage externe, j'utiliserais JQuery sur telerik. De cette façon, vous aurez plus de contrôle.

Je pense que Telerik a annoncé qu’elle utiliserait JQuery pour le client.

Telerik commence tout juste à consacrer plus de temps au support client de son réseau RadGrid. Jusqu'à présent, j'ai été déçu par la grille. Je me sens mal pour eux, car ils doivent essentiellement gérer 2 bases de code: une pour leurs contrôles serveur qui redessine tout en C # en fonction de Postbacks et de ViewState et l'autre pour les contrôles côté client qui redessine des parties du contrôle en javascript. (un peu comme un portage de leur code C # en javascript). C'est beaucoup de travail pour eux et jusqu'à présent, je pense que c'est incomplet.

Par exemple, le support côté client de la version actuelle de leur grille (ASP.nET AJAX 2008.3.1105.35) n'inclut pas:

Grouper les expressions
Augmenter la taille de la page
Autres styles de pageur que NextPrev
Masquer / afficher des colonnes
AllowNaturalSort = " false "
Tri pur côté client (c'est-à-dire directement dans le navigateur)

Cela étant dit, si vous préférez utiliser les commandes Telerik avec le rendu traditionnel Postback / Viewstate, je dirais qu’aucune grille jQuery n’est concurrentielle.

Habituellement, je ne poste pas sur ces sujets - mais je n’ai pas pu résister à celui-ci. Je suis allé avec jQuery / jQuery UI sur Telerik. J'ai vraiment aimé ce qu'ils avaient sur les pages de démonstration - puis j'ai essayé de le faire fonctionner. Je me suis débattu avec le ruban et leur ai montré un ou deux insectes. Ils étaient… ça allait être réglé bientôt… ce n'était pas… alors la prochaine version… ça ne l'était pas. Finalement, ils ont eu une version bêta et m'ont demandé de la tester pour eux - bon chagrin. Leur contenu est beau, mais je ne pouvais pas gérer les choses qui ne fonctionnaient pas.

J'utilise jQuery / jQuery UI depuis environ 6 mois et je l'aime bien. Facile à utiliser. Poids léger. Fait ce qu'il dit. Peut-être pas aussi complet que Telerik, mais il est compréhensible et peut être intégré à votre projet avec seulement quelques scripts. J'aime beaucoup le Themeroller aussi.

J'utilise Telerik pour les contrôles depuis 3 ans. J'ai finalement réalisé que je suis amoureux de l'idée, mais les contrôles eux-mêmes sont très bogués, ennuyeux à mettre en œuvre et, au final, ils m'ont coûté beaucoup plus de temps qu'il aurait fallu me construire moi-même. Je recommande vivement de ne pas utiliser Telerik.

J'ai travaillé avec jQuery et Telerik . Telerik apprécie beaucoup les démonstrations de son site officiel, mais lors de son utilisation, vous le sentez très lourd et lent. Avec jQuery , vous pouvez écrire des codes légers et efficaces qui répondent à vos besoins mais nécessitent plus de temps. En termes de performances, je recommande de restituer les premiers résultats HTML lourds sur le serveur plutôt que sur le navigateur client. (Ex. Big Grids)

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow