Пришло время попрощаться с Rails

http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html
  • Перевод

В прошлом году я принял решение, что не буду больше использовать Rails, и не буду поддерживать Rails в своих гемах. Кроме того, я буду делать все возможное, чтобы мне никогда не пришлось снова столкнуться с Rails на работе.


Так как я вовлечён во множество Ruby-проектов, люди часто спрашивают меня, почему я не люблю Rails, какие проблемы у меня есть с ним и так далее. Поэтому я решил написать этот длинный пост, чтобы подвести итоги и все объяснить.


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


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


Хорошая часть


Я не буду делать вид, что все в Rails плохо, неправильно, и фреймворк является воплощением зла. Это было бы не справедливо, да и просто глупо. О Rails можно сказать очень много хорошего. И я упомяну пару (очевидных?) вещей для поддержания баланса.


Итак, Rails сделал Ruby популярным. Это факт. Я стал Ruby-разработчиком, что в свою очередь изменило мою карьеру и дало мне много удивительных возможностей, именно благодаря Rails. Многие рубисты тех дней прошли по тому же пути. Мы все здесь благодаря Rails. Во многих случаях, Rails на самом деле оказал огромное влияние на людей, и буквально улучшил им жизнь. Люди получили лучшие рабочие места, лучшие возможности и хорошие деньги. Это было радикальной сменой условий "игры" для многих из нас.


На протяжении многих лет Rails & DHH вдохновили многих людей, в том числе людей из других сообществ, на переосмысление того, что они делают. Например, я уверен, что Rails способствовало улучшению PHP сообщества (вы можете попытаться доказать, что я ошибаюсь, но у меня есть довольно яркие воспоминания как Symfony подчерпнул кучу вдохновения от Rails). То же самое произошло в Java, фреймворк Play является примером.


Есть и другие фантастические аспекты. Rails был всегда нацелен на простоту использования и возможность быстро создавать веб-приложения, что позволило преуспеть таким инициативам, как Rails Girls. Rails доказал людям, что они способны создать что-то самостоятельно, без какого-либо опыта программирования, в относительно короткий промежуток времени. Это удивительно, так как это легко может стать воротами в мир программирования для людей, которые в противном случае даже не рассматривали возможность стать программистом.


Мое путешествие


Позвольте мне рассказать вам немного о моем бэкграунде и как я пришёл к Rails.


Я начал работать с Ruby в конце 2006 года, поскольку моя дипломная работа была о Rails. Я изучал язык в то время, как писал свой диплом. Это было весело, это было интересно, это было что-то новое для меня. Тогда я еще работал в качестве PHP-разработчика. И как типичный PHP-программист в ~2005-6, я делал все эти типичные вещи: писал SQL-запросы в шаблонах представлений, писал в процедурном стиле, а затем разрабатывал свой собственный фреймворк и свой собственный ORM, разочаровывался и выгорал. Несмотря на некоторые знания C, C++, Java и Python, я решил перейти на Ruby, из-за Rails. Я выбрал их для своего диплома и совершенно случайно наткнулся на предложение о работе от местного магазина на Rails. Я ответил и они наняли меня. Это было в марте 2007 года.


Итак, с марта 2007 года я начал работать с Ruby профессионально, и где-то с 2009-го я начал вносить вклад в OpenSource проекты на Ruby. С тех пор я работал в консалтинговой компании в течение 3.5 лет, в основном c большими и сложными проектами. Потом работал фрилансером в течение нескольких лет, работал с кучей клиентов, открыл свою собственную компанию, а затем вернулся на полный рабочий день, а затем снова на фриланс, и теперь я вновь штатный сотрудник. Я создавал Rails-приложения с нуля, и участвовал в разработке относительно больших Rails-приложений.


Позвольте мне рассказать вам одну историю. Однажды я присоединился к существующему проекту. Это было огрооомное приложение, которое управляло веб-сайтом торгового он-лайн сообщества. Сложные модели продаж, сложные промо-акции, затейливые конфигурации товаров, купоны, группы пользователей, сообщения — в нём было всё это. Я присоединился к ним, чтобы помочь добавить несколько новых фич. Одной из моих первых задач было… добавить ссылку на что-то на какой-то странице. Мне потребовалось несколько дней, чтобы добавить эту глупую ссылку. Почему? Приложение было большим шаром сложной логики предметной области, раскатанным по нескольким слоям и с настолько сложными вьюхами, что было не просто даже найти нужный шаблон, в котором добавить ссылку. Так как мне нужны были некоторые данные из заказа для того, чтобы создать эту ссылку, не было очевидно, как я должен получить их. Недостаток внутренних API приложения и опора исключительно на ActiveRecord сделали эту задачу чрезвычайно трудной. Я не шучу.


Мои первые фрустрации с Rails начались довольно рано. Я испытал недовольство от ActiveRecord примерно после 6 месяцев его использования. Также мне никогда не нравилось, как Rails подошел к работе с JavaScript и AJAX. В случае, если вы не помните, или не застали версии до того, как Rails принял UJS подход (который был хитом обсуждений в 2007-2008 годах), Rails использовал inline JavaScript в шаблонах, порожденный связкой противных хелперов. Как и всё с Rails, это было "легко и приятно в начале", а затем превращалось в неподдерживаемое дерьмо. В конце концов, Rails принял UJS в версии 3.0 и, кажется, сообщество согласилось, что это лучший подход. Это было, когда Merb был убит влит в Rails. О, вы не знаете, что такое Merb? Хорошо, давайте поговорим об этом.


Почему я был восхищён Merb & DataMapper


Merb — проект, созданный Ezra Zygmuntowicz. Он начался как хак, чтобы сделать загрузку файлов быстрее и потокобезопасной. И он прошёл интересный путь от этого хака до модульного, потокобезопасного, быстрого full-stack фреймворка для разработки веб-приложений. Я помню, как люди начали говорить о Merb в 2008-м и это было удивительное чувство, что происходит что-то новое, и это будет здорово!


Вы возможно обрадовались, когда в Rails появился режим API, не так ли? Хм, а Merb имел 3 режима: режим полного стека, режим API и микро-режим, в котором он был урезан до минимума, и я до сих пор помню, что это было самой быстрой вещью когда-либо существовавшей в Ruby мире. Это было более 7 лет назад. Вдумайтесь в это.


В то же время еще один проект привлёк внимание сообщества — DataMapper. Он стал частью Merb стека, являясь его выбором для ORM. Я был очень возбуждён тем, как он решал многие проблемы, которые были в ActiveRecord. DataMapper уже в ~2008-9 имел определения атрибутов в моделях, пользовательские типы, ленивые запросы, более мощный DSL запросов и так далее. В 2008 году Yehuda Katz был одним из Core-разработчиков проекта, он активно продвигал его и был большой ажиотаж по этому поводу. DataMapper в конечном счете был лучшим ORM, чем ActiveRecord в 2008-9. Было бы несправедливо не упомянуть о том, что Sequel появился примерно в то же время и до сих пор он используется гораздо меньше, чем ActiveRecord, несмотря на то, что является более хорошим решением.


Я был восхищён Merb и DataMapper так, как они принесли надежду, что мы можем сделать что-то лучше и создать здоровую конкуренцию для Rails. Я был взволнован, потому что оба проекта поощряли модульный подход и потокобезопасность, не говоря уже о таких вещах, как просто более хорошие стандарты написания кода.


Оба проекта были в конечном счете убиты Rails, так как Merb был "влит" в Rails, что вылилось в огромный рефакторинг Rails для версии 3.0. DataMapper потерял внимание сообщества и без особой поддержки проект не смог развиваться, как это могло бы быть, если Merb не был бы "влит" в Rails.


С этим решением экосистема Ruby потеряла кучу важных проектов и только Rails выиграли от этого. Является ли решение убить Merb хорошим или нет, это вопрос личного мнения, мы можем только предполагать, что могло бы произойти, если бы решение не было принято. Тем не менее, есть простая истина о конкуренции — это здорово. Отсутствие конкуренции означает монополию, и есть простая истина о монополии — это не здорово. Конкуренция способствует прогрессу и инновациям, конкуренция создает здоровую экосистему, она позволяет людям сотрудничать больше, чтобы поделиться тем, что распространено, чтобы создавать лучший фундамент. Это не то, что происходит в сообществе Ruby.


После того, как Merb & DataMapper были практически уничтожены (в долгосрочной перспективе), создать нечто новое в экосистеме Ruby оказалось крайне сложно. Поскольку внимание людей сфокусировано на Rails, новые проекты были под его сильным влиянием. Прорваться с новыми идеями было трудно, если не сказать больше… так как каждый раз, когда вы что-то демонстрируете, люди просто хотят, чтобы это было похоже на Rails и хорошо работало с Rails. Делать проекты, которые работают с Rails, — трудно, но я вернусь к этому вопросу позже.


После всех этих лет мы в конечном итоге пришли к одному фреймворку, подчиняющему всю нашу экосистему, влияя на тысячи разработчиков и создание стандартов, которые… весьма спорны. Мы потеряли разнообразие экосистемы, которая начала расти в 2008 году и была подавлена Rails.


Эй, я знаю, как это звучит почти как теории заговора, но не относитесь к этому так. То, что я сказал здесь, — это факты с примесью моих личных чувств. Я начал участвовать в DataMapper в конце 2009 года и, видеть как он рушится было очень грустно.


Сложность!


Сложность является нашим самым большим врагом. Люди стали проявлять меньше энтузиазма к Rails, поскольку быстро оказалось, что имея дело с растущей сложностью, он оставляет нас с большим количеством вопросов без ответа. То, что предлагают DHH & co. никогда не было достаточно, чтобы решить многие проблемы, с которыми тысячи разработчиков начали бороться ещё в 2007-2008 гг. Некоторые люди надеялись, что, возможно, Merb/DataMapper принесут улучшения, но теперь вы знаете, что произошло, так что мы все вернулись обратно к Rails в 2010 году, когда Rails 3.0 был выпущен.


Пару дней назад кто-то запостил на /r/ruby ссылку на статью об организации кода с помощью "Service объектов". Это одна из многих подобных статей. Если вы думаете, что это своего рода тенденция последнего времеми, взгляните на статью James Golick от марта 2010 — "Crazy, Heretical, and Awesome: The Way I Write Rails Apps".


Мы говорим о путях совершенствования архитектуры наших Rails приложений в течение примерно 6 лет. Я пытался внести свой вклад в эту дискуссию насколько я мог — статьями, выступлениями на конференциях и работой над многими проектами с открытыми исходниками, которые стремятся решать различные сложные задачи.


Однако подобные аргументы и идеи всегда высмеиваются членами Rails Core Team, и особенно DHH. Это было отпугивающим и обескураживающим для меня, и это причина почему я никогда не пытался внести свой вклад в Rails. Я чертовски уверен, что мои предложения будут в конечном итоге заминусованы. Monkey-patches? Да ладно, не проблема, мы любим нашу 10.years.ago! Новые абстракции? Кому это нужно, Rails — это просто! TDD? Не проблема, она мертва, не беспокойтесь! ActiveRecord раздутая — ну и что, это же так удобно, давайте добавим больше возможностей!


Экосистема Rails, особенно вокруг своей Core Team, никогда не производила на меня хорошее впечатление, и для меня не проблема признать, что я просто боюсь предлагать любые изменения. Это особенно актуально, так как первое, что я хотел бы предложить "Пожалуйста, удалите ActiveSupport" (ха-ха… представьте себе это!).


Ладно, давайте перейдем к некоторым техническим деталям.


Удобство-ориентированное проектирование Rails


Как я уже говорил, Rails был построен с прицелом на удобство использования. Не путайте это с простотой. Только вчера я наткнулся на этот твит, который говорит об этом всё:


Simple vs Easy


Вот как работает Rails, классический пример:


User.create(params[:user])

Вы видите простую строку кода, и вы можете сразу сказать(если вы знаете, является ли User моделью ActiveRecord), что она делает. Проблема здесь заключается в том, что люди путают простоту с удобством. Эту строку удобно/легко написать в вашем контролере и всё сразу заработает, не так ли?


Однако, эта строка кода не является простой, её легко написать, но код "под капотом" чрезвычайно сложен, так как:


  • params должны пройти через СУБД-специфические приведения типов
  • params должны быть валидированы
  • params могут быть изменены с помощью колбеков, включая потенциальные вызовы внешних систем, вызывающие побочные эффекты
  • невалидное состояние приводит к установке сообщений об ошибках, которые зависят от внешних систем (например I18n)
  • валидные params должны повлиять на состояние объекта, и возможно изменить состояние ассоциированных с ним объектов
  • один объект или весь граф объекта должен быть сохранен в базе данных

Это нехватка разделения ответственности, которая всегда наносит ущерб любому сложному проекту. Это увеличивает связывание(coupling) и затрудняет изменение и расширение кода.


Но в Rails мире это не является проблемой. В Rails мире основные принципы дизайна такие как SRP (и SOLID в целом) высмеивают и представляют как "раздутые, ненужные абстракции, увеличивающие сложность". Когда вы говорите, что предпочитаете моделировать варианты использования приложения, используя свои собственные объекты и делать сложные части явными, лидеры Rails скажут вам YAGNI. Когда вы говорите, что вы предпочитаете использовать композицию, которая делает ваш код более надежным и гибким, лидеры Rails, за исключением tenderlove, скажут вам “use ActiveSupport::Concerns”.


Для Rails-разработчика не проблема, что данные, поступающие из веб-формы направляются в глубины ActiveRecord, где Бог знает, что произойдет.


Действительно сложная часть в этой дискуссии — быть в состоянии объяснить, что это первоочередная проблема. Людей привлекает Rails, потому что он дает вам ложное чувство простоты, в то время как то, что происходит на самом деле, заключается в том, что сложность спрятана за удобными интерфейсами. Эти интерфейсы основаны на многих предположениях о том, как вы собираетесь писать и проектировать ваше приложение. ActiveRecord является лишь одним типичным примером, но Rails полностью построен на этой философии, каждая часть Rails работает аналогично.


Я должен упомянуть, что я знаю об огромных усилиях сделать ActiveRecord лучше, таких как введение Attributes API (сделано с помощью серьезного внутренного рефакторинга, который улучшил кодовую базу). К сожалению, до тех пор пока ActiveRecord поставляется с более чем 200 публичными методами и поощряет использование колбеков и concerns, это всегда будет ORM, которая не в состоянии справиться с растущей сложностью.


Изменится ли эта философия в Rails? Я так не думаю. У нас нет никаких признаков того, что что-то улучшится в этом отношении, так как лидеры Rails просто против этого. Простое доказательство — недавнее спорное дополнение ActiveRecord.suppress, которое было предложено самим DHH. Обратите внимание на то, как он в очередной раз подшучивает над обычными Ruby классами, говоря: "Да, вы можете добиться того же, создав отдельную фабрику CreateCommentWithNotificationsFactory". Ну-ну!


ActiveCoupling


Должен ли Rails являться вашим приложением? Это был важный вопрос, который задают многие после просмотра выступления дядюшки Боба, где он в основном предлагает более сильное разделение между веб-частью и вашим основным приложением. Отбросив технические детали, это хороший совет, но Rails не был разработан с учетом этого факта. Если вы делаете это с Rails, вы теряете всю суть этого фреймворка. По факту, взгляните на то, что сказал DHH об этом:


Rails is your app


Его мысли на этот счёт предельно ясны, не так ли? Важной частью является "конечно, является". И знаете, что? Я полностью согласен!


Rails является вашим приложением, и всегда будет так, покуда вы не прилагаете огромные усилия, чтобы использовать его таким образом, для которого этот фреймворк не был предназначен.


Подумайте об этом:


  • ActiveRecord призван стать центральной частью логики вашей предметной области. Вот почему он предоставляет гигантский интерфейс с большим количеством функций. Вы можете иногда извлекать часть логики в отдельные компоненты, когда это имеет смысл. Но Rails философия заключается в том, чтобы поместить всё в ActiveRecord, а не беспокоиться о SRP, не беспокоиться о LoD, не беспокоиться о тесной связи между логикой предметной области и слоем сохранения и так далее. Вот как вы можете эффективно использовать Rails.
  • Весь "слой" представления в Rails связан с ActiveModel, и как следствие он связан и с Active Record ORM (это может быть и Sequel, но это не имеет значения)
  • Контролеры являются неотъемлемой частью Rails-приложения, и сильная связанность имеет место и здесь
  • Хелперы также являются неотъемлемой частью Rails-приложения, сильная связанность ещё раз
  • Все в Rails, и во множестве сторонних gems, созданных для Rails, происходит через наследование (либо mixins, либо на базе классов). Rails и сторонние gems обычно не предоставляют автономных, повторно используемых объектов, они предоставляют абстракции, от которых наследуют ваши объекты — это еще одна форма сильной связанности.

Имея это в виду, было бы сумасшествием считать, что Rails — не ваше приложение. Если вы пытаетесь избежать этого типа связанности, можно себе представить, какие усилии придётся приложить и сколько из встроенной функциональности вы потеряете. И именно поэтому демонстрация альтернативных подходов в Rails создают впечатление раздутых, ненужных абстракций, напоминающих людям об их "страшных" Java днях. Rails не был построен с ориентацией на низкую связность и компонентно-ориентированный дизайн.


Не боритесь с этим. Примите это.


Нежеланная часть


Несмотря на всё вышесказанное, моя самая большая жалоба на Rails — это ActiveSupport. Так как я уже писал об этом, я не чувствую, что мне нужно повторяться. Я также рекомендую почитать комментарии в той статье.


Единственное, что я хотел бы добавить, что именно из-за ActiveSupport я не считаю Rails желанной частью экосистемы Ruby. Эта библиотека является квинтэссенцией всего неправильного в Rails для меня. Отсутствие фактических решений, отсутствие чётких абстракций, просто куча воркэраундов для решения проблемы под рукой, воркэраунды, которые превращены в официальный API, и карго-культ в результате. Чудесно!


Rails является закрытой экосистемой, и это накладывает плохие требования на другие проекты. Если вы хотите заставить что-то работать с Rails, вы должны позаботиться о таких вещах, как работоспособность при подключенном ActiveSupport, или что ничего не сломается от зверской перезагрузки кода в режиме разработки, или что объекты предоставляются глобально, потому что, ну вы знаете, в Rails всё должно быть доступно везде, для вашего удобства.


То, как работает Rails, требует много дополнительных усилий от разработчиков, создающих свои гемы. Прежде всего, следует ожидать, что ваши гемы могут работать с Rails (потому что, очевидно, все будут использовать их с Rails), и это само по себе является непростой задачей. У вас есть библиотека, которая работает с базами данных, и вы хотите заставить её работать с Rails? Ну вот, теперь вы должны заставить её работать, как ActiveRecord, более или менее, поскольку интерфейс интеграции — ActiveModel, изначально основан на ActiveRecord времён Rails 3.0.


Есть множество ограничений, которые делают интеграцию с Rails весьма трудной задачей.


Вы понятия не имеете, со сколькими проблемами вы можете столкнуться при попытке заставить код работать с горячей перезагрузкой кода в режиме разработки. Rails ожидает глобальную, изменяемую среду выполнения. Для того, чтобы сделать всё еще труднее, они ввели Spring. Этот гем открывает целую категорию потенциальных новых багов, с которыми ваши гемы могут столкнуться, когда вы пытаетесь заставить их работать с Rails. Я настолько задолбался с этим, друзья мои, что мне больше нечего сказать. Мало того, что перегрузка кода в Ruby работает ненадежно, так это к тому же добавляет кучу совершенно ненужной сложности для наших гемов и приложений. Это влияет на всех, кто разрабатывает гемы, которые должны работать с Rails. Никто из команды ядра Rails, несмотря на критику на протяжении многих лет, даже не думал, что было бы хорошей идеей, посмотреть, как это можно было бы сделать лучше. Если бы кто-нибудь просто сосредоточился на повышении скорости загрузки приложения, мы могли бы положиться просто на перезапуск процесса. Кроме того, вы должны действительно использовать автоматизированное тестирование, чтобы удостовериться, что изменение, которое вы только что сделали, на самом деле работает, а не жать F5. Просто к вашему сведению.


Я знаю, это звучит, как будто я жалуюсь, хотя по сути так и есть! Я пытался поддерживать Rails и это было слишком разочаровывающим опытом для меня. Я сдался, я не хочу делать это больше.


Посколько моё решение проблем подразумевало выдирание ActiveSupport, удаление ActiveRecord и добавление нормального слоя представления, который был бы отделен от любого ORM, я понял, что неразумно думать, что это когда-нибудь произойдет в Rails.


Уход от Rails


В результате девяти грёбанных лет работы с Rails и активной работы над многими OpenSource проектами на Ruby, я сдался. Я больше не верю, что нечто хорошее может случиться с Rails. Это моя личная точка зрения, но многие люди разделяют те же самые чувства. В то же время, есть много других, которые по-прежнему счастливы с Rails. Рад за них! Честно! Rails вошёл во всеобщее употребление, у него есть своя сфера применения, он по-прежнему помогает людям и это зрелый, хорошо поддерживаемый, стабильный веб-фреймворк. Я не пытаюсь убедить кого-либо, что Rails в конечном счете плохой! Он просто очень плохой для меня.


Впрочем это имело свои последствия. Именно поэтому я оказался вовлечён в такие проекты, как dry-rb, hanami and trailblazer и поэтому я давно работаю над rom-rb. Я хочу помочь построить новую экосистему, которая, мы надеемся, вернёт тот же самый энтузиазм, который мы все чувствовали во времена Merb и DataMapper.


Нам нужна разнообразная экосистема, нам нужно больше маленьких, целенаправленных, простых и надёжных библиотек. Нам нужны рубисты, которые чувствуют себя комфортно, используя фреймворки совместно с небольшими библиотеками.


Уход от Ruby


Правда в том, что уход от Rails — также начало моего следующего путешествия — ухода от Ruby в качестве основного языка. Я вдохновился функциональным программированием в последние пару лет. Вы можете видеть, что в этом стиле я пишу теперь и на Ruby. Я наблюдаю за ростом Elixir с большим воодушевлением. Я также изучаю Clojure, который в данный момент находится на вершине моего списка "языки для изучения". Чем больше я узнаю, тем больше я люблю его. Моя конечная цель состоит в том, чтобы изучить ещё и Haskell, поскольку я заинтригован его статической типизацией. В настоящее время на работе я программирую на Scala. Я смог очень быстро оценить преимущества статической типизации в нём, несмотря на то, что это была жёсткая перестройка моего рабочего процесса разработки, включая компиляцию и TypeError ошибки. Это освежающий опыт — видеть как мой редактор говорит мне, что я сделал ошибку, прежде чем я добрался до выполнения каких-либо тестов.


Чем больше я погружаюсь в функциональное программирование, тем больше я вижу насколько отстаёт Rails, когда дело доходит до современного дизайна приложений. Monkey-patching, опора на глобальное изменяемое состояние, сложный ORM — эти вещи рассматриваются в качестве основных проблем в функциональных языках.


Я знаю, многие скажут "но Ruby является объектно-ориентированным языком, используй это в свою пользу, вместо того, чтобы пытаться сделать из него то, чем он не может быть". Но это не так. Прежде всего, Ruby является объектно-ориентированным язык с функциональными особенностями (блоки, лямбды и т.д.). Во-вторых, избегание изменяемого состояния является общим, хорошим советом, который вы можете применить в своем Ruby-коде. Устранение глобального состояния и изолирование его, когда вы не можете его избежать, — также очень хороший общий совет.


Как бы там ни было, я покидаю Ruby. Я уже начал этот процесс. Он займёт годы, но это мой путь. Я буду продолжать работать и поддерживать rom-rb, dry-rb, помогать с hanami и trailblazer. Так что не волнуйтесь, эти проекты очень важны для меня, и я счастлив наблюдать рост их сообществ.


Наиболее частая обратная связь


Это заранее подготовленный список обратной связи и вопросов, но он основан на реальной обратной связи, которую я получал.


Заткнись. Rails великолепен и работает очень хорошо для меня.

Это является наиболее распространенным вариантом обратной связи, которую я получаю. Прежде всего, меня беспокоит, что многие люди так реагируют. Мы обсуждаем инструмент, а не человека, нет необходимости воспринимать это так эмоционально. Не поймите меня неправильно, я понимаю, что это естественно "защищать" что-то, что помогло вам, или то, что вам просто нравится, в то же время здорово иногда выходить за рамки привычного мышления, быть открытым к критике и спокойно анализировать её. Если вы счастливы с Rails, это здорово, на самом деле.


Ты просто жалуешься, ты не помогаешь, ты ничего не сделал, чтобы помочь Rails стать лучше, ты не предложил никаких решений описанных проблем

Этот тип обратной связи раньше меня очень злил и огорчал. В момент написания этой статьи, в соответствии с GitHub, я сделал 2435 коммитов в OSS прошлом году. Это было в моё свободное время. Да, я не способствовал улучшению непосредственно Rails из-за причин, которые я объяснил в этой статье. Там слишком много того, с чем я не согласен, и это было бы пустой тратой времени для обеих сторон. Я вносил свой вклад через статьи в блогах, доклады на конференциях и тысячи строк OpenSource кода, которые вы можете найти на GitHub.


Это OSS, просто форкни Rails

Это абсолютно мимо кассы. Нам необходимо разнообразие в экосистеме с хорошим выбором библиотек, а также несколько фреймворков с их уникальным набором фич, делающим их пригодными для различных вариантов использования. Форк Rails не будет иметь никакого смысла. Никто не будет форкать Rails, чтобы пройти через такие испытания, как удаление ActiveSupport и устранение высокой связности от таких концептов как ActiveRecord и т.д. Проще и быстрее создать что-то новое, что другие люди уже и делают (см. Hanami).

Поделиться публикацией

Комментарии 404

    +2
    > User.create(params[:user])
    >…
    > код «под капотом» чрезвычайно сложен

    От сложности никуда не деться, все что перечислено всеравно надо делать. И если сделать вместо одной «ручки» россыпь то код проще не станет. Более того, с россыпью появляется новая проблема: а все ли ручки дернуты.

    > Как бы там ни было, я покидаю Ruby

    Основной вопрос — а куда? Несмотря на свой почтенный возраст рельсам существует крайне мало альтернатив. Могу вспомнить только elixir/phoenix — кстати от людей из команды rails. И там, кстати, решены многие вопросы упомянутые тут (возможность переписать фреймворк с нуля развязывает руки, да)
      0

      В оригинале в комментах пишут про clojure. Что на нём прототипирование по скорости сравнимо с рельсами. Подробнее не читал, может там и либы предлагают.

        0
        Под Clojure сейчас популярен Luminus
        +8
        И если сделать вместо одной «ручки» россыпь то код проще не станет.
        В том то и дело, что код станет именно проще, т.к. всё будет написано в явном виде. Пример из Elixir:

        %User{}
        |> User.changeset(params["user"])
        |> Repo.insert!
        

        где User.changeset — это обычная функция, определенная в модуле User

        def changeset(struct, params \\ %{}) do
          struct
          |> cast(params, @allowed_fields)
          |> validate_required(@required_fields)
        end
        

        И всё, никаких скрытых колбеков и никакой магии. Если данные пользователя редактируются через несколько форм с разными требованиями по обязательным полям, то можно создать changeset-функцию для каждой формы. Другими словами валидация полностью отвязана от модели и работа с БД тоже полностью отвязана от модели.

        Основной вопрос — а куда?
        Пётр явно называет Clojure и Elixir, а также Hanami для тех, кто не готов изучать новые языки.
          0
          И сколько еще будет объявлено кастомных функций которые «вроде бы» делают то что там написано? в каждой модели каждый раз и бегать проверять что кто то написал именно то что надо? вместо того чтобы положиться на подобный метод фреймворка?
            0
            И сколько еще будет объявлено кастомных функций

            Да, сейчас у некоторых разработчиков мода на копипасту.
              +1
              Одна дефолтная changeset-функция сгенерируется генератором модели. А остальные по мере необходимости.
              В Rails долгим и мучительным путём пришли к тому, что вызывающий код должен преобразовать параметры самостоятельно:
              def user_params(params)
                params.require(:user).permit(@allowed_fields)
              end
              

              Но куда подобные методы помещать не придумали и пихают пока прямо в контролеры, что в нетривиальных случаях приводит к реализациям user_params, разбросанным по разным файлам.
              А вот для создания разных правил валидации одной модели в Rails пока из коробки ничего нет.
                +1
                А чем такой вариант плох? отдельный класс. Там где вызываете указываете для какой операции нужно. можно еще юзера внутрь передать. Вот тут развитие этой идеи в гем.
                  +2
                  Вариант хорош. Но никто и не говорит, что невозможно использовать обычные Ruby-классы совместно с Rails. Автор статьи прекрасно об этом осведомлён, просто устал бороться с тем, что генеральная линия Rails Core Team идёт совсем в другом направлении.
                  +2

                  Именно поэтому появляются проекты, подобные Trailblazer: в них как раз придумывают места, где это должно быть. Конкретно в нём для разных валидаций создаются отдельные форм-объекты, которые используются в операциях (это у них так сервисные объекты). Важно, что валидации выносятся с уровня хранения данных (модели) в отдельное, специальное место. См. http://trailblazer.to/#form

                +4
                Пётр несколько раз упоминает о Hanami. Я считаю, что этот фреймворк может стать хорошим ответом Rails.
                  +3
                  Когда дорастет до стабильной версии
                +1
                crystal же.
                  0
                  Это не фреймворк, он ещё даже до стабильного как язык не дорос, емнип. А так да — хорошее направление, как мне кажется.
                0
                deleted
                  –5
                  > Оба проекта были в конечном счете убиты Rails

                  Как можно убить open-source проект? Не нравится — форкайся и продолжай пелить так, как нравится.
                    +9
                    Автор использует несколько драматичный слог, когда вспоминает о Merb и DataMapper, но по большому счёту так и было. Более полное понимание можно получить прочитав статью по ссылке из статьи «Rails and Merb Merge». Если вкратце, то Rails Core Team обещала реализовать модульность и низкую связность, в частности легкость отказа от ActiveRecord в пользу DataMapper или Sequel. По факту всё оказалось не так радужно, как в обещаниях.
                    А чтобы форкаться и продолжать пилить нужны команда и ресурсы, а команда Merb как раз распалась в результате того «объединения».
                      –2
                      Но сами Merb и DataMapper никуда не делись ведь. Можно взять последнюю версию до слияния и продолжить работу с этого места.

                      Если недовольных вроде автора — больше одного, то они вполне могут этим заняться.
                        +3
                        Вы считаете, что если создатели и основатели Merb и DataMapper опустили руки, и распались, забросив свое родное детище, то посторонние люди внезапно объединяться, схватят и начнут внезапно пилить качественный продукт?

                        Форки это хорошо, но редко какие форки превосходят оригиналы.
                        0
                        команде мерба дали возможность сохранить лицо, разрешив им «объединиться». На самом деле они просто попрогали что-то и бросили, но поскольку все друзья, решились иммитацию сливания.
                        +1
                        OpenSource без масштабности — ничто. Rails всасывает в себя разработчиков, не оставляя сил другим проектам.
                        Не обязательно, что другие проекты хуже. А и потом что Rails слишком авторитетен.
                        Это и не дает развивать другие проекты в Ruby
                          0
                          Вы так говорите, как будто чуваки из Rails приходят к разработчикам домой, направляют им пистолет в голову, и под угрозой смерти заставляют использовать только Rails и контрибутить только в Rails.
                            0
                            Речь идет о написании библиотек, которые могли бы пригодиться большому количеству людей. Вам нужно их продвигать, чтобы они действительно стали общепринятым решением. Вам может быть это непонятно, если вы не писали их, но у меня есть пример под рукой: гем dry-types, который занимается приведением типов. Это абсолютно общая и при этом конкретная задача. Но он из коробки не работает с рельсами из-за горячей перезагрузки кода, а если вы захотите подружить его с ActiveSupport, то вас ждет веселый вечер (если вы опытный руби-разработчик, иначе шансов ноль), результатом которого будет запутанное и ненадежное решение.
                              0
                              гем dry-types, который занимается приведением типов
                              стоит упомянуть, что это как раз один из многих гемов автора статьи :-)
                            +2
                            Напрашивается идиома Язык одного фреймворка =)
                              0
                              Надо отметить — что именно (и только) благодаря такому проекту как Rails (и по сути, лично DHH) — мир веб-разработок узнал про Ruby. И по причине, что ruby стало пользоваться на несколько порядков людей чем во времена «до-rails» — Ruby улучшился (по крайней мере по направлению производительности).
                            +5
                            Спасибо за оперативный перевод.
                              –2
                              Если учитывать число вакансий в РФ, то я наблюдаю следующую картину:

                              — число проектов на рельсах снижается (старые все еще поддерживаются, а вот с новыми уже нет).
                              — растет число проектов на python (django).]
                              — растет число проектов на js-фреймах.

                                –5
                                js кросплатформенный, nodejs можно завести хоть на своём телефоне под android (Если там заводили полноценный VoIP Asterisk, то завести nodejs явно проще). Что бы не писалось на js оно может быть использовано в телефоне, телевизоре, VoIP терминале, да даже на десктопе с «полноценным» UI конкретной платформы, внешне не отличимым от привычных контролов, поэтому естесственно, количество проектов на нём будет расти.
                                  0
                                  Хорошо бы перевести эту картину в плоскость цифр, чтобы было ясно где рост замедлился, а где — ускорился.
                                  +8
                                  В статье меня ничего не удивило) Хотел написать длинный и пространный комментарий, но холиварить очень не хочется.
                                  Поэтому только факты.

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

                                  Сами рельсы довольно продуманы и удобны в мелочах — миграции, ассеты, сиды, енв и пр. инфраструктурные штучки.
                                  Есть с чем сравнить, Play, Spring Boot и т.п. Быстрый релоад в отличии от Play + Scala. Работа с ассетами в Spring Boot напомнился времена голого JSP и сервлетов).

                                  Я не отказываюсь даже от Active Record, но работаю с ним очень осторожно, практически не применяя магии и скрыв за слоем репозиториев.
                                  Стараюсь не использовать гемы, засоряющие глобальное пространство или сильно сорящие в ActiveController/ActiveRecord::Base. Они дают быстрый старт, но большое количество проблем в будущем. Как пример — karmi для elasticsearch. Работать с ним через модель поначалу удобно, но шаг в сторону (скажем маппинги сильно отличаются от схемы бд) — и ты получаешь массу проблем.
                                  Если сначала потратить немножко времени, и написать сервис, используя более низкоуровневый механизм того же karmi, то в дальнейшем все находится под контролем и времени написание функционала уже особо не занимает. Гораздо экономнее, чем потом дебажить и писать воркэраунды.

                                  Многие клиенты на эти практики реагируют довольно нервно. Чем менее привязан к rails community клиент, тем больше шансов, что он отнесется к ним позитивно.
                                    0
                                    > Работа с ассетами в Spring Boot напомнился времена голого JSP и сервлетов).
                                    Можно подробнее? Стало интересно в чем проблема.
                                      0
                                      В основном упреки касаются практически стокового thymeleaf.
                                      Неуклюжие layouts. Еще подключение css/jss (тут скорее отсутствие asset pipeline, он в принципе для Spring Boot имеется, но мне неясно его качество и статус). Сурово как то все. Если вы наведете на средства сделать лучше, буду рад и признателен.
                                      По поводу шаблонов — есть надежда, что jade спасет, но опять же неясно, насколько прямо он реализован именно для Spring Boot.

                                      Оффтоп — а по миграциям — flyway уж очень суров.
                                      Ни в одном веб-фреймворке я не видел миграций, сделанных хотя бы так же удобно, как в рельсах(
                                        +2
                                        Я пару лет назад изучил и написал веб-бухгалтерию простенькую на Asp.Net MVC 4, и там как мне кажется, тоже много взято из идеологии рельс, по крайней мере оно там очень похоже. Но сменил работу и уишел в хостмастера юникс систем. Но это в будущем дало мне сейчас большой плюс в понимании работы с рельсами теперь — пишу свою панель управления хостингом приложений.
                                        Пробовал еще Perl + Mojolicious, но там слишком много надо реализовывать из того, что в рельсах идет из коробки
                                          +1
                                          Да, Asp.Net MVC 1 — это по сути порт Rails 2.x под .NET
                                          Насколько далеко они разошлись сейчас я не в курсе, но в 2008-2010 годах был настоящий бум — фреймворк аля Rails писали на всех популярных языках :-)
                                            +1
                                            Только не очень понятно почему никто кроме рельсовиков не воспринимает AR нормально, видимо он нигде толком не получился?
                                              +2
                                              Про это ещё Фаулер писал в EAA Patterns писал… Если вкратце, то AR — это одновременно и паттерн и антипаттерн, так как совершенно внаглую нарушает SRP.
                                                –2
                                                Существует масса вещей которые в наглую нарушают христианство например. Конечно Фаулер молодец, да и вообще святой, с этим трудно спорить. Но есть десятки тысяч счастливых разработчиков использующих AR на успешных проектах.
                                                  0

                                                  А причём тут религия? Вы же сами написали, что AR нигде толком не получился. Я только добавил, что он by design не может толком получиться и неизбежно будет доставлять проблемы в нетривиальных случаях.

                                                    0
                                                    Это метафора — такой литературный прием.
                                                    Ну и AR получился в Rails, 99% задач решаются через AR.
                                                      0

                                                      Т.е. Вы с проблемами от использования AR не сталкивались? И никаких неудобств от того, что логика предметной области находится в моделях AR не испытывали?

                                                        0
                                                        Сталкивался, в детстве. Уже давно бизнес логика не хранится в моделях. Но статьи про «thin controllers fat models» продолжают выходить с завидной регулярностью — это саботаж!
                                                          0

                                                          По-моему важно понимать, что если модели предметной области(классы, содержащие бизнес-логику), у вас не наследуют ActiveRecord::Base, то у вас нет паттерна ActiveRecord в проекте. Возможно вы используете рельсовый AR в качестве странной реализации паттерна Repository, возможно ещё как-то… но только не в качестве ActiveRecord.

                                                            0
                                                            Наследуют, все что хранятся в базе, но это вовсе не означает, что эти классы должны отвечать за бизнес логику в обязательном порядке.
                                                              0
                                                              это вовсе не означает, что эти классы должны отвечать за бизнес логику в обязательном порядке.

                                                              Ну вообще-то это следует напрямую из определения паттерна. Просто у Вас своё оригинальное видение ActiveRecord… поэтому мы тут тёплое с мягким сравниваем.

                                                                0
                                                                Погодите, нигде не же сказано, что бизнес логика должна быть реализована через AR?
                                                                Объект AR не должен знать как снимать деньги со счета, но он должен знать как аз balance вычесть 10.
                                                                И нет в этом ничего оригинального, на AR возложены конкретные узкие обязанности.
                                                                  +1

                                                                  AR — это когда логика сохранения данных помещена в модель предметной области, в ту самую в которой бизнес логика. Тупо по определению:
                                                                  "An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."
                                                                  "Active Record uses the most obvious approach, putting data access logic in the domain object"

                                                                    0
                                                                    «An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.»
                                                                    Я не вижу тут диррективы: «все должно быть так и только так», это пример
                                                                    PaymentService
                                                                    def withdraw(user, amount)
                                                                    validate business logic here
                                                                    user.withdraw!(amount)
                                                                    end
                                                                    end
                                                                    PaymentService.withdraw(user, 10)
                                                                    Вот я не знаю точно user.withdraw!(amount) — domain logic? помоему не очень но это AR
                                                                    Логика доступа сохранена, не вижу противоречий

                                                                      +4
                                                                      Я не вижу тут диррективы: «все должно быть так и только так»

                                                                      Такой директивы нет ни у одного паттерна. Но если что-то не совсем так, то это уже не этот паттерн. Всё просто, в AR нет никаких Service, по сути AR — это и есть fat models. Всё остально — это не AR. Не усложняйте.

                                                                        0
                                                                        Не вижу никаких усложнений, одни упрощения.
                                                                        Я не предлагаю вмешивать в AR Services.
                                                                        AR занимается своими обязанностями. Все остальное занимается своим делом.
                                                                        Всем добра и Single Responsibility.
                                                                        У юзера есть метод withdraw, но на юзера нельзя возлагать обязанности соблюдения бизнес логики всей системы, это не его обязанности.
                                                                        Снять деньги у юзера — не обязанность юзера, а обязанность сервиса банка. Причем банк как сущность может вообще не иметь AR сущностей.
                                                                        И это не усложнение, это — напротив — упрощение, сегрегация интерфейсов проще, чем порождение франкенштейнов. Собственно и в реальном мире с реальной бизнес логикой пользователь не может снять деньги со своего счета непосредственно.
                                                                          0
                                                                          И это не усложнение, это — напротив — упрощение

                                                                          Это упрощение кода, но усложнение понятий. Паттерны хороши тем, что дают названия вместо длинных определений. Вместо того чтобы говорить "Каждый класс соответствует одной таблице в БД. Строка таблицы соответствует объекту класса. Логика работы с БД помещена в модель предметной области.", мы говорим одно название — ActiveRecord. И всем понятно, о чём это и чем это плохо в нетривиальных случаях. Когда Вы вводите свою интерпретацию понятия ActiveRecord вместо общепринятого определения, и пытаетесь строить свои выводы на ней, это выглядит очень странно.

                                                                            0
                                                                            Подождите
                                                                            В моем примере AR кладет в БД, и логика работы в БД там же. Но категорически нельзя Генератору светящихся лампочек просить AR что-то делать, но можно Генератор Светящихся Лампочек попросить Модель данных AR попросить что-то сделать.
                                                                            Вы же предлагаете всю предметную область положить в AR, как быть с сущностями сервисами, которые не хранят свои данные в AR а являются сервисами?
                                                                            Вот поэтому и получаются жирные модели, когда у нас юзер становится монстром делающим не свойственные ему вещи и отвечающим за не свойственные ему операции, никакой патерн не заставит и _не_заставляет_ меня это делать, и даже не рекомендует. Всему должна быть мера.
                                                                              0
                                                                              Вы же предлагаете всю предметную область положить в AR

                                                                              Я в этом треде вообще ничего не предлагаю. Я просто констатирую определение этого паттерна и прямые следствия из него.
                                                                              А то, что Вы по факту не используете паттерн Active Record — это даже хорошо. Путаница возникает из-за того, что Вы думаете, что Вы успешно и повсеместно применяете данный паттерн, хотя по факту отходите от него безумно далеко, и при этом пытаетесь других убедить, что 2+2=5.

                                                                                0
                                                                                Не понимаю почему вы сделали такой вывод.
                                                                                Добрая половина документов в проектах обычно AR классы. Но они делают свое AR-ное дело, абстрагируют меня от СУБД, хранят бизнес логику своего поведения. 2+2 все еще 4 для меня.
                                                                                0
                                                                                Вы же предлагаете всю предметную область положить в AR

                                                                                Рельсы «предлагают». Чуть менее, чем все кодогенераторы, примеры в гемах, примеры в литературе, в остальных интернетах и на презентациях предлагают держать бизнес-логику в модели или предполагают, что она лежит в модели.

                                                              0
                                                              А что Вы делаете, если два далеких друг от друга контроллера выполняют одинаковые действия с какой-то моделью?
                                                                0
                                                                Я не люблю когда контроллеры выполняют действия над моделями, если они сложнее чем CRUD. В сложном случае, это не работа контроллеров. Стащили у питонистов form_objects, есть сервисы, есть куча всяких чужих паттернов, мы же не в вакууме?
                                                                  0
                                                                  Показалось, значит.
                                                  +2
                                                  mvc 1/2/3 прошли мимо меня, но они всяко лучше asp.net webforms, которые, оспади прости, битрикс в мире дотнета, судя по тому «коду» что я видел и мое счастье, что я ЭТО не застал
                                                    0
                                                    Хаха, а я застал «краешком»… серьёзные проекты на WebForms я не делал, но там реально была жесть, он генерировал совершенно дикий HTML, а AJAX работал через UpdatePanel, т.е. тупо обновлял практически всю страницу… Так что да, ASP.NET MVC в сравнении с WebForms был крут уже с первой версии.
                                                0
                                                Мы намучавшись с thymeleaf в итоге ушли на простенький написанный одним человеком twig подобный шаблонизатор.
                                                Скрипты собираются с помощью Maven, настроили один раз и больше не трогаем.
                                                Ну в целом понятно о чем вы, соглашусь есть неудобные места.
                                              +3
                                              Такой подход не плох и безусловно имеет право на существование. Только фишка в том, что Rails разнообразно сопротивляется такому использованию (как запчасть). Поэтому это требует хорошей дисциплины от всей команды разработки и дополнительных усилий. Впрочем, на этом пути помогают такие проекты, как trailblazer.
                                              +2
                                              Я, как человек недавно познавший быстрое прототипирование Rails, в когнитивном диссонансе. Только недавно пришел к мысли о том, что вот оно — будущее (в сравнении с PHP). Конечно, я не занимался ничем крупным и толком не работал на Rails, я лишь где-то в начале пути, и понимаю, что эта статья не призыв к действию, но ладно бы это было только мнение автора, он то уже потратил не мало времени и знает о чем говорит. Более того, комментаторы что здесь, что к оригинальной статье, все поголовно соглашаются. И теперь, продолжая изучать Ruby, я мысленно просто буду ждать какого-то подвоха, который ждет меня прям здесь — за углом.
                                                +4
                                                Серебряной пули, как известно, нет. Критическое мышление это хорошо, нужно трезво оценивать плюсы и минусы инструментов. К сожалению, сообщество последователей DHH сильно догматично.
                                                  0
                                                  Я согласен. Но это я описал свою ситуацию, а не мнение о статье.

                                                  С одной стороны, когда отзываются о чем-то плохо, значит это что-то есть с чем сравнить. Потому что в моей ситуации, я сейчас не вижу ничего криминального, что описывает автор. И у меня еще больший диссонанс от того, что вроде бы автор работает долго с Rails и ему, возможно, просто уже он надоел, а возможно, что он попробовал что-то другое.

                                                  Сейчас я вижу это так: автору статьи надоели автомобили. Надо стоять в пробках и ездить только по дорогам с определенными правилами. Отсюда возникает мысль: или у автора в гараже стоит летающее авто и он так пытается сам себя убедить, что оно то лучше, или ему просто надоели машины и он собирается ходить пешком. Насколько я понял, летающие машины = elixir и scala по мнению автора?
                                                    +2
                                                    Я думаю, что дело в этом:

                                                    > Одной из моих первых задач было… добавить ссылку на что-то на какой-то странице. Мне потребовалось несколько дней, чтобы добавить эту глупую ссылку.

                                                    У меня те же самые мотивы «нестандартного применения» рельсов. С чем сравнить есть — я нативно из java. Поддался на то самое «быстрое прототипирование». В этом рельсы хороши, слов нет. Настоящие проблемы начинаются после N месяцев разработки и эксплуатации.
                                                    В принципе зная и обходя минусы, можно вполне успешно работать. К сожалению, у клиентов особого понимания такой подход не встречает. Поэтому проще отползти.
                                                      +2
                                                      > Одной из моих первых задач было… добавить ссылку на что-то на какой-то странице. Мне потребовалось несколько дней, чтобы добавить эту глупую ссылку

                                                      Мне кажется, что это мог быть, например, просто не очень качественный проект, с первых версий рельс, и с большим историческим наследованием, как например, виденная мною ЦРМ с 10+ летней историей разработки с нуля под компанию и тоннами кода, удаление которого может поломать всё в очень и очень неожиданном месте.
                                                      0
                                                      Бросьте это дело, это даже не какая-нибудь захудалая статистика, это просто мнение одного человека. Конечно, не каждый день публикуются статьи по руби, но всё же — просто не обращайте внимания. Программирование оно в целом уже вещь индивидуальная, каждый воспринимает по своему, а кто-то вовсе не воспринимает, а уж отдельный язык — тем более.
                                                        0
                                                        Я согласен. Но я уже написал, что обратил на эту статью внимание из-за комментариев. Посмотрите, несколько штук здесь, а на оригинальном сайте еще больше, в поддержку автора. Хотя, с другой стороны, вы правы насчет статистики, она бывает и вредна. Может это отписались 1% недовольных, остальные 99% довольных просто игнорируют, потому что не согласны.
                                                          0
                                                          Из практики моей работы инженером технической поддержки хостингов в несколько лет — могу с этим согласиться — те, кто доволен — могут привести новых клиентов, но жаловаться «ах вы козлы, у меня ничего не работает, почините быстро» они врядли будут,
                                                          А вот с теми, у кого не хватает понимания работы хостинга, например и «шаловливые ручки», и желание кому-то повыносить мозг «быстро сделайте шоб работало а то в суд подам», те звонят и жалуются, но и запоминаются в основном они.
                                                        +1
                                                        P.S. Для себя, пока что, сайт писал бы исключительно на руби. Просто по другому, см. https://habrahabr.ru/post/301532/#comment_9622742
                                                          +3
                                                          Насколько я понял из статьи (сам я никогда не использовал, ни Rails, ни Ruby, знаю только самые общие вещи о них, так что, все что я напишу ниже это выводы, сделанные исключительно из данной статьи), проблема в том, что большинство методов и компонентов Rails завязаны на некое глобальное состояние. Еще автор жалуется на засилье наследования. Все это, конечно же, приводит к слишком большой связности между сущностями. В результате это мешает использовать некоторые части Rails независимо. То есть, если используешь, то используешь все полностью. Как следствие, архитектура твоего приложения становится продолжением архитектуры Rails, которую автор считает крайне плохой. Если там действительно все на глобальном состоянии построено, то я с ним полностью соглашусь. Одна вот эта фраза чего стоит: «в Rails всё должно быть доступно везде, для вашего удобства.» — просто убило. Для маленьких проектов это может быть и удобно, но когда проект начнет расти, это будет боль. Ну и, поскольку Rails это главный фреймворк в мире Ruby, всем, кто пишет свои компоненты на Ruby, приходится делать их совместимыми с Rails. Плюс, помимо плохой архитектуры фреймворка, его основные разработчики еще и ведут себя довольно агрессивно, и всем пытаются доказать, что другая архитектура не нужна. Видимо, не хотят все переписывать. Вот это то, что я понял из статьи. В принципе краткое ее изложение получилось.
                                                            0
                                                            большинство методов и компонентов Rails завязаны на некое глобальное состояние. Еще автор жалуется на засилье наследования. Все это, конечно же, приводит к слишком большой связности между сущностями. В результате это мешает использовать некоторые части Rails независимо.
                                                            Мне кажется, что проблема в гемах. Автор, и люди в комментах, это немного затрагивают, намекая, что люди слишком сильно увлекаются ими. Возможно, я неправильно понял.
                                                              +1
                                                              Проблема гемов тоже есть, также как и проблема зависимостей. Сама рельса тянет за собой кучу гемов, плюс для любого проекта наверняка нужно будет добавить еще парочку (десятков) гемов, вот и выходит зависимости от огромного количества библиотек, у которых в свою очередь свои зависимости, которые могу конфликтовать с другими. И вот да тогда начинается настоящий ад.
                                                                +2
                                                                Проблема не в гемах, а в том, что гемы должны быть написаны с прицелом на Rails. Т.е. по-большому счёту гемы зависят от Rails. Именно это и не нравится автору. Он, как и многие другие программисты, хочет чтобы гемы были независимыми и простыми библиотеками.
                                                              +2
                                                              Я, как человек недавно познавший быстрое прототипирование Rails, в когнитивном диссонансе. Только недавно пришел к мысли о том, что вот оно — будущее (в сравнении с PHP).
                                                              Не волнуйтесь. У автора статьи в 2007 году были такие же мысли о Rails, что и у Вас. Да и у меня было такое же ощущение в 2008-м.
                                                              Просто у Rails есть свои границы применимости, за которыми вся его магия оборачивается против программиста. С накоплением опыта участвуешь во всё более сложных проектах и всё чаще натыкаешься на эти границы. Поэтому со временем эта борьба с фреймворком утомляет и хочется иметь инструмент простой и предсказуемый.
                                                              Но Rails в ближайшие годы никуда не денется. И на простых проектах Вы вполне можете оставаться в рамках Rails Way и не испытывать никаких неудобств. А для сложных — посмотрите сразу в сторону trailblazer.
                                                                0
                                                                Спасибо. Я особо не переживаю. Всегда хочется учиться чему-то новому, а в наши дни количество языков/фреймворков растет неутомимо быстро и каждый день появляется что-то новое, да не факт, что стоящее. И тут дело даже не в Rails, а в общей тенденции. За чем гнаться?
                                                                  0
                                                                  Хочется надеятся, что серьезные проекты вы получите, только став опытным разработчиком.
                                                                  А к тому времени будете уже и сами знать. Не парьтесь понапрасну.
                                                                    0
                                                                    Так в том и дело, что сейчас для меня Rails отдых/хобби, которое может перерасти в работу. В работе мне приходится использовать PHP.
                                                                    Хочется надеятся, что серьезные проекты вы получите, только став опытным разработчиком.
                                                                    Не совсем понял к чему это? К тому, чтобы сам себя не замучал костылями?
                                                                      +1
                                                                      В качестве хобби и работы на ближайшее время Rails вполне подойдёт. Если говорить о России, то в ближайшие 3-4 года Вы скорее найдёте работу именно c Rails, а не с «летающими машинами», как Вы выразились.
                                                                      Однако, основная мысль статьи в том, что не стоит идеализировать Rails. Он симпатично выглядит снаружи, но внутри никогда особо не блистал понятностью или удобством. К тому же фреймворк оброс кучей функционала, часть из которого весьма спорна, и стал медленно развиваться в плане действительно важных вещей… В чём-то он уже пытается догнать конкурентов, к примеру, наконец-то добавляя поддержку веб-сокетов.
                                                                      На тему самого Ruby тоже спохватились и пытаются угнаться за языками, на которые идёт массовый переход: Ruby 3x3, Concurrent Ruby
                                                            0
                                                            На самом деле очень странная статья. Автор буквально ругает те плюшки рельс за которые его очень сильно любят пытаясь сделать из него строгий фреймворк которым он сам по себе никогда не являлся и не собирался. А по высокой связанности это здравая мысль, тут уже каждый сам выбирает для себя.
                                                              +2
                                                              Эти плюшки хороши, когда Вам надо сделать блог за 10 минут. Но чем сложнее становится проект, тем больше сложности они в него добавляют.
                                                              Очень рекомендую всем, кто имеет дело с Rails, книгу «Rails Anti-Patterns». В ней описаны многие анти-паттерны, на которые в какой-то мере провоцирует сам Rails.
                                                              0
                                                              Продолжайте изучение инструмента и на этом этапе меньше слушайте подобных «особых мнений». Не стоит превращать инструмент в идеологию. Идеальная архитектура — это не решение задачи, к а один путей к ее решению, зачастую достаточно дорогой для компании и, в целом, очень субъективный.

                                                              Тут кто-то писал про Coldfusion, мол «фе». Пару лет назад я работал в прибыльной компании из штатов с 10М+ пользователей, добротной архитектурой приложений (не идеальной, но достаточно понятной для внесения изменений и поддержки меняющихся требований бизнеса), все на распоследних версиях фреймворков, в том числе Rails. И вот в один прекрасный момент нас купила фирма-конкурент, которая клонировала изначальную идею нашей фирмы (геймификация ритейла + персональные рекомендации), повела более грамотную маркетинговую политику, набрала больше инвестиций и выкупила нашу компанию (по сути покупался бренд и база пользователей). Весь наш чудесный код выкинули на помойку и заменили ужасным и кривущим кодом на Coldfusion (практически никто из нашей dev-команды не захотел работать с этим ужасом дальше и все уволились). Компания по прежнему процветает. Код по прежнему на Coldfusion. Делайте выводы, господа идеалисты. Рынку не нужна идеальная архитектура приложения, да никто про нее и не знает даже, кроме инженеров.
                                                                +2
                                                                Спасибо за мнение. Я и не собирался никуда уходить. Статья лишь подтолкнула посмотреть, а что там еще есть интересного в нашем мире. Например, открыл для себя elixir.
                                                                Весь наш чудесный код выкинули на помойку и заменили ужасным и кривущим кодом на Coldfusion
                                                                Какая жестокая, но реальная правда. Такой «коммерческий» подход я часто встречал в русских компаниях. Команда зарубежная?
                                                                  0
                                                                  > Статья лишь подтолкнула посмотреть, а что там еще есть интересного в нашем мире. Например, открыл для себя elixir.

                                                                  Это здорово, на самом деле, знать много подходов.

                                                                  > Команда зарубежная?

                                                                  Да, все это происходило в LA.
                                                                  0
                                                                  Если контора большая и есть ресурсы тратить несколько дней на вставку ссылки, почему бы и нет.
                                                                  Maintainability это одно из качеств проекта, и если его отсутствие можно решить в лоб, ковбоями, да флаг им в руки.
                                                                  Остальным же это экономит время.
                                                                    +1
                                                                    > Maintainability это одно из качеств проекта, и если его отсутствие можно решить в лоб, ковбоями, да флаг им в руки.

                                                                    Я рассмотрел крайний случай, обычно дела с поддерживаемостью обстоят намного лучше, рельсы как раз помогают с этим хотя бы на уровне «что где должно примерно лежать».
                                                                    +1

                                                                    "Компания по прежнему процветает. Код по прежнему на Coldfusion." — ситуация, хорошо знакомая онкологам.

                                                                    +7
                                                                    Занимаюсь Рельсами уже… эээ… тоже где-то лет 9. А до этого и на C писал и на Java, и даже на ассемблере доводилось.

                                                                    Как написали ниже, основная проблемы с рельсами начинаются после нескольких месяц разработки. И, на самом деле, многие проблемы возникают от того что кто-то плохо знает рельсы и попросту делает костыли, эти костыли обрастают своими костылями и т.д. Либо от того что заложил неправильную архитектуру. И дальше уже повезет или нет. Рано заметешь что не так, и есть время на рефакторинг — исправил и проблемы нету. Но чаще бывают, что проблемы живут неосознанными достаточно долгое время чтоб пустить корни, и так просто от них не избавиться, да и клиент со сроками подгоняет, на рефакторинг времени не остается.

                                                                    А вот тут параллельно решил React.js изучить. Redux'ы там всякие и т.п. Казалось бы вот оно «счастье» с точки зрения архитектуры. И что? Я форму логина делаю уже неделю. Простой логин по email и паролю. Перечитал уже тонну тутариалов. Просмотрел кучу примеров. Вот только для того чтоб понять примеры нужно прочитать еще тонну туториалов. И до сих пор кстати не доделал. Осталось сделать переход на новую страницу. Пытаюсь второй день понять откуда по правильному я должен вызывать это переход. Вы можете представить такую проблему в рельсах? Что там автор про простоту говорит? Что про модульность? Может где-то там и есть в рельсах лишняя связанность которая не дает автору жить и спокойно спать ночами, вот только разрабатывать на рельсах на порядок быстрее чем на других фрэймворках. Быстрее разрабатываешь, быстрее получаешь деньги. У тебя стало 100500 пользователь и рельсы не справляются? (хотя я лично поддерживал проект на рельсах с 10к запросами в минуту, и не сказал бы что это было очень сложно) Вот теперь время подумать и нанять разработчиков которые напишут тебе с нуля под высокую нагрузку хоть на хаскеле, избавившись от кучи костылей…

                                                                    Это вот мои немного сумбурные мысли
                                                                      +2
                                                                      Спасибо за мнение. Первое, что мне бросилось в глаза в rails-community — это перфекционизм. Я обратил внимание, что разработчики rails как никто другие любят делать красиво. Отсюда у меня сложилось мнение, что rails в первую очередь любят за удовольствие, которое он приносит. И такие комментарии как ваш только подкрепляют мое мнение.
                                                                      И что? Я форму логина делаю уже неделю. Простой логин по email и паролю.
                                                                      Как это знакомо! Иногда кажется, что подобные технологии просто навязывают
                                                                        +1
                                                                        Мне все же кажется react + redux это несколько edge и поэтому такая кривая входа, в дальнейшем будет проще (может уже и не в react-redux, а в чем то новом).
                                                                        А что для роутинга используете?
                                                                          0
                                                                          Да, я тоже думаю (надеюсь) что это просто технология еще не устоялась. Но после рельсов все очень сложно. На каждом шаге.

                                                                          > А что для роутинга используете?

                                                                          react-router пытюась использовать.
                                                                            0
                                                                            Сам до роутеров еще не дошел, рекомендовать не могу, но посмотрите, может лучше что-то специализированное?

                                                                            https://github.com/reactjs/react-router-redux
                                                                            https://github.com/acdlite/redux-router
                                                                              0
                                                                              Так эти библиотеки призваны работать в связке с react-router.

                                                                              А вот то что мне надо вроде как вот-тут обсуждается. https://github.com/reactjs/redux/issues/297
                                                                          +2
                                                                          Йо

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

                                                                          Сначала несколько общее замечание:
                                                                          React.js — это, все таки, буква V в паттерне MVC. То есть все остальные части (например, бизнес-логика) — она как бы и не должна быть проблемой реакта.

                                                                          А конкретный хороший рецепт типа из самых последних трендов — используйте redux-saga. Самое то для авторизации.

                                                                          Ну и последнее, в целом:
                                                                          Если вы хотите простоты и понятности, смотрите скорее в сторону Angular.js с его богатейшим API на все случаи жизни и огромной коллекцией пакетов.

                                                                          Если проводить аналогии между Ruby и Front-End JS, то, скорее:
                                                                          Angular.js == Ruby on Rails
                                                                          React.js + Redux == Sinatra (скорее, даже Padrino)

                                                                          Если вам нравится вариант, когда вы с нуля тщательно отбираете только нужные вам либы и сами ваяете архитектуру, которую вам надо — лучше брать React.js
                                                                          Если вам нравятся примеры типа "блогчат за 10 минут" — это к Angular.js
                                                                            0
                                                                            Спасибо за ссылку, посмотрю.

                                                                            А вот angular и прочие ember'ы как-то пробовал и сбежал от них нафик. По мне там никакого упрощения нету, только сложности лишние добавляет, и код еще более запутанный становится. Вот React мне сразу понравился своей идеей.
                                                                              0
                                                                              А не могли бы вы привести примеры больших приложений на связке React+[Some Flux like stuff].
                                                                              Сейчас в раздумьях по поводу миграции с Angular 1.3. Пока смотрим на Angular 2.0(+Typescript) и Ember.js.
                                                                                +1
                                                                                Ну, например:
                                                                                Facebook, Instagram и AirBnB использует React.js и React Native весьма активно.
                                                                                По заявлению инженера Facebook, у них больше 20 000 компонентов уже используется. Но исходники закрыты.

                                                                                Khan Academy использует реакт для большей части рендера. Код открыт:
                                                                                https://github.com/Khan/perseus

                                                                                Марафон использует реакт:
                                                                                https://github.com/mesosphere/marathon

                                                                                Насколько я знаю, Atom (текстовый редактор от Github) использует React для рендера, код открыт.

                                                                                Что же по поводу самой проблемы «Angular.js v2 vs Ember.js vs React.js» — так-то все хороши, тут подсказать не могу, самому все нравится. Смотрите куда хочется двигаться.
                                                                                  0
                                                                                  Интересует аналог Discourse, Taiga и тд. У марафона маловат UI :)
                                                                                  То есть фронт не для конечного потребителя, где обычно мало ресурсов и вьюх, а UI для администрирования серверов со сложной UI логикой и тд. Что нить типа 200+ actions с Flux и как это вообще живет и поддерживается :))
                                                                                    0
                                                                                    Ну, проблема в том, что если Discource и Taiga уже есть и здравствуют, то какой смысл писать их клоны? :)

                                                                                    А так на реакте дофига всего пишется. В гугл-трендах запрос react.js обогнал angular.js

                                                                                    Общий список: https://github.com/facebook/react/wiki/Sites-Using-React

                                                                                    Те, что конкретно мне нравятся:

                                                                                      0
                                                                                      Я не про клон. Пример — админка серверного приложения. 50+ ресурсов, вьюх и компонентов за сотню. В связке Angular 1.3 + ui-router + свой слой для REST живет отлично. И поддерживается достаточно легко. По сложности Jira или VisualStudio Online.

                                                                                      Просто хотел посмотреть как очень большое приложение живет от и до.

                                                                                      По sprintly: https://github.com/sprintly/sprintly-kanban/tree/master/app/actions вот тут получается 50+ файлов будет жить?
                                                                                        0
                                                                                        Ну я например писал онлайн-бухгалтерию на React.js + Backbone.js: http://imboss.ru/.
                                                                                        По размеру там в районе 1000 компонентов.
                                                                                        Но вот так, чтобы выложить вам ссылку на открытый код — боюсь, не знаю таких.

                                                                                        Про srpintly — вообще сами actions спорная инициатива, я бы не так сделал, но получается да, у них там и будет жить. Возможно по подпапкам еще разнесут, не знаю уж, на какой базе — каждому отдельно или будут группировать по смыслу.
                                                                                          0
                                                                                          Спасибо за ответы :)
                                                                                            0
                                                                                            Нашел:) Вдруг кто наткнется на вопрос.
                                                                                            WP Calypso
                                                                                            В целом близко к тому, что хотелось посмотреть и организация проекта норм.
                                                                                0
                                                                                Вот еще хорошую ссылку хочется подкинуть: https://github.com/mxstbr/react-boilerplate/

                                                                                Это типа boilerplate для Universal App на базе React.js + Redux + Reselect.
                                                                                Примечателен тем, что все используемые библиотеки типа bleeding edge.

                                                                                Вам будет полезно посмотреть, как делается авторизация с unidirectional data flow.
                                                                                +1

                                                                                Если вам нравятся Рельсы, не обязательно с них уходить. Просто следует помнить, что они заточены под быстрое создание несложных приложений. Более сложные приложения на них писать можно, но нужно добавлять к Rails другие инструменты, которые будут помогать масштабироваться. Например, Trailblazer.
                                                                                См. https://habrahabr.ru/post/301532/#comment_9623484

                                                                                  +3
                                                                                  Находясь в подобной ситуации могу вас заверить, что изучение руби вам не повредит. Сам язык очень хороший, автор статьи даже указывает на то, что будет саппортить некоторые библиотеки на Руби.
                                                                                  Из личного опыта — написание парсера на руби было очень веселым и быстрым. Книги по руби читаются легко. Все, что не касается напрямую Rails — очень удобно и просто.
                                                                                  Rails так-же имеет смысл установить, по играться, развить своё восприятие данного фрэймворка. Очень многое вам покажется правильным и вы решите использовать подобные схемы решения задач на PHP.
                                                                                  Используйте Руби в качестве трамплина для вашего развития как программиста в целом.
                                                                                  –3
                                                                                  Создается впечатление что рельсы ждет судьба ColdFusion. Тоже в свое время выглядел круто.
                                                                                    +5
                                                                                    Комментарии к статье от Yehuda Katz

                                                                                    https://twitter.com/wycats/status/734991937862795264
                                                                                    https://twitter.com/wycats/status/734992848987258880
                                                                                    https://twitter.com/wycats/status/734993723029868544
                                                                                    +13

                                                                                    Статья просто потрясная! Очень коррелирует с моими мыслями по поводу Rails.


                                                                                    Показушная "простота" работает хорошо только до тех пор, пока не надо чуток выйти за рамки. В тот момент когда это происходит, совершенно теряется понимание "что делать", код превращается в макароны из грязных хаков и теряет полностью свою простоту и привлекательность.
                                                                                    ЗА адептами Рельсов очень интересно наблюдать тогда, когда они пытаются написать что-то на… Ruby! ActiveSupport — это по сути новый язык программирования.
                                                                                    По моим ощущениям, создание rails приложения — это сборка камней/гемов — как в лего, только вся сложность начинается в тот момент, когда эти кубики надо собрать вместе. Когда гем подключается одной строчкой и делает кучу вещей — я его просто боюсь! А такие "батарейки" — везде.
                                                                                    Самое главное, API Рельсов не очевидное, не однозначное, и разработчика на Рельсах по сути ничего не заставляет его как то изучать и понимать. Можно создать десяток сайтов на Рельсах и так и не узнать, что скрывается за волшебным словом Rack, и чем middleware гемы отличаются от "не middleware"!
                                                                                    Ничего не имею против ActiveRecord, если чувствовать пределы, его использовать очень удобно. Но когда можно забрать модель из формы через :params и сохранить как есть одной строчкой как в статье — это рождает миллионы вопросов на SO — "Почему сохраняет пустую модель/не сохраняет ничего" которые просто нереально чинить — там всего одна строка!)


                                                                                    Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как? Если многим это удобно, то писать RFC к самому Руби? 10.years.ago — возможно это должно быть в стандартной библиотеке?


                                                                                    А что касается проблем ООП — мне кажется Руби — не показатель плохости такой парадигмы. Monkey patching и вся рефлексия — это по сути нарушение инкапсуляции. И это то, что самое крутое в руби, с его method_missing, символами и открытиями классов в любом месте вашего кода. А ведь именно на этом строится такая "классная" ActiveRecord, роутинг, ActiveSupport. Оставь в Рельсах "чистое" ООП — и от всей прелести Релься ничего не останется.

                                                                                      0
                                                                                      Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как?
                                                                                      Нет ничего плохого в отдельных модулях для подобных методов, не обязательно их добавлять к базовым классам. По началу это даёт определённый вау-эффект, но не даёт реальных преимуществ, а вот весёлый дебаг временами обеспечивает.
                                                                                      +15

                                                                                      Чел перерос технологию и закономерно направился в функциональное программирование. Все с порядке вещей.

                                                                                        +1
                                                                                        Спасибо за перевод. Интересная статья. Никогда не программировал на Ruby, было очень интересно сложить хотя бы такое поверхностное представление о достоинствах и недостатках Rails. Автора я понимаю, сам не люблю ограничивать себя набором готовых функций, особенно, если они вызывают проблемы с не интуитивным решением (виной тому моя криворукость или желание выйти за рамки — решайте сами).

                                                                                        Я так понял, главная проблема автора не столько в самом Rails, сколько в сообществе. Поскольку всё-таки можно сделать проект по всем правилам, создать обёртки вокруг функционала Rails, нагородить собственных классов и организовать всё так, чтобы проект был масштабируемым. Но любители Rails просто привыкли пользоваться готовыми функциями и мириться с возникающими проблемами. Конечно, с такой разницей во взглядах работать с этими людьми — одно мучение.

                                                                                        "… дает вам ложное чувство простоты, в то время как то, что происходит на самом деле заключается в том, что сложность спрятана за удобными интерфейсами"

                                                                                        Эта фраза актуальна вообще для всего, и не только в компьютерном мире :)
                                                                                          0
                                                                                          > Поскольку всё-таки можно сделать проект по всем правилам, создать обёртки вокруг функционала Rails, нагородить собственных классов и организовать всё так, чтобы проект был масштабируемым. Но любители Rails просто привыкли пользоваться готовыми функциями и мириться с возникающими проблемами. Конечно, с такой разницей во взглядах работать с этими людьми — одно мучение.

                                                                                          Точные у вас формулировки)
                                                                                          Можно. И да, так и есть, мучение, борьба Дон Кихота с ветряными мельницами.
                                                                                            0
                                                                                            Извините, ничего конкретнее написать не мог. Но поскольку прочитал статью с интересом (пусть и отнесясь к ней, как к поучительной истории из жизни), решил выразить переводчику благодарность, отписавшись под ней :)

                                                                                            «Борьба с ветряными мельницами», кстати, очень интересное занятие, сравнимое с поиском сокровищ по пиратской карте.
                                                                                            0
                                                                                            Спасибо за отзыв :-)
                                                                                            Я так понял, главная проблема автора не столько в самом Rails, сколько в сообществе.
                                                                                            Автор хочет привлечь внимание сообщества к тому, что есть жизнь за пределами Rails. Как на Ruby, так и на других языках. В частности он является автором более чем десятка полезных гемов для Ruby.
                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                            +1
                                                                                            А что мешает теперь? Ведь раз вы все себе под задачу выбрали, то кто после статьи вам мешает так же хорошо ваш проект реализовать?

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

                                                                                            В общем, «старый конь», пока он решает задачи, почему бы и не поработал? Тем более что выбирать сегодня инструмент, которые закроет все проблемы проекта на долгие годы — это нереально, и в чем-то безответственно. Даже банальный движок форума можно писать на php+mysql (и поиметь в будущем более-менее понятные проблемы — но «потом»), а можно на oracle+хранимые процедуры+веб-приблуды от уважаемого Oracle — будет круто до небес, никто никогда себе это не поднимет (стек сильно не массовый), и проект не взлетит, поддержка станет до небес дорогой, и будет вопрос «а зачем».
                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                0
                                                                                                Если у вас 1000 активных пользователей, то вам придётся озаботиться кешированием в любом случае.
                                                                                                  0
                                                                                                  По-моему, вы доросли до микрофреймворков. Например, я сейчас на python использую flask + peewee + pyjade + webassets (css сразу в sass, html сразу в jade), хочу прикрутить marshmallow для работы с json и angularjs, а виджеты angular'a делать автоматом с помощью flask-triangle… будут нужны сокеты или асинхронные запросы — просто добавить.
                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    0
                                                                                                    Это ещё бабушка на двое сказала, что у проекта будет 1000+ пользователей онлайн.
                                                                                                    Если так и будет (дай-то Бог каждому проекту) — то просто кидай в него железом и всё, а потом перепишешь на чём-то более высокопроизводительном (если это вообще нужно будет к тому моменту). Большенство проектов не взлетит так и так и смысла делать всё круто с самого начало — нуль ))
                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                        0
                                                                                                        В людом случае, рельсы хоть и не самый высокопроизводительное решение (GIL и всё такое) в конечно счёте все решит выстроенная архитектура, имхо. Можно разбить приложение на части (микросервисы) и самые медленные переписать на чём-то другом.
                                                                                                        А вообще, как мне кажется, чем дальше в сторону хайлоада, тем больше общих решений будет у всех языков и фреймворков — кэширование, низкоуровневое ковыряние и т.д.
                                                                                                      +1
                                                                                                      Начали и начали. От ещё одного проекта на Rails никому хуже не станет )))
                                                                                                      А на будущее посмотрите ещё и в сторону Elixir+Phoenix. Конфет много не бывает xD
                                                                                                        +1
                                                                                                        А там и вовсе в сторону чистого Erlang можно глянуть, ну и в качестве веб-фреймворков «Chicago Boss» или «N2O».
                                                                                                        Красивейший язык, в самом деле.
                                                                                                        За один синтаксис в стиле пролога можно уже простить многое.

                                                                                                        Хотя, непонятно, зачем я это пишу — любой человек, изучающий эликсир, как минимум, погуглит, что такое Erlang ;)
                                                                                                          +1
                                                                                                          А там и вовсе в сторону чистого Erlang можно глянуть

                                                                                                          глянуть — и обратно, к pipe operator, макросам, ecto и прочей прелести

                                                                                                            +1
                                                                                                            /me Поднимает руки
                                                                                                            Извините, спорить не буду. Мне нравится и elixir, и erlang. И, кроме того, я искренне считаю, что изучение erlang как минимум не повредит, а как максимум сильно расширит горизонты и возможности изучающего.
                                                                                                              0
                                                                                                              А что бы Вы все-таки порекомендовали предпочесть разработчику, переходящему с Python/Django? Мне нравится Python своей четкостью и гибкостью, и Django своим порядком и ОО стилем. В Ruby и Rails я усмотрел какой-то хаос, оттого и предпочел Python/Django. Что будет ближе в таком случае?
                                                                                                                +2
                                                                                                                Эм. Сложно что-то подсказать при такой постановке задачи. Разработчик переходит с Python/Django — а куда? :)

                                                                                                                Вообще, я так понял из ваших комментариев ниже, вы уже много лет в вебе, поэтому первое что я посоветую — серьезно задумайтесь о смене фокуса. Неужели вам совсем неинтересны, например, IoT, VR? С вашим опытом на них реально найти вакансию джуниора как минимум, а в этих областях даже джуниоры получают вполне достойную плату, не меньше чем senior в вебе. Ну и кроме того, часто в этих проектах нужны как минимум веб-странички, а то и полноценные приложения, написанные на базе Electron.

                                                                                                                По поводу же смены технологии именно для веба… Настоятельно рекомендую посмотреть и попробовать функциональный язык вроде Erlang|Closure|Haskell, крайне освежает. Тут нужно заметить, что перечисленные языки — они, вообще-то, очень сильно разные, с разной концепцией, и лучше посмотреть каждый.
                                                                                                                Возможно, вы и не перейдете на них, но очень много полезного для себя найдете.

                                                                                                                Не бойтесь тратить время на какой-нибудь Erlang, работы конкретно под функциональщину хватает: https://functionaljobs.com/.

                                                                                                                Еще из неплохих вариантов в вебе я бы посоветовал Go и JS. Первый предлагает большую производительность и очень крутой параллелизм, второй мультипарадигменный, с возможностью писать и в ООП и функциональном стиле по желанию пользователя. И там и там есть работа, есть живая экосистема с огромным количеством библиотек.

                                                                                                                Ну и чисто для вдохновения и расширения горизонта, хотелось бы посоветовать глянуть на вот эти два языка:
                                                                                                                • Фунциональщина под веб, пока что очень новый язык, использовать осторожно, но заложенные концепции просто офигенны: http://elm-lang.org/
                                                                                                                • Настоящее ООП в стиле SmallTalk. Как и в Ruby, все объект. После знакомства с этим языком вам динамичный руби с открытыми классами (вы еще называете это хаотичным) покажется заскорузлым монстром, на котором нельзя толком метапрограмминг писать. К сожалению, из-за своей динамической природы этот язык довольно медленный, так что годится скорее для изучения в академических целях, писать на нем реальные программы я бы не стал. Но для расширения сознания, получения нового опыта и оттопыривания чакр крайне рекомендую взглянуть.
                                                                                                                  0
                                                                                                                  Упс, забыл ссылку для второго языка: IO
                                                                                                                    +1
                                                                                                                    Спасибо!
                                                                                                                    Вопрос не в деньгах и вакансиях, а в продуктивности использования того или иного языка. Меня в основном интересует веб и сетевые приложения.

                                                                                                                    Вы предлогаете три разных языка: Erlang|Closure|Haskell — я них сейчас в основном и смотрю, и еще Scheme, Comron Lisp и Elixir тоже привлекают внимание. Дело в том, что мне нужно решать реальные задачи, и хотелось бы начинать сразу с практичного и мощного языка. Среди прочих равных выбрал бы тот, что можно компилировать в JS. А проблема в том, что я не могу среди них выбирать, так как совершенно не разбираюсь в ФП. Когда выбирал между Python и Ruby — было гораздо проще, так как я знал, что именно меня не устраивает в других императивных языках с поддержкой ООП: строгая типизация, негибкие списки параметров функций, отсутствие множественного наследования, отсутствие хорошей поддержки метапрограммиравания, нечитабельность или громоздкость языка, непоследовательный синтаксис.

                                                                                                                    Теперь же я просто не знаю, как выбирать. Стоит ли промянять мощные макросы лисп-подобных языков на декларативность полностью функциональных языков? Не будет ли мешать статическая типизация так же как в ООП? Нужна ли мультипарадигменность и поддержка ООП, и какую проблему они решают? И т.д.
                                                                                                                      +1
                                                                                                                      А на Nim не смотрели? Вроде и компиляция в JS, и ФП есть, и мощный, даже серия статей здесь была про то, чем он хорош.
                                                                                                                      Мне даже интересно потом Ваше мнение будет…
                                                                                                                        0
                                                                                                                        Не могу ничего про него сказать кроме того, что он меня не привлекает, разве что кажется любопытным. На вид он кажется больше объектно-ориентированным, чем функциональным. А то, что там есть поддержка ФП — так это и в Python есть, и в Ruby, и в JS. Только эта поддержка весьма слабая.

                                                                                                                        Меня лично сейчас интересует прежде всего ФП в чистом виде, а также его сочетание с метапрограммированием.
                                                                                                                          +1

                                                                                                                          Nim логичнее сравнивать с Go, Rust, Crystal.
                                                                                                                          Язык интересный, но стабильной версии пока нет, да и библиотек пока тоже немного. Причём ощущение, что разработчики слегка подзабили в этом году… После выхода версии 0.13 уже 5 месяцев никаких новостей от них не слышно. Коммиты есть, но активность в разы меньше, чем в прошлом году.

                                                                                                                            0
                                                                                                                            Знаю, что platoff сравнивал его с Go и Rust (не в пользу последних), других статей пока не встречал. Столько он на него надежд возлагал. Интересно было бы узнать его впечатления после почти года знакомства.
                                                                                                                              0
                                                                                                                              почему возлагал? все прекрасно — вот первая ласточка от наших ребят — обернули Unreal Engine 4 — и игрушку пишут: https://github.com/pragmagic/nimue4, но это, как говорится только начало, на подходе еще сервер сайд и веб/десктоп приложения на Nim
                                                                                                                                0
                                                                                                                                Здорово! А игрушка — это для развития своих навыков?
                                                                                                                                  0

                                                                                                                                  Почему возлгал то? На офф.сайт зайдите, там последняя новость в январе была. По-моему, это маркетинговая недоработка… мало что-то делать, надо не забывать об этом писать.

                                                                                                                            +1

                                                                                                                            Вообще для всех кто выбирает язык для веб-разработки, я бы посоветовал такой алгоритм:


                                                                                                                            1. определяете наиболее популярный веб-фреймворк
                                                                                                                            2. ищете актуальную книгу "Programming НазваниеФреймворка" или "Web Development with НазваниеФреймворка" или "Web Development with НазваниеЯзыка"
                                                                                                                            3. Бегло читаете https://learnxinyminutes.com/ по языку, а затем найденную книгу
                                                                                                                            4. По результатам прочтения книг делаете осознанный выбор что вам ближе
                                                                                                                            5. Изучаете сам язык и вдумчиво перечитываете понравившуюся книгу
                                                                                                          +1
                                                                                                          Вот кстати, про вебсокеты на 5х рельсах — я пытался осилить официальный гайд с этим примером чатика, но так и не осилил — нет ли у Вас желания по горячим следам написать статью, думаю, многие бы оценили
                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                            +2
                                                                                                            А что не так с Django?
                                                                                                              +1
                                                                                                              С Django в принципе много чего не так, но применительно к задаче автора комментария думаю ключевое это отсутствие вебсокетов в 2016 году.
                                                                                                                0
                                                                                                                Ну, вебсокеты — они ж не всем нужны (игры и чаты — там да). А что именно Вас не устраивает в Django? (не для разжигания бесплодных споров, но информации для)
                                                                                                                  0

                                                                                                                  А как же оповещения о новых комментариях и прочих обновлениях на всех социально-ориентированных сайтах? На хабре, вон, вручную кнопку «обновить» нажимать надо. А в том же гитхабе новые комменты в ленте сами появляются.

                                                                                                                    0
                                                                                                                    Пожалуй, соглашусь с Вами, что это удобно, и уже назрело.
                                                                                                                    +1
                                                                                                                    Это вопрос для целый статьи :) Если очень кратко из последнего наболевшего: очень не нравиться «тупая» орм, тяжелые и непредсказуемые FormSet, нарушение одного из важных принципов дзена питона «явное лучше чем не явное».

                                                                                                                    Я понимаю что скорее всего это вопрос не столько к Django сколько к его области применимости. Но дело в том что начиная долгоживущий проект я вряд ли могу предсказать как он будет развиваться и как скоро мы упремся в границы Django-песочницы. И я не готов рисковать своим временем и деньгами выбирая столь ограниченный инструмент для долго живущих проектов. Если дело касается классического контент сайта (лендинга, страницы компании, какого-нибудь блога, вот этого всего) то к Django вопросов нет, отрабатывает на все деньги. Просто я такими проектами не занимаюсь.
                                                                                                                      0
                                                                                                                      Спасибо! А что используете в качестве «тяжёлой артиллерии» для догло живущих проектов? Ну, или, что стоит из нового рассматривать?
                                                                                                                        0
                                                                                                                        Как раз то "тяжелой артиллерии" стараемся избегать в последнее время, предпочитая легкие компоненты со слабой связанностью. Сейчас в основном строим на базе tornado, т.к. активно используем вебсокеты, и планируем переход на асинхронную работу с бд и чистый sql. До этого вполне успешно использовали Flask. Когда кодовая база бизнес логики гораздо больше чем непосредственно веба преимущества Django совсем не очевидны, а гибкость Flask решает. Захотели, подтянули монго, не понравилось, поменяли на sqlalchemy.

                                                                                                                        Так же смотрим за рамки питона, интересны Java Spark или, чем черт не шутит Clojure Luminus ))
                                                                                                                          0
                                                                                                                          Спасибо за развернутый ответ!
                                                                                                                            0
                                                                                                                            Посмотрите на Java Rapidoid, похож на Spark но еще более минималистичен.
                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                      0
                                                                                                                      Спасибо! Надо глянуть django-websocket-request.
                                                                                                                    +5

                                                                                                                    Продолжайте использовать Rails. Просто помните, что одних Rails не достаточно. Точнее, недостаточно трёх букв MVC, которые есть в них.


                                                                                                                    Пока у вас приложение маленькое (5-10 моделек) и с не очень большой логикой, всё будет окей. Когда число моделей перевалит за 50, а просто список функциональности перестанет помещаться в голове одного человека (а ещё помножьте на скорость разработки) — вы запутаетесь и будете погребены под приложением.


                                                                                                                    Решения есть, их много, но, к сожалению, ни одно из них пока не стало стандартом. Посмотрите на Trailblazer (мы его используем) — он добавляет новых уровней абстракции и этим снимает нагрузку с существующих букв MVC. Посмотрите, какие проблемы, решает этот инструмент — если они вас не волнуют, то вам ещё рано. Я же когда читал книжку по нему, плакал над каждой, потому что мы страдали просто от всех: к примеру — у нас было 500+ строк коллбэков в некоторых основных моделях, например.

                                                                                                                      0
                                                                                                                      Про коня в контексте данной статьи и комментариев выше. Просто ассоциация, поскольку на Ruby никогда не писал, но с описанными проблемами сталкивался в нескольких других «местах». Так вот, полностью эта пословица звучит так: «Старый конь борозды не испортит, но и глубоко не вспашет». Мне кажется, что это стоит помнить, выбирая навороченные «коробочные» фрэймворки Rails или Django, потому что иногда лучше собрать свою «коробочку», как это делают во Flask.
                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        +4
                                                                                                                        Многие из перечисленных здесь недостатков характерны для Yii/Yii2
                                                                                                                          +1
                                                                                                                          Насколько я могу судить, Yii немало и концепций позаимствовал из Rails, и задачи аналогичные решает в той же нише. Итог, как говорится, предсказуем.
                                                                                                                          После нескольких лет работы с Yii, на проекте сложнее среднее много усилий начинает уходить на борьбу с «удобствами» ActiveRecord, которую нельзя выкинуть из приложения и нагромождения собственных абстракций чтобы разбавить изкоробочную связанность компонентов фрейворка.
                                                                                                                          И да, начинаешь мечтать о DataMapper =)
                                                                                                                            +1
                                                                                                                            Да, совершенно согласен. Сам сталкиваюсь с этими же проблемами. Пытаюсь решать с помощью паттерна «Репозиторий» поверх ActiveRecord
                                                                                                                          +1
                                                                                                                          >DataMapper в конечном счете был лучшим ORM, чем ActiveRecord в 2008-9.

                                                                                                                          тут и кроется отличие профессиональных программистов от веселых хипсто-хакеров. Датамаппер никогда не работал. Я сделал один проект на этом кошмаре и слава богу он разорился и закрылся до того, как кто-то начал его поддерживать.

                                                                                                                          Рельсы в некоторых вопросах огорчают, так что поменьше гемов пожалуйста, их итак слишком много.
                                                                                                                            +4
                                                                                                                            Без «веселых хипсто-хакеров» профессиональные программисты до сих пор бы писали на COBOL.
                                                                                                                              +1
                                                                                                                              это опять же миф. Я бы никак не назвал DHH хипстером. Талантливый профессионал с хорошим вкусом и четким пониманием того, что нужно, а что не существенно.
                                                                                                                              +2

                                                                                                                              Ну не знаю, я в 2014 работал в проекте с Datamapper. И оно вполне себе работало, даже несмотря на отсутствие поддержки разработчиком. Так или иначе, ползать по его коду было всяко приятнее, чем по AR.

                                                                                                                                +1

                                                                                                                                ActiveRecord в 2008-м (2-е рельсы?) и ActiveRecord в 2016-м (5.0) — это две большие разницы.


                                                                                                                                В 2.х ActiveRecord был ужасен, в 4.х он уже был хорош (в первую очередь благодаря arel'у). И все 4-е рельсы он продолжал сильно перепиливаться (помнится, один мой pull request пришлось сильно переделывать с 4.1 на 4.2).

                                                                                                                                  0
                                                                                                                                  ужасен — это не совсем то слово, которое отражает реальность.

                                                                                                                                  Читать один файл на 3 экрана гораздо проще, чем 10 файлов на пол-экрана каждый.

                                                                                                                                  Простое распиливание кода на куски, которые вроде как должны быть в разных файлах по сути только ухудшает читаемость и не дает из коробки расширяемость кода.
                                                                                                                                    0
                                                                                                                                    Ох, не напоминайте мне про Arel. Надо было мне как-то раз его подружить с PG-функциями без скобок, типа current_date.
                                                                                                                                    Для тех, кто не знает, у Arel есть возможность вызывать SQL-функции, но только со скобками
                                                                                                                                    Account.where{created_at == :now.func()} # работает
                                                                                                                                    Account.where{created_at == :current_date.func()} # не работает
                                                                                                                                    

                                                                                                                                    В общем, пока я воркэраунд писал, достаточно ознакомился с его исходниками. Мягко говоря, там реальный треш. Если не согласны, попробуйте решить вышеописанную задачу. У меня на тот момент была версия arel-4.0.2.
                                                                                                                                      +1
                                                                                                                                      А зачем тут arel?

                                                                                                                                      Account.where('created_at::date = current_date')
                                                                                                                                      
                                                                                                                                        0
                                                                                                                                        Ахах, ну видимо придётся контекст задачи описывать…
                                                                                                                                        Нужно было предоставить пользователю возможность создавать сегменты по определённым моделям. Т.е. пользователь накидывает критерии в интерфейсе, а мы по этим критериям с помощью Arel генерируем SQL-запрос. Естественно давать пользователю вводить raw SQL в планы не входило. Переписывать без Arel было бы долго, потому что для заказчика это выглядило просто «а давайте добавим ещё 1 тип критериев в форму». При этом требования к скорости результирующего запроса были очень высокими, т.е. обернуть current_date в SQL-функцию тоже не прокатывало.
                                                                                                                                        +1

                                                                                                                                        В вашем случае, может, не стоило тогда даже и рассматривать current_date как функцию?


                                                                                                                                        Arel — это, ИМХО, вещь не для прикладных разработчиков, а для разработчиков ActiveRecord'а и прочих вещей, напрямую общающихся с базой. В его исходный код не заглядывал, но простым он точно не будет, ведь его задача — генерить разный SQL для разных БД с их особенностями. Например, oracle_enhanced адаптер вместе с последним arel'ом научились генерить разные SQLи типа SELECT для 11-го и 12-го Ораклов.


                                                                                                                                        Но ваша правда, даже документации толковой к нему нет, а чем хардкорнее вещь, тем она нужнее.

                                                                                                                                          0
                                                                                                                                          Я чуть выше описал зачем это было нужно. Именно как построитель запросов он и использовался, т.е. по самому прямому назначению.

                                                                                                                                          не стоило тогда даже и рассматривать current_date как функцию?
                                                                                                                                          Как не рассматривай, а как-то надо было её запихнуть в результирующий SQL и обойдясь при этом без raw SQL. Реальнее оказалось запихнуть как функцию )))
                                                                                                                                          +2
                                                                                                                                          потому что они все как писали под мускль без индексов, так и продолжают под него писать.
                                                                                                                                      –1
                                                                                                                                      Автор использует вполне ожидаемые аргументы. Active Record заменить на DataMapper. Но насколько знаю, по производительности один другому не проигрывает. Это просто вопрос вкуса
                                                                                                                                        +3
                                                                                                                                        Местами ловил себя на мысли что читаю про Django. Похоже это болезнь всех мега фреймворков…
                                                                                                                                          +1
                                                                                                                                          Что насчет Symfony2?
                                                                                                                                            0
                                                                                                                                            Не знаю, не приходилось использовать на практике, если с ним все хорошо то я за него рад ))
                                                                                                                                              0
                                                                                                                                              Там в основном споры об архитектурных решениях в Doctrine2 и версионность пыха для Symfony3
                                                                                                                                                0
                                                                                                                                                Symfony2 (и 3), ИМХО, противоположность рельсам. Мало чего работает по одной команде из коробки, что-то приходится делать руками, что-то докручивать, донастраивать. В общем, полная противоположность принципу convention over configuration. Но это окупается в крупных проектах, проще дается построение правильной архитектуры, легко выкинуть и заменить не устраивающий модуль хоть из ядра фреймворка — огромная гибкость. И конечно за это приходиться платить сложностью освоения и скоростью начальной разработки, в итоге для небольших проектов не особо оправдано выбирать symfony.
                                                                                                                                                0
                                                                                                                                                Какие из описанных проблем Вы наблюдаете в Django?
                                                                                                                                                  +1
                                                                                                                                                  Большое количество «магии» (Explicit is better than implicit явно не про него). Перегруженность основных компонентов, как из коробки, так и базовых батареек (при этом, что удивительно, они откровенно не дотягивают до аналогов из параллельных вселенных). Сильная связанность. Тотальная привязка к ORM.
                                                                                                                                                  Я не хейтер Django, я работаю с ним много лет, и до сих пор поддерживаю на нем проекты, но это крайне не гибкий инструмент. И на долгоживущих проектах с не полностью определенным фичелистом я его не использую.
                                                                                                                                                    0
                                                                                                                                                    Я что-то не нахожу в статье ничего про магию.
                                                                                                                                                    По поводу перегруженности — субъективно несогласен. Постоянно чего-то не хватает, и со временем функционал расширяют и улучшают, что радует. Наверное, это зависит от задач.
                                                                                                                                                    Не могу понять, где там тотальная привязка к ORM. Мало того, все компоненты легко расширяемы и заменяемы.
                                                                                                                                                    О гибкости — это вообще странно слышать. Огромная структура классов дает возможность переопределить почти все, что угодно. Только с админкой раньше было очень плохо, она как буд-то посторонним человеком делалась. Но и ее в последнее время заметно улучшили.
                                                                                                                                                    Единственный реальный минус — это сложность. Изменить можно почти любой аспект поведения, но для этого может понадобиться очень серьезное изучение всех потрохов. Чтобы эффективно работать с Django на любых сложных проектах, надо быть настоящим гуру, а не просто юзером фреймворка.
                                                                                                                                                    Похоже, невозможно одновременно достичь функциональности, гибкости и простоты. Чем-то одним надо пожертвовать. Хотелось бы, чтобы это было не так.
                                                                                                                                                      +2
                                                                                                                                                      Сложность за простыми интерфейсами это всегда магия, в Django с этим еще хуже, так как интерфейсы заменили соглашениями.
                                                                                                                                                      Про перегруженность я так сразу и сказал, куча невнятных мелочей есть, а нормальный явный left outer join или темплейт таг добавляющий класс к форме сделать уже который год не могут.
                                                                                                                                                      Если из Django выкинуть орм то останется уродливый парсинг урлов, половина форм и cbv и тормозной шаблонизатор. А админка, единственное в чем Django на голову превосходит аналоги, превратиться в тыкву. Зачем мне тогда вообще тянуть в проект Django если для всего этого есть более внятные инструменты?

                                                                                                                                                      Django гибкий на столько на сколько любой другой открытый проект. Понятно что при нужде все можно допилить, докостылить и т.д., исходный код открыт, гит в руки, «пилите Шура, пилите»… только Вы совершенно правильно сказали это требует серьзный уровень знания потрохов, потому что связанность высокая, интерфейсы магические и как только ты начинаете что то модифицировать под себя, в другом, неожиданном, месте что то начинает отваливаться. Зачем мне все это? Я выберу более подходящий инструмент, благо выбор есть.
                                                                                                                                                        0
                                                                                                                                                        Не-не, Вы явно не поняли мою мысль… В Джанго функционал очень грамотно разбрит по методам классов. Вас не устраивает какой-то класс — вы его наследуете, переопределяете какой-то метод — и все. Это не то же самое, что форкнуть и пилить под свои нужды, и даже не манки-патчи. Это грамотная разработка с использованием всей мощи языка.

                                                                                                                                                        Я не хочу сказать что Джанга идеальна. Но там другие проблемы, имхо. И они уж точно не в гибкости.

                                                                                                                                                        Про админку Вы правы, конечно. А как иначе-то? Потому и нет аналогов.

                                                                                                                                                        Шаблоны «тормознутые» только потому, что они делают всю грязную работу за программистов, которую те часто забывают делать сами. Так что джанго-шаблоны — одни из самых надежных шаблонов, и гнать на них не нужно :) А плата за это — производительность. Не бывает ничего бесплатного. Если работу не делает программист — ее делает компьютер. НО! Не устраивает скорость — всегда можно было использовать Jinja2, а теперь, к тому же, его поддержка хорошо интегрирована, да и ничто не мешает подключить любой другой шаблонизатор. Джанго постепенно все больше открывает двери для сторонних решений.
                                                                                                                                                          0
                                                                                                                                                          Не хочу я с Вами спорить, это спор ни о чем. Если в Вашем бекграунде Django не приносил вам боли и сожаления о бесцельно потраченном времени, я искренне за Вас рад, я лично брать на себя эти риски больше не хочу. Django хорош для своего, весьма ограниченного, круга задач которых я в последнее время не касаюсь.
                                                                                                                                                          А так же я не хочу тратить время на «серьезное изучение всех потрохов» что бы стать «настоящим гуру» этих потрохов. Если молоток требует знаний металлургии и сопромата для использования я не бросаюсь их изучать, я просто меняю молоток.
                                                                                                                                                            0
                                                                                                                                                            Согласен, тут не о чем спорить. Если нет желания тратить время на глубокое изучение всей архитектуры, Django — не самый лучший выбор. Лучше выбрать какой-то простой «молоток». Потому что Django — это целый «комбайн-конструктор», если можно так выразиться. Мало того, что надо понимать внутреннюю структуру, так еще и очень желательно понимать и уметь использовать метаклассы, которые по своей сути — хоть и простая, но довольно мозговзрывательная концепция.
                                                                                                                                                +1
                                                                                                                                                Сложность задач увеличивается. То, что создавалось ранее, уже не так просто развивать — вылазят ранее не видимые недостатки подхода и реализации. Люди ищут замену…
                                                                                                                                                  +3
                                                                                                                                                  Думаю, автор немного не прав в том смысле, что Rails надо оценивать сравнивая с другими фрэймворками, а не просто перечисляя что в нем плохо. Если это хорошо в других фрэймворках, может оказаться что в них плохо что-то другое. Это не вопрос того, что Rails лучше. Это вопрос того, что Rails лучше для автора статьи в задачах, которые он решает. Вполне возможно, что ему просто надоело и ему банально хочется развития. Вполне естественный процесс, правда, ничего не говорящий о недостатках Rails.
                                                                                                                                                    +3
                                                                                                                                                    Очень интересная статья но просто ужасный перевод. Я понимаю что текста много, но мне кажется что автор перевода не перечитывал текст перед публикацией. Читать сложно и неудобно.
                                                                                                                                                      +9
                                                                                                                                                      Мне вот эта картинка понравилась (12 лет прогресса веб-разработки):

                                                                                                                                                      image

                                                                                                                                                      У меня есть один проект (первый) — дак он всё ещё крутится на Rails 1.0 (был переписан с Access) — и заказчик вполне доволен до сих пор (прошло уже почти 10 лет). Изучать новые технологии необходимо, но и понимать, что в конечном итоге надо решать бизнес задачи.

                                                                                                                                                      А автору спасибо за DataMapper — использовал (совместно с Sinatra) в нескольких проектах.