Мы сделали 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. В общем, если угадаете, то дополнительных усилий предпринимать не придется — новый популярный фреймворк привлечет к вам кадры самостоятельно.
Комментарии (48)
uniqm
21.11.2016 12:24+3Статья 2015 года… Я бы перевел краткую суть вот так: «Не надо использовать Ruby on Rails 3.х для нового проекта» и в этом я с ним согласен.
eyeofhell
21.11.2016 12:43+5Есть подозрение, что за последний год фундаментально ничего не поменялось. Разве что график трендов еще больше сдвинулся в сторону ноды :)
uniqm
21.11.2016 13:54+3Специально посмотрел, тенденции идентичны — плавный спад по поисковым запросам у обоих (что может говорить о некой зрелости, а может и чем то другом ^^).
Рельсы с 3 на 4 стали «приятнее» в плане работы с ActiveRecord и не только. Улучшение имеющегося функционала точно идет. Action Cable немного сомнительный в 5й версии, но зато в коробке.
foxmuldercp
21.11.2016 13:03я начал писать на 4х, потом докрутил туда реакт.
Сейчас пишу апи на 5х рельсах + отдельный фронт на реакте с редуксом, роутером и под вебпаком.uniqm
21.11.2016 14:00+2Писать бэкенд (не сильно сложного проекта) на рельсах сплошное удовольствие. Да, там немного абстракций не доложили, но на первых парах можно и имеющимися не сильно напрягаясь обходиться.
Ну а случае реальных нагрузок, масштабируемся железом. Зато легко =) Ну или дербаним от монолита «узкие места» и пишем их на чем-нибудь компилируемом.foxmuldercp
21.11.2016 18:03Панель управления хостингом — это, по Вашему, сильно сложный проект?
uniqm
22.11.2016 09:46+1Сама по себе панель достаточно простой проект, на мой взгляд. А вот подкапотное взаимодействие с ОС на низком уровне — по мне задача сложная или как минимум серьезная =) Но тут вопрос не к рельсам уже, админки на них пишутся прекрасно. А к коду бизнес-логики.
foxmuldercp
23.11.2016 14:42Код и логику бизнес логики я вынашивал год. даже на сентябрьской осдн немного про панельку рассказал. Но сейчас я пришел к тому что апи сервер и фронт на реакте надо разнести окончательно и засел за фронтенд
fogone
21.11.2016 12:33+9Два из четырех графиков в статье показывают зависимость вообще непонятно чего, вот как так? Зачем их вообще добавлять в статью, если они ни о чем не говорят?
eyeofhell
21.11.2016 12:43Это какие?
SunX
21.11.2016 12:50Первый и третий.
Можно, конечно, пройти по ссылкам и понять, о чем они, но как-то хотелось бы сразу понимать, о чем графики.
Если с 3м хоть что-то понятно (хотя непонятно, лучше когда больше или когда меньше), то в Первом совсем не понятно, где чей трендeyeofhell
21.11.2016 13:38Первый поменял, третий — тяжкое наследие перевода, полагаю там обычный relative to each over
Source
21.11.2016 13:14+5Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.eyeofhell
21.11.2016 13:39+1Знать бы еще как это замерить :) Один из самых больных для меня вопросов, который мучает уже много-много лет — как определить меру использования той или иной технологии. Есть нехорошее подозрение, что то, что датамайнится — это очень нерепрезентативная выборка «публичного доступа». И мы понятия не имеем, что используют внутри компании Fortune 500, просто потому, что их разработчики мало ходят на stackoverflow и не пользуются публичными репозиториями git :)
vdmitriyev
21.11.2016 14:12+3Я все же думаю, что почти любые разработчики, будь они из компаний списка Fortune 500 или нет, в любом случае время от времени ходят на stackoverflow (или на другой подобный тематический ресурс). А вот с отсутствием использования публичных репозиториев я вас полностью поддержу.
raidhon
21.11.2016 13:47+1Согласен, но не полностью с автором.
В данный момент пишу проект на фреймворке Sails.js совмещая его с микросервисом на Go ( тяжелые воркеры с очереди Beanstalkd ).
Но от Rails я тоже не отказываюсь, с три месяца назад закончил проект на пятой версии (помучал Action Cable для websocket ) все это положил под Nginx + Passenger.
Доволен как слон и потратил на проект всего пару месяцев, на node.js пилил бы полгода.
j_wayne
21.11.2016 13:47+3С одной стороны, да, руби сравнительно медленный.
С другой стороны, насколько это важно? Железо дешевое, программисты дорогие.
Для большей части стартапов вопрос нагрузки чуть менее чем неактуален на раннем этапе. Быть бы живу.
Еще один момент — из-за нативных гемов что-то конкретное может быть очень быстрым.
Пример.
Генерация json при помощи oj gem. По факту, он написан на С.
Если ваш проект — обычный CRUD API, где много Read, толку то от «быстрого» языка, где нет хорошей и быстрой реализации json генератора…
Короче, проблемы надо комплексно рассматривать.
На мой взгляд проблемы Rails совсем не в Ruby. Здесь было много статей на эту тему.
j_wayne
21.11.2016 13:53+1>> JRuby по-прежнему активен и последние версии подают надежды, но впереди ещё много работы.
Только вот стартует он секунды, даже со всеми нужными прописанными заклинаниями, даже на мощных процессорах. Использование console tools как в rails — мука. Прелоадеры? Покажите мне хоть один нормально работающий.
Diaskhan
21.11.2016 13:55+1До этого писал проект на чистом ПХП,
После этого пробывали писать документооборот на YII,
Как же надоели эти $ в PHP почему нельзя просто было сделать переменные без $?
Изучал Rails, но там было многое не явно.
Друг утроился в Mail.ru и сказал используй Django.
Теперь смотрю и оцениваю Benchmark'i.
Прельщает Go со своей скоростью, но отталкивает что MVC приложение на нем хорошее не напишешь.
Хотел Изучать Nodejs но увидев Асинхронную лапшу, понял что это ужжжссс,
Теперь уж даже не знаю куда стоит плыть!uniqm
21.11.2016 14:29+1Я бы сказал, что все три варианта хороши: MVC-фреймворки на «китах»(главных интерпритируемых языках). Какой язык больше нравится(опыт, окружение помощников, личное отношение и тд), в ту сторону и идти. Врятли в ближайшие 2-4года скажите себе: «Какой же я был, надо было Y, а не X выбирать».
akzhan
21.11.2016 17:19Используйте Babel с JavaScript, или TypeScript, и можете радоваться async/await, убирает сложности со спагетти. В ES2017 будет входить в язык. Взято из .NET.
svboobnov
21.11.2016 18:09Может, стоит попробовать Dart?
svboobnov
23.11.2016 23:15Я так понимаю, минус мне влепили за то, что предлагаю новую, не распространённую в индустрии технологию. Попробую объяснить своё предложение:
Diaskhan сказал, чтоКак же надоели эти $ в PHP почему нельзя просто было сделать переменные без $?
, а в Руби на Рельсах многое неявно (слишком много магии). Так вот, в Дарте магии немного, есть встроенные типы массивов, множеств (Set), отображений (Map); и он компилируется в JavaScript, то есть, его можно воспринимать как тот же TypeScript, но на сервере его можно исполнять либо в DartVM, либо компилировать Dart --> JS и запускать в node.js. Так что, в качестве будущей замены PHP, Dart вполне себе вариант, ПМСМ. Ну и нужные на веб-сервере библиотеки уже включены в стандартный набор.
baka_cirno
21.11.2016 15:25Я так понимаю, статья старая. Аналогом Rails в Node.js я бы, скорее, назвал Adonis.
raidhon
21.11.2016 16:01Тут вы правы, но мне все равно больше нравиться Sails очень удобно работать с websocket, Grunt из коробки и тд.
Больше плюшек больше популярность.
А так у Node есть из чего выбрать.
http://nodeframework.com/index.html#mvc
AmdY
21.11.2016 16:13-1Какой-то бред, зачем-то приплели сюда facebook, хотя этим самым hiphop никто не пользуется, сообщество ускоряет язык и без мордокниги. Nodejs и Go концептуально другие языки, а не замена ruby, копаться в асинхронных запросах то ещё удовольствие.
Ну и самое важное, что он рассматривает язык с точки зрения нагрузки(он стал третьим по посещаемость сайтом на Rails), а этот кейс далеко не критичен для большинства проектов, тем более узкие места всегда можно затюнить.
Пришлось саппортить один проект на рельсах, норм фреймворк, много полезных фич, которые перенимают фреймворки с других языков, не стоит торопиться его хоронить.AmdY
21.11.2016 17:30-2Ну что за гадкая привычка молча лепить минус и портить карму, отпишитесь хоть почему. Я же привёл аргументированную точку зрения, если надо ещё докину аргументов и ссылок.
nightwolf_du
21.11.2016 16:22+5Смущают тренды в первом графике.
Откуда node.js в 2004м году?
ya-est
22.11.2016 01:31Думаю, что аналитика немного неверная и подразумевается DOM Node JS.
https://developer.mozilla.org/en-US/docs/Web/API/Node
Source
22.11.2016 01:46Тренд до середины 2009 года можно использовать для нормировки текущего… Неважно что ещё ищут по такому запросу, но это явно надо вычесть, если хотите увидеть тренд именно по Node.JS
Sega100500
22.11.2016 09:52+1Довольно странно видеть все эти графики популярности, составленные по количеству запросов в поисковиках. А о том, что сколько компаний используют какой-то фреймворк — так это вообще чушь — сколько еще компаний не опрошено, сколько просто разработчиков не опрошено.
Я использую Ruby и Ruby on Rails уже более 5 лет в своей работе (опыт разработки более 20 лет) и АБСОЛЮТНО ВСЕМ доволен — скорость меня устраивает, удобство разработки, сам язык восхитителен, переход на более новые версии RoR без затруднений (прошел от 3 до 5) — разработал уже множество проектов — от простейших страничек до порталов — все прекрасно работает. В том-то и дело, что на Ruby пишут преимущественно профессионалы, потому как у языка довольно высокий порок вхождения, и поэтому абы кто на нем не сможет писать. А если занимаются этим профессионалы, то, по своему опыту скажу, что спрашивать что-то у гугл особой необходимости не возникает — все есть в документации, да и сам знаю, как и что работает, как и что написать.
Я согласен, что сейчас много новых проектов, фреймворков, направлений — вот молодые и неопытные мечутся в поисках святого грааля — чтобы толком ничего не изучить, а получались прям супер-крутые проекты.
Например, я сам вообще не сторонник г… на под названием JavaScript — вот и лажу по каждому поводу в поисковик за ответами, а он из-за этого как бы набирает популярность, если судить по количеству запросов в поисковиках.
Уже столько лет прочат закат Ruby, Ruby on Rails, а эти проекты, не обращая внимания особо ни на какие мнения, все развиваются и становятся только лучше. Я думаю, что со мной согласятся многие разработчики Ruby — мы просто делаем свое дело, а смотреть и, тем более, ориентироваться на какие-то там графики — это совершенно излишне. Инструментарий удобный и качественный — этого достаточно для профессионала.
poxu
22.11.2016 10:32-1Уважаемый переводчик!
Ваш перевод значительно лучше недавних шедевров от гуру перевода LukinB и лидера рейтинга MagisterLudi, но и его можно улучшить.
Я тут написал немного рекомендаций:
РекомендацииWe built Scribd into the #3 largest rails site by traffic and it worked for us,
Ваш перевод:
Мы сделали Scribd на Rails, и он стал третьим по посещаемость сайтом на Rails, и фреймворк работал, как надо.
Уточнённый перевод
Мы сделали Scribd третьим по посещаемости сайтом на rails, и нас это устроило
I see a lot of new companies using rails
Ваш перевод:
я вижу огромное число новых проектов,
Уточнённый перевод
я вижу много новых компаний
Вообще перевод слова company как проект встречается у вас больше одного раза, я не понимаю почему
Most new sites were still being written in PHP or Java, and there were huge numbers of engineers for those platforms.
Ваш перевод:
Большинство новых сайтов продолжали писать на PHP и Java – этому способствовало наличие огромного количества разработчиков для этих платформ.
Уточнённый перевод
Большинство новых сайтов всё ещё писалось на PHP и Java и для этих платформ существовало огромное количество разработчиков.
У автора оригинала нету утверждения, что наличие большоного количества разработчиков способствовало чему либо. Есть просто констатация факта, что они были.
deep set of open-source libraries and, most importantly, a pool of developers interested in working in it.
Ваш перевод:
свитой хороших библиотек и армией лояльных разработчиков
Смысл, в общем не потерян, только вот в оригинале нет слов свита, армия и лояльный.
А вот most importantly и open-source — есть.
Поэтому перевести лучше вот так
множеством библиотек с открытым кодом и, что самое важное, программистами которым интересно с ним поработать.
It was the right bet.
Ваш перевод:
Нам повезло
Уточнённый перевод
И ставка была верной!
As one of the first rails sites to hit scale, we benefited enormously from this, picking up great talent by offering a chance to work with rails.
Ваш перевод:
Когда взлетел наш проект, мы оказались в выигрыше — к нам потянулись талантливые ребята, поскольку мы могли предложить им поработать на Rails.
Уточнённый перевод:
Будучи одним из первых взлетевших сайтов на Rails, мы очень сильно выиграли от перемен, поскольку имели возможность забрать себе талантливых ребят, просто предложив им возможность поработать с Rails
Все знают, что Ruby медленный. Но на самом деле, Ruby – это самый медленный язык среди популярных языков программирования.
Тут нету "Но". Можно оставить "На самом деле", можно написать "Вообще-то", но тут нету "Но".
Some people will point to language design characteristics, which are part of the story
Ваш перевод:
Некоторые укажут на характеристики языка, которые сложились исторически. И это верно.
Про то, что характеристики сложились исторически в оригинале нет.
Есть — "language desing characteristics"
Некоторые укажут на особенности дизайна языка, что вносит определённый вклад
Source
22.11.2016 12:49Раз Вы вынесли это в комментарий, подразумеваю, что Вы хотите обсудить тему улучшения переводов не только с автором, поэтому вставлю свои 2 копейки.
Мы сделали Scribd третьим по посещаемости сайтом на rails, и нас это устроило
В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.
Вообще при переводе необязательно сохранять дословный смысл, потому что языки отличаются не только словами, и буквальный перевод будет выглядеть как у ребят из Edison.
Например, "It was the right bet." переведённая как "И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.poxu
22.11.2016 13:23-1Раз Вы вынесли это в комментарий, подразумеваю, что Вы хотите обсудить тему улучшения переводов не только с автором, поэтому вставлю свои 2 копейки.
Хочется обсудить со всеми у кого есть к этому желание, да. Почему-то в последние несколько дней стандартный ответ на коментарий о качестве перевода с примерами ошибок — минус коментарию и минус в карму безо всякого пояснения. Предыдущий коментарий — не исключение :).
В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.
Фразу можно понять как — мы сделали наш сайт третьим по посещаемости, среди сайтов на Rails и нас третье место в общем устраивало, мы были довольны.
Или можно истолковать как — мы сделали сайт третьим по посещаемости среди сайтов на Rails и Rails нас устроил.
Я понял первым способом. Вполне возможно, что я не прав.
"И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Поддерживаю.
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.
Согласен, конечно, но когда статья называется Why I wouldn’t use rails for a new company — увидеть в переводе — Почему я бы не стал использовать Rails для нового проекта — ну очень неожиданно. Я считаю, что такие коррективы в авторский текст это уже неправильно.
Source
22.11.2016 15:38+1стандартный ответ на коментарий о качестве перевода с примерами ошибок
Просто считается, что это надо в личку автору перевода писать. Хотя я такую агрессию не одобряю, т.к. тема улучшения переводов тоже интересная.
Фразу можно понять как — мы сделали наш сайт третьим по посещаемости, среди сайтов на Rails и нас третье место в общем устраивало, мы были довольны.
Ну нет, всё-таки оригинал о том, что фреймворк не стал для них узким местом, несмотря на большую посещаемость. Иначе вторая часть фразы(про сегодняшний день) напрочь теряет смысл.
Why I wouldn’t use rails for a new company — увидеть в переводе — Почему я бы не стал использовать Rails для нового проекта — ну очень неожиданно.
Но если подумать, то это вполне корректная адаптация к российским реалиям. Это у них распространённая практика для каждого нового проекта открывать новую компанию. У нас так не принято. Вот и получается, что речь в статье именно о старте новых проектов, просто для американца начать проект и открыть компанию — это одно и то же.
yul
22.11.2016 14:39Подавляющее большинство современных веб-приложений (нормально написанных) по настоящему нагружают только базу данных, так что зависимость от языка программирования для них довольно небольшая. Ну и масштабировать никто не мешает (разве только бюджет).
Так что именно на скорость языка стоит обращать внимание только если действительно планируются высокие вычислительные нагрузки, которые при этом нельзя или не имеет смысла передать специализированному приложению на чем-то быстром, или самописному расширению на C.
tonissimo
22.11.2016 21:29Ну, если на чистоту, все-таки ruby прилично времени тратит на десериализацию-сериализацию большого количества данных, GC опять же не особо шустрый. У меня рендеринг чаще медленнее гет-запросов происходит, если не из кэша доставать. Но, даже зная все узкие места производительности, я все равно начинаю проекты на ruby тупо из-за меньшего времени разработки. Потом уже, если потребуется оптимизация, какие-то части переписываю с использованием других инструментов.
handicraftsman
22.11.2016 23:07Наткнулся на следующее: http://chrisseaton.com/rubytruffle/announcement/
И на следующее: http://jruby.org/bench9000/
prostofilya
не «мейнстримовых»?