З року в рік на світ Ruby сходило благословення - тут з'явилася завидна кількість фреймворків для розробки веб-додатків. Однак двоє з них нещодавно стали явними лідерами цієї сфери. Більшість читачів цього сайту чули про Ruby on Rails. Він був розроблений Девідом Хайнемайером Хенссоном в 2004 і являє собою MVC фреймворк, який допомагає підвищити продуктивність і зробити при цьому розробників щасливими. Sinatra був створений Блейком Мізерані в 2007, є предметно-орієнтованим мовою (domain-specific language), який виступає обгорткою для рівня легковагових HTTP запитів і відповідей поверх Rack. Його мінімалістичний підхід витончений і елегантний. Статистика на RubyGems.org наочно показує, наскільки популярні обидва ці фреймворки: Rails був скачан 7 мільйонів разів, а Sinatra - 1.5 мільйона. Саме Rails втягнув мене в веб-розробку на Ruby, але протягом декількох останніх років я набагато частіше використовував Sinatra (і ось 7 причин, через які я його люблю). На повірку виявилося, що мені для побудови програми потрібен лише Sinatra разом з кількома гемами. Це змусило мене поміркувати над тим, а чи можна з Sinatra подужати будь-який проект. Коли найкраще використовувати Sinatra, а коли найкращим вибором буде Rails? Намагаючись знайти відповідь на це питання, я запитав у знаменитих Ruby розробників, що вони думають з цього приводу.
- Кожен з них вирішує різний ряд проблем, навіть не дивлячись на те, що вони, насправді, пов'язуються на цьому терені. У той час, як Rails є фреймворком, який фокусований на написанні модельно-орієнтованих веб-програм, Sinatra - бібліотека для обробки HTTP на серверній стороні. Якщо ви мислите термінами запитів/відповідей HTTP, то Sinatra стане ідеальним інструментом. Якщо вам потрібна повна інтеграція і якомога більше бібліотечних шаблонів, то Rails у цьому випадку буде для вас чудовим вибором.
- Sinatra чудово підходить для мікро-стилю, а ось Rails - ні. До тих пір, поки ви дотримуєтеся мінімалізму, Sinatra перевершує Rails. Якщо ви виходите за рамки оного, то Rails б'є Sinatra.
- Якщо у вашому додатку 5-10 кінцевих точок, то вигідно використовувати Sinatra для власноручного рішення. Особливо, коли сама структура контролерів може поміститися на 1-2 сторінках коду, - чудово, якщо це можна запустити одним файлом.
- Sinatra дійсно чудово працює як API, а також на малих сайтах (внутрішні програми, Github Jobs і т. д.)
- Rails дозволяє людям робити вибір між кращими технологіями («кращими» їх охрестив я і спільнота Rails) і в цьому криється велика частина його успіху... Я змінюю Rails щотижня, щоб він краще відповідав ідеальному, в моєму уявленні, фреймворку.
- Я люблю Rails. Rails творив наше уявлення про веб-додатки. Rails вирішує для вас такі проблеми, які Sinatra вирішити не в силах, оскільки він може зробити більше припущень про ваш додаток. Для вас вже все встановлено незалежно від того, знадобиться воно вам чи ні, найбільший вилучений в архітектурі Rails - прийняття того, що все має вирішуватися за допомогою одного інструменту.
- Створення більш складних програм на Sinatra (або, швидше, використання Sinatra серед числа інших програм) змусить розробника значно більше часу витратити на обмірковування архітектури та інструментарію. Це як перевага, так і недолік.
- Стабільність - найбільша перевага Sinatra. Ви жертвуєте своїми власними дизайнерськими рішеннями заради зручностей від кількох генераторів Rails. Написання на Sinatra може подарувати розробникам і бізнес API стабільність, оскільки фреймворк змінюється рідко. Ви володієте своїм кодом, і ви вирішуєте, коли його варто змінити.
- Кожен з моїх нових додатків починається з Sinatra і, зазвичай я приходжу до висновку, що крім Sinatra разом з кількома Rack плагінами, мені більше то нічого і не потрібно, невелика CouchDB бібліотека і Backbone.js в якості фронт-енду.
- Sinatra виконує все що мені потрібно на базовій платформі, а все інше або вже забезпечено хмарними платформами і сервісами (наприклад, Heroku і його екосистема аддонів), або я можу реалізувати за допомогою гемів. А для всього, що залишився, я можу написати код власноруч.
- Розбиття всього на маленькі частинки і примус розробників до власноручного збору всього і вся є антитезою всього того заради чого створювався Rails і того як він переміг у грі фреймворків. Були витрачені десятки тисяч людино-годин заради того, щоб ми досягли цієї мети. Спроба це відтворити - порожня затія.
- Головним недоліком Sinatra, який не вирішує за вас проблему, є саме те, що Sinatra її не вирішує. Ви повинні самостійно з нею розібратися. Це може призвести до того, що ви витратите невиправдано велику кількість часу, намагаючись її вирішити.
- Швидше за все, вся та робота, яку вам належить зробити, заради відтворення рішень, вже наданих в Rails, негайно перекреслить простоту використання Sinatra. Мені шкода тієї людини, яка намагається поодинці побудувати Basecamp, GitHub, Shopify або якісь інші великі програми в Sinatra. Rails - величезний і заплутаний інструмент, оскільки він містить рішення більшості проблем з якими стикаються більшість людей, які працюють над створенням програми такого масштабу. Спроба відтворити всі ці рішення вручну - все що завгодно, але тільки не простота.
- Стандартна програма Rails надає багато з того, що мені потрібно і що потребувало б додаткових установок в Sinatra. А це додає додаткову швидкість при розробці на Rails.
- Я думаю, що протягом першого року Rails був головним інструментом для засновників [GitHub]. Їм вдалося скористатися перевагами деяких можливостей Rails більш високого рівня і швидко виконати ітерацію.
- Генератори і структури Rails дають угоди, які не надає Sinatra.
- Rails хороший, якщо для вас прийнятні його догматичні угоди і ви дотримуєтеся «золотого шляху».
- "Sinatra слід абстрактному шаблону: НННВШ (Нам Не потрібні смердючі шаблони). НННВШ означає, що Sinatra більш ніж гнучкий і не зумовлює те, яким чином ви будете організовувати доменну або бізнес логіку. У нього немає явно вказаної структури тек, відсутня абстракція баз даних за замовчуванням і немає обмежень щодо того де і як його застосовувати ".
- У минулому я застосовував Sinatra і мені він дуже подобався. Він пропонує зовсім інший підхід, який чудово підходить для вирішення завдань значно меншого кола, проте вирішує їх дійсно чудово.
- По суті, в Sinatra немає нічого такого через що б мені захотілося переробляти Rails по-іншому.
- Ми хотіли додати в Rails режим єдиного файлу (single-file mode), але відмовилися від цього, навіщо нам оптимізувати те, з чим Sinatra і так чудово справляється?
- Сам по собі Rails не такий вже й «важкий», особливо якщо взяти до уваги його поточну можливість зменшення в розмірі на свій розсуд.
- У моїй практиці програми на Rails часто стають єдиним монолітним додатком. [Відмова від Rails] дає в підсумку модульність, гнучкість, швидкість на тестах і масштабованість. Однак ви можете домогтися такої ж архітектури, якщо будете акуратно конструювати Rails програми, справа в тому, що вчинити інакше (не робити цього) занадто привабливо.
- Фізично видаливши ділянку коду Rails, яку ви не використовуєте, ви не отримаєте нічого корисного. Ніхто не змушує вас користуватися всіма можливостями. [Багато можливостей Rails] цілком опціональні і можуть бути повністю відключені, якщо вони вам настільки заважають.
- Я думаю, що насправді кожен з них можна використовувати в будь-якому з протилежних випадків. Вважаю, що врешті-решт, це суб'єктивний вибір.
- Я вважаю, що зрештою це залежить від того, що ви віддаєте перевагу: почати налегку і додавати за потребою, або почати з важкого, а потім видаляти що-небудь, якщо необхідно позбутися ваги.
- Я думаю, що серед Ruby розробників є істотна відмінність: є ті, хто віддає перевагу малому розміру, легковісності, швидкості, експліцитності (explicit) і розширюваності; а є ті, хто віддає перевагу фреймворкам з повним набором можливостей. Sinatra задовольняє запити перших, а Rails - других. Так що я не думаю, що Sinatra витіснить Rails. Просто це інша філософія, яка подобається певному виду розробників.
- Якщо в процесі розробки 2 фреймворки стали один одного доповнювати, то це говорить про те, що я зараз працюю над багатоарендним додатком (multi-tenant), яке інтенсивно експлуатує Sinatra всередині Rails, крута річ. Sinatra дозволив мені надати своєму додатку модульність, перш зробити це настільки просто було мені не під силу.
- Вам не варто занадто турбуватися про вибір, він відбувається за вас завдяки можливості вбудовувати Sinatra програми в програми на Rails 3.
- Багато людей вбудовують Sinatra програми в програми на Rails. Це імітує дизайн Django фреймворку, де (основний) додаток складається з безлічі більш дрібних програм, кожна з яких відповідальна за певну частину в оном (і часто можуть бути повторно використані іншими додатками).
- У вас навіть може бути мікроприкладення на Sinatra всередині Rails структури. Таке застосовується на Github для вирішення декількох завдань. Чудова модель.
- Я дуже радий, що Rack і Sinatra настільки тісно інтегруються з [Rails]. Замість того, щоб підлаштовувати Rails під свою волю заради специфічної можливості, ви можете перенаправити запит на Sinatra або кінцеву точку Rack і виконати саме те що необхідно.
- У кожного з них є своє місце. Rails буде найкращим варіантом у тому випадку, якщо вам просто необхідно розібратися із завданням. Для простих речей найкращим вибором буде Sinatra, а також тоді, коли ви хочете все контролювати і дотримуватися власних поглядів.
Костянтин Хаас, який зараз займається підтримкою Sinatra, вважає що, кожен з інструментів відповідає вимогам додатків свого виду:
Кожен з них вирішує різний ряд проблем, навіть не дивлячись на те, що вони, насправді, пов'язуються на цьому терені. У той час, як Rails є фреймворком, який фокусований на написанні модельно-орієнтованих веб-програм, Sinatra - бібліотека для обробки HTTP на серверній стороні. Якщо ви мислите термінами запитів/відповідей HTTP, то Sinatra стане ідеальним інструментом. Якщо вам потрібна повна інтеграція і якомога більше бібліотечних шаблонів, то Rails у цьому випадку буде для вас чудовим вибором.
Девід Хайнемаєр Хенссон також вважає, що для кожного з них є своє місце, але вважає, що, вибираючи між ними, слід керуватися розміром свого додатку:
Sinatra чудово підходить для мікро-стилю, а ось Rails - ні. До тих пір, поки ви дотримуєтеся мінімалізму, Sinatra перевершує Rails. Якщо ви виходите за рамки оного, то Rails б'є Sinatra.
Дійсно, більшість людей, швидше, погодяться що Rails більш орієнтований на великі проекти, в той час як Sinatra краще підійде для мікроприкладень і API. Девід продовжує, пояснюючи правило вибору між Rails і Sinatra, яке він набув з досвідом:
Якщо у вашому додатку 5-10 кінцевих точок, то вигідно використовувати Sinatra для власноручного рішення. Особливо, коли сама структура контролерів може поміститися на 1-2 сторінках коду, - чудово, якщо це можна запустити одним файлом.
Рік Олсон з Github підтверджує, що Sinatra дійсно є чудовим вибором для невеликих проектів:
Sinatra дійсно чудово працює як API, а також на малих сайтах (внутрішні програми, Github Jobs і т. д.)
Девід Хайнемайер Хенссон пояснює, чому Rails стає настільки хорошим вибором, коли справа стосується побудови великих веб-додатків:
Rails дозволяє людям робити вибір між кращими технологіями («кращими» їх охрестив я і спільнота Rails) і в цьому криється велика частина його успіху... Я змінюю Rails щотижня, щоб він краще відповідав ідеальному, в моєму уявленні, фреймворку.
Костянтин Хаас ділиться своїм ентузіазмом з приводу Rails і його філософії:
Я люблю Rails. Rails творив наше уявлення про веб-додатки. Rails вирішує для вас такі проблеми, які Sinatra вирішити не в силах, оскільки він може зробити більше припущень про ваш додаток. Для вас вже все встановлено незалежно від того, знадобиться воно вам чи ні, найбільший вилучений в архітектурі Rails - прийняття того, що все має вирішуватися за допомогою одного інструменту.
Отриманим можливостям, які вам, загалом-то, в Rails і не потрібні, визначено супроводжують втрати, останні, однак, компенсуються тим, що ви знаходите велику кількість можливостей, яких дійсно потребуєте. Зрештою, це може себе виправдати, особливо коли справа стосується великого проекту. Однак, не всі погодяться з тим що великий проект може бути реалізований тільки на Rails. Джоффрі Грозенбах з Peepcode Screencasts вважає, що це «застарілий погляд, який справедливий лише для Sinatra в 2008, але, безумовно, не в наші дні». Він звернув увагу на чудовий додаток Gaug.es, побудований на Sinatra, як на приклад, який доводить, що він (Sinatra) більш ніж підходить для створення експлуатованих великомасштабних сайтів.
Незважаючи на вищесказане, Костянтин Хаас звертає увагу на потенційну проблему при використанні Sinatra для створення великих додатків:
Створення більш складних програм на Sinatra (або, швидше, використання Sinatra серед числа інших програм) змусить розробника значно більше часу витратити на обмірковування архітектури та інструментарію. Це як перевага, так і недолік.
Деякі розробники напевно до цього поставляться як до переваги, якщо вони воліють суворо контролювати те, що відбувається в своєму додатку і усвідомлювати те, як це все відповідає один одному. Джоффрі Грозенбах вважає, що це жертва, яка себе виправдовує:
Стабільність - найбільша перевага Sinatra. Ви жертвуєте своїми власними дизайнерськими рішеннями заради зручностей від кількох генераторів Rails. Написання на Sinatra може подарувати розробникам і бізнес API стабільність, оскільки фреймворк змінюється рідко. Ви володієте своїм кодом, і ви вирішуєте, коли його варто змінити.
Він продовжує пояснювати, чому Sinatra є чудовим кандидатом для побудови додатків:
Кожен з моїх нових додатків починається з Sinatra і, зазвичай я приходжу до висновку, що крім Sinatra разом з кількома Rack плагінами, мені більше то нічого і не потрібно, невелика CouchDB бібліотека і Backbone.js в якості фронт-енду.
Соу Шеонг Чанг з Yahoo і автор Клонування Інтернет Додатків з Ruby дотримується простої моделі розробки:
Sinatra виконує все що мені потрібно на базовій платформі, а все інше або вже забезпечено хмарними платформами і сервісами (наприклад, Heroku і його екосистема аддонів), або я можу реалізувати за допомогою гемів. А для всього, що залишився, я можу написати код власноруч.
Насправді цю ідею можна було б використовувати як більш досконалий підхід у застосуванні Sinatra - створення свого власного спеціального фреймворку, який повністю задовольняє ваші потреби. Почніть з Sinatra, а потім додайте геми, які реалізують потрібні вам можливості, щоб створити власний індивідуальний фреймворк. Щось подібне реалізовано в проекті Padrino.
Девід Хайнемайер Хенссон не бачить в цьому сенсу:
Розбиття всього на маленькі частинки і примус розробників до власноручного збору всього і вся є антитезою всього того заради чого створювався Rails і того як він переміг у грі фреймворків. Були витрачені десятки тисяч людино-годин заради того, щоб ми досягли цієї мети. Спроба це відтворити - порожня затія.
Хоча контроль над тим, що відбувається всередині вашого додатку може бути хорошою ідеєю, Костянтин Хаасе попереджає, що це може відняти багато вашого часу:
Головним недоліком Sinatra, який не вирішує за вас проблему, є саме те, що Sinatra її не вирішує. Ви повинні самостійно з нею розібратися. Це може призвести до того, що ви витратите невиправдано велику кількість часу, намагаючись її вирішити.
А якщо у розробників обмежений бюджет, то у них цього часу банально може і не бути. Девід Хайнемайер Хенссон стурбований, що застосування Sinatra при спробі заново винайти колесо загрожує втратою величезної кількості часу даремно:
Швидше за все, вся та робота, яку вам належить зробити, заради відтворення рішень, вже наданих в Rails, негайно перекреслить простоту використання Sinatra. Мені шкода тієї людини, яка намагається поодинці побудувати Basecamp, GitHub, Shopify або якісь інші великі програми в Sinatra. Rails - величезний і заплутаний інструмент, оскільки він містить рішення більшості проблем з якими стикаються більшість людей, які працюють над створенням програми такого масштабу. Спроба відтворити всі ці рішення вручну - все що завгодно, але тільки не простота.
Райан Бейтс, ведучий Railcasts вважає, що перевага при використанні Rails полягає в заощадженні часу, коли проект починається з нуля:
Стандартна програма Rails надає багато з того, що мені потрібно і що потребувало б додаткових установок в Sinatra. А це додає додаткову швидкість при розробці на Rails.
Цю ж думку висловлює Рік Олсон, який вважає, що Rails полегшив втілення проекту GitHub.
Я думаю, що протягом першого року Rails був головним інструментом для засновників [GitHub]. Їм вдалося скористатися перевагами деяких можливостей Rails більш високого рівня і швидко виконати ітерацію.
Чад Фоулер (із засновник RubyConf) цитує мантру Rails про «угоду з конфігурації» як ще одну причину завдяки якій Rails прискорює розробку великих проектів:
Генератори і структури Rails дають угоди, які не надає Sinatra.
Проблема в тому, що ці угоди іноді схожі на смиренну сорочку, Rick Olson звертає увагу на такі випадки:
Rails хороший, якщо для вас прийнятні його догматичні угоди і ви дотримуєтеся «золотого шляху».
На відміну від нього у Sinatra немає будь-яких обмежень, Сатиш Талім з Ruby Learning навів чудову цитату Арона Квінта, яка це пояснює:
"Sinatra слід абстрактному шаблону: НННВШ (Нам Не потрібні смердючі шаблони). НННВШ означає, що Sinatra більш ніж гнучкий і не зумовлює те, яким чином ви будете організовувати доменну або бізнес логіку. У нього немає явно вказаної структури тек, відсутня абстракція баз даних за замовчуванням і немає обмежень щодо того де і як його застосовувати ".
Sinatra найбільш привабливий там, що дозволяє визначати як і яким чином від і до структурувати додаток. Побудова на Sinatra може дати свободу, оскільки ви не обмежені в розмірі, структурі або потоці робіт. Ви можете побудувати API, веб-додаток або запакувати свій код в гем.
Можливо, деяких здивує той факт, що Девід Хайнемаєр Хенссон теж обожнює простоту Sinatra:
У минулому я застосовував Sinatra і мені він дуже подобався. Він пропонує зовсім інший підхід, який чудово підходить для вирішення завдань значно меншого кола, проте вирішує їх дійсно чудово.
Так чи є у Sinatra така перевага, які б йому захотілося перенести в Rails?
По суті, в Sinatra немає нічого такого через що б мені захотілося переробляти Rails по-іншому.
Однак він все ж визнає, що в Rails практично повністю скопійована одна з найкрутіших можливостей Sinatra:
Ми хотіли додати в Rails режим єдиного файлу (single-file mode), але відмовилися від цього, навіщо нам оптимізувати те, з чим Sinatra і так чудово справляється?
Поза всяким сумнівом, Rails надає величезну кількість можливостей, але нерідко серед них є ті, яких ви не потребуєте або вони не працюють саме так, як вам необхідно. У Rails 3 була зроблена спроба згладити це настільки, наскільки це можливо - шляхом роз'єднання деяких з можливостей різного виду, що в результаті може дати більш легкий і конфігурований продукт, на що і звертає увагу Чад Фоулер:
Сам по собі Rails не такий вже й «важкий», особливо якщо взяти до уваги його поточну можливість зменшення в розмірі на свій розсуд.
Rails 3 привніс багато налаштувань, які дозволяють підлаштувати програму під виконуване для вас завдання. Незважаючи на те, що існує можливість позбутися непотребу, Костянтин Хаас попереджає, що залишити все як є нерідко здається занадто привабливим, що призводить до роздування:
У моїй практиці програми на Rails часто стають єдиним монолітним додатком. [Відмова від Rails] дає в підсумку модульність, гнучкість, швидкість на тестах і масштабованість. Однак ви можете домогтися такої ж архітектури, якщо будете акуратно конструювати Rails програми, справа в тому, що вчинити інакше (не робити цього) занадто привабливо.
Девід Хайнемаєр Хенссон не бачить в цьому проблеми і вважає, що незалежно від того користуєтеся ви всіма можливостями чи ні, Rails підійде в будь-якому випадку:
Фізично видаливши ділянку коду Rails, яку ви не використовуєте, ви не отримаєте нічого корисного. Ніхто не змушує вас користуватися всіма можливостями. [Багато можливостей Rails] цілком опціональні і можуть бути повністю відключені, якщо вони вам настільки заважають.
Rails стає легше, а Sinatra показав що може впорається з важкими завданнями, це означає що вони все більше пов'язуються. Чад Фоулер вважає, що насправді і Sinatra і Rails можуть застосовуватися в широкому колі проектів:
Я думаю, що насправді кожен з них можна використовувати в будь-якому з протилежних випадків. Вважаю, що врешті-решт, це суб'єктивний вибір.
В цілому всі погодяться, що «для роботи повинен бути підібраний відповідний інструмент», але їх сполучення означає, що рішення часто зводиться до персонального вибору. Sinatra може дати більше контролю над архітектурою, але чи будуть додаткові зусилля гідною тратою вашого часу (або вашого клієнта, що більш важливо)? Райан Бейтс підводить підсумок щодо типів особистості і того який фреймворк вони вибирають:
Я вважаю, що зрештою це залежить від того, що ви віддаєте перевагу: почати налегку і додавати за потребою, або почати з важкого, а потім видаляти що-небудь, якщо необхідно позбутися ваги.
Джоффрі Грозенбах припускає, що існує два абсолютно різних типи розробників:
Я думаю, що серед Ruby розробників є істотна відмінність: є ті, хто віддає перевагу малому розміру, легковісності, швидкості, експліцитності (explicit) і розширюваності; а є ті, хто віддає перевагу фреймворкам з повним набором можливостей. Sinatra задовольняє запити перших, а Rails - других. Так що я не думаю, що Sinatra витіснить Rails. Просто це інша філософія, яка подобається певному виду розробників.
Але, можливо, вам не потрібно робити вибір між ними. Автор, Дейв Кеннеді, член Ruby Source, звертає увагу, що Rails і Sinatra загалом то досить непогано разом працюють:
Якщо в процесі розробки 2 фреймворки стали один одного доповнювати, то це говорить про те, що я зараз працюю над багатоарендним додатком (multi-tenant), яке інтенсивно експлуатує Sinatra всередині Rails, крута річ. Sinatra дозволив мені надати своєму додатку модульність, перш зробити це настільки просто було мені не під силу.
Безліч людей зрозуміли, що завдяки можливості вбудовувати Sinatra в Rails 3 + програми, дійсно можна отримає найкраще з того, що пропонують два світи. Чад Фоулер вважає, що концепція вибору між одним і іншим безглузда сама по собі:
Вам не варто занадто турбуватися про вибір, він відбувається за вас завдяки можливості вбудовувати Sinatra програми в програми на Rails 3.
Джоффрі Грозенбах вважає, що це додасть додаткам більш модульний вигляд:
Багато людей вбудовують Sinatra програми в програми на Rails. Це імітує дизайн Django фреймворку, де (основний) додаток складається з безлічі більш дрібних програм, кожна з яких відповідальна за певну частину в оном (і часто можуть бути повторно використані іншими додатками).
Девід Хайнемайер Хенссон також вважає, що це було б непоганим способом для виконання завдань:
У вас навіть може бути мікроприкладення на Sinatra всередині Rails структури. Таке застосовується на Github для вирішення декількох завдань. Чудова модель.
Рік Олсон пояснює наскільки часто на GitHub використовується ця пара в тандемі:
Я дуже радий, що Rack і Sinatra настільки тісно інтегруються з [Rails]. Замість того, щоб підлаштовувати Rails під свою волю заради специфічної можливості, ви можете перенаправити запит на Sinatra або кінцеву точку Rack і виконати саме те що необхідно.
Всі погодяться з тим, що для кожного з цих двох фрейморків в екосистемі Ruby є певне місце. По суті, вони чудово разом працюють, і до певної міри доповнюють один одного безліччю способів. Схоже, чимало людей вважає, що найкращим чином два фреймворки працюють саме разом, і задовольняють різні потреби в загальному плані. Різні види розробників роблять свій вибір за смаком, якщо рішення лежить у полі сполучення інструментів. Кожен з двох робить лише те, з чим добре справляється, і кожен є винятковим прикладом хорошої практики; настільки хорошою, що ці інструменти були скопійовані в інші мови незліченну безліч разів. Джон Нунемакер з GitHub красиво і лаконічно це підсумував:
У кожного з них є своє місце. Rails буде найкращим варіантом у тому випадку, якщо вам просто необхідно розібратися із завданням. Для простих речей найкращим вибором буде Sinatra, а також тоді, коли ви хочете все контролювати і дотримуватися власних поглядів.
Нам, як спільноті, невимовно пощастило, що у нас є настільки добре розроблені інструменти, з такою хорошою підтримкою, та ще й у відкритому коді. І Rails і Sinatra чудово справляються з усіма аспектами завдань, тому можна з упевненістю сказати, що завдяки їм у нас є найкраще з двох світів.
А ви як вважаєте - ви користуєтеся кожним з них, або віддаєте перевагу один іншому? Чи думали ви над створенням власного фреймворку, як альтернативі Rails? Залиште внизу коментар.
Оригінал статті можна переглянути тут.