SproutCore vs. Cappuccino

Question

Mis à part les différences de langage entre Javascript et Objective-J, quels sont les avantages de Cappuccino par rapport à SproutCore et vice-versa, selon votre expérience ?

En termes de prévision à long terme, SproutCore est-il plus "soutenu" que Cappuccino parce qu'il est soutenu par Apple ?

J'essaie de choisir entre les deux. Je suis à la fois familier avec JavaScript et Objective-C.

Answer 1

C'est une question intéressante, qui revient assez fréquemment dans divers groupes de discussion, sur Twitter et même sur IRC. Il y a plusieurs façons d'évaluer SproutCore par rapport à Cappuccino, mais, peut-être, certains des caparisons immédiats que les gens regardent sont les suivants :

1) Leurs caractéristiques respectives
2) Facilité d'utilisation
3) Soutien communautaire et documentation

Examinons le premier point : l'ensemble des fonctionnalités respectives. Par "ensemble de fonctionnalités", il y a plusieurs façons de voir les choses. Du nombre de widgets d'interface utilisateur qu'ils possèdent, au support fondamental pour connecter les choses ensemble et communiquer avec une sorte de back-end, en passant par l'approche architecturale générale du framework, qui n'est pas nécessairement une "fonctionnalité", mais qui reste importante, et, oui, même le langage que vous pouvez utiliser.

En ce qui concerne la langue, je pense qu'il est important que vous ne négligiez pas ce qui est utilisé (JS contre Obj-J). Pourquoi ? En raison de l'adoption et d'où vous venez. SproutCore est parti du principe que JavaScript est effectivement le langage du web, et c'est donc ce que vous utilisez pour programmer contre le framework. Les lacunes de JavaScript en matière de complétude OO du langage (héritage objet-objet correct, etc.) sont compensées par le framework (par exemple, MyApp.Foo = SC.Object.extend({...})). Cappuccino arrive sous un angle différent. Il utilise Obj-J comme une amélioration du langage primaire de JS afin d'injecter des fonctionnalités de langage qui manquent à JS, au lieu d'injecter ces fonctionnalités de langage directement dans le framework (Cappuccino) lui-même. Bien sûr, comme les gens de Cappuccino l'ont déjà fait remarquer, vous pouvez toujours utiliser JS pour programmer avec Cappuccino proprement dit, mais, dans ce cas, vous ne bénéficiez pas de ce que fournit Obj-J. Note à la communauté Cappuccino : Veuillez me corriger si je me trompe :-). Enfin, si vous êtes déjà familiarisé avec Obj-C, alors Obj-J sera peut-être plus votre tasse de thé. Hé, même Sony est apparemment en train de prendre le train en marche d'Obj-C pour développer sur leur plateforme mobile :-P.

Si l'on examine l'architecture des deux frameworks, on constate qu'ils se sont tous deux inspirés, sous une forme ou une autre, du framework Cocoa d'Apple. Cappuccino a pris Cocoa à cœur et a essentiellement porté l'API de Cocoa. Encore une fois, si vous venez de développer des applications dans Apple en utilisant Cocoa, vous allez probablement vous sentir comme chez vous. SproutCore, quant à lui, s'est inspiré de Cocoa là où il le fallait. En ce qui concerne l'architecture pure, ils suivent tous les deux le modèle MVC, ils utilisent tous les deux des liaisons de style Cocoa, ils disposent tous les deux d'un mécanisme de stockage des données et ils ont tous les deux leur propre style respectif de rendu et de composition des widgets et des vues de l'interface utilisateur.

Le rendu des vues est, à mon sens, un point particulièrement important. Les deux frameworks présentent un certain niveau d'abstraction afin de vous éviter de vous occuper directement des CSS et du HTML, même si, en fin de compte, ils doivent effectuer le rendu en fonction de ce que le navigateur Web comprend en définitive.

Du côté de Cappuccino, on fait complètement abstraction des CSS et du HTML. Au lieu de cela, vous utilisez les diverses primitives de rendu du framework pour "dessiner" vos vues. Grâce à ce niveau d'abstraction, Cappuccino peut utiliser la meilleure approche de rendu disponible au lieu de vous coupler, dans une certaine mesure, avec CSS et HTML.

En ce qui concerne SproutCore, vous effectuez un rendu plus proche du "métal", pour ainsi dire. Lorsque vous effectuez un rendu pur d'une vue, vous utilisez un objet de contexte de rendu qui fournit un certain degré d'abstraction, mais, en fin de compte, vous injectez directement du HTML et ajoutez des noms de classe pour appliquer du CSS. Même après que votre vue a été rendue et que vous souhaitez manipuler certaines parties de la vue en fonction d'un événement, vous pouvez accéder directement aux éléments du DOM et manipuler leurs propriétés. Selon votre point de vue, cela peut sembler bon ou mauvais. C'est une bonne chose pour ceux qui ont l'habitude de travailler avec les CSS et le HTML et qui aiment le contrôle plus direct de la façon dont les vues sont rendues et stylisées. Mauvais si vous voulez rendre une vue de manière générique afin d'utiliser la meilleure approche de rendu en fonction de ce que le navigateur permet (HTML/CSS, SVG, HTML5 canvas, etc.). Mais, notez qu'il existe des plans futurs pour que SproutCore ait une approche de rendu plus abstraite tout en vous permettant de travailler directement avec HTML et CSS si vous le souhaitez. Vous obtiendrez ainsi le meilleur des deux mondes.

En ce qui concerne les widgets et les vues de l'interface utilisateur de base fournis par les deux frameworks, ils sont tous les deux dotés d'un grand nombre de fonctionnalités prêtes à l'emploi. Boutons, étiquettes, listes, vues segmentées, boutons radio, défileurs, etc ils sont tous là. Par conséquent, on peut dire que vous êtes bien dans les deux camps.

En revenant en arrière, parlons maintenant de la facilité d'utilisation. Pour moi, la facilité d'utilisation est basée sur votre expérience personnelle de travail avec JavaScript, HTML, Obj-C, Cocoa, d'autres frameworks MVC, la documentation et le support de la communauté. Si vous n'avez jamais travaillé avec Cocoa, ou si vous n'avez jamais construit une application de type decktop ou iPad, il est juste de dire que vous allez avoir une certaine courbe d'apprentissage, quel que soit le framework que vous choisissez. Cela dit, ce que vous ne savez pas et ce que vous voulez apprendre peuvent être acquis par le biais de la communauté et de la documentation de chaque framework. Les deux ont des communautés actives d'une manière ou d'une autre, vous ne serez donc pas laissé de côté si vous êtes bloqué quelque part. En ce qui concerne la documentation, il est vrai que Cappuccino a le dessus. La documentation de SproutCore est insuffisante, mais le code de base est au moins entièrement commenté. La communauté SproutCore est pleinement consciente de la nécessité de mettre à jour la documentation, et c'est une question qui est actuellement traitée, alors continuez à vérifier.

Enfin, vous avez mentionné les prévisions à long terme pour les deux cadres. Il est de notoriété publique que Motorola a acheté le framework Cappuccino, de sorte qu'une grande entreprise soutient certainement sa croissance et sa longévité, ou du moins c'est ce qu'il semble pour l'instant. En ce qui concerne Apple et SproutCore, je ne peux personnellement pas parler en leur nom, mais Apple ne possède pas le framework. De nombreuses entreprises et de nombreux individus utilisent le framework et y contribuent d'une manière ou d'une autre. Cela pourrait donner à certaines personnes et entreprises une pause ou un malaise pour ceux qui s'intéressent à SproutCore en raison de la nature plus organique du développement du framework, mais je ne vois pas cela comme un problème. J'ai le sentiment que les deux frameworks existeront encore longtemps, surtout maintenant que de plus en plus de personnes envisagent de développer des applications de bureau et iPad de nouvelle génération à l'aide de frameworks open source. Et, hé, la concurrence entre les frameworks est une bonne chose - elle permet à chacun de rester sur ses gardes :-).

J'espère que ces informations vous aideront à prendre votre décision !

A la vôtre,

Mike

Answer 2

J'aimerais revenir sur les commentaires faits sur l'objectif-j Michael.

Vous ne perdrez rien si vous passez à JavaScript au lieu d'Objectif-j. En réalité, la distinction est assez difficile à faire, surtout dans les cas où nous avons des classes passerelles gratuites (nous y reviendrons).

Objective-j n'est en fait qu'une enveloppe fine sur js. Il fournit l'héritage classique - quelque chose qui a traditionnellement été implémenté comme une fonctionnalité du langage, que sproutcore implémente comme une fonctionnalité du framework - il fournit également l'importation de code, la génération d'accesseurs, le scoping statique, et le support de la messagerie nil.

Les variables d'instance d'Objective-j sont accessibles via la syntaxe traditionnelle du point si vous le souhaitez... J'aime à penser qu'une fois que vous commencez à écrire une méthode, vous écrivez principalement du JavaScript. C'est-à-dire que les boucles, les variables, les fonctions, les fermetures, etc. ne sont que du JavaScript. Vous ne perdez rien en descendant, c'est exactement comme ça que le langage est conçu.

Nous allons encore plus loin en créant des passerelles gratuites avec certaines de nos classes CPDate, CPArray, CPException, CPString et peut-être d'autres dont je ne me souviens plus. Le Toll free bridging signifie simplement qu'un CPArray EST un tableau natif js, et qu'un tableau natif js est un CPArray, de sorte que vous pouvez utiliser les méthodes et fonctions des deux mondes de manière interchangeable.

Ainsi, par exemple, on pourrait faire :

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

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

Comme vous pouvez le voir, j'utilise la syntaxe objective-j et la syntaxe js ensemble... Vous pouvez imaginer la puissance de cette méthode.

La dernière chose que je veux dire, juste pour m'assurer qu'il n'y a pas de confusion : objective-j est analysé dans le navigateur. Il n'a pas besoin d'être compilé avant (bien que nous fournissions des outils de compilation pour le moment où vous êtes prêt à déployer votre application).

Je pense que certaines personnes sont inutilement rebutées par l'objectif-j comme s'il s'agissait d'une bête monstrueuse qui prendrait du temps à apprendre, et bien que l'objectif-j ajoute beaucoup de fonctionnalités intéressantes à js, les apprendre ne vous prendra pas vraiment la majeure partie d'une journée si vous êtes déjà familier avec la programmation orientée objet, et évidemment si vous venez du cacao vous serez capable de vous lancer directement.

Answer 3

J'ai écrit un article de blog sur le thème "cappuccino vs. sproutcore". Il ne s'agit pas d'une comparaison technique mais d'une comparaison d'autres données intéressantes.

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

Answer 4

La réponse de Michael Cohens a pratiquement tout couvert puisqu'elle était extrêmement détaillée.

Je me débats avec une décision depuis 3 semaines. J'ai lu tout ce qu'il y a sur le web à propos des deux frameworks et j'ai écrit beaucoup d'exemples de sources avec les deux, mais je n'arrive toujours pas à prendre une décision. Les problèmes suivants me font sauter d'un framework à l'autre et rendent ma décision encore plus difficile.

1. Sproutcore a une meilleure api de stockage de données que celle de Cappuccino.

2. Sproutcore utilise les liaisons mieux que ne le fait actuellement cappuccino. Cappuccino prend également en charge kvc/kvo, mais les liaisons ne sont pas encore tout à fait au point. Par exemple, dans sproutcore, vous pouvez implémenter très facilement le chargement incrémentiel avec les bindings et ArrayController, alors que dans cappuccino, ce n'est pas aussi simple. Bien sûr, cappuccino offre l'api CPTableView DataStore qui est assez propre et permet d'obtenir des résultats similaires, mais pas avec des bindings. C'est ce que faisait Cacao avant le Core Data. On travaille constamment sur les liaisons dans Cappuccino.

3. Cappuccino a un meilleur api de vue selon mon goût personnel. Bien que je sois habitué à développer du html et du DOM, je préfère de loin l'idée d'abstraire complètement le DOM et de se débarrasser du css.

4. Un problème qui me tient vraiment à cœur est l'absence d'un bon TableView dans sproutcore. Actuellement, SC.TableView est en version alpha et n'est pas du tout performant. Je ne connais pas de calendrier pour le TableView dans Sproutcore. J'ai essayé de demander sur le canal irc sproutcore mais je n'ai pas obtenu de réponse satisfaisante. Cappuccino, d'un autre côté, a une vue de table formidable et très optimisée.

5. J'ai trouvé plus d'applications réelles écrites sur cappuccino que sur sproutcore. Il existe également une application complète très intéressante, fournie par cappuccino en tant qu'échantillon source, qui est très utile. Consultez le site http://githubissues.heroku.com/ .

Malgré le fait que je n'ai aucune expérience en Objective-C et que je préfère de loin la syntaxe js pure, je vais probablement utiliser Cappuccino pour mon projet actuel et j'espère que Sproutcore proposera une meilleure vue de table à l'avenir.

Answer 5

Extrait du site web de Cappuccino :

"À l'opposé des cadres existants, on trouve des technologies comme SproutCore. Bien que SproutCore ait des objectifs similaires à ceux de Cappuccino, son approche est nettement différente. Il s'appuie toujours sur HTML, CSS, JavaScript, Prototype et un ensemble entièrement nouveau et unique d'API. Il nécessite également un logiciel de développement spécial et une étape de compilation fastidieuse. Nous pensons que c'est la mauvaise approche.

Avec Cappuccino, vous n'avez pas besoin de connaître le langage HTML. Vous n'écrirez jamais une ligne de CSS. Vous n'aurez jamais à interagir avec le DOM. Nous ne demandons aux développeurs que d'apprendre une technologie, Objective-J, et un ensemble d'API. De plus, ces technologies sont des implémentations de technologies existantes bien connues et bien comprises. Les développeurs peuvent s'appuyer sur des décennies d'expérience collective pour accélérer le rythme de création d'applications web riches."

Il semble donc que Cappuccino n'ait pas besoin d'outils de construction et qu'il rende le navigateur complètement abstrait pour le développeur. Alors que dans Sproutcore, vous disposez d'outils de construction (un serveur de développement, par exemple) et le développeur devrait être quelque peu conscient de ce qu'est DOM.