Cadres d'interface utilisateur HTML5
J'ai trouvé beaucoup de frameworks HTML5 pour l'interface utilisateur, tels que:
Je suis un peu dépassé par tant de ressources. Certains en avaient l'air, mais presque tous semblaient trop lents et trop lourds.
Je suis un peu confus de savoir lequel j'apprendrai. Chacun de leurs sites Web parle de leur produit comme s’ils étaient les meilleurs du marché. (stratégies marketing évidentes).
En tant que débutant sur le développement d'applications Web et les infrastructures JS UI côté client; En fonction de votre expérience, lequel recommandez-vous pour le développement rapide d'applications Web de bureau en tenant compte de la vitesse, des collections de widgets, de la complexité, de l'apparence, du support, etc.?
Lequel me recommandez-vous pour commencer à apprendre?
Je sais qu'il pourrait y avoir beaucoup de réponses et que chacune pourrait en préférer différentes, mais cela pourrait m'aider à me guider un peu et à critiquer certains des cadres les plus populaires.
Il y a tellement de choses dans votre question que la réponse ne sera pas facile et ne sera pas précise du tout. Ce sera aussi très avisé. En regardant la liste des cadres que vous avez apportés, je vois des choses très différentes qui sont difficilement comparables les unes aux autres. Je vais essayer de les regrouper d'une manière ou d'une autre et d'ajouter plus de cadres à la liste.
La principale question ici n'est pas le pour et le contre d'un cadre particulier. La question principale est: combien voulez-vous ? Voulez-vous vraiment dire une application comme Gmail ou Grooveshark? Ou voulez-vous dire quelque chose comme Stackoverflow - une dynamique et pas du tout simple, mais toujours un site Web. Considérons toutes ces options.
Peut-être souhaitez-vous simplement améliorer votre site Web avec des widgets, tels que des onglets, des boîtes de dialogue, des éléments déplaçables/réductibles, l'édition de texte, etc. et vous ne souhaitez pas modifier votre modèle de développement. Je veux dire, vous utilisez votre Java/PHP/Ruby préféré et ne souhaitez pas écrire la plupart des logiques et comportements de votre application en JavaScript. Dans ce cas, les solutions de type plug-in basées sur jQuery vous conviendront particulièrement, interface utilisateur jQuery et jQuery Mobile .
les widgets jQuery suivent son système de plug-in. Cela signifie généralement qu'ils sont extrêmement faciles à utiliser. Pour créer un bouton, vous écrivez:
$('#myButton').button();
Maintenant, si vous voulez le désactiver, vous appelez une méthode en utilisant le modèle suivant:
$('#myButton').button('disable');
Et obtenir ou définir des valeurs, par exemple sur slider ou datepicker, ressemble à ceci:
$('#mySlider').slider('value');
$('#mySlider').slider('value', 42);
Comme vous le voyez, les solutions basées sur jQuery n’ont pas de modèle. Toutes vos données sont conservées dans le DOM et sont obtenues via des appels de méthodes bizarres. Si vous devez traiter vos données de manière dynamique, par exemple, faire des validations complexes, charger quelque chose en arrière-plan, filtrer ou trier, alors vous voyez que cela va vite devenir compliqué. En passant, c’est le problème pour lequel l’équipe de jQuery UI n’a pas encore fourni de contrôle de grille - elle ne peut le faire sans modèle. Dans jQuery Mobile, vous obtenez une interface utilisateur mobile Nice au moyen d'un balisage simple, mais il n'existe aucun moyen officiel de transmettre des données entre les pages.
En résumé, si vous avez un site Web comportant plusieurs pages, si vous POST vos formulaires, utilisez ensuite l'interface utilisateur jQuery ou une solution plus légère telle que Twitter Bootstrap .
Peut-être souhaitez-vous créer quelque chose de plus complexe, plus semblable à une application (une application d'une seule page?). Vous savez que vous devrez travailler avec des données côté client. Quelles sont vos options alors?
Vous pouvez utiliser l'un des nombreux frameworks JavaScript qui vous fournissent des modèles, la liaison de données et probablement d'autres moyens de créer des applications Web et de les intégrer à JQuery UI. Ou vous pouvez utiliser un cadre plus complet comme Kendo ou Wijmo ou jqWidgets . Ces frameworks reposent sur jQuery (Wijmo s'appuie sur jQuery UI) et fournissent des moyens supplémentaires de manipulation des données. Ils ont des modèles de données. Kendo implémente sa propre solution (je pense), alors que Wijmo et jqWidgets s’intègrent au célèbre Knockout JS.
Donc, Kendo et Wijmo appartiennent au groupe de frameworks qui fournissent à la fois des widgets/contrôles et un modèle de sauvegarde. Il existe d’autres frameworks comme ceux-ci, qui ne sont pas basés sur jQuery, par exemple. Boîte à outils Dojo . Ajoutez du chargement de données dynamique et vous obtiendrez une application Web quelque peu complexe. Que pouvez-vous souhaiter de plus?
En fait, la chose la plus importante est oubliée - comment structurez-vous (organisez-vous) votre application? Si vous essayez de créer une application d'une seule page qui communique avec le serveur de manière RESTful, vous vous retrouverez bientôt dans le pétrin si votre application n'a pas d'architecture. Les fonctionnalités généralement requises à cet effet sont notamment la séparation des problèmes (MVC, MVVM), la modélisation, le routage et la gestion des modules. C'est ici que SproutCore et Sencha apparaissent. Ils fournissent une solution complète pour la création d'applications Web, où les widgets ne sont qu'une petite partie.
SproutCore et Sencha semblent être les gagnants, car ce sont les solutions les plus complètes, qui incluent à la fois l’UI et les logiques d’entreprise, ainsi que la structure de votre application. Malgré tous les avantages, il y a des inconvénients. Certains disent qu'ils sont trop lourds ou qu'ils devront adhérer à leur modèle de développement, ce qui pourrait ne pas vous plaire. Par exemple, dans Sencha, vous décrivez votre interface graphique en JavaScript et utilisez le système de types de Sencha. Cela ajoute une sorte de forte impression qu'il y a des abstractions et des wrappers, alors que vous aimez vraiment la facilité de HTML, CSS et JavaScript Vanilla.
Mais ce n'est pas le seul moyen. La puissance du Web réside dans le fait qu’il existe de très nombreux frameworks, bibliothèques et outils, plus petits et plus grands, qui vous aideront à concevoir votre application comme vous le souhaitez. Par exemple, considérons AngularJS . Il ne fournit pas lui-même un ensemble de contrôles, mais associé à Twitter Bootstrap devient une solution complète pour RIA. Ou, par exemple, regardez EmberJS , une Cadre léger du créateur du poids lourd SproutCore, il ne vous fournit pas non plus un ensemble de widgets, mais constitue, à mon avis, une très bonne base pour une application.
Alors voici ma dernière pensée au lieu de la conclusion. Tous ces frameworks vous montrent généralement leur ensemble de widgets, des thèmes jolis et d'autres éléments visuels. Mais ce qui compte vraiment, c'est comment vous allez réellement développer votre application, comment vous allez la structurer, où vous allez mettre en œuvre votre logique. Apprenez ce que le cadre fournit et réfléchissez pour savoir si vous pouvez remplacer ce qui manque.
La réponse d'Infeligo est excellente. Mon expérience peut intéresser certains. J'utilise Ruby sur Rails) comme plate-forme serveur sur laquelle réside l'essentiel de ma logique métier.
A l’avant, j’utilise dHTMLX, une bibliothèque JS d’objets, dont le plus puissant est leur objet grille. La plupart de mes applications ont des exigences en matière de traitement et d’affichage des informations commerciales/comptables et l’objet maillé y est mon pilier. Cependant, leur ensemble d'objets est complet, y compris la possibilité de créer des "fenêtres" supplémentaires dans une seule application pour fournir une interface de type MDI) à l'utilisateur final. J'ai généralement un formulaire de connexion qui, une fois appliqué, s'ouvre une seule page HTML avec un menu en haut. En fonction de la sélection dans le menu, de nouvelles fenêtres sont ouvertes et fermées pour afficher/manipuler des informations. Ces fenêtres entrent dans le champ de la page HTML unique.
Tous les objets ont de très bons événements qui leur sont associés et je fais pas mal de validation au début utilisant ces événements. Cependant, j’ai l'habitude de dupliquer toutes les validations de données dans le modèle Rails. C'est un travail supplémentaire, mais je suis simplement très prudent. Il existe également un certain nombre d'objets abstraits qui permettent de connecter des données entre les fichiers. objets visuels frontaux, par exemple, grille et serveur principal. La plupart des connexions de données peuvent être établies à l'aide de XML ou JSON. J'utilise XML sur JSON simplement en raison de mon expérience avec cette structure et du fait que Rails = fournit un constructeur XML correct. Dans mon cas, j’utilise rarement des vues basées sur Rails car tous mes objets visuels proviennent de dHTMLX.
L'autre chose que j'aime chez dHTMLX est la vitesse de leurs objets. Par exemple, l'objet de grille gérera assez facilement plus de 10 000 lignes à des vitesses très acceptables.
Le gros inconvénient de la suite est sa documentation. La société est un développeur d’Europe de l’est et il est donc souvent difficile de comprendre exactement ce que signifie leur documentation. De plus, leur documentation a tendance à ne pas tout documenter complètement, ce qui fait perdre beaucoup de temps à l'apprentissage par essais et erreurs.
J'espère que cela t'aides