SproutCore против капучино

Ответ 1

Это интересный вопрос, который довольно часто выскакивает на разные группы сообщений, твиттер и даже IRC. Есть несколько способов оценить SproutCore и Cappuccino, но, возможно, некоторые из непосредственных соображений, которые люди смотрят, следующие:

1) Их соответствующий набор функций 2) Простота использования
3) Поддержка и документация сообщества

Посмотрим на первую точку - соответствующий набор функций. Под "набором функций" есть несколько способов взглянуть на него. Из количества виджетов пользовательского интерфейса; основополагающая поддержка для соединения вещей и общения с каким-то внешним видом; каркасный общий архитектурный подход, хотя и не обязательно "особенность", но все же важная; и, да, даже язык, который вы можете использовать.

Что касается языка, я считаю важным, чтобы вы не отвергали то, что используется (JS против Obj-J). Зачем? Из-за принятия и того, откуда вы пришли. SproutCore пришел с точки зрения того, что JavaScript действительно является языком Интернета, так что вы используете для программирования против фреймворка. В тех случаях, когда JavaScript не хватает на языке OO полноты (надлежащее наследование объектного объекта и т.д.), Это компенсируется в рамках (например, MyApp.Foo = SC.Object.extend({...})). Капучино приходит под другим углом. Они используют Obj-J в качестве основного улучшения языка для JS, чтобы внедрять языковые функции, отсутствующие в JS; это вместо того, чтобы вводить эти языковые функции непосредственно в структуру (Cappuccino). Конечно, как уже отмечали люди в Cappuccino, вы все равно можете использовать JS для программирования непосредственно с Cappuccino, но тогда вы упускаете то, что предоставляет Obj-J. Обратите внимание на сообщество Cappuccino: Пожалуйста, поправьте меня, если я ошибаюсь:-). Наконец, если вы уже знакомы с Obj-C, то Obj-J может быть больше вашей чашкой чая. Эй, даже Sony, судя по всему, теперь прыгает на всем победителе Obj-C, чтобы развиваться против своей мобильной платформы: -P.

Глядя на архитектуру двух фреймворков, они оба смотрели на структуру Apple Cocoa для руководства/вдохновения в той или иной форме. Cappuccino принял Cocoa полностью к сердцу и в основном портировал Cocoas API. Опять же, если вы собираетесь разрабатывать приложения в Apple с помощью Cocoa, тогда вы, вероятно, почувствуете себя как дома. С другой стороны SproutCore взял вдохновение от Cocoa, где он чувствовал себя хорошо. Что касается чистой архитектуры, они оба следуют MVC, они оба используют привязки Cocoa -style, у них обоих есть механизм хранения данных, и оба они имеют свой собственный стиль визуализации и компоновки виджета/представлений пользовательского интерфейса.

Проведение представлений - это для меня особая область важности. Обе структуры имеют некоторую абстракцию уровня, чтобы удалить вас от прямого взаимодействия с CSS и HTML, хотя в конце концов они должны отображать то, что в конечном итоге понимает веб-браузер.

На стороне Cappuccino они полностью абстрагируют от вас CSS и HTML. Вместо этого вы используете фреймворк различных примитивов рендеринга для "рисования" ваших представлений. Из-за этого уровня абстракции Cappuccino может использовать лучший подход рендеринга, а не связывать вас, в некоторой степени, с CSS и HTML.

Что касается SproutCore, вы оказываетесь ближе к "металу", так сказать. При выполнении чистого рендеринга представления вы используете объект контекста рендеринга, который обеспечивает определенную степень абстракции, но, в конечном счете, вы непосредственно вставляете HTML и добавляете имена классов для применения CSS. Даже после того, как ваше представление было отображено, и вы хотите манипулировать определенными частями представления на основе события, вы можете напрямую обращаться к элементам DOM и управлять их свойствами. В зависимости от того, откуда вы пришли, это может показаться хорошим или плохим. Хорошо для тех, кто привык работать с CSS и HTML, и как более прямой контроль над тем, как визуализируются и стилизуются представления. Плохо, если вы хотите в целом визуализировать представление, чтобы использовать лучший подход рендеринга на основе того, что позволяет браузер (HTML/CSS, SVG, холст HTML5 и т.д.). Но, обратите внимание, есть планы на будущее сделать SproutCore более абстрактным способом рендеринга, но все же позволять вам напрямую работать с HTML и CSS, если вы этого захотите. Таким образом, вы в конечном итоге получите лучшее из обоих миров.

Теперь, что касается виджета/просмотров пользовательского интерфейса запаса, в который входят две рамки: у них обоих есть много возможностей, чтобы вы начали. Кнопки, метки, списки, сегментированные представления, переключатели, скроллеры и т.д. - все они есть. Поэтому можно с уверенностью сказать, что у вас все в порядке в обоих лагерях.

Возвращаясь назад, давайте обсудим простоту использования. Для меня простота использования основана на вашем собственном личном опыте работы с JavaScript, HTML, Obj-C, Cocoa, другими структурами MVC, документацией и поддержкой сообщества. Если вы никогда не работали с Cocoa, или никогда не строили приложение для работы с decktop или iPad, то справедливо сказать, что у вас будет немного кривой обучения, независимо от того, какую структуру вы выберете. Это, как говорится, то, что вы не знаете и хотите узнать, можно получить через каждую структуру, соответствующую сообществу и документам. У обоих есть активные сообщества в том или ином, так что вы не останетесь на холоде, если где-нибудь застрянете. Что касается документов, Каппучино, по общему признанию, имеет верх. Документов для SproutCore не хватает, но база кода, по крайней мере, полностью прокомментирована. Сообщество SproutCore полностью осведомлено о документах, нуждающихся в обновлении, и в настоящее время это то, что рассматривается, поэтому продолжайте проверку.

Наконец, вы упоминали долгосрочный прогноз для двух структур. Это общеизвестно, что Motorola купила платформу Cappuccino, поэтому у вас, безусловно, есть большая компания, поддерживающая ее рост и долговечность, или, по крайней мере, сейчас так выглядит. Что касается Apple и SproutCore, я лично не могу говорить за них, но Apple не владеет этой картой. Есть много компаний и разных людей, которые все используют и вносят свой вклад в рамки. Это может привести к тому, что некоторые люди и компании сделают паузу или дискомфорт для тех, кто смотрит на SproutCore из-за более органичного характера разработки фреймворка, но я не вижу в этом проблемы. Я чувствую, что обе структуры будут работать в течение долгого времени, особенно сейчас, когда больше смотрят на разработку приложений для настольных компьютеров и iPad следующего поколения с использованием фреймворков с открытым исходным кодом. И, эй, конкуренция между фреймворками хороша - держит всех на своих пальцах:-).

Надеемся, что эта информация поможет вам принять ваше решение!

Приветствия,

Mike

Ответ 2

Я хотел бы затронуть комментарии, сделанные о объективе-j Майкл.

Вы ничего не потеряете, если вместо объектива-j вы перейдете к JavaScript. Во всей действительности это различие сложно сделать, особенно в тех случаях, когда у нас есть бесплатные мостовые классы (подробнее об этом немного).

Objective-j на самом деле просто тонкая оболочка над js. Он обеспечивает классическое наследование, которое традиционно реализуется как языковая функция, которая sproutcore реализует как функцию структуры, она также обеспечивает импорт кода, генерацию доступа, статическую привязку и поддержку обмена сообщениями nil.

Переменные экземпляра Objective-j доступны через традиционный синтаксис точек, если вы хотите... Мне нравится думать об этом так: как только вы начнете писать метод, вы в основном пишете JavaScript. То есть, петли, переменные, функции, замыкания и т.д. - это всего лишь javascript. Вы ничего не теряете, опускаясь вниз, точно так же, как язык разработан.

Мы делаем еще один шаг: "бесплатный мостик" некоторых наших классов CPDate, CPArray, CPException, CPString и, возможно, больше, чего я не могу вспомнить. Toll free bridging просто означает, что CPArray IS является родным массивом js, а собственный массив js - это CPArray, поэтому вы можете использовать методы и функции обоих мира взаимозаменяемо.

Так, например, можно было бы сделать:

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

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

Как вы можете видеть, я использую синтаксис object-j и синтаксис js вместе... Вы можете представить себе силу, если это.

Последнее, что я хочу выпустить, просто чтобы убедиться, что нет путаницы: цель-j анализируется в браузере. Его не нужно компилировать заранее (хотя мы предоставляем инструменты компиляции, когда вы готовы к развертыванию своего приложения).

Я думаю, что некоторые люди бесполезно отстраняются объектив-j, как будто это какой-то чудовищный зверь, которому потребуется время, чтобы учиться, и, хотя объектив-j добавляет много хороших функций js, чтобы на самом деле их изучить, на самом деле не будет возьмите на себя большую часть дня, если вы уже знакомы с объектно-ориентированным программированием, и, очевидно, если вы собираетесь с cocoa, вы сможете прыгать прямо.

Ответ 3

Я написал статью в блоге именно о "cappuccino vs. sproutcore". Это не техническое сравнение, а сравнение других интересных данных.

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

Ответ 4

На веб-сайте Cappuccino:

"На другом конце существующих фреймворков есть такие технологии, как SproutCore. Хотя SproutCore схожи с целями Cappuccino, он использует разный подход. Он по-прежнему полагается на HTML, CSS, JavaScript, Prototype и совершенно новый и уникальный набор API, а также специальное программное обеспечение для разработки и громоздкий этап компиляции. Мы считаем, что это неправильный подход.

С Cappuccino вам не нужно знать HTML. Вы никогда не будете писать строку CSS. Вы никогда не взаимодействуете с DOM. Мы только просим разработчиков изучить одну технологию Objective-J и один набор API. Кроме того, эти технологии являются реализациями хорошо известных и хорошо понятных существующих. Разработчики могут использовать десятилетия коллективного опыта, чтобы действительно ускорить темпы создания богатых веб-приложений ".

Итак, похоже, что у Cappuccino нет/необходимости каких-либо инструментов сборки и полностью абстрагирует браузер от разработчика. Если в Sproutcore вы получаете инструменты построения (например, сервер разработки), и разработчик должен знать, что такое DOM.

Ответ 5

Майкл Коэнс почти полностью покрыл все, потому что он был чрезвычайно подробным.

Я боролся с решением за последние 3 недели. Я прочитал все, что есть в Интернете, о обеих фреймворках, и я написал много исходных образцов с обоими и все еще не могу принять решение. Следующие проблемы заставили меня перейти от одной рамки к другой и продолжать принимать мое решение жестче.

• У Sproutcore есть лучшее хранилище данных api, чем у одного каппучино.

• Sproutcore использует привязки лучше, чем каппучино. У Cappuccino также есть поддержка kvc/kvo, но привязки еще не полностью. Например, в sproutcore вы можете реализовать инкрементную загрузку с привязками и ArrayController очень легко, где, с другой стороны, в капучино это не так просто. Конечно, cappuccino предлагает CPTableView DataStore api, который довольно чист и может достичь аналогичных результатов, а не с привязками. Его то, что cocoa выполнялось до основных данных. Привязки постоянно обрабатываются в капучино, хотя.

• Cappuccino имеет лучшее представление api в соответствии с моим личным вкусом. Хотя я привык к разработке html и DOM, я предпочитаю идею полностью абстрагировать DOM и избавляться от css.

• Одна важная для меня проблема - отсутствие хорошего TableView в sproutcore. В настоящее время SC.TableView находится в альфа и совсем не работает. Я не знаю временную шкалу для таблицы в sproutcore. Я попробовал просить по каналу sproutcore irc, но не получил удовлетворительного ответа. С другой стороны, Cappuccino имеет отличный и оптимизированный вид таблицы.

• Я нашел больше приложений реального мира, написанных на капучино, чем на sproutcore. Существует также довольно приятное полномасштабное приложение, которое предоставляется капучино в качестве исходного примера и очень полезно. Проверьте http://githubissues.heroku.com/.

Несмотря на то, что у меня нет опыта работы в objective-c, и я предпочитаю чистый синтаксис js, я, вероятно, поеду с cappuccino в свой текущий проект и надеюсь, что sproutcore выйдет с лучшим представлением таблицы в будущем.