Огляд фреймворків JavaScript. Що, для чого і коли використовувати

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всім привіт, мене звуть Олег, я основний 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 і був прямим конкурентом першому ангуляру.

Варто зазначити, що саме в цей час через зростання складності клієнтської частини застосунків виникла професія фронтенд-розробника.

Це був цікавий та бурхливий час, було створено безліч фреймворків і бібліотек під конкретні цілі, і на 2021-й у нас існує три гіганти: Angular (не плутаємо з AngularJS, про який говорив раніше, про різницю можна почитати тут), React, Vue.js. Тож познайомимося з цією трійкою більш детально.

Angular

Angular — це повноцінний MVC-фреймворк від Google з підтримкою Typescript та Web Workers з коробки, а також з прекрасним CLI, за допомогою якого ви можете згенерувати шаблони для компонентів, маршрутів, сервісів за допомогою простих команд командного рядка.

Приклад роботи генерації компоненти «componentname»

Але за «все з коробки» розробники платять великим розміром самого фреймворку, який у 7–8 разів більший за Vue.js чи React.

Завдяки чіткій і жорсткій структурі цей фреймворк є стабільним і надійним, але потребує досить багато ресурсів для написання застосунку, тому рідко використовується для маленьких проєктів, але прекрасно себе почуває в 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 може більш ефективно підчищати пам’ять, яку використовує програма.

Варто зазначити, що для великих застосунків, де 25–50 чи навіть 170 КБ фреймворку це лише 1–2% від усього розміру застосунку, а Virtual DOM дає більше користі, ніж використовує ресурсів, переваги Svelte є несуттєвими.

З усім тим він активно набирає популярність і може стати новим подихом у світі фронтенду. Але вакансій на цю мить дуже мало. На Djinni станом на 26 серпня я знайшов 6 вакансій. Це говорить про те, що ринок поки не зацікавлений у Svelte і починати з нього свій шлях у світ JS я не рекомендую.

Що обрати початківцю

На мій погляд, найкраще стартувати з чогось гнучкого, що пробачає помилки та дає експериментувати, тому я б рекомендував React та Vue.

React — через величезну популярність і безліч готових шаблонів і статей, в яких ви швидко знайдете приклади вирішення своїх проблем.

Vue — тому що має круту документацію, особисто спілкувався з однією з Core-девів цього фреймворку і знаю, скільки сил вкладає команда в документацію, щоб її можна було читати не як довідник, а як книгу для самонавчання.

Якщо ж ви прийшли зі світу ООП, наприклад з C# чи Java, варто глянути в сторону Angular, адже його чітка структура вам буде знайомою і, найімовірніше, більш зрозумілою, ніж гнучкі React чи Vue.

Світ бекенду

Ми поговорили про фреймворки для створення SPA, що працюють в браузері. Але це не один із напрямків використання JS, після запуску у 2008 році Node.js — платформи виконання JS поза межами браузера, активно почали розвиватись і фреймворки для створення серверних застосунків.

Express

Одним з перших потужних фреймворків став Express.js, який вийшов 2010-го, він був побудований на принципі Middlewares, що підняло його на пік популярності та стало приводом для хейту в просунутих колах Node.js розробників. Адже велика кількість мутацій по ланцюгу призводила до довгих та важких пошуків джерела проблем в старому коді. Також з цим фреймворком асоціюють антипатерн Big ball of mud (велика купа бруду), це зумовлено тим, що він дозволяє всю логіку написати в одній функції:

Приклад антипатерну Big ball of mud

Проте він чудово виконує свою функцію швидкого прототипування.

А низька крива навчання разом з безліччю готових рішень, відсутністю чіткої структури, яка б’є по руках, досі дає йому таку високу популярність.

Koa.js

Розробники Express в якийсь момент зрозуміли деякі проблеми цього фреймворку та згодом випустили Koa.js. Він будується на основі свого старшого брата, тому дає схожий девелоперський досвід, але доповнює її більшою кількістю спрощень, де вже подумали за вас.

Основними відмінностями є:

  • усунення роботи з callback;
  • використовується синтаксис async/await;
  • з коробки має оброблювач помилок (асинхронних в тому числі);
  • підчищає кеш, підтримує узгодження проксі та вмісту ваших кінцевих точок.

Як і Express, може використовуватись для побудови серверних застосунків будь-якого рівня. Попри значну роботу над помилками та більшу ефективність в деяких сценаріях, Koa не став заміною Express, а лише його альтернативою з набагато меншим ком’юніті, тому навряд чи підійде для початківців.

Adonis.js

В ІТ часто відбувається перенесення практик та підходів з однієї мови на іншу. Так ми отримали всім відомий C-подібний синтаксис, який має Java, C++, C#, JS, Rust, Go та багато інших мов. Те саме відбувається у світі фреймворків. Прикладом є Adonis.js, розробники якого повторили MVC-підхід популярного PHP-фреймворку Laravel. Це серйозний і надійний фреймворк, у якому за вас подумали за підтримку з коробки:

  • маршрутизації;
  • управління залежностями (підтримує 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, але в 4-й версії додали підтримку React та Vue, а також перейшли з Cordova на Capacitor — проєкт, який дав змогу будь-який вебзастосунок загортати у WebView у мінімальну кількість кроків за допомогою технології PWA (Progressive Web App).

Вийшло непогане рішення, щоб накидати прототип на тому, що знаєш (або знає твоя команда), щоб швидко оцінити його релевантність.

Хоча деякі серйозні застосунки працюють на 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-фреймворках можна будувати надійні і великі вебзастосунки, зробити прототип для власного стартапу, швидко автоматизувати рутинні задачі, а також, як я часто говорю, «потикати» майже будь-який ІТ-напрям.

👍НравитсяПонравилось6
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Что-то не вижу ни от кого комментария про аксиому Эскобара.

Огляд фреймворків JavaScript
React

Оце так розворот

Кажуть шо іноді можна читати трохи далі заголовка. Та і мусолення «реакт не фреймворк» вже трохи підзадовбало.

Кажуть що не варто впихувати те що не впих**ме.

Та і мусолення «реакт не фреймворк»

дивно таке чути що хтось ще щось мусолить.

До "

Світ мобільної кросплатформи

" можна додати flutter

Так флаттер это приблуда на дарте, разве нет? какое отношение она имеет к джс-фреймворкам?

Для бекенду Hapi.js забули)

Пошуком нових рішень, бібліотек та й загалом технологій потрібно займатись ледь не щодня.

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

npm-upgrade для цього існує)

ага, то есть большую часть дня жс разраба вводит в терминал эту комманду

Ах вот откуда раковая идея middleware просочилась в asp.net core. Спасибо express.

А в чем проблема этой идеи?

docs.microsoft.com/...​e.svg?view=aspnetcore-5.0
Все это потихоньку и незаметно становится сложнее чем выучить все ивенты в WebForms.
Я смотрю как дядьки с 15 годами опыта аспнета при переходе на core рвут на себе волосы на стэковерфлоу. В какой ад превращается работа с нескольким AuthenticationSchemes тоже отдельная песня.

Откровенно говоря, WebForms задачи

AuthenticationSchemes

просто не решал.

По-перше, 2020.stateofjs.com/...​ies/front-end-frameworks
По-друге, серед бекенду набагато більше гравців на будь-який смак, зокрема Loopback чи Sails.

1. Ну це як і рейтинг, де Rust найулюбленіша мова. Я хотів показати популярність інтрументів на ринку. Думаю моя помилка в тому, що я додав рейтинг і не пояснив його, на майбутнє буду вважати.

2. Так безумовно, але я з ними взагалі не стикався, та й не хотів перевантажувати статтю

Історію уніфікаціїі та організації JS-коду в бібліотеки і фреймворки можна почати з появи JQuery у 2006 році. В той час браузерів було вже багато, і JS у кожному був свій, тому бібліотека стала срібною кулею для усіх проблем з підтримкою кількох браузерів.

Історію уніфікаціїі та організації JS-коду нужно починати з Prototype.js (2005) та Backbone.js (2010). jQuery до уніфікаціїі та організації JS-коду має лише негативне відношення.

За Prototype.js насправді не чув, буду знати.

А стосовно негативного відношення цілком можливо, але її вплив в будь якому випадку значний і вагомий

вплив дійсно вагомий. Деякі частини jQuery зайшли в спеціфікацію Document Object Model всіх браузерів.

Его (Prototype.js) признали как «bad practice», потому что меняет поведение build-in js объектов и больше старались так не делать.

Всплыло в памяти :)
script.aculo.us

jQuery 1.3 был хорош, вообще пока его писал John Resig.

По части SPA фреймворков есть еще JavascriptMVC, который отчасти был предтечей бэкбона и в котором был свой лоадер StealJS еще задолго до вебпаков и реквайров. KnockoutJS как первый MVVM фреймворк по примеру которого делали первый ангулар. ExtJS великий и ужасный. В общем, не бэкбоном единым.

Основною проблемою є його перевага — потрібно збирати фреймворк самому, з великої кількості бібліотек. Типовий проєкт на React виглядає так: React, React Router, React DOM, Redux, Redux React. Якщо все це упакувати в коробку, вийшов би фреймворк, але це все потрібно робити самотужки.

Не потрібно нічого робити самотужки. Ви маєте можливість взяти create-react-app або Next.js, де є все необхідне.

Так Next.js це і є вже фреймворк на базі React, і є вибір не використовувати його. Згідний що варто було його згадати

React — це не фреймворк, а бібліотека візуалізації, якщо взяти патерн MVC (Model-View-Controller), то React — це лише частина View.

React — це не бібліотека візуалізації. Його неможливо вписати в MVC паттерн замість View. React додатки реализують альтернативний паттерн — Flux.
По друге, React DOM — це не додаткова бібліотека. Без React DOM практично ніхто не застосовує React.

бібліотекі візуалізації це D3.js, Raphaël.js, Paper.js

Дякую за уточнечнення

Щодо візуалізації, я мабуть вжив не вірне слово, хотів більш наглядно дати зрозуміти чим відрізняється React. Стосовно Flux, то це не єдиний патерн з яким можна використовувати React, якщо захотіти можна й MVC використовувати, знову ж таки для більшої наглядності використав саме цей патерн. Ну і по React DOM, так практично ніхто не використовує для Web, повністю згідний, але React можна використати без проблем і з іншими бібліотеками рендеру, знову ж таки є право вибору, тому вважаю її додатковою. Ось тут можна побачити альтернативи цій бібліотеці: github.com/...​in/awesome-react-renderer

React DOM — це не додаткова бібліотека. Без React DOM практично ніхто не застосовує React

Чому це не додаткова бібліотека? Цілком собі. Вона зв’язує React і браузер. Крім браузера реакт компоненти можна рендерити на стороні сервера або в мобільний UI.

Його рідко використовують самотужки

Тут мабуть краще вжити «окремо», аніж «самотужки».

баланс між суворістю і гнучкістю

Мабуть краще написати «баланс між обмеженнями та гнучкістю».

Але це не один із напрямків, після запуску у 2008 році Node.js — платформи виконання JS поза межами браузера, активно почали розвиватись і фреймворки для створення серверних застосунків.

Хмм... Тут непросто зрозуміти що автор хотів сказати.

А інтегровані сценарії захисту — надійності.

Шо?

з чіткою структурою підтримкою DI

Видно автор вже підзаморився, і почались якісь аномалії...

дає змогу писати чистими
Це браузер (Web View), загорнутий у значок мобільного застосунку.

Далі очевидні помилки:

звернувся варто до React
які дають на фреймворки

P.S. Якщо ці помилки будуть виправляти модератори, то потім можна видалити і цей мій комент.

Дякую. Взагалі то добре пишете, але помилок вистачає. Ще б додати підпис до графіку популярності фреймворків. На основі яких даних він складений? Начебто схоже на кількість скачувань, але Angular трохи частіше скачують за Vue, а на графіку Angular десь у дупі внизу

Дякую за конструктив! Повністю згідний всіх зауважень. Врахую в подальших роботах😊

Подписаться на комментарии