Одна из лучших особенностей Rails - это самоуверенный фреймворк.

Самоуверенность является такой ключевой частью философии фреймворка, что она появляется как №3 в доктрине Rails, где №2 - соглашение важнее конфигурации - также особенность самоуверенного фреймворка (мы заранее расскажем вам, как все устроено. сделано вместо того, чтобы писать что-либо!)

Доктрина Rails объясняет, почему быть самоуверенным - это хорошо: безопасность в цифрах, лучшая поддержка сообщества, более высокое общее качество. По сути, это означает следующее: давайте не будем создавать 6 разных гемов для обработки вложенных файлов - каждый гем имеет свое собственное сообщество, синтаксис, философию и несколько разные функции. Вместо этого, когда мы видим очень распространенную проблему веб-разработки (а вложения файлов повторяются в огромном количестве проектов), давайте запишем ее во фреймворк. Вот почему Rails 5.2 представит ActiveStorage. Вот почему у нас есть ActionCable. И ActiveRecord, и многое другое.

Я хочу увидеть встроенного админа в Rails

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

Я не хочу, чтобы мне приходилось выбирать гем администратора в новом проекте Rails или спорить с каким-то разработчиком, которому действительно нравится X, а не Y. Я не хочу запоминать синтаксис ActiveAdmin, RailsAdmin, Administrate и тому подобное. У всех нас есть гораздо лучшие дела для своего времени.

Наличие «выбора» замедляет разработчиков при переключении проектов, фрагментирует сообщество и заставляет нас тратить энергию на воссоздание и повторное изучение одного и того же снова и снова. В целом это очень плохо для продуктивности. Этого не должно произойти, если Rails просто встроит панель управления администратора во фреймворк. Это просто административная панель, не можем ли мы придумать достаточно хорошее решение для большинства проектов и внедрить его? Те 5% проектов, которым действительно нужен собственный уникальный админ-снежинка, всегда могут отказаться и использовать то, что хотят.

Админ, входящий в состав Django, часто называют одним из основных моментов фреймворка, и это правильно. Это красиво, легко понять, изменить и т. Д. Мне это очень понравилось.

Авторизация и аутентификация тоже подойдут

Еще одна область, в которой выделяется Django, - это аутентификация и авторизация, а также безупречная работа с администратором Django. Как новичок в Django, я чувствовал, что использовать их было почти легко. Я думаю, что Rails было бы разумно встроить их во фреймворк, поскольку практически каждый проект требует аутентификации и авторизации. Мы уже раздроблены между Cancan и CanCanCan (надеюсь, я не доживу до CanCanCanCan), а затем есть Pundit. И Rolify. И неизвестно что еще. Это просто разрешение, а не ракетостроение. Я уверен, что мы сможем согласовать подход, который работает для большинства людей, и встроить его в структуру. Сообщество Django сделало именно это.

Конечно, если вы займете определенную позицию, это, скорее всего, вызовет разногласия. Некоторым не нравится подход X, а не подход Y. Но Rails действительно хорош в том, чтобы занять твердую позицию и быть самоуверенным. Те разработчики, которые хотят большей свободы, в любом случае не выбирают Rails: они выбирают Sinatra или Flask. Или Node. Остальные из нас ждут, что Rails упростит веб-разработку, найдя общие решения и лучшие практики для типичных проблем.