Ще десять років тому ми тягнули в проєкти бібліотеки та фреймворки не від хорошого життя. Це був єдиний спосіб вижити в часи «бравзерних воєн» і не потонути в спагеті-коді. Фреймворки стали нашим порятунком, і ми до них звикли. З того часу веб змінився, а наші звички — ні. HTML, CSS та JS зробили величезний стрибок вперед, але ми продовжуємо автоматично тягнути мегабайти абстракцій, щоб просто відрендерити список товарів, і гордо називаємо це «сучасним стеком». Настав час поставити собі незручні питання: • Що насправді вирішує фреймворк сьогодні, окрім нашого страху залишитися наодинці з чистим JS? • Де межа, за якою «комфорт розробника» стає безглуздим тягарем для продукту? • Чи не став фреймворк просто зручною ширмою, за якою ми ховаємо небажання знати, як працює платформа? Я не закликаю видалити React завтра (хоча…). Але я прагну розібратися: чи досі фреймворки вирішують реальні технічні проблеми, а чи ми створюємо черговий Hello World на реакті просто тому, що вже не вміємо інакше?

Чому сучасні фреймворки вкотре намагаються переосмислити реактивність — і до чого тут signals? У цій доповіді ми подивимось на signals як на спробу дати JavaScript-розробникам інструмент точкової реактивності без зайвого коду, проксі чи мемоізації. Задача, яку вони вирішують, стара як сам фронтенд: як оновлювати лише те, що потрібно — і робити це передбачувано. Ми розберемось, як працює цей підхід, які фреймворки його вже впровадили, і що означає поточна пропозиція в TC39. А головне — чи signals справді розв’язують проблему, чи просто створюють нову точку складності з іншим синтаксисом.

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