web-dev-qa-db-de.com

Warum hat knockout.js den Ruf, für kleine Projekte besser zu sein, backbone.js für große?

Ich benutze knockout.js seit ein paar Monaten und finde es eine tägliche Freude, es zu benutzen. Die Vorteile, wenn Sie den Status auf dem Dom nicht verwalten oder Ihre eigenen benutzerdefinierten Bindungen anwenden müssen, sind unglaublich, und es macht mir nichts aus, wenn Sie nicht über die Funktionen des Standardmodells verfügen. Aber jedes Mal, wenn ich einen Überblick über knockout.js im Vergleich zu anderen Frameworks lese, scheint der Konsens zu bestehen, dass es großartig ist, insgesamt weniger Code und Komplexität erzeugt, aber besser für kleinere Projekte geeignet ist. Diese Aussage wird immer faktisch gemacht, ohne viel Erklärung, so dass ich verwirrt bin, wie der Konsens zu sein scheint. (Fairerweise habe ich Backbone noch nicht verwendet und weiß daher nicht wirklich, wie sie miteinander verglichen werden.)

Ich habe es bei zwei ziemlich großen Projekten verwendet, jedes mit ungefähr einem Dutzend Modellen und ungefähr einem Dutzend Ansichtsmodellen, und habe kein Problem damit gesehen. Der einzige Nachteil, den ich in einem großen Projekt gegenüber Backbone feststellen kann, ist, dass Sie einen nicht zu vernachlässigenden Leistungseffekt erzielen, wenn Sie alle Bindungen im Knockout-Modus anwenden und verwalten. Aber ist das die Hauptsorge oder fehlt mir noch etwas?

65
Jeremy Smith

Aus meiner (kurzen) Vergleich von Knockout und Backbone :

Ziel von Knockout ist es, eine übersichtliche, benutzerfreundliche Modellbindung zwischen HTML und Modell bereitzustellen. Es ist sehr XAML/Silverlight/WPF-ähnlich wie in den Implementierungs- und Verwendungsmustern (dies ist sinnvoll, wenn man bedenkt, woher es stammt). Knockout bietet jedoch keine Anleitung oder Konstrukte außerhalb des Modells. Die Entwickler müssen gut strukturierte JavaScript-Anwendungen erstellen, die über die Modelle und Modellbindungen hinausgehen. Dies führt Entwickler ohne gute JavaScript-Kenntnisse häufig auf einen schlechten Weg, da sie nicht erkennen, dass sie bei der Verwendung von Knockout eine gute Anwendungsstruktur berücksichtigen müssen. Natürlich ist dieses Problem keineswegs die Schuld von Knockout. In vielen Fällen fehlt lediglich das Verständnis dafür, was das Tool bietet oder wie große JavaScript-Apps strukturiert werden.

Persönlich mag ich Knockout nicht. Ich bin kein Fan des MVVM-Musters. Ich bevorzuge den Backbone-Ansatz und verbringe die meiste Zeit damit. Ich denke jedoch, dass die "sachlichen" Meinungen darüber, dass Knockout nicht für große Anwendungen geeignet ist, falsch sind. Mit Knockout können Sie sehr große, komplexe und gut strukturierte Anwendungen erstellen. Sie müssen jedoch die gesamte Struktur über die Datenbindung und die Modelle hinaus bereitstellen .

70
Derick Bailey

Sie werden feststellen, dass Webanwendungstrends, wie Modetrends, spark= viele Meinungen auslösen. Meistens gibt es keine richtigen oder falschen Antworten. Aber jeder hat seinen eigenen persönlichen Stil und du musst nur deine finden.

Ich persönlich mag sowohl Knockout als auch Backbone und habe mich gefreut zu erfahren, dass man sich eigentlich nicht zwischen ihnen entscheiden muss. Sie können ein Plugin namens "Knockback" verwenden, das sie gut miteinander verbindet.

Ich mag die MVP-Struktur von Backbone mit den deklarativen Bindungen von Knockout. Ich habe einen Blogeintrag darüber geschrieben , mit einigen Beispielen, wenn Sie mehr erfahren möchten.

Der Performance-Hit von Knockout für große komplexe DOMs kann umgangen werden, indem Sie Ihre Bindungen auf bestimmte DOM-Elemente beschränken, anstatt sie global anzuwenden:

ko.applyBindings(myViewModel, $('#myElement')[0]);

Die [0] am Ende ist erforderlich, da Knockout ein DOM-Element und kein jQuery-Objekt als zweiten Parameter erwartet.

35

Die Code-Organisation von großen Javascript-Anwendungen ist ein herausforderndes Problem und völlig unabhängig von dem verwendeten Framework - es sei denn, das Framework bietet eine umfangreiche Strukturierung mit Meinungen.

Wenn man bedenkt, dass weder Backbone.js noch Knockout.js eine empfohlene Verzeichnisstruktur oder empfohlene Lifecycle-Management-Methodik haben und welche fehlende Funktionalität auch immer in Bezug auf eine andere vorhanden ist, mit von der Community unterstützten Plugins oder eigenständigen Mikroframeworks ausgefüllt werden kann, hat dies ernsthaft keinen Sinn im Hinblick auf Größe/Komplexität der Anwendung eines als dem anderen überlegen zu betrachten.

Wenn Sie derzeit mit einer umfangreichen Javascript-Anwendung beginnen, ist die Verwendung von Angular.js möglicherweise besser geeignet als die Verwendung von Knockout.js, wenn Sie einen deklarativen Ansatz, eine DOM-Attribut-basierte Datenbindung und ein MVVM-Muster sowie Ember.js bevorzugen besser geeignet als Backbone.js, wenn Sie MVC- und string-basierte Vorlagen (Handlebars) bevorzugen. Beide befinden sich in der aktiven Entwicklung und vergleichen sich in Bezug auf die Funktionen miteinander. Sie wurden speziell entwickelt, um die Probleme bei der Arbeit mit großen Anwendungen mit kleineren Frameworks wie Backbone und Knockout zu lösen.

3
lorefnon