In many projects, hooks have become a reflex: they’re added automatically, even where they aren’t needed. But every unnecessary hook adds extra complexity—often without any benefit. In this talk, we’ll explore when hooks are unnecessary and how to write simpler, more readable code without redundant use*.

Do you remember the times when we spent a week configuring Webpack before even starting to code? Now we have a builder deeply integrated with a framework. Do you even know what Vite configuration you have inside your Next.js or Remix.js application? But do we even need this? What are we missing to forget about all these nasty bundlers?! Let's find out!

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.