От переводчика: перевожу не ради холивара, сам RoR не знаю, но чувствую исходящее от специалистов по RoR положительное к нему отношение, мельком видел красоту и самого языка и фреймворка, но здесь не об этом. Цель перевода еще раз обратить внимание на Meteor, который развивается семимильными шагами — в начале 2014 ждем релиз 1.0. В англоязычном Интернете все кипит, а у нас тишина — лишь несколько статей.
Почему Meteor?
Помню как начинал заниматься Rails в 2004 году — это было «волшебное время» — и, конечно, я помню, что меня по крайней мере раз в неделю спрашивали, почему же стоит использовать rails. Я всегда отвечал одинаково: разработчикам нравится этот фреймворк, потому что он позволяет делать работу быстро и с удовольствием. К этому моменту я чуть больше месяца вплотную проработал с Meteor и готов ответить на вопрос: «Почему Meteor?» — который мне тоже часто стали задавать.
Сложности привязки
Когда клиент просит создать приложение, обычно это сложное, интерактивное приложение с множеством JavaScript для богатого интерфейса. Проблема в том, что для приложений созданных на чем-то типа rails, JavaScript является чем-то вроде третьего рукава, пришитого сбоку, ввиду разного времени развития технологий. Конечно, можно потратить несколько дней соединяя все вместе так, что и разработчиков все будет устраивать, но ведь rails создавался и получил такое широкое именно благодаря своим конвенциям по конфигурированию. Я работал над 4-мя различными backbone-приложениями, большими и маленькими, и все они настраивались по разному. Если каждый будет по своему делать настройки node.js, angular и т.д., как же мы тогда сможет быстро включаться в проекты?
Meteor решает эту проблему, объединяя вместе, «одну из самых современных» подборку пакетов, причем вполне понятным и удобным образом. jQuery, Handlebars, Node.js, websockets, mongoDB, и DDP — все это есть в хорошо организованном инструменте, позволяющем нам создавать приложения быстро и эффективно. Мы запустили наиболее важный функционал (MVP) приложения за 3-4 недели, тогда как на rails это бы заняло 4-6 недель. Недавно мы потратили 2 дня сопрягая angular с rails для совершенно нового проекта — нам пришлось12-16 часов заниматься конфигурированием, вместо того, чтобы делать то, что хотел клиент. Когда платишь опытным разработчикам 100$-200$ в час, эти 12 часов многого стоят, если у тебя в наличии всего 20$-25$ тысяч на создание продукта. В худшем случае, можно потратить 6% бюджета на сопряжение двух фреймворков. И это не включая затраты на настройку таких вещей, например, как websockets, позволяющих производить двусторонний обмен данными в реальном времени. И все это бесплатно в Meteor.
Проблема переключения внимания
Надеюсь все признают, что многозадачность для человека довольно тяжела, потери возникают при переключении с одной задачи на другую? Да, все мы, хорошие разработчики, знаем несколько языков и можем переключаться между ними — но потери неизбежны, когда мы вынуждены переключаться с Angular на Rails и обратно. Если я пишу приложение backbone или angular, а там необходимо получать данные из rails, мне приходится тратить время на написание контроллера в rails, который бы обеспечивал доступ к данным, через ActiveRecord. Чистой воды неэффективность — заставлять мой туда-сюда переключаться, чтобы обеспечить корректную валидацию и там и там.
Что если бы вам можно было бы работать с одним языком и одним фреймворком, с самого начала созданном для эффективности и простоты разработки? Я не хочу выглядеть, как менеджер по продажам, но это просто прозрение, увидеть фреймворк, который все это действительно может. Я понимаю, что Meteor еще должен подтянуться в таких областях, как тестирование и масштабирование, но я уже видел, как эти вопросы решились в ruby on rails, и поэтому уверен — немного времени и усилий, и все будет сделано как надо.
Рекрутинг
Давайте взглянем правде в глаза: JavaScript — язык №1 на GitHub по вполне понятной причине — он везде. Java нам обещала это в 90-х, но оказалась слишком большой, раздутой и неудобной (признаюсь, я использовал Java только в колледже), хотя интерес единому языку тогда явно был. Под «везде» я прежде всего подразумеваю здесь, конечно же, браузер. Быть самым популярным языком имеет свои преимущества, основное — очень многие его знают.
Подбор сотрудников становится намного легче, когда у вас большой выбор. Я гарантирую вам, что вы можете запустить Meteor проект любой структуры и сложности при помощи практически любого JS программиста — он сможет очень быстро все изучить и запустить приложение. Это очень важно в мире разработки программного обеспечения — чрезмерно сложная структура усложняет замену участников команды разработчиков и замедляет скорость разработки. Никому не нравится быть привязанным к какому-то разработчику или команде, понятно же, что чем больше возможностей выбора, тем лучше.
Дизайнеры его любят
Помните как в рекламе хлопьев: «Он им нравится, он им ДЕЙСТВИТЕЛЬНО нравиться!». За эти годы я работал с многими дизайнерами, помогая им устанавливать Ruby, объясняя файловую структуру, методику отображения статических файлов, обучая их SASS/Less и т.д. Мне всегда нравилось это делать, потому что еще не встречался такой дизайнер, которому бы Less или SASS нравился меньше чистого CSS. Еще не разу такого не было, чтобы я не потратил меньше чем несколько дней на помощь дизайнерам, когда они начинают изучать rails. Структура довольно сложна и требуется время, чтобы все это осознать.
Кроме шуток, но наш дизайнер (который был знаком с rails до этого) до того влюбился в Metero, что даже по собственной инициативе создал шаблонный «Meteor boilerplate», который мы теперь используем, как стартовую точку для всех наших Meteor приложений. Кроме того, устав от rails, он перенес целиком весь дизайн нашего сайта в Meteor, сделав 40% работы полностью до того, как потревожить кого-то из разработчиков вопросами. Подумайте над этим.
Дизайнеру вообще не нужен разработчик, чтобы тот создал какой-то код или задал файловую структуру — для меня это было просто каким-то озарением.
Решение, созданное с полнейшим вниманием
Meteor впитал в себя частички многих фреймворков, и я думаю это и привело к тому, что было создано превосходящее по всем параметрам решение — они хорошо изучили, что работает, а что нет. Обработка событий в Meteor сильно напоминает мне backbone — это именно то, за что в большей степени я люблю backbone! Менеджер пакетов очень сильно напоминает мне NPM и Ruby Gems — мне нравится то, что кто-то может один раз написать код, и повторно его использовать, и в Meteor это сделать очень просто. Все это они смешали с такими продвинутыми технологиями как websockets и mongodb, что существенно ускоряет разработку.
Так почему же все-таки Meteor?
Да потому, что если кто-то из ранних последователей технологии вовсю кричит о чем-то, это скоро выстрелит. Это не означает, что Angular, Ember или backbone вдруг вымрут, нет они займут свое место, в основном поддерживая уже существующие приложения с богатым интерфейсом. Каждый разработчик и предприниматель должны обязательно очень серьезно посмотреть в сторону Meteor. Время выхода на рынок сократиться, а удовольствие от разработки увеличиться десятикратно.
Автор: zag2art
