Ten years ago, we pulled libraries and frameworks into our projects not because we wanted to — but because we had to. It was the only way to survive the “browser wars” era and avoid drowning in spaghetti code. Frameworks became our спасіння, and we got used to them. Since then, the web has evolved — but our habits haven’t. HTML, CSS, and JavaScript have made huge leaps forward, yet we still automatically pull in megabytes of abstractions just to render a simple product list — and proudly call it a “modern stack.” It’s time to ask ourselves some uncomfortable questions: • What problems do frameworks actually solve today — beyond our fear of being left alone with plain JavaScript? • Where is the line where “developer comfort” turns into unnecessary weight for the product? • Have frameworks become just a convenient shield — hiding our reluctance to truly understand the platform? I’m not saying we should delete React tomorrow (although…). But I do want to explore this: do frameworks still solve real technical problems — or are we just building another “Hello World” in React because we’ve forgotten how to do it any other way?

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?

Here you'll hear a story about how a framework can make your life easier in a huge project. Story about our pains, tears and joys at Wix Editor.