Мы сделали Scribd на Rails, и он стал третьим по посещаемость сайтом на Rails, и фреймворк работал, как надо. Но сегодня я вижу огромное число новых проектов, которые используют Rails, и, кажется, совершают ошибку. Я начал использовать Rails в 2006, сразу после скрикаста Давида Ханссона, в котором он с помпой представил миру фреймворк. Мы написали первую версию Scribd на Rails 0.7. Тогда, когда фреймворк не имел даже миграций.
В то время вокруг Rails было много шума, но выбирать его было довольно рискованным шагом. Большинство новых сайтов продолжали писать на PHP и Java – этому способствовало наличие огромного количества разработчиков для этих платформ. Мы сделали ставку на то, что Rails продолжит набирать популярность, обзаведется свитой хороших библиотек и армией лояльных разработчиков.
Нам повезло! Пока мы поднимали Scribd, вместе с нами рос и Rails. Он становился базовой технологией для разработки новых проектов Силиконовой долины. Разработчики Java Spring, PHP and ASP.NET поняли, к чему все идет, и начали искать работу, где они могут переключиться на новый язык. Когда взлетел наш проект, мы оказались в выигрыше — к нам потянулись талантливые ребята, поскольку мы могли предложить им поработать на Rails.
Ветер перемен
Я переживаю из-за того, что расцвет Rails уже позади. Запускать сейчас новый проект на Rails, это почти то же самое, что запускать проект на Java Spring в 2007. График ниже показывает, какие веб-фреймворки гуглили с 2007 по 2016 годы.
Источник: Google Trends
Невозможно не увидеть, что интерес разработчиков переместился с Rails в сторону более новых фреймворков.
Самая большая проблема Rails – это Ruby
Все знают, что Ruby медленный. Но на самом деле, Ruby – это самый медленный язык среди популярных языков программирования.
Почему Ruby такой медленный?
Некоторые укажут на характеристики языка, которые сложились исторически. И это верно. Но я думаю, что есть более глубокая причина. У Ruby нет корпоративного спонсора.
В далеком 2007 году Python, PHP и JavaScript были достаточно медленными языками. Компания Facebook очень сильно проинвестировала в PHP и создала HipHop, чтобы сделать его быстрее. А Google случайно подтолкнула бурное развитие серверной части JavaScript, сделав быстрой JIT-компиляцию в JavaScript.
Интерпретатор Ruby сделан усилиями волонтеров. Между 2007-2012 годами не раз предпринимались попытки починить интерпретатор и сделать его быстрым (Rubinius, JRuby, YARV и так далее). Но недостаток надежного спонсора привел к тому, что волонтеры заскучали и сдулись. JRuby по-прежнему активен и последние версии подают надежды, но впереди ещё много работы.
Twitter, первая большая IT-компания на Rails, мог подхватить Rails и починить интерпретатор. Точно так, как в свое время поступил Facebook с PHP. Это могло все изменить и гарантировать доминирование Rails на годы вперед. Но инженеры Twitter решили, что чем ускорять Ruby, проще переписать Twitter на более быстром языке.
Rails стоял на месте, пока другие его догоняли
Rails принадлежит много открытий, которые сделали написание обычных веб-приложений быстрее. Но через некоторое время другие фреймворки просто подхватили эти инновации. Сейчас Django для Python – клон Rails. То же самое можно сказать о Sails.js для JavaScript. И эти фреймворки не страдают от того, что пишутся на “не мейнстримовых” языках программирования.
В это же время застопорилась разработка самого Rails. Его третья версия была выпущена в августе 2010 года. Github не переходил на новую версию фреймворка в течении четырех лет – преимущества были не достаточно значимыми. Вспоминая боль, которую мы испытали во время обновления Scribd до Rails 3, я не уверен, что мы когда-либо рискнем с Rails 4.
Это интересно – сравнить рост инноваций в JavaScript и фронтэнд-разработке со стагнацией на Rails. В последние 7 лет наш бекэнд менялся маленькими шажками, а фронтенд мигрировал с Prototype на jQuery, потом на Coffeescript, потом на Angular, потом на React. Каждый раз – с ростом продуктивности.
Новобранцы
В последние два года выросло много центров обучения программированию для начинающих. Они обучают много чему, но когда дело касается разработки серверной части, преимущество за Rails. По-видимому, это ответ рынка на по-прежнему высокий спрос на разработчиков Rails у стартапов.
С одной стороны выигрывала экосистема Rails, потому что увеличивалось количество талантливых людей внутри нее. К сожалению, был и обратный эффект. Серьезные разработчики, особенно со степенью по информатике (CS), стали смотреть свысока на эти курсы как на «программирование по верхам». Я заметил, что всё больше и больше опытных разработчиков отказывалось работать на Rails – из-за подпорченной репутации фреймворка. Видел, как это уже случалось с Flash/ActionScript: серьезные разработчики часто (ошибочно) относились к нему как к облегченной версии «для дизайнеров».
Новые игроки
Среди фреймворков есть несколько сильных претендентов на статус наследника Rails. Лидирует Node.js. Не верите? Вот статистика использования серверных языков популярными компаниями:
Источник: CodingVC
А здесь показано, что происходит на рынке труда:
Источник: indeed.com
Это при том что все новые языки имеют недоработки. Node.js страдает от дробления с шестью соревнующимися фреймворками. Прямо сейчас Go очень популярен для микросервисов, но испытывает недостаток в крупномасштабных приложениях. Django/ Python, кажется, держит свои позиции, но и не растет.
Если вы хотите быть уверенным в вашем веб-приложении, вам нужно понять, на чем инженеры захотят писать через три года. Это важнее, чем выбрать фреймворк, который увеличит продуктивность прямо сейчас. Если вы Facebook, можете использовать, что угодно – люди все равно захотят работать на вас. Но большинство компаний не Facebook. В общем, если угадаете, то дополнительных усилий предпринимать не придется — новый популярный фреймворк привлечет к вам кадры самостоятельно.
