I have interviewed several hundred front-end engineers. The candidates who struggle are almost never the ones who do not know the current framework. They are the ones who know only the current framework.

Ask what happens when a form submits and you get a description of a hook. Ask what a browser does with a cookie and the room goes quiet.

The half-life of a framework is about three years

Between 2013 and today the default front-end stack has changed four times. Each change threw away most of the specific knowledge and none of the underlying knowledge. HTTP, the DOM, the event loop, CSS layout, how a browser caches things: all of it survived every rewrite.

That is not an argument against learning frameworks. It is an argument about ratio. If you spend nine hours a week studying, roughly six of them should go to things that will still be true in 2032.

What the platform actually means

Concretely, the list is shorter than people expect:

  • HTTP and the network tab. Requests, status codes, caching headers, what a preflight is and why yours is failing.
  • The DOM and events. Bubbling, delegation, why a listener attached in a loop behaves the way it does.
  • CSS layout. Flexbox and grid properly, containing blocks, stacking contexts.
  • The event loop. Microtasks against macrotasks, and why your promise resolved later than you expected.
  • Forms. Native validation, submission, and the accessibility that comes free if you use the elements as intended.

Five topics. A committed month.

How to test whether you actually know it

Rebuild a feature you have already built with a framework, using no framework at all. Not a whole application: one feature. A filterable list, a multi-step form, a modal that traps focus correctly.

You will discover which parts of the framework you were using as a substitute for understanding. That discovery is the point of the exercise, and it is uncomfortable in a productive way.

Then go back to the framework

Once the platform is solid, framework knowledge stops being memorisation. React becomes a set of decisions about when to re-render, and you can reason about those decisions because you know what the browser is doing underneath.

The Web Development path is built on this order, which is why the first eleven courses contain very little framework code. Students regularly tell us that section felt slow. The same students tell us, about four months later, that it was the part that made everything after it fast.