Summary
This topic contrasts shipping heavy JavaScript with leaning on native browser capabilities like HTML, CSS, forms, navigation, caching, and built-in accessibility.
Interview Points
- “Code that runs in the browser” often means large client-side JavaScript.
- “Code the browser runs” means using platform features directly.
- Native browser features are usually faster, more accessible, and more resilient.
- Senior frontend architecture should choose JavaScript intentionally, not reflexively.
2-3 Minute Interview Script
“The distinction I like is between writing code that runs in the browser and writing code the browser itself can run. A lot of frontend complexity comes from re-implementing platform features in JavaScript: routing, forms, validation, scrolling, focus, and caching.
At senior level, I try to use the browser as a runtime with built-in capabilities. HTML gives semantics, forms give submission behavior, CSS gives layout and animation, and browser navigation gives history and loading behavior. JavaScript should enhance the experience, not replace everything by default.
This matters for performance and reliability. Less JavaScript usually means faster startup, fewer hydration issues, better accessibility, and less main-thread pressure.
I would not say never build rich client apps. I would say choose client-side complexity when the product needs it, and let the browser carry the work when it already has a robust primitive.”
Follow-Ups
- When is client-side rendering still the right choice?
- What browser features are often underused?