Каковы недостатки RoR? [закрыто]

В настоящее время я пытаюсь решить, какой язык на стороне сервера изучать и использовать для веб-разработки, и хотя относительно легко получить информацию о том, почему x, y или z - хорошая вещь, сложнее определить недостатки каждой из них. их.

В частности, мне любопытно, какие есть недостатки в изучении и / или использовании Ruby on Rails по сравнению с любым другим языком / фреймворком.

Исходя из опыта: недостатком является то, что вы слишком сильно полагаетесь на среду Rails . Это замечательно и замечательно, если вы когда-нибудь пишете простые, простые в использовании приложения CRUD, которые попадают прямо в «сладкое пятно» Rails; Ваша производительность будет стремительно расти. Однако в тот момент, когда вам нужно что-то сделать за пределами этого приятного места - взаимодействовать с существующей базой данных, общаться с другим приложением, для которого не определен JSON или XML API, реализовать сложный рабочий процесс, Rails станет вашим врагом. это являетсяможно делать это с помощью Rails, но это идет "вразрез", так что вы в основном сами решаете, как это сделать, поскольку сообщество обычно просто отвечает: "Не делайте этого, это не Rails путь "- это приводит либо к потере производительности, либо к очень грязному коду, так как вам в основном приходится взламывать фреймворк Rails.

Кроме того, есть невысказанный недостаток: все остальное покажется уродливым и грязным. Как только вы попробуете сладкий, сладкий нектар Rails (хорошо, проповедуйте немного здесь ...), все остальное помои. Переход от Rails к PHP, или к ASP.NET WebForms, или к Java - это все равно, что ходить по гвоздям после резвых прогулок в пышном саду; вы не увидите другие языки / фреймворки в таком же свете, и, хотя вы все еще можете их ценить, вы втайне жаждете любящих объятий Rails.

Для вашего первого языка на стороне сервера, я чувствую, что с RoR могут возникнуть проблемы:

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

2. Так как это фреймворк, и при этом «самоуверенный», я чувствую, что он даст вам очень ограниченный охват того, что происходит в фреймворке.

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

Я пытался изучить RoR несколько раз, и моя самая большая проблема - всегда пытаться заставить пакеты работать правильно и документацию. Проблема с документацией заключается в том, что она всегда кажется устаревшей (или очень простой). Я получил основы с сайта, но кроме этого все выглядело устаревшим (даже книга, которую я купил и в итоге вернулась). Другим недостатком могут быть зависимости, которые есть у некоторых библиотек, и то, как они могут конфликтовать с другими, как заявил Бен Коу .

Что-то, о чем я подумал позже, и вместо того, чтобы сделать это комментарием, я просто отредактирую свой ответ так: у RoR есть шанс испортить Ruby для вас. Я знаю, когда я попробовал это, это заставило меня думать, что "Руби был глуп". Затем, спустя несколько месяцев, я решил попробовать Ruby и полюбил язык. Именно это заставило меня ненавидеть язык. Я не особо увлекался этим, но когда мне это нравилось, я действительно наслаждался Синатрой . Я думаю, что я получил радость, что большинство людей выходят из RoR из Синатры.

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

Я работаю с RoR и ASP.NET ежедневно, но, как ни странно, я предпочитаю мир ASP.NET, но это больше связано с личной философией, чем с языком или самой архитектурой. (Я немного ненормальный, и я тяготею к строго типизированным языкам).

Независимо от того, я говорю, попробуй. RoR - отличная среда для работы, но прежде чем перейти непосредственно к Rails, освоитесь с Ruby в качестве языка. Помимо веб-приложений, Ruby - это довольно крутой язык сценариев, если вам придется управлять * nix-боксом и он может сэкономить вам массу времени.

Как человек, который недавно изучил Rails (в качестве хобби - никогда не использовал его для разработки коммерческих классов) и уже работал в JEE и ASP.NET, ответ Уэйна М оказался очень верным.

Во всяком случае, в этом есть тонкая сторона, о которой еще никто не упомянул, но которая немного беспокоила меня в Rails - сильная зависимость от соглашения по конфигурации .

По сути, если вы привыкли ориентироваться по принципу «Поиск в файлах» с новой кодовой базой, CoC, вероятно, будет раздражать вас при попытке подобрать Rails. Он отлично подходит для простых гринфилдов CRUD, которые выполняются именно Rails-способом (как говорит Уэйн М), но для чего-то более уникального и сложного, будет трудно понять, что происходит, если вы попытаетесь отработать поток путем поиска вещи в файлах, чтобы увидеть, как подключена сантехника.

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

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

Ruby on Rails - хороший выбор для начала - здесь есть хорошее сообщество, множество документации и хорошие учебные пособия. Но не забывайте об альтернативах, особенно если вы начинаете больше заниматься веб-разработкой. RoR может быть излишним для некоторых проблем, неадекватным решением для других и лучшим выбором для другого набора. Знайте, что это сильные и слабые стороны, и как использовать инструмент.

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

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

Я, честно говоря, не могу понять тех, кто поэтично рассказывает о том, что такое прогулка по саду Ruby-on-Rails. Я пришел к этому как опытный разработчик ASP.NET-MVC, Java, PHP, Python - и обнаружил, что это самая ужасная трата времени! 90 процентов онлайн-ответов Google являются неправильными или неполными. Зачем? Изменилось ли так много каждый год? Или же никто не заботится о том, чтобы код действительно работал? Мне потребовалось огромное количество времени, чтобы просто делать простые вещи; далеко, намного больше, чем это заняло бы меня в C # / ASP.NET-MVC, например. Конечно, мне никогда не удавалось так долго изучать мои оригинальные технологии. Конечно, ROR - это кратко. Если это важно для вас. Но я редко обнаруживал, как создать код, который бы выполнял задачу. Лично я предпочел бы набрать на клавиатуре в течение 20 секунд, чтобы написать код, который определенно работает, ясно, и вы можете следовать ему, а не набирать краткий код Ruby в течение 2 секунд, но это никогда не работает, пока я не буду всю ночь искать какой-то способ заставить его работать. Это ужасная вонючая куча додо. Зачем? Является ли этот код с открытым исходным кодом (как в бесплатном) не стимулирующим делать его качественным инструментом? Слишком много сценаристов, качающих в него ревизии и модули и плохую документацию? Я не знаю. Но когда я наконец смог уйти от первого проекта Ruby-Rails, я поклялся, что больше никогда не попаду в этот беспорядок! не дает никаких стимулов, чтобы сделать его качественным инструментом? Слишком много сценаристов, качающих в него ревизии и модули и плохую документацию? Я не знаю. Но когда я наконец смог уйти от первого проекта Ruby-Rails, я поклялся, что больше никогда не попаду в этот беспорядок! не дает никаких стимулов, чтобы сделать его качественным инструментом? Слишком много сценаристов, качающих в него ревизии и модули и плохую документацию? Я не знаю. Но когда я наконец смог уйти от первого проекта Ruby-Rails, я поклялся, что больше никогда не попаду в этот беспорядок!

Я предлагаю вам взглянуть на показатели рейтинга распространенности различных языков / сценариев. Вот ссылка, которая может оказаться полезной: популярные профессионально используемые веб-языки.

Это показывает относительную популярность языков, связанных с сетью, на основе поиска объявлений о вакансиях в Интернете.

Я согласен с некоторыми из приведенных выше ответов о RoR, я разрабатывал приложения с RoR в течение последних двух лет. Это действительно хорошо с простыми приложениями, операции CRUD (Create, Read, Update и Delete) работают очень хорошо, это благо для разработки простых приложений, но также является его ограничением. Хотя есть много драгоценных камней, предлагает различные преимущества и простоту использования, в основном это так. Если вы выйдете из коробки, вы получите все приложения.

Если вы большая команда, работающая над приложением, использующим RoR, с трудовым делегированием может быть сложно сойти с рук.