Frontend

Partner companies ask me to help hire their frontend developers. Not “sit in on the final call.” The work starts in a room with their CTO, someone from HR, and whoever currently leads the development team. I listen to what they think they need. Then I tell them who they can actually use, read the incoming resumes, choose who is worth an interview, and run the loop. I follow the same path for my own team. The difference is who lives with the result. When I hire badly for myself, I absorb it — I mentor the person, or I carry the gap in the sprint. When I hire badly for a partner, they keep the person and I keep the reputation. ...

For years, frontend engineering had a comforting boundary. The backend held the real power: databases, payments, authorization, infrastructure, production secrets. The frontend rendered the interface. It ran in the browser, where users could inspect it, modify it, and ultimately distrust it. That model still contains an important truth. The browser is not a trusted environment. A serious authorization decision cannot depend on what a client-side application chooses to show or hide. ...

For years, the default Angular auth tutorial looked like this: call /login, get a JWT, stash it in localStorage, attach Authorization: Bearer … from an interceptor, and sprinkle a couple of route guards on top. It ships. It demos well. And it quietly trains teams to treat the browser as a safe place for long-lived credentials. It is not. In 2026 the guidance has converged, and it is blunt: Prefer OAuth 2.0 / OIDC with a reverse proxy or dedicated auth provider — not a hand-rolled password form that mints forever-tokens for the SPA. Prefer short-lived access tokens (and refresh handled outside the SPA) over long-lived credentials in the browser. Prefer HttpOnly, Secure, SameSite cookies over storing sensitive JWTs in localStorage or sessionStorage. This post is the practical shape of that advice for Angular apps: why localStorage JWTs lose to XSS, how a Backend-for-Frontend (BFF) or reverse-proxy session keeps tokens off the client, and what Angular still owns — interceptors, CSRF headers, and guards that improve UX without pretending to enforce authorization. ...

At first glance, a client-side JavaScript framework looks like “just” UI code. It runs in the browser, the browser already has security boundaries, and most of the app logic is yours. So what exactly is a “security update” for that framework supposed to fix? The answer is the same whether you use Angular, React, Vue, or anything else in the same role: the framework is not only application code — it is part of the security boundary. It parses templates or JSX, sanitizes HTML, protects against XSS and related request attacks, and in many apps also powers server-side rendering. If the framework makes a mistake in any of those layers, an attacker may be able to steal data, inject script, or break request isolation even though the code ultimately runs in a browser or helps render content for one. ...

Progressive Web Apps sell reliability: installable shells, offline reads, background sync when the network returns. Angular’s @angular/service-worker makes that easy to turn on. Security does not get the same one-liner. A service worker sits between your app and the network with a long-lived cache — which means it can also sit between an attacker and your users’ private data if you treat “offline” as “store everything.” Industry checklists already call out HTTPS everywhere, including service worker scope, and auth guidance keeps warning against patterns that inflate XSS and CSRF risk when sessions go offline. This post is the Angular-shaped version: enforce TLS and a tight SW scope, cache only what is safe to replay, and keep offline UX without parking bearer tokens in IndexedDB. ...

Angular apps are rarely “just Angular.” They sit on the CLI, a pile of third-party libraries, often Nx or another monorepo tool, and a lockfile that quietly doubles every quarter. That surface is where a lot of real risk lives: not in your component tree, but in a transitive package nobody reviewed last sprint. Best-practice write-ups keep repeating the same triad — scan regularly, automate checks in CI, and treat framework updates as security work. The missing piece for many teams is turning that advice into a pipeline that generates an SBOM, fails on high-severity CVEs, and tells humans when something broke — without waiting for someone to remember npm audit on Friday. ...

Angular already sanitizes template bindings. That is necessary and still not enough. XSS keeps showing up through supply-chain scripts, sanitizer edge cases, and the occasional bypassSecurityTrustHtml that “was only temporary.” Content Security Policy is the browser-level seatbelt: even if a payload reaches the DOM, the browser refuses to execute script the policy does not allow. CSP is repeatedly listed as a must-have for Angular apps. Many write-ups still skip the Angular-specific parts: dynamic styles the runtime injects, critical CSS inlining, autoCsp / ngCspNonce / CSP_NONCE, and the temptation to “just add unsafe-inline and unsafe-eval so the build works.” ...

TypeScript 7 has arrived, and the first reaction across the developer world is a mix of excitement, curiosity, and caution. That feels like a healthy response to a release this big. For frontend developers, this is the kind of update that genuinely changes the feel of work. Faster builds, quicker feedback, and lighter editor workflows are not abstract improvements; they make coding more pleasant and less interruptive. This is also a story about reducing friction in daily developer life, not just improving benchmark numbers. In the TypeScript 7.0 announcement, Microsoft says the release can deliver major speedups, with examples from VS Code, Sentry, Bluesky, Playwright, and tldraw showing much faster builds. ...

Shipping an educational lab to a global audience means more than translation strings. Bio-Dynamics adds RTL layout for Persian, keyboard region shortcuts, ARIA live announcements, touch gesture hints, and URL-encoded lab checkpoints so teachers can share a mid-simulation state without a backend. Companion resource Bio-Dynamics: Microbiome Sandbox Try ?lang=fa or copy a lab link after running a scenario — source for i18n and labState.ts is on GitHub. github.com/omidfarhang/example-projects/labs/microbiome-sandbox Open live lab View source on GitHub Lightweight i18n without a framework Locales live in src/i18n/en.ts, de.ts, and fa.ts. A small t() helper resolves dot-path keys with parameter interpolation: ...

The Bio-Dynamics dashboard exposes a lot of buttons: regional stressors, inoculations, environment sliders, and four catalog tabs for strains, prebiotics, postbiotics, and products. The trick is not rendering HTML — it is keeping the catalog honest as content grows. This post explains the data-first layout and the action impact preview panel. Companion resource Bio-Dynamics: Microbiome Sandbox Hover strains and products in the live lab to see impact preview, or browse the catalog TypeScript files on GitHub. github.com/omidfarhang/example-projects/labs/microbiome-sandbox Open live lab View source on GitHub Data catalogs, not hard-coded panels Almost every control maps to a typed catalog under src/data/: ...