Чому я б не став використовувати Rails для нового проекту

Ми зробили Scribd на Rails, і він став третім за відвідуваність сайту на Rails, і фреймворк працював, як треба. Але сьогодні я бачу величезну кількість нових проектів, які використовують Rails, і, здається, роблять помилку.


Я почав використовувати Rails в 2006, відразу після скрикаста Давида Ханссона, в якому він з помпою представив світу фреймворк. Ми написали першу версію Scribd на Rails 0.7. Тоді, коли фреймворк не мав навіть міграцій.

У той час навколо Rails було багато шуму, але вибирати його було досить ризикованим кроком. Більшість нових сайтів продовжували писати на PHP і Java – цьому сприяло наявність величезної кількості розробників для цих платформ. Ми зробили ставку на те, що Rails продовжить набирати популярність, обзаведеться свитою хороших бібліотек і армією лояльних розробників.

Нам пощастило! Поки ми піднімали Scribd, разом з нами ріс і Rails. Він ставав базовою технологією для розробки нових проектів Силіконової долини. Розробники Java Spring, PHP and ASP.NET зрозуміли, до чого все йде, і почали шукати роботу, де вони можуть переключитися на новий мову. Коли злетів наш проект, ми опинилися у виграші — до нас потягнулися талановиті хлопці, оскільки ми могли запропонувати їм попрацювати на Rails.

Вітер змін
Я переживаю через те, що розквіт Rails вже позаду. Запускати зараз новий проект на Rails, це майже те ж саме, що запускати проект на Java Spring 2007. Графік нижче показує, які веб-фреймворки гуглили з 2007 по 2015 роки.



Джерело: Google Trends

Неможливо не побачити, що інтерес розробників перемістився з Rails в бік більш нових фреймворків.

Найбільша проблема Rails – це Ruby
Всі знають, що Ruby повільний. Але насправді, Ruby – це найповільніший мову серед популярних мов програмування.


Чому Ruby такий повільний?

Деякі вкажуть на характеристики мови, які склалися історично. І це вірно. Але я думаю, що є більш глибока причина. У Ruby немає корпоративного спонсора.

В далекому 2007 році Python, PHP і JavaScript були досить повільними мовами. Компанія Facebook дуже сильно проінвестувала в PHP і створила HipHop, щоб зробити його швидше. А Google випадково підштовхнула бурхливий розвиток серверної частини JavaScript, зробивши швидкої JIT-компіляції в JavaScript.

Інтерпретатор Ruby зроблений зусиллями волонтерів. Між 2007-2012 роками не раз робилися спроби полагодити інтерпретатор й зробити його швидким (Rubinius, JRuby, YARV і так далі). Але брак надійного спонсора призвів до того, що волонтери занудьгували і здулися. JRuby як і раніше активний і останні версії подають надії, але попереду ще багато роботи.

Twitter, перша велика IT-компанія на Rails, міг підхопити Rails і полагодити інтерпретатор. Точно так, як свого часу вчинив Facebook з PHP. Це могло все змінити і гарантувати домінування Rails на роки вперед. Але інженери Twitter вирішили, що чим прискорювати Ruby, простіше переписати Twitter на більш швидкому мовою.

Rails стояв на місці, поки інші його наздоганяли
Rails належить багато відкриттів, які зробили написання звичайних веб-додатків швидше. Але через деякий час інші фреймворки просто підхопили ці інновації. Зараз Django для Python – клон Rails. Те ж саме можна сказати про Sails.js для JavaScript. І ці фреймворки не страждають від того, що пишуться на «мейнстрімових» мовах програмування.

В цей же час застопорилася розробка самого Rails. Його третя версія була випущена в серпні 2010 року. Github не переходив на нову версію фреймворку протягом чотирьох років – переваги були не досить значущими. Згадуючи біль, яку ми випробували під час оновлення Scribd до Rails 3, я не впевнений, що ми коли-небудь ризикнемо з Rails 4.

Це цікаво – порівняти зростання інновацій в JavaScript і фронтэнд-розробці зі стагнацією на Rails. В останні 7 років наш бекэнд змінювався маленькими кроками, а фронтенд мігрував з Prototype на jQuery, потім на Coffeescript, потім на Angular, потім на React. Кожен раз – з зростанням продуктивності праці.

Новобранці
В останні два роки виросло багато центрів навчання програмування для початківців. Вони навчають багато чого, але коли справа стосується розробки серверної частини, перевага за Rails. Мабуть, це відповідь на ринку як і раніше високий попит на розробників Rails у стартапів.

З одного боку вигравала екосистема Rails, тому що збільшувалася кількість талановитих людей всередині неї. На жаль, був і зворотний ефект. Серйозні розробники, особливо зі ступенем з інформатики (CS), стали дивитися зверхньо на ці курси, як на «програмування по верхах». Я помітив, що все більше і більше досвідчених розробників відмовлялося працювати на Rails – через зіпсованої репутації фреймворка. Бачив, як це вже траплялося з Flash/ActionScript: серйозні розробники часто (помилково) ставилися до нього як до полегшеної версії «для дизайнерів».

Нові гравці
Серед фреймворків є кілька сильних претендентів на статус спадкоємця Rails. Лідирує Node.js. Не вірите? Ось статистика використання серверних мов популярними компаніями:


Джерело: CodingVC

А тут показано, що відбувається на ринку праці:


Джерело: indeed.com

Це при тому, що всі нові мови мають недоробки. Node.js страждає від дроблення з шістьма спортсменами фреймворками. Прямо зараз Go дуже популярний для микросервисов, але випробує недолік у великомасштабних додатках. Django/ Python, здається, тримає свої позиції, але і не росте.

Якщо ви хочете бути впевненим в вашому веб-додатку, вам потрібно зрозуміти, на чому інженери захочуть писати через три роки. Це важливіше, ніж вибрати фреймворк, який збільшить продуктивність прямо зараз. Якщо ви Facebook, можете використовувати, що завгодно – люди все одно захочуть працювати на вас. Але більшість компаній не Facebook. Загалом, якщо вгадаєте, то додаткових зусиль докладати не доведеться — новий популярний фреймворк приверне до вас кадри самостійно.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.