Thirteen Web Development Habits That Outlast the Framework

Why web development resists roadmaps

The web moves faster than any curriculum written about it, which is why every list of what to learn is out of date by the time it has been shared enough times to reach you. Half the tools on a two year old roadmap are now the wrong default and the other half were never necessary.

What survives is not the tool list. It is a set of situations that keep recurring: a page that is slow, a form that lets something through, state that is stored in two places and has started to disagree with itself. Recognise the situation and the tool almost picks itself.

Here are thirteen of those pairings. They are defaults rather than rules, and the point of a default is that it gives you a specific thing to disagree with when your project is genuinely different.

Before you touch a framework

1. A page + a browser → HTML and CSS on their own first. Spend a few weeks with no build step at all. Frameworks are abstractions over the document, the box model and the event loop, and an abstraction over something you have never seen directly is just magic you cannot debug.

2. A small piece of interactivity + the urge to install something → plain JavaScript. A dropdown, a tab strip, a bit of validation. Doing these with the DOM directly teaches you what the framework was actually saving you from, which is the only way to judge whether it is worth its weight on your next project.

3. Data on a page + a question about where it came from → learn the request and the response. What a URL contains, what headers do, what the difference between a 302, a 401 and a 500 tells you. Every web bug you will ever have is somewhere in that round trip, and most developers treat it as weather.

4. A component + a keyboard → semantic HTML. A button element is focusable, announced correctly, activated by space and enter, and free. A div with a click handler is none of those and you will spend a day rebuilding what the browser gave away. Reach for the right element before you reach for ARIA.

Getting the structure right

5. State + two owners → one source of truth. The moment the same fact lives in two places, your job becomes keeping them in sync, and you will lose. Decide which one is authoritative and derive the other, every time, even when duplicating looks easier in the moment.

6. Server data + client state → treat them as different problems. What the user has typed and what the database currently holds have different lifetimes, different failure modes and different staleness rules. Bundling them into one store is the single most common source of mysterious UI bugs.

7. A form + a user → validate on the server, always. Client validation is a courtesy that makes the interface pleasant. It is not a control, because anyone can send whatever they like straight to your endpoint. Do both, and never let the pleasant one be the only one.

When it needs to be fast

8. Slow + a theory about why → open the network tab. Almost every page that feels slow is slow for a boring measurable reason: an oversized image, a blocking script, a waterfall of three dependent requests. Look before you optimise, or you will tune the part that was already fine.

9. Repeated requests + an unchanged answer → cache it properly. HTTP has had a good caching model for decades and most applications ignore it. Correct cache headers on the responses that rarely change will beat almost anything clever you build in front of them.

10. Images and fonts + a page weight problem → start there. Your JavaScript bundle gets all the attention and is usually not the biggest thing on the page. Right sized images in a modern format, and fonts that do not block text from rendering, are the two highest return changes on most sites.

When it meets the real internet

11. A public endpoint + the open web → rate limit it. Anything reachable without a login will be found by something automated, usually within days. Contact forms, search endpoints and anything that sends an email or costs you money per call need a limit before they need features.

12. Anything from the client + a decision that matters → do not trust it. Prices, user ids, roles, quantities. If the browser sent it, treat it as a suggestion and check it server side, because the browser is a piece of software running on somebody else's computer.

13. A deploy + a question about rolling back → ship smaller. The size of a release determines how frightening it is and how long the bisect takes when something breaks. Small frequent deploys are safer than careful large ones, and the safety comes from being able to undo one thing.

What else belongs on this list

Stable identity on lists, so that a key belongs to the item rather than to its position and an insert at the top does not quietly leave three inputs holding the wrong values. The gap between your machine and production, which is nearly always a version, a missing variable or real latency, and which has to be reproduced before it can be fixed. Error and empty states, which are most of what users actually experience and the last thing anyone builds. Real devices, because the phone you test on is nicer than the phone your users have. And search engines, which are simply the largest visitor you will ever have and the one least willing to run your JavaScript.

I would also add one meta heuristic: if you cannot explain what a dependency does for you, you have not chosen it, you have inherited it from a tutorial. Every package is a bet on somebody else's maintenance.

The short version

Learn the document, the box model and the round trip before the framework. Keep one source of truth. Never trust the client. Validate on the server. Cache what does not change. Measure before optimising. Rate limit anything public. Ship small.

The tools will keep turning over, and that is genuinely fine. Every one of the heuristics above was true before React existed and will be true after whatever replaces it, because they are about the browser, the network and the people, and none of those three are being rewritten.