Wo irre ich mich über mein Projekt und diese Javascript Frameworks?

Zunächst einmal ist das wichtigste Element des Projekts, das ich erstellen möchte, eine Wiki-Engine, die als Web-App für eine einzelne Seite implementiert ist. Ich habe vor, von Anfang an eine Reihe von Funktionen mit zahlreichen zusätzlichen Funktionen zur Verfügung zu haben.

Grundfunktionen

• Seitenerstellung (erstellt sowohl einen Wiki-Artikel als auch ein Diskussionsforum für diesen Artikel)
• Markup und WYSIWYG ala Markitup
• On-the-Fly-Konvertierung zwischen Markup / HTML / WYSIWYG
• eine Seitenleiste zur schnellen Navigation
• Eine obere Symbolleiste zur Auswahl von Bearbeiten / Anzeigen

Erweiterte Funktionen

• konfigurierbare Seitenleiste zum Navigieren über verschiedene Methoden
• konfigurierbare Symbolleiste (möglicherweise Markup-Sprache Ihrer Wahl hinzufügen)
• Stichworte
• bearbeitbare Aufgaben
• Datei-Uploads und Bildanhänge per Drag & Drop

Die Engine bestand ursprünglich aus der grundlegendsten Seitenerstellung, Markup- und WYSIWYG-Bearbeitung sowie dem Speichern. Ich möchte diese grundlegende Engine eventuell mit Drag & Drop-Bildunterstützung, Datei-Uploads, Live-Datendiagrammen und einer Seitenleiste zum Anpassen von Ansichten erweitern.

Ich habe eine ziemlich umfangreiche Suche nach einem anständigen Projekt durchgeführt, auf dem mein Projekt basieren kann, aber außer TiddlyWiki scheint es keine guten Javascript-basierten Wiki-Engines zu geben. Ich habe auch darüber nachgedacht, Jquery auf vorhandene Wiki-Engines anzuwenden, aber ich glaube, ich würde es letztendlich sowieso umschreiben (außerdem ist es nur aufregender, die gewünschten Funktionen hinzuzufügen, wenn ich gehe). So oder so bin ich dazu gekommen, dieses Biest mit einer Javascript-Bibliothek + Framework zu implementieren.

Ich weiß, dass man einige dieser Frameworks nicht wirklich miteinander vergleichen kann, da es sich nicht um Äpfel mit Äpfeln handelt. Ich habe versucht, Vergleichskommentare / -fragen mit vergleichbaren Teilen der jeweiligen Frameworks zu verknüpfen, bin jedoch offen für Korrekturen.

Auf geht's:

Aufgrund meiner eigenen Recherchen und Meinungen habe ich die Liste auf die folgenden Punkte eingegrenzt. Ich habe absichtlich Dinge wie SproutCore, corMVC, YUI und andere weggelassen, da ich in meiner begrenzten Kapazität dachte, dass die folgenden Elemente besser passen würden.

Meine Optionen

• jquery + jqueryUI + backbonejs
• Knockoutjs
• javascriptMVC
• Dojo
• ExtJS
• Cappuccino

jquery / UI + backbonejs

Insgesamt

Nach dem, was ich gelesen habe, wird diese Kombination von vielen benutzt und geliebt und ist sehr flexibel und erweiterbar. Mein Hauptanliegen ist, dass diese Kombination einfach nicht der beste Ausgangspunkt für die Entwicklung einer eher desktoporientierten Benutzeroberfläche ist.

Benutzeroberfläche

Obwohl jQueryUI oder jqueryTools möglicherweise wettbewerbsfähig sind, scheinen sie sicherlich nicht mit den UI-Funktionen anderer Frameworks mithalten zu können. Insbesondere scheinen sie die Effekte stark zu beeinträchtigen, es fehlt ihnen jedoch an einer angemessenen Unterstützung für das Schneiden von Layouts.

javascriptMVC

Insgesamt

JavascriptMVC scheint mir im Wesentlichen eine Erweiterung von jquery + MVC (jqueryMX) zu sein, zusammen mit einigen anderen Apps für die Dokumentation (documentJS), Funktionstests (funcUnit) und das Code- und Abhängigkeitsmanagement (stehlenJS). Abgesehen von den Vorteilen des zusätzlichen Moduls denke ich, dass die funktionale Debatte wirklich auf backbonejs vs. jqueryMX hinausläuft. Bin ich damit richtig und hat jemand mit beiden gearbeitet oder sie verglichen?

• Features: Jupiter (Hersteller von jMVC) Übersicht über ihre Features
• Link zu jqueryMX

Benutzeroberfläche

JavascriptMVC fügt die MXUI- Elemente zusätzlich zu den für Jquery verfügbaren Elementen hinzu, sodass ich zumindest denke, dass dies ein leichter Gewinn in dieser Kategorie ist.

Knockoutjs

Insgesamt

Meine Gedanken und Bedenken dazu sind den Kommentaren zu jquery + backbone sehr ähnlich. Beide scheinen ähnliche Funktionen zu bieten, jedoch nur aus einer anderen Perspektive. Ein oft genannter Nachteil ist, dass Knockoutjs Geschäftslogik und Präsentation zu eng mit den Datenbindungen verbindet und dass diese Bindungsmethode für komplexe UI-Interaktionen zusammenbrechen kann, aber ich würde gerne hören, warum dies kein Problem ist.

• Diskussion von Backbone vs KnockoutJS-Konzepten
• Merkmale von Knockoutjs

Benutzeroberfläche

Im Moment leer

Dojo & ExtJS

Insgesamt

Ich werde die Diskussion Dojo und ExtJS kombinieren, weil ich am wenigsten über sie weiß und sie auf fast demselben Raum zu spielen scheinen. Die meisten Informationen zum Stapelüberlauf über diese beiden scheinen veraltet zu sein. Ich habe gesehen, dass es sich bei beiden um große Frameworks handelt, die sich gut für die Implementierung von Desktop-Apps eignen. Dojo war wegen schlechter Dokumentation getadelt worden, aber das scheint nicht mehr der Fall zu sein. ExtJS hat natürlich die kommerzielle Lizenz, aber es ist wirklich vernünftig für das, was Sie bekommen, und ich würde das nicht zu sehr dagegen halten. Die Widgets in ExtJS scheinen etwas professioneller zu sein als Dojo, aber ich könnte dort sicherlich korrigiert werden. Es würde mich interessieren, von jemandem zu hören, der Erfahrung in beiden Bereichen hat.

Benutzeroberfläche

Dojo verfügt über die Dijit- UI-Bibliothek ExtJS verfügt über UI-Funktionen, die sich jedoch nicht im Ext-Kern befinden. Hier ist die Dokumentation und hier sind ihre Demos

Cappuccino

Insgesamt

Und dann ist da noch Cappuccino. Kein CSS, kein HTML, aber es könnte auch schwierig sein, vorhandene Javascript-Bibliotheken zu verwenden. Objective-J scheint nicht beängstigend zu sein, besonders wenn man bedenkt, dass sie auch einfaches Javascript schreiben können. Die Demos sind beeindruckend und scheinen den Anforderungen der Benutzeroberfläche für die Wiki-Engine sehr nahe zu kommen. Die kakaobasierte API ist eine Menge für jemanden, der nicht damit vertraut ist, aber vielleicht lohnt es sich. Ich habe gehört, dass die Layout-Engine nicht immer einfach zu bedienen ist, aber eine junge und möglicherweise störende Technologie wie diese wird sicherlich einige Mängel aufweisen.

Benutzeroberfläche

Im Moment leer

Ich entschuldige mich dafür, dass ich so viel geschrieben habe, aber hey, zumindest ist es keine Frage zwischen Axt und Y und Z, in der Hoffnung auf jede Menge billiger Antworten. Also was denkst du? Was sollte die Basis für meine Desktop-ähnliche Wiki-Engine sein, die mit der Zeit hoffentlich funktionsreicher (komplexer lesen) wird?

Ich würde vorschlagen, zuerst spezifische UI-Anforderungen für Ihr Projekt zu erstellen. Welches der Frameworks, die Sie ausprobiert haben, haben Sie für eine Spritztour genommen?

Persönlich bin ich in die ExtJS-Entwicklung eingestiegen, weil die Projekte, an denen ich arbeite, viele Anpassungen der Steuerelemente / Widgets erfordern. ExtJS hat eine Menge davon direkt nach dem Auspacken und kann jederzeit erweitert, kombiniert oder in die Monstrosität verwandelt werden, die Ihr Unternehmen benötigt.

Mit ExtJS 4 können Sie auch Ihre Benutzeroberflächen "häuten", um das Erscheinungsbild weiter anzupassen.

Wenn Sie mit JavaScript noch nicht vertraut sind und mit Java vertraut sind, sollten Sie sich sogar eine serverseitige Lösung wie GWT , JSF oder sogar Vaadin ansehen

Ich bin mir nicht sicher über Ihre Zeitachse und Ressourcen, aber wenn ich versuche, mich zwischen mehreren Frameworks / Umgebungen zu entscheiden, versuche ich einfach, schnell einen Prototyp zu erstellen. Selbst wenn es nur eine oder zwei Hauptfunktionen sind, finde ich, dass alle Recherchen und Dokumentationen der Welt niemals mit dem Versuch übereinstimmen werden, tatsächlich etwas mit den Werkzeugen zu bauen. Ich sage, nimm dir einen Tag mit jedem und schau, wie weit du kommst. Das gibt Ihnen einen ziemlich guten Hinweis darauf, welche Tools für die Aufgabe geeignet sind und sich für Sie am wohlsten fühlen.

Meteorist heutzutage der letzte Schrei (das bekannteste Full-Stack-JavaScript-Framework auf GitHub und Meteorpedia ist eine in Meteor geschriebene Wiki-Engine.

Das Startvideo wird Sie um 1:28 begeistern.

Es ist in Bezug auf die Benutzeroberfläche agnostisch und wurde ausführlich mit Bootstrap und Famo.us getestet . Es generiert auch mobile Apps aus derselben Codebasis.

Ihre Wahl des Frameworks schränkt Ihre UI-Auswahl möglicherweise nicht so stark ein, wie Sie es sich vorstellen. Dieser kürzlich erschienene Artikel von Henri Bergius über das Entkoppeln von Content Management veranschaulicht den Punkt viel besser als ich - und enthält übrigens Links zu einem ziemlich süß aussehenden In-Place-Content-Editor mit reinem JavaScript (Framework-unabhängig) .

Du bist nicht allein!

VanillaJS und Ampersand .. sind großartige Beispiele für das ernsthafte Bestreben nach einfacherem, modularerem JavaScript.

Es gibt sogar ein Buch darüber.

Die Einfachheit wird durch eine unterbewertete es6-Funktion angetrieben: Module und den SystemJS- Implementierungsstandard. Es kann sogar auf Nicht-Es6-Systemen verwendet werden.

Wie cool ist das!

Ich würde sagen, dass Sie bei der Auswahl der Kandidaten insgesamt falsch liegen, da Sie Angular und Ember weglassen, die beide besser geeignet sind als alle anderen aufgeführten Frameworks.

Insgesamt würde ich sagen, dass Angular.js das Framework für dieses ist.

Schwerpunkt Routing

Vieles, worüber Sie sprechen (mehrere Seitenleisten für die Navigation, eine App für eine einzelne Seite), hängt vom Routing ab oder davon, wie das Front-End den Text in Ihrer URL-Navigationsleiste interpretiert.

Sowohl Angular.js als auch Ember verfügen über hervorragende Router, mit denen Sie alles, was Sie benötigen, ohne zusätzlichen Code ausführen können.

Zu Ihrem Vorteil finden Sie hier eine kurze Aufschlüsselung der Funktionen in Angular, mit denen Sie Ihr Wiki für einzelne Seiten erstellen können

Die Struktur der Site selbst

Angular verfügt über eine erstaunliche Bibliothek namens UI-Router, mit der Sie sowohl eine benutzerdefinierte Navigation erstellen als auch eine SEO-freundliche Struktur zum Anzeigen Ihrer Inhalte einrichten können. Mehrere Ansichten würden auch eine obere Symbolleiste ermöglichen.

Ui-Router-Tutorial: http://cacodaemon.de/index.php?id=57

WYSIWYG-Editor

Angular basiert auf einer Live-Zwei-Wege-Bindung (wenn Sie irgendwo etwas ändern, ändert es sich automatisch überall anders.) Daher enthält es viele Funktionen, die mit dieser Art von Editor gut funktionieren. Es wurden bereits einige gute erstellt, die Sie nur implementieren müssen.

http://textangular.com/

Grafiken und andere ordentliche Sachen

Winkelanweisungen dienen beispielsweise zum Erstellen wiederverwendbarer Diagrammkomponenten. Sie unterscheiden sich nicht vollständig von Wordpress-Widgets. Viele davon wurden bereits entwickelt und können in Ihr Angular-Projekt eingefügt werden.

http://www.sitepoint.com/creating-charting-directives-using-angularjs-d3-js/

In Bezug auf Ember weiß ich nicht viel darüber, daher kann ich nicht mit seinen Besonderheiten sprechen.

Ein Vorschlag zu Backbone: Wenn Sie sich für die Verwendung von Backbone entscheiden, sollten Sie sich für Marionnete entscheiden, da es Backbone ist, aber eine bessere architektonische Struktur und eine bessere Meinung hat (ich persönlich bin der Meinung, dass Backbone keine Richtlinien festlegt, und das fühlt sich bei großen Apps wie ein Nachteil an). .

Ich habe ein paar Monate damit gearbeitet, indem ich verschiedene js-Bibliotheken kombiniert habe und mich nicht wie andere Frameworks in den Weg gestellt habe. Die Nachrichten-Pipeline ist eine wirklich gute Möglichkeit, Komponenten über die App zu verbinden, aber sie zu entkoppeln.

Hier hast du ein großartiges Gespräch, das mich dazu gebracht hat, mich dafür zu entscheiden: https://www.youtube.com/watch?v=qWr7x9wk6_c

Und hier haben Sie einen Demo-Prototyp, der auch das Drag & Drop-Element sowie andere verbundene js-Bibliotheken enthält. Würde gerne hören, was Sie über meinen Code denken, da ich 1,5 Jahre an der Webentwicklung gearbeitet habe ... Ich bin immer noch ein Neuling: https://github.com/Drasky-Vanderhoff/marionette-demo/

Über Knockout ist es wirklich gut, wenn Sie mit den bereits vorhandenen Inhalten interagieren möchten und sich nicht ständig mit dem Backend verbinden. Ich habe 6 Monate damit gearbeitet und muss am Ende viele andere js libs für das Routing verwenden. Außerdem wiederhole ich am Ende viele der Strukturen, die Backbone und andere JS Frameworks haben. Was ich sagen werde ist, dass es dir überhaupt nicht in die Quere kommt und eher ein Werkzeug als eine Einschränkung ist. Auch das war vor fast einem Jahr, also haben sich einige Dinge geändert.

Eine Sache, wenn Sie Knockback (Knockout + Backbone) finden ... vermeiden Sie es, die Dokumentation ist nicht so gut wie sie sein sollte und Sie werden viel mehr Zeit brauchen, um es zu lernen. Wenn Sie es versuchen möchten, machen Sie zuerst einen schnellen Prototyp, um zu sehen, ob es das ist, was Sie wollen.