Frontend

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/: ...

Most microbiome diagrams are flat. Bio-Dynamics tries the opposite: a single Three.js scene that starts as a rotatable body map, then animates into a tissue cross-section when you pick a region — with microbe meshes, SCFA particles, and fog density tied to live simulation state. This post covers the visualization layer. Companion source and the full architecture write-up are in the repository. Companion resource Bio-Dynamics: Microbiome Sandbox Open the live lab, zoom into gut or nasal tissue, then inspect the Three.js scene code on GitHub. github.com/omidfarhang/example-projects/labs/microbiome-sandbox Open live lab View source on GitHub One scene, two modes SceneManager owns a single WebGL scene with two interaction modes: ...

Bio-Dynamics is an educational 3D lab, not a clinical simulator. That constraint shaped every decision in the simulation layer: reproducible ticks, scalar tissue state, capped agent counts, and inflammation that emerges from pressure instead of jumping on every button press. This post walks through the engine design. Companion resource Bio-Dynamics: Microbiome Sandbox Run the live lab or inspect the simulation source — tick engine, golden tests, and full docs in the repository. github.com/omidfarhang/example-projects/labs/microbiome-sandbox Open live lab View source on GitHub Why deterministic? Interactive demos fail the educational test when the same button sequence produces different outcomes on refresh. Readers cannot build intuition from noise. ...