Огляд фреймворків JavaScript. Що, для чого і коли використовувати
Всім привіт, мене звуть Олег, я основний Full Stack JS Developer в невеликому продуктовому blockchain-стартапі Subsocial. Грубо кажучи, ми готуємо свій фреймворк для створення децентралізованих соціальних мереж. Ось вже майже три роки ми ведемо запеклий бій з блокчейном, щоб зробити продукт не гіршим, ніж звичайні централізовані конкуренти.
Пошуком нових рішень, бібліотек та й загалом технологій потрібно займатись ледь не щодня. Саме тому вирішив написати цю статтю та ввести в курс новачків, в яких розбігаються очі від світу JS-фреймворків.
Одразу попереджаю, що це оглядова стаття. Я не буду вдаватись в технічні деталі кожного фреймворку, адже це вже не раз зробили до мене.
Для нашої подорожі одразу варто розібратись, що таке фреймворк. Дослівно з англійської це «каркас», тобто якась готова структура, поверх якої ви будуєте свій застосунок. Він має свої правила, структуру та обмеження, що дають змогу достатньо швидко розробляти, але якщо потрібно вийти за межі дозволеного, починаються великі проблеми.
Цим можна й пояснити велику кількість фреймворків на ринку, адже кожний з них вирішує певну проблему. Коли розробнику чогось не вистачає в інструменті, він створює щось своє, часто це виливається в новий фреймворк.
Світ фронтенду
Історію уніфікаціїі та організації JS-коду в бібліотеки і фреймворки можна почати з появи JQuery у 2006 році. В той час браузерів було вже багато, і JS у кожному був свій, тому бібліотека стала срібною кулею для усіх проблем з підтримкою кількох браузерів.
Але це була бібліотека для маніпулювання DOM, цього було мало, адже кожний прикручував свої велосипеди у проєкт, не було чіткої структури, як саме має виглядати правильний Front-end проєкт.
Для вирішення цієї проблеми у 2010 році з’явився Backbone.js — бібліотека, яка реалізує патерн MPV (Model-Presenter-View). За допомогою Backbone.js можна було створити SPA (Single Page Application) з клієнтським роутингом. За ним одразу з’явився AngularJS від Google, який вже був дійсно повноцінним фреймворком, з чіткою MVC (Model -View-Controller) структурою і можливістю без додаткових бібліотек створити повноцінний вебзастосунок.
Ще одним з перших став Ember.js, що вийшов у 2011 році. Він мав власний потужний шаблонізатор HTML — Handlebars і був прямим конкурентом першому ангуляру.
Варто зазначити, що саме в цей час через зростання складності клієнтської частини застосунків виникла професія фронтенд-розробника.
Це був цікавий та бурхливий час, було створено безліч фреймворків і бібліотек під конкретні цілі, і на
Angular
Angular — це повноцінний
Приклад роботи генерації компоненти «componentname»
Але за «все з коробки» розробники платять великим розміром самого фреймворку, який у
Завдяки чіткій і жорсткій структурі цей фреймворк є стабільним і надійним, але потребує досить багато ресурсів для написання застосунку, тому рідко використовується для маленьких проєктів, але прекрасно себе почуває в Enterprise-рішеннях.
React
Це дітище Facebook 2013 року, а також мій основний інструмент, який я використовую на фронтенд-частині.
Варто зауважити, що React — це не фреймворк, а бібліотека візуалізації, якщо взяти патерн MVC (Model-View-Controller), то React — це лише частина View.
Це перший продукт, що почав використовувати Virtual DOM для оптимізації оновлення DOM дерева (document object model — моделі, що згодом перетворюється в HTML і витрачає для цього велику кількість ресурсів). Суть оптимізації в тому, щоб оновлювати лише ті дані, які дійсно змінились, а для пошуку відмінностей використовувати полегшену віртуальну структуру.
Однак це йому не заважає бути найпопулярнішою бібліотекою серед фреймворків.
Його рідко використовують окремо, а одразу підключають такі додаткові бібліотеки, як React Router, React DOM або їхні аналоги.
React має значно нижчий поріг входу, велику гнучкість і свободу, що є перевагою для невеликих проєктів, але й не менш потужний, щоб використовувати його для великих.
Основною проблемою є його перевага — потрібно збирати фреймворк самому, з великої кількості бібліотек. Типовий проєкт на React виглядає так: React, React Router, React DOM, Redux, Redux React. Якщо все це упакувати в коробку, вийшов би фреймворк, але це все потрібно робити самотужки.
Але світ ІТ не був би собою, якби не були знайдені рішення. На просторах GitHub можна знайти безліч шаблонів, які генерують повністю готовий для роботи проєкт на будь-який смак, з будь-якими препроцесорами CSS, бібліотеками для роутерів чи управління станом, тому хвилюватись за відсутність повноцінної CLI не варто.
Vue.js
Це фреймворк, який знайшов баланс між обмеженнями та гнучкістю. Його ядро вирішує передусім задачі представлення даних, тому він легко інтегрується в наявні проєкти поступово. Проте підходить для створення повноцінних SPA (Single-Page-Application) застосунків, адже має повний набір функціоналу.
Завдяки хорошій документації, низькому рівню входу та невеликому розміру досить активно завойовує серця розробників
Він має CLI, маршрутизацію, як Angular, використовує Virtual DOM і має досить швидкий час розробки, як React.
Та все ж таки він має менш гнучкий компонентний підхід, ніж React, а керування життєвим циклом, що відбувається «під капотом» у великих проєктах, може стати проблемою через неочевидність і важкість відлагодження.
З цього можна зробити висновок, що Vue.js круто підходить для розробки більшості вебзастосунків, але якщо треба робити надто складне відображення, звернутися варто до React.
Svelte
Не можу не згадати ще одного цікавого кандидата у світі фронтенду — Svelte. Це принципово новий підхід до розробки фронтенду, адже коли типові фреймворки завантажуються вам у браузер і тоді починають свою роботу, то Svelte є компілятором, що переводить код, написаний з використанням власного синтаксису, в елегантний і оптимізований чистий JS-код. Без Virtual DOM, без абстракцій, лише чистий низькорівневий JS.
І здавалось би, в чому тут переваги, ми втрачаємо всі бонуси, які дають нам фреймворки...
Насправді велика перевага в тому, що нам не потрібно з собою в браузер користувача тягнути сам фреймворк, немає додаткових навантажень, для обраховування Virtual DOM, а також збірник сміття JS може більш ефективно підчищати пам’ять, яку використовує програма.
Варто зазначити, що для великих застосунків, де
З усім тим він активно набирає популярність і може стати новим подихом у світі фронтенду. Але вакансій на цю мить дуже мало. На Djinni станом на 26 серпня я знайшов 6 вакансій. Це говорить про те, що ринок поки не зацікавлений у Svelte і починати з нього свій шлях у світ JS я не рекомендую.
Що обрати початківцю
На мій погляд, найкраще стартувати з чогось гнучкого, що пробачає помилки та дає експериментувати, тому я б рекомендував React та Vue.
React — через величезну популярність і безліч готових шаблонів і статей, в яких ви швидко знайдете приклади вирішення своїх проблем.
Vue — тому що має круту документацію, особисто спілкувався з однією з Core-девів цього фреймворку і знаю, скільки сил вкладає команда в документацію, щоб її можна було читати не як довідник, а як книгу для самонавчання.
Якщо ж ви прийшли зі світу ООП, наприклад з C# чи Java, варто глянути в сторону Angular, адже його чітка структура вам буде знайомою і, найімовірніше, більш зрозумілою, ніж гнучкі React чи Vue.
Світ бекенду
Ми поговорили про фреймворки для створення SPA, що працюють в браузері. Але це не один із напрямків використання JS, після запуску у 2008 році Node.js — платформи виконання JS поза межами браузера, активно почали розвиватись і фреймворки для створення серверних застосунків.
Express
Одним з перших потужних фреймворків став Express.js, який вийшов
Приклад антипатерну Big ball of mud
Проте він чудово виконує свою функцію швидкого прототипування.
А низька крива навчання разом з безліччю готових рішень, відсутністю чіткої структури, яка б’є по руках, досі дає йому таку високу популярність.
Koa.js
Розробники Express в якийсь момент зрозуміли деякі проблеми цього фреймворку та згодом випустили Koa.js. Він будується на основі свого старшого брата, тому дає схожий девелоперський досвід, але доповнює її більшою кількістю спрощень, де вже подумали за вас.
Основними відмінностями є:
- усунення роботи з callback;
- використовується синтаксис async/await;
- з коробки має оброблювач помилок (асинхронних в тому числі);
- підчищає кеш, підтримує узгодження проксі та вмісту ваших кінцевих точок.
Як і Express, може використовуватись для побудови серверних застосунків будь-якого рівня. Попри значну роботу над помилками та більшу ефективність в деяких сценаріях, Koa не став заміною Express, а лише його альтернативою з набагато меншим ком’юніті, тому навряд чи підійде для початківців.
Adonis.js
В ІТ часто відбувається перенесення практик та підходів з однієї мови на іншу. Так ми отримали всім відомий
- маршрутизації;
- управління залежностями (підтримує Dependency Injection);
- обробки помилок;
- розсилки email;
- валідації даних;
- авторизації;
- інтеграції з Redis.
Це все виглядає як «бери і розробляй», без думок про якісь низькорівневі речі та налаштування і дає значні переваги у швидкості розробки.
Загалом вважаю його одним з високорівневих фреймворків, який дійсно круто виконує свою роль «каркаса».
Nest.js
Ще один високорівневий фреймворк з чіткою структурою та підтримкою DI, обов’язковим використанням TypeScript та ООП-підходу.
Його називають «Angular у світі бекенду», і це справді так, адже розробники надихались саме Angular.
Фреймворк має чудовий CLI, структуру, в якій немає права на помилку, хорошу документацію, де можна знайти приклади більшості сценаріїв використання.
Також цікавим фактом є те, що під капотом Nest вміє використовувати різні низькорівневі фреймворки, з коробки це — Express, але з легкістю можна перейти, наприклад, на Fastify.
Fastify
Хоч він має досить низьку популярність, але цей фреймворк я полюбив з першого погляду. Він є потрібною мені серединою між чіткою структурою і свободою.
З одного боку, він подібний за написанням коду до Express, але немає Middlewares, чудово підтримує асинхронну обробку помилок та дає змогу писати чистими функціями.
Має крутий підхід для опису ваших кінцевих точок. Ви перед функцією вашого оброблювача за допомогою JSON схем чітко можете описати, які дані очікувати і які мають повертатись на кожний код статусу.
А ще позиціонує себе як найшвидший Node.js фреймворк і, як на мене, повністю відповідає цьому статусу, це підтверджують open-source бенчмарки, які розміщенні на офіційному сайті:
Бенчмарки з офіційного сайту
Що ж обрати початківцю
Якщо у фронтенді було два схожих варіанти входу, то тут два протилежних — швидкий (Express) та якісний (Next.js)
Express — якщо ви хочете отримати безліч готових рішень, матеріалів і за короткий час писати робочі застосунки, але є великий ризик взяти у свій арсенал антипатерни (від яких досить важко відівчитись, знаю на власному досвіді).
Nest.js — попри велику кількість абстракцій, вважаю його крутим входом в бекенд-розробку, адже його структура змушує вчитись писати правильно, що дуже важливо для бекенд-спеціаліста, адже коли фронтенд в останні роки почав набувати якоїсь чіткої організації коду і підходів, то бекенд вже більше десятка років її має і лише удосконалює.
Світ мобільної кросплатформи
Cordova
Ідея писати один код для двох мобільних платформ з’явилась майже одразу, як тільки виникли дві платформи.Одним з перших, як не дивно, був фреймворк на JS під назвою Cordova (який спочатку називався PhoneGap). Його перший реліз відбувся у 2009 році.
Це браузер (Web View), загорнутий у значок мобільного застосунку.
Можна розробляти на всьому, що є у фронтенд-розробці, і обновляти сторінку під час розробки через F5 чи налаштувати повноцінний проєкт на React, Vue чи Angular.
Це досить низькорівневий фреймворк, набір бібліотек для роботи з API мобільної платформи та зв’язування їх з WebView.
З часом Cordova обросла різними шаблонами та збірками на різних вебтехнологіях, але великою проблемою був вигляд, ніхто не хотів бачити просто сайт у смартфоні, хотілось щось схоже на нативний застосунок.
Ionic
Рішенням цієї проблеми став Ionic, який базувався на Cordova, мав власну бібліотеку UI-компонентів, які давали можливість робити застосунок схожим на нативний.
Спочатку фреймворк давав змогу розробляти лише на Angular, але в
Вийшло непогане рішення, щоб накидати прототип на тому, що знаєш (або знає твоя команда), щоб швидко оцінити його релевантність.
Хоча деякі серйозні застосунки працюють на Ionic і непогано себе показують з точки зору швидкості і потреби в ресурсах.
NativeScript
Та WebView це не єдиний підхід, за допомогою якого можна запхнути наш JS на мобільні девайси.
Фреймворк під назвою NativeScript зробив це досить цікавим способом. За допомогою рефлексії прокидається API, на стороні JS відбувається робота з ним.
На практиці це виглядає так, ніби ви пишете, наприклад, на Java, але через обгортку JS.
Клас на Java
Модуль-обгортка на JS
Використання в JS
В результаті отримуємо скомпільований JS-бандл, який виконується в JSCore (іOS) чи V8 (Android) і спілкується з платформою через міст.
З рисунка бачимо, що писати можна за допомогою Angular та Vue. Також розробники постарались над оточенням для розробників і надають готовий набір UI-компонентів, «пісочницю», а також плагін для дебагінгу у VSCode.
Загалом вийшла хороша альтернатива Ionic/Cordova, яка показала світу, що мобільна розробка на JS реальна і це може бути не лише замаскований браузер.
React Native
Як ви помітили, NativeScript не має підтримки React. Тож чого і потрібно було чекати, в результаті хакатону з’явився React Native. Ціль розробників була показати, що React можна застосувати для будь-якого рушія рендерингу віртуального DOM-дерева, навіть якщо це мобільна платформа.
Перший реліз відбувся 2015 року. І саме React, який став за основу, став причиною популярності фреймворку. Зараз це стандарт кросплатформи на JS, який часто використовують для Enterprise-рішень.
Під капотом цей фреймворк дуже схожий до NativeScript, але з кращою абстракцією API, де нативні плагіни пишуться на стороні платформи (і можуть бути розширені самими розробниками застосунку), а з JS в них передаються лише параметри через міст. За рендер відповідає кросплатформовий фреймворк — Yoga, який реалізує flexbox layout на цільовій платформі.
React Native має широкий набір інструментів серед яких: CLI, дебагер, hot reloader, різні бібліотеки компонентів (наприклад, Material UI, Ant Design), а також безліч готових рішень, які дає сам React.
Хоча я сам не прихильник кросплатформи на JS, мені більше симпатизує Flutter з мовою Dart. Але у своїх проєктах ми не раз задумувались над тим, щоб брати в озброєння React Native, особливо коли вебверсія проєкту написана на React.
Що вибрати початківцю? Загалом я не вважаю, що кросплатформа є хорошим вибором для початківця в JS. Але якщо ж вам все-таки цікаво спробувати писати під смартфони, обирайте React Native, у вас хоча б буде підтримка ком’юніті і тисячі питань та відповідей на Stack Оverflow.
Висновок
Ми розглянули понад десяток фреймворків у трьох категоріях. Думаю, цього достатньо, щоб зрозуміти, що, володіючи JS, ви можете писати майже все. Але не варто забувати, що JS не всемогутній і не у всіх сценаріях він є найкращим рішенням. З розглянутих сьогодні — це кросплатформа, вона несе допоміжний характер, наприклад, прототипування чи створення деяких спільних компонент (наприклад, так робить Facebook, пише нативні застосунки і лише відображення рендерить на React Native, не намагаючись на ньому будувати логіку аплікацій).
В цій статті я розглянув лише популярні фреймворки для найбільш поширених сценаріїв застосування, але існують і досить специфічні. Наприклад, Embedded чи GameDev чи Machine Learning.
Тому підсумок такий: на JS-фреймворках можна будувати надійні і великі вебзастосунки, зробити прототип для власного стартапу, швидко автоматизувати рутинні задачі, а також, як я часто говорю, «потикати» майже будь-який ІТ-напрям.
35 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів