×

Порівнюємо React, Angular і Vue — найпопулярніші бібліотеки й фреймворки у 2022 році

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Всім привіт! Мене звуть Олександр, і я Team/Technical Lead, Senior Front-end Engineer у компанії TechMagic.

Протягом останнього часу з’явилась й продовжує з’являтись величезна кількість доволі цікавих і різноманітних фронтендних бібліотек і фреймворків для роботи з DOM, зокрема таких як Svelte, Lit, Solid і т.д.

Попри те, що в кожного з цих молодих фреймворків є хороший потенціал, більшість з них є ще доволі «сирими», в плані розміру ком’юніті, кількості доступних бібліотек (розмірі екосистеми), й навіть банальної можливості щось нагуглити у випадку, якщо у вас з ними виникнуть проблеми не описані в документації.

У цій статті, я розповім вам про основні переваги й недоліки React, Angular і Vue. Чому саме цих трьох бібліотек і фреймворків?

  1. З усіма ними мені довелось працювати лише за останній рік.
  2. Саме ці три бібліотеки зустрічатимуться вам у переважній більшості Outsource/Outstaff проєктів.
  3. В них найбільша кількість аудиторії і завантажень на GitHub i NPM.

Порівняння може бути корисним тим з вас, хто досі думає, яку з добре підтримуваних і наймасовіших (читати також, як «найпопулярніших») бібліотек обрати для наступного комерційного проєкту.

React

React або «ReactJS» являє собою бібліотеку для значного спрощення побудови й маніпулювання DOM елементами. Творцем цієї бібліотеки виступає компанія Facebook. Спочатку її розробляли й використовували лише для внутрішніх потреб (тобто безпосереднього написання своєї соцмережі), й лише згодом зробили публічною, надавши до неї доступ широкому загалу програмістів.

У своєму чистому вигляді React і справді є нічим більшим, аніж звичайнісінькою бібліотекою для написання простих фронтендних додатків (при цьому, навіть не Single Page Application), оскільки не містить ані Routing, ані інших додаткових можливостей. Лише відносно нещодавно отримав офіційну можливість використовувати Context API для реалізації доволі простенького state management.

Щоб користуватись React, достатньо додати посилання на бібліотеку у `index.html` сторінку. Найпростіший додаток/компонент з виводом тексту «Hello World» на React наразі виглядає наступним чином:

const HelloWorldComponent = () => {
  const message = "Hello world";
 
  return <div>{message}</div>;
};
 
 
const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(AppComponent);

Для того, аби це запрацювало, також необхідно додати один елемент <div id="root"></div>, щоб нашому застосунку було до чого підв’язатись. Він слугує кореневим елементом для зображення усього нашого застосунку.

По суті всі компоненти у React є функціями, які приймають аргументи й повертають розмітку. Також, варто відзначити, що все, що є нижче за визначення функції AppComponent буде вказуватись лише раз — виключно у файлі «точці входу» застосунку.

Також тут є ще один цікавий момент. Якщо придивитись, функція повертає щось схоже на HTML. React використовує особливий синтаксис — JSX (Javascript Extended). JSX є синтаксичним цукром, котрий приховує набір методів і функцій, покликаних будувати репрезентацію DOM в Javascript (Virtual DOM), під виглядом максимально подібним на побудову HTML DOM дерев.

Також JSX дозволяє «змішувати» HTML i Javascript. До прикладу, ось так може виглядати промальовування списку елементів:

<ul>
 { unorderedListItems.map((item) => <li key={ item.name }>{ item.name }</li>) }
</ul>

Тобто ми просто беремо і «промальовуємо» кожен елемент до <li> з item.name, як ключ і контент цього елемента.

Плюси:

  • Синтаксис є максимально зрозумілим, якщо вам знайомі Javascript i HTML.
  • Крива входу у користування React є максимально пологою.
  • Функціональний підхід до написання компонентів.
  • Основним з найважливіших підходів, які пропагує React, на мою думку, є принцип Immutability. Тобто все, що робиться в межах компонентів, в жодному випадку не має мутувати стану або даних, а лишень створювати нові екземпляри на основі вже наявних.
  • Компоненто-центристський підхід до написання застосунку (тут все є компонентами).
  • Вага бібліотеки — 2.5Kb мінімізована Gzip версія.
  • Підхід до створення екосистеми застосунку — від меншого до більшого. Тобто тут лише ви вирішуєте, що потрібно брати з додаткових бібліотек і пакетів, а що — ні.
  • Стан DOMу зберігається й обчислюється у віртуальному DOMі, що робить React дуже швидким в плані рендерінгу.
  • Юніт тестування є максимально простим, оскільки не потрібно налаштовувати жодного «додаткового» оточення і браузерів для відрендерювання компонентів.
  • Величезна кількість різноманітної інформації про помилки і основні проблеми.
  • Окрім великої кількості бібліотек, призначених спеціально для React, до нього також можна «докрутити» будь-яку Javascript-бібліотеку, було б бажання.
  • Відмінна документація, зокрема доступна й українською мовою, з хорошими прикладами й достойним описом.
  • Велике ком’юніті.
  • Велика кількість різноманітного тулінгу для полегшення процесу роботи й дебагу.
  • Широкий вибір бібліотек під будь-яку задачу і смак.
  • Повноцінна підтримка Typescript при використанні React Create App або ж інших React CLI бібліотек.
  • Регулярно оновлюється і вдосконалюється.
  • Підтримується Facebook.

Мінуси:

  • Оскільки «з коробки» React не включає практично жодних додаткових можливостей, окрім роботи з DOM, необхідно знати або ж вміти добре гуглити потрібні й надійні бібліотеки для тих чи інших завдань.
  • В простоті React криється й головний його недолік — тут можна запросто напартачити, не знаючи best practices передачі пропсів (у Angular — це Inputs і Outputs), декомпонентизації, структурування файлів React додатків, масштабування застосунку в цілому і решти нюансів. Що, з часом (й збільшенням кількості коду), може призвести до вкрай складної структури застосунку для її підтримання й подальшого розширення.

Angular

На відміну від React, Angular, що є продуктом компанії Google, вже є не просто бібліотекою для роботи з DOM, а цілим повноцінним фреймворком, котрий керується принципами MVVM побудови застосунків, й «з коробки» містить зокрема такі можливості, як:

  • CLI для генерування структури файлів різних Angular-конструкцій, структури npm бібліотек, тестування, лінтування і т.д.
  • Ряд бібліотек для самих різноманітних завдань — router, бібліотеки для роботи з формами, анімацією й інші.
  • При ініціалізації проєкту можна доволі тонко налаштовувати те, що з доступних бібліотек буде додано до нього.
  • Засоби лінтування.
  • Karma + Jasmine для Unit i End to End тестування.

Історично, Angular хоча й виник трішки пізніше за React, фактично є переписаною з «нуля» версією фреймворку AngularJS, котрий існував раніше за нього. На початку серед фронтендщиків навіть виникали деякі непорозуміння, оскільки ніхто не розумів різниці між назвами Angular i AngularJS.

Як наслідок, команда розробки фреймворку почала використовувати назви Angular першої версії (для AngularJS) i Angular другої версії (для Angular), аби чіткіше їх розрізняти.

Якщо порівняти Angular з React, то його структура є значно складнішою. Окрім компонентів, тут також з’являються наступні елементи, кожен зі своїм призначенням:

  • Пайпи — свого роду допоміжні функції для трансформації візуального вигляду даних у HTML темплейтах. Наприклад: форматування чисел, дат, валют тощо.
  • Директиви — класи, котрі використовуються для надання додаткового функціонала іншим елементам застосунку. І також поділяються на кілька видів, в залежності від форми взаємодії з елементами (цей момент я пропущу, аби не вдаватись в подробиці). В основному застосовуються у вигляді користувацьких атрибутів елементів розмітки.
  • Компоненти — є елементом для візуального зображення даних. Поєднують в собі стилі, HTML-файл з розміткою, а також JS або TS з логікою компонента.
  • Сервіси — для можливості централізованого зберігання даних і утилітарних методів. Можуть використовуватись Пайпами, Директивами, Компонентами й навіть іншими Сервісами, додаючи їх за допомогою Dependency Injection.
  • Модулі — спосіб згрупувати всі вищеперелічені елементи. В більшості випадків, по функціоналу або ж сторінках.

Аби трішки візуально розбавити цей потік інформації, далі буде приклад того ж простенького «Hello World» застосунку, що й у секції про React, але реалізованого засобами Angular.

Варто відзначити, що тут простим додаванням посилання на бібліотеку в index.html не обійдеться. Прикладу передували ініціалізація структури проєкту за допомогою Angular CLI. Структура вже має в собі всі необхідні файли (зокрема кореневого компонента AppComponent, який я побудував як простий приклад) з підв’язуванням застосунку до DOM, а також налаштуваннями лінтерів, тестів, Typescript і тому подібного.

Також для простоти розмітку було написано в межах властивості template, на противагу винесенню її в окремий html файл з подальшим вказанням шляху до нього у властивості templateUrl.

src/app/app.component.ts

import { Component } from '@angular/core';
 
@Component({
  selector: 'app-root',
  template: `<h1>{{ message }}</h1>`
})
export class AppComponent {
  public message = 'message';
}

src/app/app.module.ts

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
 
import { AppComponent } from './app.component';
 
@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule],
  bootstrap: [AppComponent]
})
export class AppModule { }

Що ви щойно побачили?

  1. Створення простенького AppComponent компонента з розміткою і текстом «Hello World» за допомогою Javascript Class і спеціального декоратора @Component()
  2. Декларування (визначення) цього компонента в модулі AppModule, а також його реєстрацію в якості «вхідної точки» нашого застосунку, шляхом додавання його посилання в масив bootstrap.

На відміну від React JSX, який дозволяє вставляти по суті будь-який валідний JS код в розмітку напряму, Angular здійснює маніпуляції з DOM за допомогою вбудованих директив.
Для прикладу, ось як виглядатиме промальовування списку елементів в HTML шаблоні Angular:

<ul>
 <li *ngFor="let item of unorderedListItems">{{ item.name }}</li>
</ul>

Тобто ми створюємо кілька <li> елементів використовуючи директиву «ngFor», що дозволяє отримати елемент, на який ми його навісили unorderedListItems.length кількість разів.

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

Плюси:

  • Можливість чітко групувати елементи, використовуючи модулі.
  • Є повноцінним фреймворком, що має все необхідне для написання сучасних вебзастосунків і навіть більше.
  • Підтримка Typescript «з коробки». По суті фреймворк є побудованим з прицілом на підтримку Typescript, як однієї з головних ідей.
  • Використання MVVM принципів побудови застосунків, що дає змогу чітко розмежовувати реалізацію бізнес-логіки від її представлення.
  • Завдяки наявності модулів — чудово масштабується, якщо попередньо чітко планувати структуру застосунку й слідувати їй.
  • Dependency Injection — чудовий спосіб передачі лише необхідних залежностей (у вигляді сервісів), у компоненти й інші елементи Angular. Особливо розквітає, коли починаєте писати всілякого роду тести для ваших компонентів, бо дозволяє легко підмінити будь-яку з цих залежностей необхідною вам імплементацією.
  • Документація актуальна і вичерпна, в плані доступних класів, методів і типів. Також містить масу додаткової інформації, зокрема такої, як:
    • Angular coding style guide — офіційний гайд по рекомендованому синтаксису, конвенціях, структурі застосунку.
    • Best Practices, як рекомендації з написання Безпечних і Доступних застосунків, а також підходів для розбиття коду на множину окремих бандлів — Lazy-loading feature modules.
    • І багато чого ще, з повним переліком доступної інформації можна ознайомитись тут.
  • Кількість інформації, доступної в інтернеті щодо будь-якого аспекту роботи, чи певної бібліотеки.
  • Велике ком’юніті.
  • Широкий вибір бібліотек під будь-яку задачу і смак.
  • Регулярно оновлюється і вдосконалюється.
  • Дуже просунуте CLI, котре при цьому також піддається деякій кастомізації (для прикладу Blueprints, для кастомізації генерації компонентів та інших елементів і файлів).
  • Підтримується Google.

Мінуси:

  • Оскільки структура передбачає доволі великий обсяг знань, яким необхідно володіти аби почати писати на Angular, крива входу є доволі крутою. Як наслідок, мінусом є висока складність, порівняно з іншими фреймворками й бібліотеками.
  • В документації подекуди катастрофічно бракує прикладів використання того чи іншого функціоналу, оскільки знання його сигнатури буває недостатньо.
  • Офіційна документація доступна лише сімома мовами. Українська в їх переліку відсутня.
  • Інколи низька швидкість роботи, яку дуже просто «зіпсувати». Але при цьому, якщо знати про те, як працює Angular Change Detection і як в цілому оптимізувати швидкість роботи й завантаження вебзастосунків, стає більш ніж конкурентною.
  • Також мінусом, на мою думку, є пряме мутування властивостей класу для зміни або оновлення стану компонента.

Vue (v2.6.x і трішечки v3.x.x)

Наймолодший з цієї трійки бібліотек/ фреймворків і замикальний — Vue (читається як View). Я навмисне взяв для порівняння саме версію 2.6.х, оскільки це — основна версія, котру зараз використовують на проєктах.

Також більшість нових проєктів, з якими я стикався, створювалась саме на ній, а не Vue 3 (попри те, що його реліз вже місяць чи два як відбувся, станом на той час). Аргументувалось це тим, що третя версія була вкрай сирою й за відгуками дуже нестабільною. У зв’язку з цим, оновлення виходили доволі часто й нерідко містили Breaking Changes.

Vue є свого роду сумішшю Angular i React. З одного боку, у своєму чистому вигляді — це бібліотека для роботи з DOM, та з іншого боку — це фреймворк, в якого навіть є свій офіційний Vue CLI й певна екосистема бібліотек навколо нього.

Vue широко використовує й наполягає на підході Single File Component, щодо написання компонентів, як основному. Його суть полягає в тому, що стилі, розмітка і логіка компонента мають знаходитись в одному файлі. Хоча вона й надає можливість і засоби для розбиття компонента на кілька різних файлів.

Чому, як на мене, Vue є своєрідною сумішшю Angular i React? Спробую відповісти кількома пунктами, котрі продемонструють деякі можливості цієї бібліотеки:

  • Маніпулювання DOM елементами відбувається за допомогою прямого аналога Angular Директив (котрі, між іншим, також називаються Директивами).
  • V2.6 використовує декларативний підхід до написання логіки компонента (так званий Options API). Тобто по суті ми створюємо об’єкт, що містить поля, спеціальні методи й конфігурацію нашого компонента. Та з третього релізу додалась підтримка Composition API, тобто декларація логіки компонента стала візуально максимально подібною на тіло функціональних React компонентів:
    • визначаємо функції, котрі потім можемо використовувати у HTML темплейтах;
    • з’явились хуки, за аналогією з React.

Тобто в сумі своїй Vue 3 дала можливість писати компоненти з синтаксисом написання логіки, як у React, й темплейтами, як в Angular.

  • V2.6 ще використовувала міксіни, ті ж, що й React на ранніх етапах свого існування. Пригадую, що розробники React відкинули це тому, що їх було дуже важко використовувати, а звідси, й підтримувати. Внаслідок цього вони з часом стали поганою практикою й фактично відкинулись ком’юніті. Аналогічна участь, на мою думку, чекає й міксіни та Vue, оскільки використання «домішок», які непрямо додають функціонал компонентам — важко відстежувати й підтримувати.
  • У Vue оновлення стану відбувається прямим мутуванням властивостей компонента. Не для порівняння, але просто факт :)

З огляду на вище описані пункти, пишучи на Vue, і при цьому вже маючи величезний багаж роботи з Angular i React, — з’являються доволі змішані відчуття.

Тепер трішки прикладів. Я згадував про Vue 2.х і Vue 3, тому прикладів буде два, аби покрити другу і третю версії. Та перед цим зазначу наступне: якщо ви хочете використовувати Vue 3 версії без білдів і збірок, тоді це вдасться лише у версіях браузерів, що підтримують Javascript Import, тобто усі сучасні браузери, за виключенням старого IE11.

Ось так виглядатиме наш мінімалістичний Vue 2.6.x застосунок:

<script src="https://cdn.jsdelivr.net/npm/vue@2/dist/vue.js"></script>
 
<div id="root">{{ message }}</div>
 
<script type="module">
  var app = new Vue({
    el: '#root',
    data: {
      message: 'Hello World'
    }
  });
</script>

А ось так виглядатиме наш мінімалістичний Vue 3.х.x:

<script src="https://unpkg.com/vue@3"></script>
 
<div id="root">{{ message }}</div>
 
<script type="module">
  const { createApp } = Vue
 
  createApp({
    data() {
      return {
        message: 'Hello world'
      }
    }
  }).mount('#root')
 </script>

Плюси:

  • Доволі висока швидкість збірки й роботи застосунку в цілому.
  • Можливість писати додатки, як з білд бібліотеками, так і без них.
  • Кількість тулів і бібліотек доволі обмежена, але мінімально допустима. Тому цей пункт в «плюсах», хоча й недалеко від «мінусів».
  • Малий розмір бандлів після білда.
  • Складність: щось середнє між Angular i React, але все ж значно ближче до React. Тому вивчити й розпочати щось писати на Vue мало б бути доволі просто.

Мінуси:

  • Бібліотека підтримується зусиллями команди творця бібліотеки й більшою мірою — ком’юніті. Фінансується бібліотека лише з «пожертв».
  • Наразі кожен Major реліз Vue супроводжувався змінами, несумісними з попередніми версіями.
  • Доволі мінімалістична офіційна документація з обмеженою кількістю доступних мов, хоча й більшою ніж в Angular.
  • У версії 2.6 я зіткнувся з проблемою неможливості зрозуміти деякі помилки, що виникали при розробці, або бодай нагуглити проблеми, котрі виникали по ходу розробки (а виникали вони доволі часто). Тому зазвичай це суттєво підвищувало час пошуку проблем. Тобто інколи консольні помилки не допомагали, а навпаки заважали, оскільки не відповідали причині.
  • Підтримка Typescript у версії 2.6 практично відсутня. Хоча й можлива, але з надзвичайно замороченими способами його додавання, не сумісними з нормальною комфортною розробкою. Підтримка Typescript у версії 3.х стала кращою, але за відгуками досі не дуже позитивно сприймається Vue ком’юніті (принаймні судячи з тих людей, з котрими я мав справу, й статей, які читав на тему). Хоча, можливо, «не дуже позитивна підтримка» більше стосується самого Typescript, в плані «навіщо з ним, якщо можна без нього», аніж зручністю його використання з Vue 3.

Висновок

Ось тут буде дуже суб’єктивно, з яскравими персональними фаворитами й аутсайдерами.

Відверто кажучи, за той час, який я пропрацював з Angular, React i Vue, в мене сформувались наступні думки та враження від кожного з них:

React — супер комфортний, добре підтримуваний, простий в розумінні та написанні, й надзвичайно потужний, якщо старатись писати на ньому «правильно». Тобто, використовуючи класні тулзи, обов’язково Typescript, більш-менш «стандартизовані» й класно задокументовані бібліотеки (якщо це можна так назвати), й хороші підходи до структурування, по типу «Atomic Design by Bred Frost» розбавляючи це все юніт/e2e тестами (й обов’язково TDD, оскільки писати його з React — одне задоволення).

Підходить як для простих, так і для складних проєктів, в залежності від планування й дотримання структури компонентів і файлів. Також при дотриманні цих факторів, добре працює в масштабі.

Anguar — до певної межі комфортний, але потребує повного прочитання наявної документації. Добре підтримуваний з оновленнями, спрямованими як на новий функціонал, так і на вдосконалення комфорту розробки. Дуже потужний і неймовірно класно масштабується, якщо в команді наявний Senior Angular розробник, знайомий з тим, як структурувати такі проєкти правильно в залежності від потреб. Тулзи, Typescript, тестування від Unit до E2E/Integration тестів — буквально вшиті в фреймворк.

Підходить для проєктів вище середньої й високої складності. Зумовлено це тим, що для відносно простих і більшості проєктів середньої складності зусилля на написання модулів, компонентів, сервісів і використання Dependency Injection часто не виправдовує себе, чим лише починає заважати розробці.

Vue — в плані комфорту доволі неоднозначно, оскільки постійно щось сипалось, постійно гуглились помилки й наявні тулзи не дуже спрощували життя. Підтримки Typescript не було, що іще сильніше ускладнювало прослідковування типів й без того заплутаних структур даних. Сам по собі доволі сирий, хоча залишились виключно позитивні враження від швидкості того, як це все компілювалось і в кінцевому результаті — працювало.

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

В цілому, при виборі фреймворку чи стеку бібліотек я завжди керуюсь принаймні наступними запитаннями:

  • Наскільки популярною й стабільною є бібліотека?
  • Наскільки надійною є підтримка бібліотеки?
  • Наскільки хорошою є документація цієї бібліотеки?
  • Наскільки широкою є екосистема допоміжних бібліотек і тулів бібліотеки?
  • Як добре підтримується Typescript?
  • Наскільки широким є ком’юніті й наскільки важко отримати ту чи іншу допомогу з можливими проблемами?
  • Наскільки складно масштабується (в залежності від потенційного розвитку й розміру проєкту)?
  • Наскільки просто підтримувати версію бібліотеки «свіжою»?

Й, на жаль, Vue, на мою скромну суб’єктивну думку, провалює щонайменше половину цих запитань, як і більшість «нових, хайпових й надзвичайно перспективних» бібліотек.

Тому порадити можу лише наступне — не слухайте нікого, хто каже, що «Angular or React or Vue — це найкраща бібліотека or фреймворк!». Обирайте виключно виходячи з вимог, котрі перед вами стоять, і надійності бібліотек, бо «для кожної задачі — свій інструмент».

👍ПодобаєтьсяСподобалось27
До обраногоВ обраному8
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

В опросе «какой язык программирования изучать?» победил английский.

Ну одном инглише далеко не уедешь.
Много ли филологов с Романо Германских факультетов стали программистами?

Полтора года работаю исключительно с реактом, очень скучаю по ангуляру. Особенно по rxjs (первые полгода страдал, пока привыкал к нему, теперь страдаю без него) и по ngrx (имхо ни react-redux, ни тем более mobx вообще не попадают по удобству использования и структурированности всего). Хотя, конечно, бойлерплейт кода дофига, это минус. Зато нормальные сайд эффекты без всяких нечитабельных саг на генераторах.

Хлопці, шо я вам скажу, треба вже починати дивитись у бік веб компонентів. Бо боротьбу між vue react та angular може виграти lit

Щось так виграє, що у нього вже друга версія, а я за нього тільки почув...
Пишіть такі коментарі більш зважено. А то джун піде вивчить й на цьому закінчить кар’єру.

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

Ну то може проблема не в ньому а в вас? І також якщо не секрет, яка була версія React коли ви вперше про нього почули ? ;)

Якщо серйозно, то веб компоненти — то стандартне API браузера, і його потрібно вивчати не замість, а на додаток до фреймворків, якими ви користуєтесь. Наприклад, intersection observer чи workers це також стандартні API, і їх бажано знати фронтендеру незалежно від того, на якому фреймворку він пише. Так само і з веб компонентами, тим більше що там аж чотири API.

Веб компоненти можна писати взагалі без фреймворків, але з фреймворками дещо зручніше, і lit мабуть найзручніший і найпопулярніший, але є й інші. Stencil від Ionic наприклад, або preact також може.

А то джун піде вивчить й на цьому закінчить кар’єру

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

Тут ще можу додати, що lit — це інструмент для написання саме компонентів, а не застосунків. Це важливо, бо застосунки включають ще багато чого — взаємодію з сервером, routing, state, ssr/ssg та інше.

Тому, якщо ви плануєте писати саме single page frontend застосунки, то react/preact мабуть на зараз це самий правильний вибір, бо має найбільший вибір доступних бібліотек та інтеграцій достатньої якості для широкого кола потреб. Треба тільки впевнитися, що ви використовуєте найбільш сучасну react архітектуру, бо на курсах зараз дають досить застарілу архітектуру і джунам важко буває її відрізнити.

Але якщо це не single page застосунок то шанси на те, що lit буде правильним рішенням зростають.

Зараз для lit немає серйозної інфраструктури саме для написання застосунків, але треба цікавитись їм вже зараз, аби не прогавити час, коли всі на ньому вже пишуть, а ви «тільки за нього почули». Або починати писати самому цю інфраструктуру вже зараз :)

З іншого боку все більше ui бібліотек нового покоління пишуться як framework agnostic core до якого потім додаються адаптери до різних фреймворків, перш за все React. Той же Ionic або Fluent наприклад.

Ну тут багато аспектів, але якщо коротко то різниця у заміні синхронних бібліотек асинхронними та підтримка конкурентного рендерінгу. На заміну redux state який є синхронним за дизайном, і всі асинхронні додатки до нього як thunk або saga тільки вносять зайве ускладнення, до того ж ще будуть потребувати переходу на useSyncExternalStore з 18 версії, використовується apollo або react query які за дизайном вже є асинхронними. Те ж стосується і Suspense, нові роутери з асинхронними завантажувачами та кешем (react router v6.4 або react location router).

Окрім цього нова архітектура — це реюзабельні хуки, композиція хуків та бібліотеки хуків, headless компоненти, esm модулі і сучасні esm бандлери (vite, new parcel, swc/esbuild ), тотальний typescript, ssr/ssg

Ну от якщо одразу так написали, я б згодився без заперечок :)

треба вже починати дивитись у бік веб компонентів. Бо боротьбу між vue react та angular може виграти lit

Скоріш треба просто покласти в голову що web-components вже юзабельні. Але писати на них проект з нуля — ну таке. Якщо ж тільки пет-проект.

Але от якщо є бізнес-задача створити біблиотеку компонентів під великий проект з багатьма командами, тоді вже Lit (або ж аналог) і потрібен, щоб так, створити саме web-компонент, який можна буде засунути будь-куди (навіть у автомобілі, з мого досвіду).

То буде якийсь неправильний джун, бо якщо він сподівається вивчити один фреймворк на всю свою кар’єру

Треба тверезо оцінювати ситуацію по джунах :) Якщо джун вивчає щось вперше, йому треба йти вчити React. Навіть як обожнювач Vue я би сказав джуну йти вчити React. Бо плюс-мінус одне й те ж, але з React роботу точно знайде. Але якщо джун прочитає ваш оригінальний комент, якогось біса без перевірки вирішить піти вчити Lit, витратить на це пару місяців і потім не знайде роботу — мотивація зникне і одним джуном стане менше.

Тож я з вашим коментом повністю згоден. Але так як web-components зараз потрібні лише в випадках коли ти розумієш що вони тобі потрібні, то який сенс йти вчити його? Вивчеться коли потрібно буде. Я б скоріш сказав «можна вже піти ознайомитись з web-components, щоб знати що вони в принципі існують (якщо ще не знав) і їх вже можна юзати у деяких випадках». Але у більшості випадків слід обирати те, де простіше знайди команду з меншими костами. Краще мати двух мідлів React, які знають React краще за своїх друзів, аніж пару Senior зі знаннями web-components, які все одно будуть усувати corner-cases та вигадувати велосипеди, адже екосистема не розвинена.

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

Більше це мабуть дійсно не джунів стосується.

Але якщо цікаво наведу реальний приклад де використання lit навіть зараз є цілком виправданим. Один з наших замовників має платне API, доступ до якого продає як франшизу партнерам та також використовує сам з динамічного UI. Партнери можуть використовувати API зі свого кастомного UI, але зазвичай у них немає своїх розробників, щоб зробити це фахово. Тому ми надаємо готовий UI який можна кастомізувати і додати до статичного сайту / CMS. Раніше таке зазвичай робилось через iframe, але зараз набагато краще робити це саме через веб компоненти.

Тому ми надаємо готовий UI який можна кастомізувати і додати до статичного сайту / CMS. Раніше таке зазвичай робилось через iframe, але зараз набагато краще робити це саме через веб компоненти.

Можеш трохи докладніше?
Є ваші компоненти, що далі з ними роблять користувачі того АПІ?

Компоненти самі використовують API, користувачі просто додають їх до своїх сторінок / сайтів та якщо треба кастомізують їх вигляд під загальний дизайн сайту. Тобто інтеграція не потребує роботи програміста, тільки верстальника

Дякую.
Цікаво подивитись на це.
Є публічні сторінки? Можеш дати посилання?

Ну на робочий проект не можу, NDA, але можу дати посилання на свій pet project з аналогічною концепцією — пишу live chat component для корпоративного сайту потихеньку. Demo можна подивитись тут pragmasoft-ua.github.io/humane-chat-frontend а сам проект тут github.com/...​t-ua/humane-chat-frontend
Дока ще не дописана, але в принципі компонент можна буде додати одним скриптом до будь якої сторінки. Там у демо також є приклад кастомізації кольору.

Ну на робочий проект не можу, NDA

Я мав на увазі саме публічний. Але добре.

посилання на свій pet project з аналогічною концепцією — пишу live chat component для корпоративного сайту

Дуже дякую!

NDA, але можу дати посилання на свій pet project з аналогічною концепцією

НДА не заперечує робити аналогію?

Яким чином?

Поцікавився.
Я не знаю. Може бути різне НДА.

Подивився на Гітхаб.
Я на жаль зовсім не знаю тайп-скрипт. Цей демо компонент працює з якимось бек-ендом?

Бекенд поки пишу. У процесі

Повністю розумію подібні юз-кейси :) Сам невеликий час пропрацював над бібліотекою компонентів, яку використовували команди на різних фреймворках, а дехто й взагалі без фреймворків. Але за 7 років досвіду я не те що тільки один раз пропрацював на такому проекті, а й в принципі бачив подібний проект перший і останній раз, більше навіть в вакансіях подібне не вспливало.

Але так, знати що таке є і це не важко, то є важливо.

Я вважаю що вартий, бо інакше б не писав тут про нього. По перше, веб компоненти — це стандарт, який вже добре підтримується сучасними браузерами. Це має першорядний вплив на розмір фреймворку (а це швидкість завантаження) і швидкість рендерінгу. На відміну від пропрієтарних фреймворків, базовані на стандартах мають шанс жити значно довше, бо стандарти підтримують стабільний інтерфейс. Якщо ви подивитесь на нову генерацію компонентних бібліотек, то зможете помітити, що їх зараз пишуть як веб компоненти, а потім обертають у адаптери для реакту та інших фреймворків.

Побуду занудою, але там помилка в прикладі — const HelloWorldComponent а в рендер передається AppComponent

Моя субʼєктивна думка — на реакті легше зробити 100500 побажань замовника, а на ангуларі швидше наклепати 1001-шу адмінку.
Vue в реальній роботі не пробував

Швидше зробиш на тому, з чим ти найбільше працював)))

Напишу просто контраргументи про Vue, щоб джуни могли опиратись не тільки на вашу суб’єктивну думку :)

1. Наскільки популярною й стабільною є бібліотека?
2. Наскільки надійною є підтримка бібліотеки?
3. Наскільки хорошою є документація цієї бібліотеки?
4. Наскільки широкою є екосистема допоміжних бібліотек і тулів бібліотеки?
5. Як добре підтримується Typescript?
6. Наскільки широким є ком’юніті й наскільки важко отримати ту чи іншу допомогу з можливими проблемами?
7. Наскільки складно масштабується (в залежності від потенційного розвитку й розміру проєкту)?
8. Наскільки просто підтримувати версію бібліотеки «свіжою»?

Й, на жаль, Vue, на мою скромну суб’єктивну думку, провалює щонайменше половину цих запитань, як і більшість «нових, хайпових й надзвичайно перспективних» бібліотек.

1. Роботи валом, на гітхабі зірок найбільше (популярність). Багів у Vue не зустрічав жодного разу (стабільність). Говорити про «мажорна версія має breaking changes» — це які?

Те, що React на слуху, не означає, що він популярніший. Для мене його вічне «на слуху» це «а як мені в React реалізувати ось це, якщо в екосистемі знову суцільні несумісності?» або «я оце робив на тому проекті отак, а на новому нова ліба, хз як це зробити тут».

2. React підтримується Facebook на рівні «як і поки Facebook хоче». Захоче і перестане. Vue ж підтримується комьюніті онлі (спірно, є й донатери компанії) — чи не найнадійніший рівень підтримки? Angular у цьому плані хороший, там відразу цілі створення були націлені й на комьюніті, при цьому за підтримки гугла. Хоча за Angular я хз як комьюніті може впливати на релізи.

3. У Vue імхо найкраща документація. Свого часу я не подужав React не через його складність, а через лайнову документацію, яка була написана під тих, хто вже знає React. За Angular, на жаль, не скажу, але гуглівська організація документації мене завжди вводила в ступор.

4. У React вона широка, комусь це плюс, комусь це мінус. Мені — мінус. Що не проект, то нова «пєрдєлка», яку потрібно зрозуміти і вичитати доку. А що нова «пєрдєлка» робить? Те саме, що й попередня. Angular і Vue мені подобаються тим, що всі їх реалізації роутерів, сторів й тощо вже самодостатні, покриті документацією рівня фреймворку, і повністю повторюють стиль фреймворків. При цьому їх можливостей вистачає ЗАВЖДИ. А джун одного разу вивчивши підхід, далі його лише вдосконалює, а не кидається на нові ліби з проекту на проект.

5. У React і Angular все добре, суперечки немає. Але я у Vue з проблемами не стикався від слова зовсім. Може, я звичайно не так щось роблю, або рівень не той...

6. З Vue отримати допомогу проблем буквально нуль. Чому? Тому що він простіше Angular, при цьому немає того обважування бібліотек що в React. У результаті ВСІ складності, непонятки та «бест-практис» вже сто разів обсмоктали на кожному форумі.

7. На Vue написаний GitLab і з масштабуванням у них все ок. Так це ще мають стару версію. Vue3 набагато більш масштабуємий.

8. Я переклав усі свої проекти, як продакшн, так і пети з Vue2 на Vue3 за пару днів (можливо щось і за тиждень, так). І кілька днів пішли на переписування OptionsAPI на Composition. Якби не переписував, то й за пів дня впорався б. Головне спочатку писати проекти без міксинів. Усі вже сто років як визнали, що це поганий підхід.

У результаті, на мою суб’єктивну думку, вибирайте що хочете, але у Vue проблем імхо менше ніж у React та Angular.

Єдина кардинальна відмінність React і Vue для мене — з React набагато простіше керувати мікро-моментами рендерингу. Він під це буквально написаний. При цьому якщо це робити погано й бездумно (привіт джунам), то можна з todo-app зробити виродка з 25 фпс при рендерингу. У Vue це не проблема, бо Vue під капотом оптимізує дуже багато речей. Але через це у розробника менший доступ до більш точкових маніпуляцій з рендером. Але камон, 95% проектів не вимагають оптимізації рендерингу на такому низькому рівні, як вміє React. А де й вимагають, це робиться практиками не зав’язаними на фреймворк, як то віртуальний скрол чи пагінація.

Дякую за вашуу думку! Хотів написати багато із ого, що ви вказали, але ви встигли раніше)

Поясни, будь ласка — що взагалі мається на увазі під масштабуванням фронт-енда?

Те ж саме що й масштабування бекенду. Тільки на бекенді ти просто підіймаєш нові ноди з новими сервісами й дописуєш магію до куберу, а на фронтенді у тебе є лише один сервіс (твій користувач) і потрібно надіслати і запустити у користувача твій фронтенд так, щоб користувач не всрався. А команда розробників при цьому не всралась додаючи ще один функціональний модуль у проект. Це якщо без подробиць.

Мальовничо, дякую!
Але для себе ще хочу уточнити: мається на увазі, що при всіх наворотах, щоб сторінка (аплікація) все ж завантажувалася у браузері в досить прийнятний термін?

щоб сторінка (аплікація) завантажувалася у браузері в досить прийнятний термін?

Не без цього. Але часто щоб таке зробити при дуже великому проекті, треба уміло розбити фронтенд на різні модулі. Щоб все завантажувалось динамічно, при цьому щоб усюди були лоадери, обробка стейтів (як наприклад реквест на завантаження зафейлився). При цьому у великій аплікації кількість компонентів може розростись до величезної кількості, і треба вміти їх організувати так, щоб опис функціоналу не дублювався (DRY). Плюс це ще ж треба нормально протестувати. А це тільки проблеми JS-UI.

Ще є дорогі операції в воркерах, іноді велика купа закешованих даних в IndexedDB, щоб не турбувати сервер коли не треба (і це треба якось сінкати без костилів), в принципі оптимізація рендеру, аля щоб таблиця на 2000 рядків не вбивала топовий мак, і ще купа і купа всього, пов’язаного навіть з CSS і HTML, як-от critical.css або ж завантаження шрифтів. І це ще ми не говоримо про SSR (Server Side Rendering).

І у всьому цьому Vue точно ніколи не буде заважати :) В принципі як і будь-який інший фреймворк.

Так как работаю с Angular в основном много лет (хоть терпеть его не могу)
Для меня из неприятных минусов это сложность дебага и огромные по 200 линий call stack.
Таким кажется vue и react не страдает.

Обирайте виключно виходячи з вимог, котрі перед вами стоять

Є вимога косити по-більше баксів, який обирати? :D

реакт конечно же. и очевидно убъете второго зайца — всегда будет работа.

Та знаю, итак на нем. Как раз сейчас ищу работу, у проекта бабки закончились (или тикеты, или все сразу)

Є вимога косити по-більше баксів

торгівля забороненими речами, корупція, контрабанда

По-моєму в усіх 3 кейсах треба мати справу з якимись мудаками %)

це фреймворки такі :)

Але в них підтримка потроху закінчується :)

Обирайте виключно виходячи з вимог, котрі перед вами стоять

Є вимога косити по-більше баксів, який обирати?

Він мав на увазі вимоги до тебе (з боку проекту, або замовника), а ти озвучив — твої до життя :)

Прямо сплю і бачу, як я кинув реакт і почав вчити ангулар тому що цьому (одному з тисяч) замовників/проектів це треба :D

Зауваження приймається :)
Мабуть дійсно цього робити не варто у більшості випадків, але можуть бути варіації.

Нехай в тебе все складається, як бажаєш, але можуть знайтися і такі, хто

кинув реакт і почав вчити ангулар тому що цьому (одному з тисяч) замовників/проектів це треба
Вага бібліотеки — 2.5Kb мінімізована Gzip версія.

Интересно, а только с помощью этой библиотеки (без ReactDOM) вообще можно сделать хоть что-то?)

unpkg.com/...​d/react.production.min.js

Надо приглядеться, но кажется этот 2.5Kb gzip код просто делает «ничего»

А если из Vue вырезать всю реактивную часть (defineProperty для 2.6).
То останеться маленький React, такой какой он должен быть.

А если из Vue вырезать всю реактивную часть

То лучше взять preact или inferno.

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

Интересно, а только с помощью этой библиотеки (без ReactDOM) вообще можно сделать хоть что-то?)

Мабуть імпортити ReactDOM

Раз в статье есть субъективное мнение, то вот мое: да, выбирайте, что хотите, хоть в пах колитесь, но только не реакт

ну мнение то субъективное ) Но JSX ? Рили ? Дiйсно ? JSX ? Любой психически здоровый человек скажет, что это это болото, а не сахар. Далее каждый реактовец начинает строить из себя функционального программиста на хаскел и писать чистые функции, потому что срочно нужен иммутабельный стейт иначе как же стабилизировать это бесконечно перерисовуещее себя гавно )

реакт хуки это же чистой воды функциональщина! А в реакте все на хуках. Чистая функция в джс это когда функция детерминированная и не имеет побочных эффектов, мы называем её «чистой» функцией.Также существуют существуют сетевые активности, что противоречит условию что во вне опирается на внешнее изменяемое состояние. Получается что чистая функция это скорее всего условное определение.

мы называем её «чистой» функцией

Мы? Кто мы? И кто они?)

мы это трупрограммисты, если вы не мы, тогда хорошё, я вас вычеркиваю! слово чистая у меня неспроста взято в ковычки...

Ну так треба казати зразу, що функціональщину не осилив, а не видумувати дурниці) А так, по факту, реакт набагато краще монструозного ангуляра з його мутабельним стейтом. JSX — взагалі шикарна штука, повноцінний HTML-подібний цукор поверх JS, а не якийсь розширений псевдоHTML з імітацією if/for як в ангулярі чи vue.

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

Ем, чувак, мій основний профіль — бігдата) Я фронтенд шарю, але вже пару років ним не займався. А в плані функціональщини я пишу на скалі, і на фоні скали функціональщина в жс взагалі суперпримітивна і суперпроста.

і на фоні скали функціональщина в жс взагалі суперпримітивна і суперпроста

то есть ты сейчас подтвердил мои слова, о том что они строят из себя функциональных программистов, а до этого пытался опровергнуть, спасибо, очень интересно с вами общаться )

Хлопцы вы шё гоните, он же один из популярниших на сегодняшний день, React занимает второе место, набрав 165 тысяч звёзд!!!

React занимает второе место, набрав 165 тысяч звёзд

Просто жарт — в нього таке ж 2-ге місце, як у рашанській армії :)
(як воно насправді — не знаю, але якщо фронт ФБ побудований на реакті — не дуже б хотів користатися ним на своєму проекті)

Що воно таке, цей

«used by»

?
Як воно розраховується?
Подивився ще декілька репозиторіїв, нема ніде.

Знайшов.
В цілому цікаво. НЕ знаю чому Вью вимкнули в себе цей показник.
Звісно, що зараз він менше, ніж у Реакт, але здається розрив буде зменшуватись, бо зараз наявно помітно зростання частини Вью у нових проектах.

Хлопцы, а кто использует svelte.dev . Можете написать как оно, тяжело ли перейти на него с реакта?

Не складно, як і на більшість інших фронт-ендних фреймворків і бібліотек. Але документацію і гайди всеодно доведеться перечитати :)
Хоча вони всі й мають схожі риси, та все ж відрізняються одне від одного

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

Дякую за розлогу відповідь. Є питання: React з 2013 року, Anguar — 2016, Vue з 2013. Чи є в 2022 році новий фреймворк (not library) налаштований на motion design?

Вибач, та на жаль із цим я не мав досвіду окрім Material Design (як набору концептів і свого роду правил Motion Design для його втілення), D3 (як найбільш популярної бібліотеки/фреймворку) і їм подібних доволі «старих» бібліотек.
Звісно ж, якщо я вірно тебе зрозумів :)

Є дуже крутий інструмент на базі Реакта саме для моушн-дізайна — www.remotion.dev

Дякую, пропустив момент під час чергового прочитання. Виправив

Дякую за огляд! Мені, як беку, який трохи вміє в React, було цікаво почитати порівняння.

TL;DR
якщо тільки вкочуєшся в FE бери React )

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