Building the Hands: How to Practise Frontend

You now know more about how the browser works, why CSS behaves as it does, what a framework removes and where the time goes than a great many people who do this professionally.

Open an empty folder and you'll still be slow.

That isn't a failure and it isn't unusual. Reading about frontend and doing frontend are two separate skills, and only one of them is the job. This last article is about crossing that gap deliberately instead of hoping it closes on its own — which, unaided, it mostly doesn't.

Reading about frontend and doing frontend are two different skills, and only one of them is the job.

Why this field manufactures the illusion

Every subject has the gap between knowing and doing. Frontend has two things that make it worse.

Tutorials feel like practice. You follow a video, you type what's typed, the thing works at the end, and the feeling produced is indistinguishable from competence. But following along is recognition — every decision was made just before you needed it. The How to Learn sphere calls this out as the central illusion: the smoothest study experience produces the weakest retention, and the smoothness is exactly the warning sign. Then you open a blank file and there's nothing to recognise.

The fix is unglamorous and completely reliable: close the tutorial and rebuild the same thing from an empty file. Not a different project — the same one, from nothing, with the tab closed. The moments where you get stuck are a precise list of what you didn't learn, delivered for free.

The ground moves. New framework, new build tool, new pattern, new opinion, every few months. That produces a permanent low-level anxiety of falling behind, which pushes people towards breadth — sampling six technologies badly — exactly when depth is what compounds. Which brings us to the most useful piece of career advice in this sphere.

Durable versus expiring

Split what you could learn into two piles, because they have wildly different returns.

Durable — how the browser builds a page, HTML semantics, the cascade and layout, the language and how data is transformed, the DOM and events, async, HTTP and the network, accessibility, performance principles, debugging as a method, how to decide where state lives. None of this has changed meaningfully in a decade, and none of it will by the time you're senior.

Expiring — this year's framework API, the current build tool's configuration, the state library everyone's arguing about, the CSS-in-JS approach of the season. Necessary to do the job today. Substantially different in five years.

The mistake nearly everyone makes is spending most of their learning time on the second pile, because it's what job posts list and what tutorials teach. The people who get durably good invert it: they learn the expiring layer as needed, from the documentation, while spending deliberate study time on the durable one.

There's a practical test. When a new framework appears, someone with the durable knowledge reads its docs and thinks "so this is how they handle derived state and list identity" — a week to productivity. Someone without it starts from zero again, for the fourth time. The concepts were always the transferable part.

Your chunk inventory

The How to Learn sphere describes skill as a library of fused blocks: a chef thinks "the sauté," not twelve steps. Frontend has its own list, and knowing it lets you build the blocks on purpose instead of hoping they accumulate:

A page layout with a sidebar. A responsive card grid. A form with validation and every state. A modal that manages focus. A table with sorting, filtering and pagination. A search field with debouncing. A list with add, edit and delete. Data loading with loading, error and empty states. Authentication and a protected route. A file upload with progress. Infinite scroll or pagination. A theme switch that respects the system setting. A toast notification system.

That's thirteen. An experienced developer given "we need a data table with filters" doesn't reason from first principles — they recall a block, remember the three decisions that matter and the two traps, and spend their attention on what's specific to this product.

You build them the way blocks are always built: by making each one several times, in different contexts, with the result checked. And two details separate practice that works from practice that flatters you.

Interleave. Don't build four card grids in a row. Alternate the types, and before each one, name the approach yourself instead of inheriting it from a tutorial's heading — because real work never tells you which technique the situation needs, and choosing is the skill that goes untrained otherwise.

Space it. Rebuilding the same component from scratch a week later, without opening last time's code, is worth more than an extra hour on the day. The struggle to remember is the mechanism, not evidence you've failed.

The ladder

Projects work best when each rung adds exactly one new hard thing, so the difficulty stays at the edge instead of collapsing into either boredom or panic:

A static page from a real design. Semantics, layout, responsive, accessible. No JavaScript at all.
One interactive component, by hand, no framework. A filterable list, a modal, an image gallery.
A small application in a framework. Components, state, a form. Still local data.
The same thing against a real API. Loading, errors, empty states, race conditions.
Authentication and routing. Protected pages, persisted sessions, URL state.
Something deployed that other people use. Even five people.

That last rung is different in kind, and it's the one most learners never reach. Real users generate feedback nothing else does: the browser you didn't test, the name with an apostrophe, the double-click on submit, the slow connection, the thing everybody misreads. You cannot manufacture that from a tutorial, and one small deployed project teaches more than four unfinished ambitious ones.

Deliberate practice, concretely

The How to Learn sphere's four criteria — work at the edge of your ability, a narrow goal, immediate feedback, immediate correction — translate directly here.

A bad session: "I'll work on my project." A good one: "today I'm working out how a modal traps focus and restores it on close." One narrow thing, at the edge, checkable at the end. You'll know whether you got it, which is the whole point.

And frontend is unusually well equipped for the feedback half. The browser shows the result instantly. The type checker and linter object before you save. The console tells you what broke. A test tells you whether it still works. Each of these is a tightening of the loop, which is the real reason to invest in tooling: it isn't professionalism theatre, it's making the practice loop shorter.

Read code, not only write it

Almost nobody does this, and it's one of the fastest ways to improve.

Read a good open-source component implementing something you've built — a dropdown, a date picker. You'll find the twelve cases you didn't consider, which is what "experienced" actually consists of.

Read your own code from three months ago. Not to fix it: to notice what you can't reconstruct. That's honest feedback on your naming and structure, and it's the delete test from the CSS article generalised to everything.

Read the documentation properly, once. Not searching until something works — actually reading the guide for the framework you use daily. Two hours, and it consistently reveals that you've been working around three things it does for you.

Where feedback comes from

Practice without feedback just makes habits permanent. Four sources, roughly ascending in value:

Automated signals — types, linters, tests, audits. Instant and cheap, and they cover a narrow band.

Comparison against a good implementation. Build it, then read someone else's. Limited to what you can already recognise, and still useful.

Review by another person. Ask for something specific — "is this component's API sensible?" — rather than "any feedback?", which produces nothing.

Real users. Brutal, slow and by far the most valuable.

Notice that all four require finished work. That's the practical reason to finish things: an unfinished project can't be reviewed, tested, deployed or used, so it teaches you almost nothing. Half-built ambitious projects are the most common way learning time gets spent for no return.

Using AI without hollowing yourself out

It writes frontend code well, which makes it genuinely useful and genuinely dangerous while you're learning — because the part it removes, wrestling something into working, is the part where the skill forms.

The AI sphere covers this properly; the short version for here. Attempt first, always. Ask it to explain more often than to write. When it produces code, make it explain each decision, and don't keep a line you can't defend. Use it as a tutor — "why is my version wrong", "what does this error mean", "give me a problem and don't show the answer" — rather than as a delivery mechanism. And check periodically that you can still do it unaided; slower is fine, couldn't-have-done-it is information.

Showing the work

A frontend portfolio is not a wall of clones. Three things beat twelve:

Two or three real projects, deployed, working, at a URL someone can open. Something with real data and real error handling beats a pixel-perfect clone of a famous app, because handling messy reality is the hard part and clones deliberately skip it.

A readme that explains decisions. Why this rendering strategy, what you'd change, what you got wrong first. That paragraph demonstrates judgement, and judgement is what's being hired.

Code someone can read. Clear names, small components, comprehensible structure. Anyone can produce screens.

The whole sphere as one checklist

Twenty articles, in the order you'd actually use them:

Know what the browser does with your files, in what order, and that everything after depends on it.
Choose elements by meaning, then style them — never the reverse.
Expect the cascade to decide, and read the inspector instead of adding !important.
Ask "one axis or two?" before laying anything out, and don't set heights.
Build narrow first, take breakpoints from your content, and size in relative units.
Treat forms as the highest-stakes screen: real form, real labels, right types, honest errors.
Check the second interface — keyboard, focus, names, contrast — before you call it done.
Decide tokens and scoping once, so the stylesheet is still deletable in month six.
Write the language, not the trivia: ===, the falsy seven, references versus values.
Describe transformations as pipelines and don't mutate what others hold.
Know what's underneath the framework: the DOM, events, delegation, cleanup.
Assume nothing waits: check response.ok, parallelise the independent, cancel the stale.
Debug by hypothesis, not by reloading, and keep the three-line bug journal.
Understand the pipeline well enough to name which stage broke.
Use a framework because of the bookkeeping, not because of the job post.
Split by seams, compose rather than configure, and treat props as an API.
Store the minimum, derive the rest, and put shareable state in the URL.
Know when and where your HTML is built, and that the client never enforces permissions.
Let types carry what you'd otherwise remember, and validate at the boundary.
Measure before optimising, and test on a real cheap phone.

Nobody runs all twenty every time. But when something is wrong and you can't say why, the fault is nearly always at a numbered step that got skipped — and this list will find it faster than staring at the screen will.

In practice

Rebuild one tutorial project from an empty file this week. The whole article in one exercise.

Pick your next chunk deliberately from the list of thirteen, build it three times in different contexts, and again a week later from memory.

Set a narrow goal for every session, written down before you start, checkable when you stop.

Spend two-thirds of your study time on the durable pile. Frameworks as needed, from the docs.

Deploy something small this month and get five people to use it.

Reread your own code from three months ago once a quarter, and notice what you can't reconstruct.

Keep finishing things. Small and finished beats large and abandoned, every single time.

Check yourself

Close the article and answer in your own words:

Why does following a tutorial produce confidence without competence, and what's the fix?
Give three durable topics and three expiring ones, and say how you'd split your time.
Name five of the recurring chunks and how you'd build one on purpose.
What does each rung of the project ladder add, and why does the last one matter most?
What's the difference between a bad practice session and a good one?
Why does every source of real feedback require finished work?
What's the honest way to use AI while learning, and what's the self-check?

In short

Knowing how frontend works and being able to build it are separate skills; the gap is normal, and closing it is deliberate work.
Tutorials produce recognition, not recall — close the tab and rebuild the same project from an empty file.
Split learning into durable (browser, language, layout, network, accessibility, debugging) and expiring (this year's framework and tools), and spend most of your study time on the first.
About thirteen structures recur forever; build each several times, interleaved and spaced, naming the approach yourself each time.
Climb a ladder where each rung adds one hard thing, and reach the rung where real people use what you made.
Practise with a narrow goal at the edge of your ability, and use tooling to tighten the feedback loop.
Read good code, read your own old code, and read the documentation you've been skimming for a year.
All real feedback requires finished work, so finish things — small and deployed beats large and abandoned.