Où est-ce que je me trompe à propos de mon projet et de ces frameworks Javascript?
Tout d’abord, le projet le plus simple que je souhaite créer est un moteur de wiki implémenté sous la forme d’une application web à page unique. Je prévois d’avoir un ensemble de fonctionnalités disponibles dès le départ avec de nombreux ajouts de fonctionnalités sur la route.
Caractéristiques de base
- création de page (crée à la fois un article wiki et un forum de discussion pour cet article)
- balisage et WYSIWYG ala markitup
- conversion à la volée entre le balisage / html / WYSIWYG
- une barre latérale pour naviguer rapidement
- une barre d’outils supérieure pour choisir edit / view
Fonctionnalités avancées
- barre latérale configurable pour naviguer via différentes méthodes
- barre d’outils configurable (éventuellement append un langage de balisage de choix)
- Mots clés
- todo modifiable
- faire glisser et déposer des fichiers téléchargés et des pièces jointes d’images
Le moteur se composerait à l’origine de la création de page, du balisage et de l’édition WYSIWYG les plus élémentaires, ainsi que de la sauvegarde. Je souhaiterais éventuellement étendre ce moteur de base avec une prise en charge des images par glisser-déposer, des téléchargements de fichiers, des graphiques de données en direct et une barre latérale pour personnaliser les vues.
J’ai fait une recherche assez approfondie sur un projet décent à partir duquel mon projet est basé, mais à part TiddlyWiki, il ne semble pas y avoir de bon moteur de wiki basé sur JavaScript. J’ai aussi envisagé d’appliquer Jquery aux moteurs wiki existants, mais je pense que je finirais par le réécrire de toute façon (et c’est juste plus intéressant d’append les fonctionnalités que je veux). De toute façon, je suis arrivé à implémenter cette bête avec une bibliothèque javascript + framework.
Je sais qu’on ne peut pas vraiment comparer certains de ces frameworks, car ce ne sont pas des pommes aux pommes. J’ai essayé d’encadrer tout commentaire / question de comparaison par rapport à des parties comparables des frameworks respectifs, mais je suis ouvert à être corrigé.
Alors on y va:
Sur la base de mes propres recherches et opinions, j’ai réduit la liste aux éléments ci-dessous. J’ai intentionnellement omis des éléments tels que SproutCore, corMVC, YUI et d’autres, car je pensais, à ma capacité limitée, que les éléments ci-dessous conviendraient mieux.
Mes options
- jquery + jqueryUI + backbonejs
- knockoutjs
- javascriptMVC
- Dojo
- ExtJS
- Cappuccino
jquery / UI + backbonejs
Global
De ce que j’ai lu, cette combinaison est utilisée et aimée par beaucoup et est très flexible et extensible. Ma principale préoccupation est que cette combinaison n’est tout simplement pas le meilleur sharepoint départ pour développer l’interface utilisateur plus orientée bureau.
Interface utilisateur
Bien que jQueryUI ou jqueryTools puissent être compétitifs, ils ne semblent certainement pas être à la hauteur des capacités d’interface utilisateur des autres frameworks. Plus précisément, ils semblent peser lourd sur les effets, mais ils manquent d’un support décent pour la mise en page.
javascriptMVC
Global
JavascriptMVC me semble être essentiellement des extensions jquery + MVC (jqueryMX), ainsi que quelques autres applications pour la documentation (documentJS), les tests fonctionnels (funcUnit) et la gestion du code et des dépendances (stealJS). Au-delà des avantages du module supplémentaire, je pense que le débat fonctionnel se résume vraiment à backbonejs vs jqueryMX. Ai-je raison sur cela et est-ce que quelqu’un a travaillé avec ou comparé les deux?
- Caractéristiques: Aperçu de jupiter (maker of jMVC) de leurs fonctionnalités
- Lien vers jqueryMX
Interface utilisateur
JavascriptMVC ajoute les éléments MXUI au-dessus de tout ce qui est disponible pour Jquery, donc je pense au moins que c’est une légère victoire dans cette catégorie.
knockoutjs
Global
Mes pensées et préoccupations à ce sujet sont très similaires aux commentaires de jquery + backbone. Ils semblent tous deux offrir des fonctionnalités similaires, mais dans une perspective différente. Un inconvénient souvent, c’est que knockoutjs associe trop étroitement la logique métier et la présentation aux liens de données et que cette méthode de liaison peut se dégrader pour l’interaction complexe de l’interface utilisateur, mais j’aimerais savoir pourquoi cela n’est pas un problème.
- Discussion des concepts backbone vs knockoutJS
- Caractéristiques de knockoutjs
Interface utilisateur
Blank pour le moment
Dojo et ExtJS
Global
Je vais combiner la discussion Dojo et ExtJS car je connais le moins à leur sujet et ils semblent jouer dans presque le même espace. La plupart des informations sur stackoverflow à propos de ces deux éléments semblent obsolètes. De ce que j’ai vu, c’est que ce sont deux grands frameworks qui sont bons pour l’implémentation des applications de bureau. Dojo avait été réprimandé pour mauvaise documentation mais cela ne semble plus être le cas. ExtJS a bien sûr la licence commerciale, mais elle est vraiment raisonnable pour ce que vous obtenez et je ne m’en voudrais pas trop. Les widgets d’ExtJS semblent être un peu plus professionnels que Dojo, mais je pourrais certainement y remédier. Je serais intéressé d’entendre de la part de tous ceux qui ont une expérience des deux.
Interface utilisateur
Dojo possède la bibliothèque d’interface utilisateur dijit. ExtJS possède des fonctionnalités d’interface utilisateur, mais elles ne sont pas dans le kernel Ext. Voici la documentation et voici leurs démos
Cappuccino
Global
Et puis il y a Cappuccino. Pas de CSS, pas de HTML, mais il peut aussi être difficile d’utiliser des bibliothèques javascript existantes. Objective-J ne semble pas effrayant, surtout si l’on considère qu’ils peuvent aussi écrire du javascript. Les démos sont impressionnantes et semblent approcher de près les besoins de l’interface utilisateur pour le moteur wiki. L’API basée sur le cacao est beaucoup à prendre pour quelqu’un qui ne le connaît pas, mais cela en vaut peut-être la peine. J’ai entendu dire que le moteur de mise en page n’est pas toujours facile à utiliser, mais une technologie jeune et peut-être même perturbasortingce aura certainement des inconvénients.
Interface utilisateur
Blank pour le moment
Je m’excuse d’avoir écrit autant, mais bon, au moins sa question n’est pas opposée à celle de z en espérant des tonnes de réponses bon marché. Alors qu’est-ce que tu en penses? Quelle devrait être la base de mon ordinateur de bureau comme un moteur de wiki, qui deviendra plus riche en fonctionnalités (lecture complexe) avec le temps?
Je suggérerais d’abord d’établir des exigences spécifiques pour votre projet. Lequel des frameworks que vous avez essayé vous avez fait tourner?
Personnellement, je me suis lancé dans le développement d’ExtJS car les projets sur lesquels je travaille nécessitent beaucoup de personnalisation des contrôles / widgets. ExtJS en a des tonnes dès la sortie de la boîte et peut toujours être étendu, combiné ou intégré à la monstruosité dont votre entreprise a besoin.
ExtJS 4 vous permet également de personnaliser l’apparence de votre interface utilisateur.
Si vous êtes novice en JavaScript et que vous maîsortingsez Java, vous pourriez même envisager une solution côté serveur telle que GWT , JSF ou même Vaadin.
Je ne suis pas sûr de votre calendrier et de vos ressources, mais lorsque j’essaie de choisir entre plusieurs frameworks / environnements, je vais simplement essayer de créer rapidement un prototype. Même si ce n’est qu’une ou deux fonctions majeures, je trouve que toutes les recherches et la documentation dans le monde ne correspondront jamais à une tentative de créer quelque chose avec les outils. Je dis prendre une journée avec chacun et voir jusqu’où vous êtes. Cela vous donnera une bonne idée des outils qui vous conviennent le mieux et qui vous conviennent le mieux.
Les meteors sont à la mode de nos jours (le framework JavaScript full-stack le plus étoilé sur GitHub et Meteorpedia est un moteur wiki écrit en Meteor.
La vidéo de lancement vous rendra accro à 1:28.
Il est agnostique en ce qui concerne l’interface utilisateur et a été largement testé avec Bootstrap et Famo.us. Il génère également des applications mobiles à partir du même code.
Votre choix de framework peut ne pas limiter vos choix d’interface utilisateur autant que vous le pensez. Ce récent article d’Henri Bergius sur le découplage de la gestion de contenu illustre bien mieux que je ne le pouvais – et, incidemment, des liens vers un éditeur de contenu in- situ purement JavaScript (indépendant du framework).
Vous n’êtes pas seul!
VanillaJS et Ampersand .. sont de bons exemples de la recherche sérieuse de JavaScript plus simple et plus modulaire.
Il y a même un livre à ce sujet.
La simplicité repose sur une fonctionnalité es6 sous-évaluée: les modules et la norme d’ implémentation SystemJS . Il peut même être utilisé sur des systèmes non-es6.
À quel point cela est cool!
Je dirais que vous avez tort dans votre choix global de candidats car vous omettez Angular et Ember, qui sont tous deux mieux adaptés que tous les autres frameworks listés.
Globalement, je dirais que Angular.js est le cadre pour celui-ci.
Accent sur le routage
Une grande partie de ce dont vous parlez (plusieurs barres latérales de navigation, une seule application de page) sont des fonctions de routage, ou comment le frontal interprète le texte dans votre barre de navigation URL.
Angular.js et Ember disposent tous deux d’excellents routeurs qui vous permettent de réaliser tout ce dont vous avez besoin sans code supplémentaire.
Pour votre bénéfice, voici une description rapide des fonctionnalités d’Angular qui peuvent être utilisées pour créer votre wiki de page unique.
La structure du site lui-même
Angular dispose d’une incroyable bibliothèque appelée UI router qui vous permet à la fois de créer une navigation personnalisée et de mettre en place une structure SEO conviviale permettant de révéler votre contenu. Des vues multiples autoriseraient également une barre d’outils supérieure.
Tutoriel Ui routeur: http://cacodaemon.de/index.php?id=57
Éditeur WYSIWYG
Angular est construit sur une liaison bidirectionnelle en direct (lorsque vous changez quelque chose quelque part, il change automatiquement partout ailleurs). Il est donc livré avec de nombreuses fonctionnalités qui fonctionnent bien avec ce type d’éditeur. Quelques bonnes ont déjà été faites et il vous suffit de les mettre en œuvre.
Graphes et autres trucs soignés
Les directives angulars sont conçues pour faire des choses comme créer des composants de graphique réutilisables. Ils ne sont pas totalement différents des WordPress Widgets. Beaucoup d’entre eux ont déjà été développés et peuvent être déposés dans votre projet Angular.
http://www.sitepoint.com/creating-charting-directives-using-angularjs-d3-js/
En ce qui concerne Ember, je ne sais pas grand chose à ce sujet, donc je ne peux pas parler de ses caractéristiques particulières.
Une suggestion à propos de Backbone, si vous décidez de l’utiliser, vous devriez opter pour Marionnete depuis Backbone mais avec une meilleure structure architecturale et plus d’opinion (personnellement, je pense que Backbone ne définit pas de lignes direcsortingces et que cela semble être un inconvénient dans les grandes applications) .
J’ai travaillé avec lui pendant quelques mois en combinant différentes librairies js et je ne vous gêne pas comme les autres frameworks et le pipeline de messages est un très bon moyen de connecter des composants via l’application, tout en les préservant.
Ici vous avez une bonne discussion qui m’a fait décider pour cela: https://www.youtube.com/watch?v=qWr7x9wk6_c
Et ici, vous avez un prototype de démo qui contient également l’élément glisser-déposer et d’autres bibliothèques js connectées. Aimerait entendre ce que vous pensez de mon code depuis que j’ai 1,5 ans de travail sur le développement web … je suis toujours un débutant: https://github.com/Drasky-Vanderhoff/marionette-demo/
À propos de Knockout, c’est vraiment bien si vous voulez une interaction avec le contenu que vous avez déjà et que vous ne vous connecterez pas constamment avec le backend. J’ai travaillé avec lui pendant 6 mois et j’ai fini par devoir utiliser beaucoup d’autres librairies js pour le routage; De plus, je finis par répéter beaucoup de structures que Backbone et d’autres JS Frameworks ont fini par avoir. Ce que je vais dire, c’est que cela ne vous gênera pas du tout et sera un outil plutôt qu’une contrainte. Il y a presque un an, quelques choses ont changé.
Une chose, si vous trouvez Knockback (Knockout + Backbone) … évitez-le, la documentation n’est pas aussi bonne qu’elle devrait l’être et cela vous prendra beaucoup plus de temps pour l’apprendre. Si vous voulez vous lancer, faites d’abord un prototype rapide pour voir si c’est ce que vous voulez.