Why are modern frameworks once again trying to reinvent reactivity — and what do signals have to do with it? In this talk, we’ll take a look at signals as an attempt to give JavaScript developers fine-grained reactivity tools without extra code, proxies, or memoization. The problem they aim to solve is as old as frontend itself: how to update only what needs updating — and do it predictably. We’ll explore how this approach works, which frameworks have already adopted it, and what the current TC39 proposal means. Most importantly — do signals actually solve the problem, or are they just introducing a new layer of complexity with different syntax?

This talk is a lighthearted yet painfully familiar existential crisis of a frontend developer. We’ll start with simple DOM manipulation, walk through jQuery, SPA, React, and end with some thoughts on server-side rendering — with the help of a certain Twitter thread that turned out to be wiser than most textbooks.

This talk begins with a brief overview of frontend history, mentioning the era of AngularJS dominance and the reasons for its subsequent decline in popularity (particularly its complexity and the rise of React)

I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.

In recent years, I have gained most of my knowledge through reverse engineering, how I did it and what I learned during this period, I decided to share. All this concerns graphic programming, performance, best practices in the frontend.