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

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

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

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

Что касается языка, я думаю, важно, чтобы вы не упускали из виду то, что используется (JS против Obj-J). Почему? Из-за усыновления и того, откуда вы родом. SproutCore исходил из того, что JavaScript действительно является языком Интернета, поэтому вы используете его для программирования в соответствии с фреймворком. Там, где JavaScript не хватает полноты объектно-ориентированного программирования (правильное наследование объекта-объекта и т. д.), он компенсирует это фреймворком (например, 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, у них обоих есть механизм хранения данных, и у них обоих есть свой собственный соответствующий стиль рендеринга и создания виджетов/представлений пользовательского интерфейса.

Рендеринг представлений для меня является особенно важной областью. Оба фреймворка имеют некоторый уровень абстракции, чтобы избавить вас от непосредственного взаимодействия с 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 или никогда не создавали приложение, похожее на десктоп или iPad, то будет справедливо сказать, что вам придется немного поучиться, независимо от того, какой фреймворк вы выберете. При этом то, чего вы не знаете и хотите узнать, можно получить в соответствующем сообществе и документации каждого фреймворка. У обоих есть активные сообщества в той или иной форме, поэтому вы не останетесь в дураках, если где-то застрянете. Что касается документов, Капучино, надо признать, имеет преимущество. Документы для SproutCore отсутствуют, но кодовая база, по крайней мере, полностью прокомментирована. Сообщество SproutCore полностью осведомлено о том, что документы нуждаются в обновлении, и в настоящее время этим занимаются, так что продолжайте проверять.

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

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

Ваше здоровье,

Майк

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

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

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

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

Мы делаем еще один шаг вперед, «бесплатно связывая» некоторые из наших классов CPDate, CPArray, CPException, CPString и, возможно, еще какие-то, которые я не могу вспомнить. Бесплатный мост означает, что CPArray ЯВЛЯЕТСЯ нативным 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

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

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

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

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

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

С сайта Капучино:

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

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

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

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

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

1. Sproutcore имеет лучший API для хранения данных, чем у капучино.

2. Sproutcore использует привязки лучше, чем капучино в настоящее время. Cappuccino также имеет поддержку kvc/kvo, но привязки еще не полностью. Например, в sproutcore вы можете очень легко реализовать добавочную загрузку с помощью привязок и ArrayController, тогда как, с другой стороны, в капучино это не так просто. Конечно, капучино предлагает API-интерфейс CPTableView DataStore, который довольно чистый и может достигать аналогичных результатов, но без привязок. Это то, что какао делало до получения основных данных. Тем не менее, в капучино над креплениями постоянно работают.

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

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

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

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