#думки_вголос
Де межа між фреймворком та бібліотекою?
Суперечка про те, чи є той же React фреймворком чи простою бібліотекою, точиться уже давно і з перемінним успіхом. Вона не така затята, як таби проти пробілів, але усе ж.

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

Наприклад, той самий Inversion of Control. Якщо коротко, то це принцип, коли контроль за виконанням нашого коду передається зовнішній системі. І в React цей принцип певною мірою закладено ще з найперших версій.

Ми пишемо логіку рендеру та композиції. Однак ми не контролюємо життєвий цикл компонентів, не маємо влади над побудовою Virtual DOM, не впливаємо на те, як і коли саме викликаються хуки. Усе це виконується згідно внутрішньої логіки React і контрлюється саме ним.

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

Тому Angular — фреймворк. Попри те, що він дозволяє користуватися різними бібліотеками для розширення функціоналу, його ядро є незмінним. Роутинг, модульність, компоненти, модель роботи з даними — задано на рівні системи і є самодостатнім набором, аби будувати повноцінні застосунки.

React же з коробки вміє лише генерувати HTML і пропихувати пропси. Це якщо розглядати його в першому наближенні. Звичайно, якщо підійти до задачі нетривіально, то можна взагалі без зовнішніх залежностей створити робочий застосунок, і навіть із роутингом. Але, повірте, не варто, я свого часу розплутував такий код, переводячи його на роутер, і здається мені, що автор його не міг спати через гикавку кілька місяців то точно.

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

Але не реактом єдиним. Візьмемо, до прикладу, Vue. Це бібліотека чи фреймворк? Ви можете почути обидві відповіді. І, що цікаво, обидві будуть вірні. Адже самі автори визначають Vue як прогресивний JavaScript-фреймворк, де прогресивність означає не те, що він стоїть на чолі прогресу, а те, що його функціонал може варіюватися в залежності від ваших потреб.

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

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

На мою думку, важливо розуміти, що таке система, що таке її компоненти, і бачити їхні звʼязки без привʼязки до конкретних інструментів. Це означає, що застосунки на Angular та React мають виглядати для вас ідентично, якщо вони імплементують ідентичну систему. Тут стає трохи заплутано, розумію.

Ми маємо вміти розділяти наш код на абстракції. Бачити не react-компонент чи angular-компонент, а шар представлення. Бачити не redux-store чи ngrx-store, а шар даних. І так далі. Розуміти що таке MVC чи MVVM. І головне — бачити схоже в різних імплементаціях.

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

(цей допис — субʼєктивний настільки, наскільки це може в принципі бути)

@babichdev

***
З вас вподобайка з коментарем. І ще б пару гривень на збір на детектори дронів для 115 бригади на Покровський напрямок.
Дякую, і гарного вам усім початку тижня!