SproutCore vs. Cappuccino

Question

Abgesehen von den Sprachunterschieden Javascript vs. Objective-J Welche Vorteile bietet Cappuccino gegenüber SproutCore und umgekehrt in Ihren Erfahrungen?

In Bezug auf eine langfristige Prognose wird SproutCore mehr "unterstützt" als Cappuccino, weil es von Apple unterstützt wird?

Ich versuche, zwischen den beiden zu wählen. Ich bin sowohl mit JavaScript als auch mit Objective-C vertraut.

Answer 1

Dies ist eine interessante Frage, die häufig in verschiedenen Nachrichtengruppen auftaucht, twitter, und sogar IRC: Es gibt eine Reihe von Möglichkeiten, um SproutCore gegen Cappuccino zu bewerten, aber vielleicht sind einige der unmittelbaren Vergleiche, die die Leute betrachten, folgende:

1) Ihre jeweiligen Feature-Set
2) Einfache Bedienung
3) Unterstützung der Gemeinschaft und Dokumentation

das am ersten Punkt aussehen lassen - es entsprechendes Feature-Set. Mit "Feature-Set" gibt es ein paar Möglichkeiten, um es zu betrachten. Aus der Anzahl der UI-Widgets, die sie haben; die grundlegende Unterstützung, um Dinge miteinander zu verbinden und mit einer Art Back-End zu kommunizieren; der allgemeine architektonische Ansatz des Frameworks, obwohl nicht unbedingt ein "Feature", aber immer noch wichtig; und ja, sogar die Sprache, die du benutzen kannst.

In Bezug auf Sprache, denke ich, ist es wichtig, dass Sie nicht entlassen, was verwendet wird (JS gegen Obj-J). Warum? Wegen der Adoption und woher du kommst. SproutCore kam aus der Perspektive, dass JavaScript in der Tat die Sprache des Webs ist, also ist es das, was Sie verwenden, um gegen das Framework zu programmieren. Wo JavaScript in der OO-Vollständigkeit der Sprache fehlt (korrekte Object-Object-Vererbung usw.), gleicht es im Framework aus (z. B. MyApp.Foo = SC.Object.extend ({...})). Cappuccino kommt aus einem anderen Blickwinkel. Sie verwenden Obj-J als eine primäre Sprachverbesserung für JS, um Sprachfunktionen einzufügen, die JS fehlen; anstatt diese Sprachmerkmale direkt in das Framework (Cappuccino) zu injizieren. Natürlich, wie die Leute bei Cappuccino vorher bemerkt haben, können Sie immer noch JS verwenden, um gegen Cappuccino richtig zu programmieren, aber dann verpassen Sie, was Obj-J bietet. Hinweis an die Cappuccino-Gemeinde: Bitte korrigieren Sie mich, wenn ich falsch liege :-). Wenn Sie jemand sind, der bereits mit Obj-C vertraut ist, dann ist Obj-J vielleicht mehr Ihre Tasse Tee. Hey, selbst Sony scheint jetzt auf den gesamten Obj-C-Zug aufzuspringen, um sich gegen ihre mobile Plattform zu entwickeln :-P.

Mit Blick auf die Architektur der beiden Frameworks, beide sahen sich Apples Cocoa-Framework für Anleitung/Inspiration in der einen oder anderen Form. Cappuccino nahm Cocoa voll zu Herzen und portionierte Cocoas API. Auch wenn Sie von Apple mit Cocoa Apps entwickeln, werden Sie sich wahrscheinlich sofort wie zu Hause fühlen. SproutCore hingegen wurde von Cocoa inspiriert, wo es sich richtig anfühlte. Was die reine Architektur betrifft, folgen beide MVC, beide verwenden Cocoa-Stil-Bindungen, beide haben einen Datenspeicher-Mechanismus, und beide haben ihren eigenen jeweiligen Stil zum Rendern und Komponieren von UI-Widgets/Ansichten.

Die Wiedergabe von Ansichten ist für mich ein besonderer Bereich von Bedeutung. Beide Frameworks verfügen über eine gewisse Abstraktion auf der Ebene, um Sie davon abzuhalten, direkt mit CSS und HTML zu arbeiten, obwohl sie am Ende des Tages rendern müssen, was der Web-Browser letztendlich versteht.

Auf der Cappuccino-Seite abstrahieren sie komplett CSS und HTML von Ihnen. Stattdessen verwenden Sie die verschiedenen Rendering-Grundelemente des Frameworks, um Ihre Ansichten zu zeichnen. Aufgrund dieses Abstraktionsniveaus kann Cappuccino den besten verfügbaren Rendering-Ansatz nutzen, anstatt Sie bis zu einem gewissen Grad mit CSS und HTML zu koppeln.

Wie bei SproutCore, Rendern Sie näher an das "Metall" sozusagen. Beim reinen Rendern einer Ansicht verwenden Sie ein Renderkontextobjekt, das ein gewisses Maß an Abstraktion bietet, aber Sie injizieren letztlich direkt HTML und fügen Klassennamen hinzu, um CSS anzuwenden. Auch nachdem Ihre Ansicht gerendert wurde und Sie bestimmte Teile der Ansicht basierend auf einem Ereignis bearbeiten möchten, können Sie direkt auf die DOM-Elemente zugreifen und deren Eigenschaften bearbeiten. Je nachdem, woher du kommst, mag das gut oder schlecht sein. Gut für diejenigen, die es gewohnt sind, mit CSS und HTML zu arbeiten und eine direktere Kontrolle darüber zu haben, wie die Ansichten gerendert und gestylt werden. Schlecht, wenn Sie eine Ansicht generisch rendern möchten, um basierend auf den Möglichkeiten des Browsers (HTML/CSS, SVG, HTML5-Zeichen usw.) den besten Render-Ansatz zu verwenden. Es gibt jedoch Pläne, SproutCore zu einem abstrakteren Rendering-Ansatz zu machen, aber Sie können auch direkt mit HTML und CSS arbeiten, wenn Sie dies wünschen. So erhalten Sie schließlich das Beste aus beiden Welten.

Nun, wie für die Aktie UI Widgets/Ansichten die beiden Rahmen kommen mit - sie beide haben eine Menge direkt aus der Box, um Sie in Gang zu bringen. Buttons, Labels, Listen, segmentierte Ansichten, Radiobuttons, Scroller, etc - sie sind alle da. Daher kann man sicher sagen, dass es Ihnen in beiden Lagern gut geht.

Gehen Sie den ganzen Weg zurück, lassen Sie uns jetzt die Benutzerfreundlichkeit diskutieren. Für mich basiert die Benutzerfreundlichkeit auf Ihrer persönlichen Erfahrung mit JavaScript, HTML, Obj-C, Cocoa, anderen MVC-Frameworks, Dokumentation und Community-Support. Wenn Sie noch nie mit Cocoa gearbeitet haben oder noch nie eine Decktop- oder iPad-ähnliche App entwickelt haben, dann ist es fair zu sagen, dass Sie eine gewisse Lernkurve haben werden, egal, welchen Rahmen Sie wählen. Abgesehen davon, was Sie nicht wissen und lernen möchten, können Sie sich über die jeweilige Community und Dokumentation des jeweiligen Frameworks informieren. Beide haben aktive Gemeinschaften in der einen oder anderen, so dass Sie nicht in der Kälte gelassen werden, wenn Sie irgendwo stecken bleiben. Wie für Docs, hat Cappuccino, zugegebenermaßen, die Oberhand. Die Dokumente für SproutCore fehlen, aber die Codebasis ist zumindest vollständig kommentiert. Die SproutCore-Community ist sich völlig bewusst, dass die Dokumente aktualisiert werden müssen, und es wird derzeit mit etwas umgegangen.

Schließlich haben Sie die Langzeitprognose für die beiden Frameworks erwähnt. Es ist allgemein bekannt, dass Motorola das Cappuccino-System gekauft hat, also haben Sie sicherlich eine große Firma, die ihr Wachstum und ihre Langlebigkeit unterstützt, zumindest scheint es so zu sein. Was Apple und SproutCore betrifft, kann ich persönlich nicht für sie sprechen, aber Apple besitzt das Framework nicht. Es gibt viele Unternehmen und verschiedene Einzelpersonen, die alle irgendwie in den Rahmen zurückgreifen und etwas dazu beitragen.Das könnte einigen Leuten und Unternehmen eine Pause oder Unbehagen bereiten, wenn man SproutCore wegen der organischen Natur der Rahmenentwicklung betrachtet, aber ich sehe das nicht als ein Problem. Mein Gefühl ist, dass beide Frameworks für eine lange Zeit existieren werden, besonders jetzt, wenn mehr Entwickler Desktop- und iPad-Apps der nächsten Generation mit Open-Source-Frameworks entwickeln. Und, hey, Wettbewerb zwischen den Frameworks ist gut - hält alle auf ihren jeweiligen Zehen :-).

Ich hoffe, diese Informationen helfen Ihnen bei Ihrer Entscheidung!

Cheers,

Mike

Answer 2

Von der Cappuccino-Website:.

„Am anderen Ende der Rahmenbedingung sind Technologien wie SproutCore Während SproutCore mit ähnlichen Zielen zu Cappuccino angegeben, dauert es einen sichtlich anderen Ansatz Es stützt sich nach wie vor auf HTML. CSS, JavaScript, Prototype und ein ganz neuer und einzigartiger Satz von APIs, erfordert auch spezielle Entwicklungssoftware und einen umständlichen Kompilierungsschritt.Wir denken, dass dies der falsche Ansatz ist.

Mit Cappuccino müssen Sie nicht wissen HTML: Du schreibst niemals eine CSS-Zeile, du interagierst nie mit DOM. Wir bitten nur Entwickler, eine Technologie, Objective-J und eine Reihe von APIs zu erlernen nologien sind Implementierungen von bekannten und gut verstandenen bestehenden. Entwickler können die jahrzehntelange kollektive Erfahrung nutzen, um die Entwicklung von Rich-Web-Anwendungen zu beschleunigen. "

So scheint es, dass Cappuccino keine Build-Tools benötigt und den Browser komplett vom Entwickler abstrahiert. In Sproutcore Sie erhalten Build-Tools (zum Beispiel einen Entwicklungsserver) und der Entwickler sollte sich etwas dessen bewusst sein, was DOM ist.

Answer 3

Michael Cohens beantworten alles ziemlich bedeckt, da es sehr detailliert war.

Ich habe in den letzten 3 Wochen mit einer Entscheidung gekämpft. Ich habe alles gelesen, was es im Netz über beide Rahmen gibt, und ich habe viele Quellproben mit beiden geschrieben und kann immer noch keine Entscheidung treffen. Die folgenden Probleme lassen mich von einem Rahmen zum anderen springen und machen meine Entscheidung härter.

1. Sproutcore hat einen besseren Datenspeicher api als der eine Cappuccino hat.

2. Sproutcore verwendet Bindungen besser als Cappuccino derzeit tut. Cappuccino hat auch kvc/kvo Unterstützung, aber Bindungen sind noch nicht ganz da. Zum Beispiel können Sie in sproutcore das inkrementelle Laden mit Bindings und ArrayController sehr einfach implementieren, während es beim Cappuccino nicht so einfach ist. Cappuccino bietet natürlich den CPTableView DataStore api, der ziemlich sauber ist und ähnliche Ergebnisse nur mit Bindings erzielen kann. Was Kakao vor den Kerndaten getan hat. In Cappuccino wird jedoch ständig an Bindungen gearbeitet.

3. Cappuccino hat eine bessere Sicht api nach meinem persönlichen Geschmack. Obwohl ich es gewohnt bin, HTML und das DOM zu entwickeln, bevorzuge ich die Idee, das DOM komplett zu abstrahieren und css loszuwerden.

4. Ein Problem, das mir wirklich wichtig ist, ist das Fehlen einer guten TableView in Sproutcore. Derzeit ist SC.TableView in Alpha und es ist überhaupt nicht performant. Ich kenne keine Zeitleiste für die Tabellenansicht in Sproutcore. Ich habe versucht, auf dem IRC-Sproutcore-Kanal zu fragen, bekam aber keine befriedigende Antwort. Cappuccino dagegen hat eine tolle und sehr optimierte Tischansicht.

5. Ich habe mehr reale Anwendungen auf Cappuccino geschrieben als auf Sproutcore. Es gibt auch eine ziemlich schöne vollständige Anwendung, die von Cappuccino als Quellprobe zur Verfügung gestellt wird und ist sehr hilfreich. Schauen Sie sich http://githubissues.heroku.com/ an.

Trotz der Tatsache, dass ich keine Erfahrung in Objective-C und ich viel lieber die reine js Syntax ich wahrscheinlich mit Cappuccino auf meinem aktuellen Projekt und Hoffnung SproutCore kommt mit einem besseren Tabellenansicht in der Zukunft gehen .

Answer 4

Ich schrieb einen Blogartikel genau über "Cappuccino vs. Sproutcore". Es ist kein technischer Vergleich, sondern vergleicht andere interessante Daten.

http://elii.info/2010/11/cappuccino-vs-sproutcore/

Answer 5

Ich möchte auf die Kommentare über Ziel-j Michael gemacht berühren.

Sie werden nichts verlieren, wenn Sie auf JavaScript anstelle von objective-j zurückgreifen. In Wirklichkeit ist die Unterscheidung schwierig, besonders in Fällen, in denen wir gebührenfreie gebrückte Klassen haben (mehr dazu ein wenig).

Objective-j ist wirklich nur ein dünner Wrapper über js. Es bietet klassische Vererbung, die traditionell als Sprachfeature implementiert wurde, die sproutcore als Framework-Feature implementiert, es bietet auch Code-Import, Accessor-Generierung, statisches Scoping und Unterstützung für Messaging-Nil.

Objective-j-Instanzvariablen sind über die traditionelle Punktsyntax zugänglich, wenn Sie möchten ... Ich denke so: Wenn Sie eine Methode schreiben, schreiben Sie meistens JavaScript. Das heißt, Schleifen, Variablen, Funktionen, Schließungen usw. sind alles nur Javascript. Du verlierst nichts durch Herunterfallen, genau so ist die Sprache gestaltet.

Wir gehen noch einen Schritt weiter, indem wir einige unserer Klassen "CPDate", "CPArray", "CPException", "CPString" und vielleicht mehr "gebührenfrei überbrücken", an die ich mich nicht erinnern kann. Gebührenfreies Bridging bedeutet nur, dass ein CPArray ein natives js-Array ist und ein natives js-Array ein CPArray ist, sodass Sie Methoden und Funktionen beider Welten synonym verwenden können.

So zum Beispiel würde tun könnte:

var foo = []; 
[foo addObject:"bar"]; 
foo.push("2nd push"); 
var value = foo[0]; 
var value2 = [foo objectAtIndex:0]; 

alert(value === value2); //true 

Wie Sie bin ich mit Ziel-j Syntax und js Syntax zusammen sehen ... Sie können die Leistung, wenn sich das vorstellen.

Das letzte, was ich herausbringen möchte, nur um sicherzustellen, dass es keine Verwirrung gibt: objective-j wird im Browser geparst. Es muss nicht vorher kompiliert werden (obwohl wir Kompilierungs-Tools zur Verfügung stellen, wenn Sie Ihre App bereitstellen möchten).

Ich denke, einige Leute werden unnötigerweise von objective-j als ob es eine monströse Bestie, die Zeit dauern wird zu lernen, und während Objective-j fügt eine Menge von tollen Funktionen zu js hinzu, um sie tatsächlich zu lernen nicht Wenn Sie bereits mit objektorientierter Programmierung vertraut sind, werden Sie wahrscheinlich den besseren Teil eines Tages brauchen, und wenn Sie aus Kakao kommen, können Sie natürlich direkt hineinspringen.