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

Ця доповідь — як легка, але дуже знайома екзистенційна криза фронтендера. Ми почнемо з простих маніпуляцій DOM, пройдемо через jQuery, SPA, React, і завершимо роздумами про server-side rendering — не без допомоги одного треду з твітеру, який раптово виявився мудрішим за більшість підручників.

Цей доклад починається з короткого огляду історії фронтенду, згадуючи часи домінування AngularJS та причини його подальшого спаду популярності (зокрема, складність та поява React)

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

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