Одностраничные приложения — новая горячность; каждый пытается найти самый простой способ их построить. Но это больше, чем просто найти пару элементов управления, чтобы соединить их вместе и посыпать на них пыль Ajax pixie. Создание масштабируемых и поддерживаемых приложений — серьезный бизнес, требующий серьезных инструментов.
Ember.js — очень серьезная основа для этого. Посмотрите интервью, которое я провел с руководителями основной группы Ember.js, Иегудой Кацем и Томом Дейлом , когда они обсуждали, что побудило их начать проект Ember, его философию дизайна и где он вписывается в уже переполненную библиотечную экосистему.
Q Расскажите нам о своем профессиональном опыте.
Иегуда: Я был специалистом по бухгалтерскому учету в колледже, с целой кучей интересных несовершеннолетних (журналистика, философия, история, телевидение / радио). Я любил учиться, но почему-то упустил тот факт, что бухгалтерский учет как профессия был довольно скучным, по крайней мере, для меня.
Я отказался от специализации в области компьютерных наук на том основании, что это слишком сложно и «не для меня», хотя в детстве я занимался программированием на QBasic и немного на Visual Basic в колледже. Я думал, что БЕЙСИК — это игрушечный язык, и он не способен выполнять настоящую работу, потому что я взял книгу на С, когда был ребенком, и нашел ее непроницаемой.
Мне очень повезло увидеть внутреннюю работу, опубликованную на моем первом месте работы веб-дизайнером, и подумал: «Я занимался полиграфическим дизайном в колледже, это то же самое, верно?»
Я также знал о Knockout, но я не был большим поклонником упаковки всей связывающей информации в атрибуты HTML.
Я очень быстро понял, что мне нужно будет изучать настоящее программирование, и мне повезло, что я только начал работать, когда jQuery и Ruby on Rails начали развиваться. Я быстро увлекся открытым исходным кодом, и, поскольку эти проекты были еще очень молодыми, я смог получить большую ценность, даже с моими весьма ограниченными навыками программирования.
Я связался с Merb, конкурентом Rails, после того, как мое первое реальное приложение быстро вышло за пределы счастливого пути Rails, и наша небольшая команда из трех человек потратила больше времени на взлом Rails, чем на написание кода приложения. Чтобы быть справедливым, мы также написали очень мало (если таковые имеются) тестов, так что, возможно, это как-то связано с этим. 😉
В конце концов, команда Merb поняла, что наши основные идеи очень похожи на идеи команды Rails, но с другой направленностью. Мы объединили усилия, чтобы придать Rails больше модульности и настраиваемости для продвинутых пользователей, при этом стараясь не нарушать счастливый путь, который так хорошо работает для начинающих. Моя работа над Rails 3 была сделана почти исключительно парным программированием с Карлом Лершем. Именно благодаря этому опыту я оценил использование парного программирования для продумывания сложных проблем и эффективного осуществления их решений.
После того, как мы выпустили Rails 3, я начал изучать веб-экосистему, чтобы увидеть, какие существуют другие проблемы. Я с ужасом увидел, что состояние создания больших веб-приложений, как для настольных, так и для мобильных устройств, не сильно изменилось с тех пор, как я начал работать с jQuery много лет назад. Несмотря на все сильные стороны jQuery как превосходной библиотеки DOM, она каким-то образом заперла поколение веб-разработчиков в одни и те же низкоуровневые абстракции. Что-то должно было быть сделано.
Сначала я потратил время на создание механизма шаблонов с поддержкой привязки данных, который стал Handlebars. В то время я знал, что у SproutCore есть привязки данных, но их использование требовало написания тонны кода JavaScript для описания очень простых структур HTML. Лучший DSL для HTML — это HTML!
Я также знал о Knockout, но я не был большим поклонником упаковки всей связывающей информации в атрибуты HTML. Это было главным образом эстетической проблемой, но иногда эстетика имеет значение.
Примерно в это же время Чарльз Джолли, создатель SproutCore, узнал, что я работаю над этим проектом. Он уже знал меня, потому что оригинальная версия SproutCore была построена на Merb, и он пригласил меня выступить в Apple во время Rails 3.
Он предложил нам объединиться и передать мои шаблонные идеи в SproutCore, у которого уже было много инфраструктуры привязки данных, которую я пытался свернуть вручную. Я уже видел эту историю с Merb и Rails 3, и я воспользовался шансом воспользоваться испытанной в бою системой привязки данных для сопряжения с моим шаблонным решением. Я присоединился к Чарльзу в его новой компании Strobe, чтобы работать над SproutCore.
В этот момент Том все еще работал в Apple над SproutCore, и мы несколько раз встречались, чтобы обсудить новые API, которые Apple добавила в SproutCore. Я быстро понял, что у Тома очень хорошие навыки разработки API, и перешел, чтобы нанять его для работы в Strobe. Когда он присоединился к нам, я начал работать с ним на SproutCore 1.6, первой версии, которая включала бы шаблонное решение.
Когда Strobe был продан в Facebook, я сформировал Tilde с партнерами по криминалу Томом, Карлом и Лией, чтобы продолжить работу над этим проектом за пределами компании, поддерживаемой венчурным капиталом. Я был там с тех пор.
Том: Ну, я, конечно, не инженер с классической подготовкой. Я взял книгу о бейсике из публичной библиотеки, когда был ребенком, но у нас дома был Mac, а инструменты для разработки в то время были недоступны. Так что через некоторое время я как бы разочаровался в программировании. Это казалось слишком сложным для меня. В итоге я получил степень в области криминологии, права и общества в Калифорнийском университете в Ирвине. Я думаю, что единственное реальное программирование, которое я делал в колледже, это создание сайта Ruby on Rails для моей гильдии World of Warcraft. (Не могу поверить, что признаю это публично.)
После окончания колледжа я работал в Genius Bar в Apple Store в Южной Калифорнии. Программное обеспечение, которое они дали нам для управления документами для ремонта, было довольно болезненным — вы знаете, стандартные корпоративные вещи, которые вы ожидаете.
Я решил, что, возможно, смогу облегчить нашу жизнь, поэтому я взял книгу о Какао и начал взламывать приложение, чтобы автоматизировать многие вещи, которые мы должны были делать вручную. Через некоторое время он начал распространяться в других магазинах региона.
У меня был приятель, который бросил розничную торговлю и поехал в Купертино, чтобы работать в корпорации Apple. Он слышал, что у меня был опыт программирования, и мне нужен был кто-то, кто бы работал над проектом, который использовал Ruby on Rails на бэкэнде и SproutCore на фронтэнде.
Иегуда, и я оба чувствовали, что нам нужно быть независимыми для достижения наших целей в открытом коде.
Я был призван для работы над бэкэндом Rails, в то время как некоторые другие парни работали над интерфейсом SproutCore. Мы закончили работу с Rails-сервером за пару недель, но во внешнем интерфейсе было еще много работы. Я не думаю, что когда-либо писал строку JavaScript в моей жизни, но я не хотел возвращаться к работе в розницу. Поэтому в один из выходных я пошел в Barnes & Noble в Кэмпбелле, купил пару книг о JavaScript и принялся за работу. Это было где-то в 2009 году.
Несколько месяцев спустя мы были близки к отправке нашей первой версии. Поскольку SproutCore еще не достиг 1.0, мы тесно сотрудничали с Чарльзом Джоли и остальной командой SproutCore, и я познакомился с ними довольно хорошо.
Помните, что в 2009 году никто на самом деле не писал подобные клиентские приложения. SproutCore во многих отношениях был далеко впереди кривой. В то время, не многие люди, которые знали Какао, также хорошо знали JavaScript, поэтому я был в нужном месте в нужное время. Команда MobileMe наняла меня, чтобы помочь создать их веб-приложения, а также внести свой вклад в SproutCore.
Работать над открытым исходным кодом в Apple было, ну, интересно. Я обнаружил, что мне действительно нравится работать над фреймворками, которые помогают другим разработчикам. К тому времени Чарльз покинул Apple и основал компанию с Иегудой, которая называлась Строб. Я познакомился с Yehuda благодаря нашей совместной работе по разработке новых API для SproutCore. У меня появилось ощущение, что я мог бы оказать большее влияние на открытый исходный код, если бы смог работать над ним вне Apple. Итак, я оставил Apple, чтобы присоединиться к Чарльзу и Иегуде в Strobe.
Строб был фантастическим опытом, и я многому научился у Иегуды и Чарльза. В конце концов мы решили, что у SproutCore было много отличных идей, но слишком много наследства. Мы начали с нуля на то, что тогда называлось SproutCore 2.0.
Как и многие стартапы, Strobe был приобретен Facebook. В то время как Facebook — интересная компания, на которую мы работаем, Йехуда и я оба чувствовали, что нам нужно быть независимыми для достижения наших целей в открытом коде. Мы вместе с двумя другими соучредителями Леа и Карлом основали нашу нынешнюю компанию Tilde в конце 2011 года.
Мы в основном делаем деньги, консультируясь, который мы используем, чтобы платить за время работы над Ember.js и другими проектами с открытым исходным кодом. Мы также работаем над некоторыми продуктами, которые, как мы думаем, понравятся разработчикам.
Q Вопрос на миллион долларов: «Зачем строить другую структуру?»
Том: Как я уже говорил, SproutCore был далеко впереди кривой, когда дело дошло до фреймворков JavaScript. Все остальное в то время было о взятии традиционной серверно-ориентированной веб-архитектуры и ее совершенствовании. JavaScript был шипением, а не стейком, если хотите.
SproutCore был далеко впереди кривой, когда дело дошло до фреймворков JavaScript.
SproutCore перевернул эту модель с ног на голову. Сервер стал просто механизмом доставки для JSON API. Интересная работа с пользовательским интерфейсом началась полностью на клиенте, в JavaScript.
Таким образом, вопрос не в том, «Зачем строить другую структуру?», Поскольку мы были одними из первых. 😉 Лучший вопрос: почему сейчас так много других фреймворков? И я думаю, что ответ таков: многие вещи выглядят намного проще, чем на самом деле.
Возьмите привязки, например. Любой компетентный инженер может построить простую систему привязки за один день. Но оказывается, что в больших системах возможно множество краевых случаев, условий гонки и бесконечных циклов. Получение чего-то прочного заняло много времени.
Это становится еще сложнее, когда вы берете все эти функции и пытаетесь заставить их работать вместе. Никакой другой фреймворк не пытается решить проблему сверху донизу, как это делает Ember.js, сохраняя его модульность, так что вы можете менять различные части, чтобы они работали так, как вам нравится. И разработчики, использующие Ember, действительно ценят то, как много мы думали о том, как каждая из этих функций работает вместе; это чувствует себя разработанным, не пощечиной.
Иегуда: Основной причиной для начала работы над новым фреймворком было сильное желание увидеть HTML и шаблоны в центре внимания фреймворка. В то время, в стремлении быть «агностиком», многие из решений говорили: «Вы можете использовать шаблонизатор… или нет шаблонизатора! Просто выведите DOM на экран!»
Я очень сильно чувствовал, что фреймворк следующего поколения будет построен на основе шаблонов с привязкой к данным. С тех пор Ember.js сильно вырос, и мы уделяем столько же внимания структуре приложения и маршрутизации, сколько и привязке данных, но все это было бы невозможно без HTML, который мог бы обновляться по мере навигации пользователя.
Q Я полагаю, что Ember.js вышел из вашей работы над SproutCore. Что подтолкнуло к переименованию и новым усилиям, теперь это Ember.js?
Том: Хотя SproutCore опередил свое время, он также допустил много ошибок. Возможно, самой большой ошибкой была попытка перенести пользовательский интерфейс Cocoa в сеть. Доставка с виджетами — это здорово, если это все, что вам нужно; но особенно в Интернете, настройка вашего интерфейса имеет первостепенное значение. Делать это в SproutCore не сложно.
Популярность Backbone стала для нас тревожным звонком. Это доказало, что разработчики действительно хотели создавать эти невероятно отзывчивые приложения на стороне клиента. Но у них также был многолетний опыт создания пользовательских интерфейсов с HTML и CSS, и мы не могли попросить их выбросить это, чтобы изучить SproutCore.
Популярность Backbone стала для нас тревожным звонком.
Создавая такие приложения дольше, чем кто-либо, мы сразу поняли, что у Backbone не было подходящих абстракций, помогающих разработчикам создавать большие приложения. Но с этим было легко начать, и разработчики могли использовать свои существующие ноу-хау HTML и CSS.
В то время как многие люди считают SproutCore просто «нативными элементами управления для сети», реальность такова, что он также охватывает архитектурные шаблоны Cocoa, которые сделали приложения для Mac и iOS настолько успешными.
Мы знали, что можем предоставить эти инструменты веб-разработчикам без лишнего слоя представления SproutCore, одновременно упрощая работу с API. Кроме того, мы хотели, чтобы новые пользователи могли максимально опираться на свои существующие навыки.
Итак, мы начали заново, с нуля, на том, что в то время мы называли SproutCore 2.0. К сожалению, название SproutCore несет много негативных коннотаций, и новый проект страдал от этого, несмотря на то, что не разделил ни одной строки кода. Кроме того, многие члены сообщества SproutCore сочли наш подход на основе шаблонов спорным. Мы решили, что отделение от сообщества SproutCore, а также переименование в Ember.js — это хороший способ отправить сообщение о том, что проект является новым началом.
Цель Ember состояла в том, чтобы дать разработчикам инструменты, которыми они привыкли пользоваться.
Yehuda: Моя самая большая проблема с SproutCore, когда я работал над ней, заключалась в количестве времени, энергии и кода, которые были потрачены на абстрагирование DOM. Честно говоря, число веб-разработчиков, которые понимают HTML и CSS, значительно превышает число разработчиков, желающих и способных освоить еще одну абстракцию сверху. И когда пришло время стилизовать или оформить приложение SproutCore (потому что ему нужна тема по умолчанию), вы обнаружите, что углубляетесь в тайный мир RenderDelegates и RenderContexts.
Это было все для хорошего дела, но в конце концов, веб-платформа представляет чрезвычайно мощную структуру для представления и размещения контента через HTML и CSS. Это идеально? Нет, определенно нет, хотя все лучше и лучше. Но это универсально и вездесуще. Цель Ember с самого начала состояла в том, чтобы дать разработчикам инструменты, которыми они привыкли пользоваться, вместо того, чтобы просить их изучить целый новый набор инструментов, свободно полученных из Какао.
Q Ember все еще ребенок с точки зрения рамок. Какие были проблемы с запуском нового проекта OSS и с ростом его популярности?
Yehuda: Проекты с открытым исходным кодом выглядят легко снаружи, но они, вероятно, являются конечной проблемой курицы и яйца. Вам нужен успешный проект для привлечения участников и пользователей, но те же пользователи — это те, кто в первую очередь сделает ваш проект успешным.
награда за работу с нестабильностью намного стабильнее 1.0
Единственное реальное решение — лично запустить проект, будучи курицей и яйцом одновременно. Вы должны лично работать с участниками и пользователями одновременно с созданием проекта до разумной степени удобства использования (и, в конечном итоге, стабильности).
Я бы сказал, что при всей этой боли важно, чтобы в новом проекте было время нестабильности, поскольку вы все еще точно знаете, каковы цели проекта. По мере того как вы приобретаете новых пользователей, многие из них предоставят ценную информацию о проблемах, о которых вы даже не думали, когда начинали. Вы должны иметь возможность изменять API, чтобы адаптироваться к этим знаниям.
Тем не менее, вы также должны в какой-то момент поставить кол в землю и выпустить гораздо более стабильную версию 1.0. Как мы с Томом часто говорим, награда за работу с нестабильностью — гораздо более стабильная 1.0, потому что многие изломы уже проработаны. Я бы порекомендовал строго придерживаться Semantic Versioning, как только вы перейдете на 1.0.
Наконец, вы должны воспитывать участников, которые занимаются чем-то другим, кроме работы над проблемами жесткого кода. Некоторые из наших лучших участников пишут документацию, поддерживают инфраструктуру и помогают управлять логистикой как для Ember, так и для членов сообщества, желающих проводить встречи. Для Ember эти участники столь же ценны, как и люди, которые выполняют глубокую работу в Ember, и поощрение их будет поддерживать сообщество сильным и здоровым.
Том: Интернет интересное место. Знаете, если вы Apple, вы можете сказать: «Вот какао. Если вы хотите зарабатывать деньги в App Store, пишите свои приложения, используя это». В конце радуги горшок с золотом. Люди готовы сесть и выучить все, что вы им скажете.
Любой может решить написать новый фреймворк или библиотеку и опубликовать его немедленно.
Сеть отличается. На открытой платформе любой может решить написать новую платформу или библиотеку и опубликовать ее немедленно. С сигналом смешивается невероятное количество шума. Как авторы фреймворка, мы должны показать ценность в течение пяти минут, иначе человек, который вас проверяет, выручит вас и оповестит конкурента. Таким образом, задача для нас заключается в том, что мы не только должны донести концепцию какао до Интернета, но и сделать их проще в использовании! И в начале нас было всего два человека.
К счастью, умных людей привлекают к решению сложных задач. Я думаю, что некоторые из самых талантливых веб-разработчиков в мире уже давно осознали, что мы собираемся решить сложную проблему, и мы собираемся сделать это правильно. Наше сообщество росло взрывоопасно, и большая часть работы, проводимой в рамках, теперь не от меня или Иегуды. Мне невероятно приятно видеть ваше сообщение — вебу нужны более совершенные инструменты, и мы можем создавать их вместе — резонировать с другими разработчиками.
Q Что касается MVC, я читал, что Ember.js использует немного другой подход к парадигме, чем другие фреймворки. Можете ли вы объяснить различия и выбор дизайна?
Том: По иронии судьбы, Ember.js, вероятно, ближе всего к оригинальному MVC, который использовался в Smalltalk в 70-х годах. С тех пор серверные MVC-фреймворки, такие как Ruby on Rails, стали очень популярными, и, по мнению большинства разработчиков, этот термин был заменен.
Возможно, самым большим отличием от других JavaScript-фреймворков является то, что мы ставим маршрутизатор спереди и по центру.
MVC Ember — это как Какао или Smalltalk. Модели представляют доменную логику и данные. Представления (которые обычно являются шаблонами) связаны с контроллером, который обычно представляет модель. Изменения в базовой модели распространяются вплоть до представления автоматически. В отличие от чего-то вроде Rails или Django, где объекты воссоздаются после каждого запроса, эти объекты долговечны; обычно до тех пор, пока пользователь открывает приложение в своем браузере.
Возможно, самым большим отличием от других JavaScript-фреймворков является то, что мы ставим маршрутизатор впереди и в центр. Многие фреймворки фокусируются на новых функциях, появившихся в веб-платформе, за счет ключевой веб-функции: URL! URL — это то, что есть в Интернете по сравнению с нативным, и что делает веб-приложения такими мощными. Скопировав URL из браузера и отправив его своим друзьям, вы должны показать им именно то, что видите. Если веб-фреймворк не делает это простым, они взорвали его.
В Ember проще написать приложение, которое работает таким образом, чем нет. Мы разработали весь API, чтобы сконцентрироваться на идее URL-адресов, так что это то, что вы получаете с самого начала, а не то, над чем вы работаете в конце. Вы можете почувствовать разницу.
Иегуда: На самом деле я не думаю, что есть какая-то парадигма MVC, которую используют другие фреймворки. Главное, что разделяет каждый, — это желание отделить HTML, который попадает в браузер, от моделей данных, которые им питают.
Подход Эмбер вдохновлен Какао
Магистраль, например, останавливается там. Вы получаете Модели и Виды, и если вы хотите другие слои, вы можете свернуть свои собственные (и многие делают).
Другие фреймворки используют слой «контроллер» как нечто очень близкое к представлениям. Эти структуры часто используют терминологию, например «Модель представления», для описания этого уровня. Я считаю, что нокаут использует этот подход.
Подход Ember вдохновлен Cocoa, который использует контроллеры для украшения объектов модели для представления в слое представления. Наш маршрутизатор выполняет ту же роль, что и «координирующие контроллеры» Cocoa, что делает возможной координацию между контроллерами. Поскольку Ember является веб-платформой, маршрутизатор делает URL-адреса приоритетными и центральными, гарантируя, что при построении структуры вашего приложения вы получите бесплатные и доступные для закладки URL-адреса в качестве побочного эффекта.
В процессе обучения я чувствую большое влияние Rails на дизайн Ember. Я выключен на этом?
Мы поняли, что Ruby on Rails давно выяснил, как ориентировать фреймворк вокруг URL.
Том: Как я уже сказал, URL является ключевой особенностью сети. Мы знали, что у Cocoa есть концепции, необходимые для создания долгосрочных приложений с отслеживанием состояния. Но мы не могли перенести API буквально в сеть; SproutCore и Cappuccino попробовали это и потерпели неудачу.
Размышляя над проблемой, мы поняли, что Ruby on Rails уже давно выяснил, как ориентировать фреймворк вокруг URL. В большинстве приложений Rails модели — это просто ресурсы, которые вы выставляете, используя обычные маршруты.
Итак, вдохновение Rails, которое вы чувствуете в Ember.js, заключается в том, что мы соединяем архитектуру нативных приложений с URL-ориентированностью Rails. И, как и Rails, мы также ценим соглашение по конфигурации!
Yehuda: Интересно, что когда мы начали работать над Ember, мы потратили много времени, стараясь не задавать точные пути, как Rails делает определенные вещи. Наша позиция заключалась в том, что Rails-стиль MVC отличался от Ember-стиля MVC, поэтому копирование любых поверхностных сходств, скорее всего, принесет больше вреда, чем пользы.
Ощущение сходства Rails в основном происходит от нашей строгой приверженности соглашениям о конфигурации и, в частности, соглашениям по именованию. Наш MVC может не очень походить на Rails, но тот факт, что вам не нужно соединять объекты вместе, вместо этого полагаясь на присвоение имен для создания проводки, очень вдохновлен Rails.
По иронии судьбы, после всего нашего желания не копировать Rails оказалось, что маршрутизатор Rails очень близко подошел к тому, что нам в итоге понадобилось в Ember, а API (в основном по совпадению) в итоге сходился на чем-то близком к используемому подходу. в рельсах.
В связи с этим, о каких ключевых вещах должны знать новые разработчики Ember.js?
Том: Шаблоны связаны с контроллерами, которые сами связаны с моделью (или набором моделей). Эти соединения устанавливаются в маршрутизаторе. Создание больших приложений Ember.js просто повторяет этот шаблон снова и снова. Шаблон, контроллер, модель.
- Ember.js делает много для вас, и в некоторых случаях это похоже на черную магию. Я знаю, что многим разработчикам это не нравится. Какую «конструктивную обратную связь» (то есть: не позволяйте Тому ответить) вы бы предложили им, что это за чёрный бокс кода?
- Маршрутизация, как я обнаружил, является одной из самых важных частей Ember. С точки зрения производительности может показаться, что подключение всех этих маршрутов и контроллеров может повлиять на производительность, но небольшое приложение, которое я создал, выглядит неплохо. Какова самая большая шкала, на которой была протестирована Эмбер?
Один из основных принципов Ember, который позволяет нам добиться высокой производительности, заключается в том, что мы делаем все настолько лениво, насколько можем. Мы никогда не вычисляем заранее, что мы можем сделать точно в срок. Лень может расстраивать людей, но это благо для веб-приложений! То же самое относится и к загрузке моделей, созданию представлений, настройке привязок между представлениями и контроллерами и т. Д. Мы тратим много времени на размышления о производительности.
Я не уверен, какое там самое большое приложение. Многие компании делают большие ставки на Ember.js и создают свои веб-приложения следующего поколения с помощью фреймворка. Это означает, что мы не видим исходный код большинства приложений Ember!
Иегуда: Ember использовался в некоторых действительно больших приложениях, таких как Zendesk, Square, Travis CI и Discourse. Все эти приложения используют большие объемы данных, которые передаются через систему привязки Ember.
Компания Square, в частности, проделала потрясающую работу, объединив Ember.js и Crossfilter, чтобы позволить исследовать сотни тысяч точек данных, не возвращаясь на сервер для отображения результатов.
Q За последний год API прошел многочисленные пересмотры. Это предъявляет высокие требования к обслуживанию проектов, которые хотят использовать эту среду. Где вы, ребята, блокируете API и как вы будете обращаться с устаревшими функциями в будущем?
Том: Наши первые последователи были невероятно терпеливы с нами, пока мы совершенствовали Эмбер. Фактически, весь отток API происходит от того, что вы проводите много-много времени с разработчиками, использующими ранние версии фреймворка, и получаете их отзывы. Мы включили этот отзыв в быстрый клип.
Недостатком является то, что мы держали людей в курсе последних событий. Хорошей новостью является то, что у нас есть намного лучший продукт, чем другие фреймворки, которые давно заблокировали свои API. Мы невероятно довольны тем, где мы оказались, и на прошлой неделе мы объявили о выпуске Ember 1.0 RC на EmberCamp. Мы будем следовать стандарту SemVer , что означает, что приложения, которые вы создаете сегодня, будут совместимы с платформой, пока мы не выпустим версию 2.0. Что, ради нашего здравомыслия, надеюсь, не будет долгое время!
Иегуда: Шаблон, который мне нравится использовать в проектах с открытым исходным кодом, заключается в том, чтобы позволить ранним пользователям управлять API до того, как проект достигнет 1.0, а затем жестко заблокировать его, как только этот этап достигнут. Это дает ранним пользователям возможность предоставлять отзывы о сценариях использования, о которых первоначальная команда, возможно, не знала, и возможность определять направление платформы. Это также дает понять, что в этом виде исследований есть тикающие часы, и делает веху 1,0 значимой.
Q Команда Discourse только что запустила свой сайт и сделала использование Ember.js ключевой темой для обсуждения. Каково было ваше участие в этих усилиях, и как вы думаете, какие плюсы и минусы были извлечены из этого опыта?
Том: Ребята из Дискурса проделали невероятную работу. Я до сих пор ошеломлен тем, что отполированный продукт два инженера смогли построить с использованием фреймворка, который интенсивно развивался.
Джефф Этвуд пришел и показал нам раннюю версию Дискурса в конце прошлого года. Их план заключается в создании программного обеспечения для форумов в течение следующих 10 лет в Интернете. Это хорошо согласуется с нашими целями — мы хотим создать основу для следующих 10 лет работы в Интернете.
Мы помогали отвечать на вопросы и давать предложения, но два разработчика Discourse — Сэм Саффрон и Робин Уорд — действительно превосходные разработчики. Во всяком случае, они действительно помогли нам сравниться с Ember и дали возможность сфокусироваться на наших основных мастерах производительности Эрике Брине и Крисе Селдене. Преданность производительности этих ребят действительно окупилась для конечных пользователей фреймворка.
Иегуда: Одна из моих любимых вещей в Discourse — это захватывающее, очень отзывчивое приложение, которое по-прежнему в основном отображает контент. Это такое приложение, которое, по словам многих скептиков, должно быть построено с использованием необработанного HTML, чтобы обеспечить удобство работы с URL и показ в Google.
Дискурс показал, что вы можете создать контентный сайт с богатым взаимодействием, не отказываясь от URL-дружественности статических сайтов. И они появляются в Google просто отлично!
Мне нравится верить, что маршрутизатор Ember, который настаивает на том, чтобы разработчики Ember создавали свои потоки приложений с точки зрения URL, помог сделать это возможным. В ближайшие месяцы мы рассмотрим шаблоны, которые они использовали для таких вещей, как бесконечная прокрутка, чтобы увидеть, сможем ли мы свернуть некоторые из этих подходов обратно в Ember.
Q Что касается проектной команды, вы намеренно решили оставить ее маленькой. Расскажите мне об этом решении и о том, как, по вашему мнению, сообщество может внести наилучший вклад.
Том: У нас с Иегудой очень специфическое видение рамок. Для нас важно, чтобы участники разделяли это видение. Я думаю, что одна вещь, которую я узнал от Иегуды, — что он узнал из своего опыта работы над большими проектами с открытым исходным кодом, такими как jQuery и Rails, и над органами стандартизации, — это то, что большинству разработчиков нравится решать для конкретных сценариев.
У нас с Иегудой очень специфическое видение рамок
Очень легко использовать функцию, которая решает конкретную проблему, с которой кто-то сталкивается. Требуется много усилий, чтобы продумать основную причину этой проблемы, попытаться продумать все возможные варианты использования и придумать что-то, что решает эту конкретную проблему, а также другие, с минимальным количеством новых концепций.
Люди становятся нетерпеливыми и даже злыми, пока вы все еще думаете о лучшем способе решения проблемы. Но конечный результат того стоит.
Трудно найти других разработчиков, которые решают сказать «нет», а не просто торопиться, потому что это решает конкретную проблему. Но, опять же, оно того стоит.
Иегуда: Мы только что объявили о нашей основной команде, которая состоит из восьми человек. Пользователи-ветераны Ember узнают все свои имена, и есть ряд людей, которые, вероятно, присоединятся к основной команде в этом году, если они сохранят свой текущий уровень вовлеченности. В Rails, который существует намного дольше, работают 14 основных членов команды.
Q Ember.js имеет много компаний в области инфраструктуры MVC, включая Angular, Backbone, Knockout.js, JavaScriptMVC и многие другие. Что отличает Ember от всех этих опций? Зачем кому-то идти с Эмбер за что-то еще?
Том: Ember — единственная платформа, которая хочет решить всю проблему, сверху вниз, и которая также заботится о создании API и документации, которая доступна и удобна для пользователя.
Разработчики любят спорить, поэтому наши строгие соглашения позволяют командам избегать споров по поводу того, что мы называем тривиальным выбором. Например, Ember ожидает, что шаблоны будут названы так же, как контроллер, к которому он подключен, который будет назван аналогично модели и маршруту. Разработчику Ember легко попасть в середину нового проекта и легко понять, что происходит. Для сравнения, каждое приложение Backbone, над которым я работал, было похоже на совершенно другую базу кода, поскольку каждая команда использует его немного по-своему.
Иегуда: За последний год мы действительно приняли к сведению то, что если люди создают веб-приложения (в отличие от нативных приложений), им необходимо сделать URL-адреса централизованным способом их структурирования и организации. их применение.
Другие фреймворки обеспечивают поддержку URL-адресов, но только Ember начинает новых разработчиков с этого важного аспекта работы в Интернете с первого дня.
Q Что вы видите в качестве ключевых решающих факторов для выбора чего-то вроде Ember.js вместо использования исключительно библиотеки, такой как jQuery или MooTools?
Но ни один не даст вам никаких архитектурных инструментов.
Том: jQuery, как и MooTools, является фантастической библиотекой для манипулирования DOM. Но вы также не дадите вам никаких архитектурных инструментов для выполнения таких задач, как выборка моделей, поддержание актуальности URL-адреса с тем, что на экране, шаблоны рендеринга или управление состоянием приложения. Вы можете попытаться сделать это вручную, но мой опыт и опыт каждого разработчика, с которым я говорил об этом, заключается в том, что вы в конечном итоге получаете грязный код спагетти, который становится невозможно расшифровать.
Иегуда: Ember — это инфраструктура приложений, в то время как jQuery и MooTools — это библиотеки для абстрагирования общих способов взаимодействия с API браузера. Ember на самом деле использует JQuery для управления DOM, поэтому вы можете видеть, что Ember использует DOM, чтобы помочь разработчикам структурировать и организовать свои приложения.
По моему мнению, если кто-то действительно обеспокоен тем, стоит ли ему использовать низкоуровневую библиотеку, такую как jQuery или инфраструктуру приложения, он, вероятно, должен идти с jQuery, пока не столкнется с проблемами, которые выиграют от инфраструктуры.
Q Я заметил, что Ember использует jQuery. Можете ли вы рассказать нам об этом выборе?
Том: jQuery просто потрясающий. Это фактически стало стандартной библиотекой сети. Мне это нравится, потому что мне не нужно беспокоиться о странных кросс-браузерных ошибках. Многие люди думают, что jQuery менее полезен сейчас, когда старые IE исчезают; но эти люди просто неправы. Ошибки WebKit и Firefox такие же плохие, а иногда и худшие, чем многие ошибки IE. Чрезвычайно приятный API — просто глазурь на торте.
Q Что касается мобильных устройств, что разработчики должны учитывать при использовании Ember?
Том: Как и любой фреймворк, Ember не может помешать вашему приложению выполнять алгоритмически неэффективные вещи. Иногда вы можете избежать неэффективности настольных компьютеров, которые становятся препятствиями для бизнеса на мобильных устройствах с их ограниченными центральными процессорами.
Лучший совет, который я могу дать: если вы развертываете на мобильных устройствах, не стесняйтесь использовать профилировщик в своем браузере. Гораздо лучше использовать профилировщик для определения горячих точек в приложении, чем пытаться преждевременно оптимизировать. Обычно это приводит к грязному коду, который в любом случае работает медленно.
При этом многие компании строят свой бизнес на приложениях Ember, работающих на мобильных устройствах.
Иегуда: Как сказал Том, если вы попытаетесь перейти на низкоуровневый уровень, чтобы получить хорошую производительность, у вас может получиться много быстрых областей кода, которые объединяются для создания очень медленного кода. У Ember больше накладных расходов на бухгалтерию, но, зная полное приложение, он имеет тенденцию выполнять лучшую работу по оптимизации, например, объединяя несколько операций DOM, чем вы бы делали вручную.
Такие библиотеки, как Ember ListView (член основной группы Erik Bryn) также предоставляют способы многократного использования DOM при работе с большими объемами данных без отказа от приятных API-интерфейсов системы шаблонов Ember.
Работая в стесненных условиях, вам определенно придется больше ориентироваться на производительность. Одна из приятных особенностей Ember заключается в том, что, поскольку вы пишете в API-интерфейс достаточно высокого уровня, мы можем реализовывать улучшения, влияющие на все существующие приложения Ember, без необходимости просить вас что-либо делать. На протяжении всего цикла разработки Discourse значительно улучшала производительность, просто обновляя каждую новую версию Ember.
Q Так как Ember четко сфокусирован на парадигме, похожей на десктоп, какие рекомендации или ресурсы вы можете предложить разработчикам, которые хотят перейти на одностраничные приложения?
Том: Руководства Ember.js отлично подходят для понимания структуры. Мы постоянно улучшаем их, обычно выкладываем обновления, по крайней мере, один раз в неделю, и теперь, когда RC вышел, мы усердно работаем над материалом, специально предназначенным для того, чтобы люди работали как можно быстрее.
Большое спасибо Иегуде и Тому за то, что они нашли время поговорить с Nettuts +! Если у вас есть какие-либо вопросы, оставьте комментарий ниже, и они просто могут ответить вам!