These are the questions that come up in every project kickoff and get answered differently depending on who is in the room. The honest answers usually depend on one or two specific details — whether search engines need the page, whether anyone else will read the code, whether the API sits on the same origin — so each answer below names the deciding factor rather than picking a side. Where there is a published number, it is here. Where the answer is genuinely "it depends", the thing it depends on is stated.
No, and that changed for a specific reason: the layout problems frameworks existed to solve are now native. Flexbox and Grid replaced the twelve-column float grid entirely. Custom properties replaced the Sass variables you needed a build step for. Container queries mean a card can respond to its own container instead of the viewport, which is something no utility class could do. Nesting works natively, and :has() gives you a parent selector.
Where a framework still earns its place is consistency across a team. Tailwind's value is not that it writes CSS for you, it is that four developers cannot invent four spacing scales. A component library like Radix or shadcn/ui earns its place differently — accessible dialogs, comboboxes and menus are genuinely hard, and rewriting focus trapping per project is a bad use of a week.
When first paint is a business metric or search engines need the content. A marketing site, documentation, an e-commerce catalogue: render on the server, or better, prerender at build time so there is no server in the path at all. A dashboard behind a login has nothing to gain — nobody is indexing it, users arrive once and stay for twenty minutes, and SSR adds a server, a hydration mismatch class of bug, and a rule that half your code cannot touch window.
The middle option people forget is static HTML with a small amount of client-side fetching. If the page is 95% the same for everyone, prerender it and fetch the personalised strip after load.
The DOM API absorbed most of it. document.querySelectorAll covers selection, classList covers class manipulation, fetch covers ajax, closest and matches cover traversal, and element.animate() plus CSS transitions cover the effects. For a page that needs interactivity but not a framework, Alpine.js or htmx gives you declarative behaviour in attributes at a fraction of a React bundle. The genuine reason to keep jQuery is an existing plugin you have no budget to replace, and that is a legitimate reason.
Reserve the space before the content arrives. Put width and height attributes on every image and video so the browser can compute the aspect ratio from markup, or set aspect-ratio in CSS. Give ad slots and embeds a fixed min-height. Never inject a banner above existing content after load — render it in the initial HTML hidden, or dock it to the viewport. For fonts, use font-display: swap with size-adjust on the fallback so the swap does not reflow the paragraph. Skeleton placeholders should match the real content's dimensions, not be a generic grey box that turns out to be shorter.
There are published thresholds, measured at the 75th percentile of real visits rather than on your laptop: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, Cumulative Layout Shift at or under 0.1. INP replaced First Input Delay because FID only measured the first interaction and almost everyone passed it while their app still felt sluggish on the fifth click.
Lab tools are for diagnosis, field data is for judgement. A Lighthouse score of 95 on a fast connection means little if your users are on mid-range Android phones. If one number is failing, LCP is usually an unoptimised hero image or a render-blocking font, and INP is usually a long JavaScript task blocking the main thread.
If it is under about 500 lines and you will never revisit it, no — the config and build cost outweighs the benefit. Past that, yes, and the deciding factor is not size but whether anyone else reads it. TypeScript's real payoff is refactoring: renaming a field and having the compiler list all 40 call sites is the thing you cannot get any other way. You can also get most of the editor benefit without a build by writing JSDoc type annotations in .js files and running tsc --checkJs --noEmit in CI.
In an httpOnly cookie, not in localStorage. Anything in localStorage is readable by any JavaScript on the page, which includes every dependency and every analytics snippet, so one compromised package exfiltrates every session. An httpOnly cookie cannot be read by script at all.
The cost of cookies is CSRF, which you close with SameSite=Lax or Strict, plus Secure, and a token check on state-changing requests if your API sits on a different origin. Keep access tokens short-lived, around 15 minutes, with a refresh token that rotates on use so a stolen one is detectable. If you must hold an access token in the browser because a third-party API demands a bearer header, keep it in a JavaScript closure in memory and never persist it.
Free tools, guides, and resources across the SPUNK13 network.
Visit spunk.bet400+ Free Tools