За часів давніх богів, воєвод і царів

• Вебплатформа довго не встигала за тим, що від неї вже хотіли продукти.
• Бравзери поводилися по-різному, а HTML, CSS і JavaScript закривали менше задач.
• Frontend швидко виріс із “трохи скриптів біля сторінки” в окремий застосунок.
• Фреймворки зʼявилися не від хорошого життя.

Фреймворк прийде — порядок наведе

• Компоненти, модулі, роутинг.
• Замість ручного оновлення DOM — залежність від стану.
• Оптимізації, швидкодія, універсальність.
• Збірка, транспіляція, dev server, hot reload та інші небачені дива.

А тепер усе інакше

…просто, просто, просто навпаки…

• HTML, CSS і JavaScript вже мають величезні можливості з коробки.
• Кросбравзерність тепер не проблема, а фіча.
• Часто платформа не лише вчасно наздоганяє реальність, а й іноді випереджає.

Але є одне але

Ми досі «вирішуємо» проблеми десятирічної давності так, ніби надворі досі 2015.

…так, React, я дивлюсь на тебе

…і на твій Virtual DOM

Коли в руках молоток, усе навколо здається цвяхом

• Фреймворк сприймається як частина вимог, а не як окреме рішення.
• Ознайомленість команди й ринок найму маскуються під потребу продукту.
• Найбільший ризик — коли зникає вибір.

Гарбуз перетворився на спорткар

Бравзер уже вміє більше, ніж ми часто від нього очікуємо.

Якщо задача закривається через <dialog>, Popover API, CSS або Custom Elements — починати треба з них.

Не кожен сайт — застосунок

• Інтерактивність ще не робить сторінку повноцінним застосунком.
• Runtime-фреймворк має ціну: вага, складність, залежності й підтримка.
• Якщо задача простіша за стек, ми створюємо проблему ще до першого релізу.

Я схуд. Ваш бандл теж може.

• Типи, транспіляція і всілякі оптимізації досі можуть бути потрібні.
• Але бандлінг уже не завжди є першим кроком.
• Native modules, dynamic import, import maps, preload і caching дають більше варіантів.

То що тепер, викинути {framework_name} на смітник?

так

• Ні. Фреймворки й інструменти досі потрібні для складних застосунків та великих команд.
• Це не означає, що кожну задачу треба вирішувати через повний стек.
• Фреймворк, білдер, роутинг, SSR, CSR та інші слова мають бути відповіддю на потребу, а не ритуалом.

У випадку пожежі телефонуйте 101

А у випадку задачі:

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

Підсумок

• Фреймворки, білдери й tooling досі потрібні.
• Але вони мають зʼявлятися після питання, а не замість нього.
• Не починайте зі стеку. Починайте із задачі.