TechBlog

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

In How to Stretch Cursor Pro Further, I argued for treating Cursor as the execution layer and routing planning, research, and cheap thinking elsewhere. Ollama got a few paragraphs — enough to explain why local models belong in the pipeline, not enough to actually set them up. This post is the missing piece: install Ollama on Manjaro, pick models for your hardware, and connect local agents that can read your repo, edit files, and run commands without sending code to a cloud API. ...

I use Cursor every day across a lot of codebases — not just one repo. At work that is mostly a large Angular/Nx monorepo plus many smaller web projects. At home it is broader still: playground companion repos tied to omid.dev articles, browser demos on playground.omid.dev, Rust/WASM experiments, Linux tooling, and whatever the next post needs. Agent mode, multi-file refactors, and inline edits are genuinely faster than doing the same work by hand on any of them. ...

In The Zoom-Out, I wrote about the moment a senior developer realizes they don’t know what they don’t know — Corepack, Yarn, Orval, the whole peripheral toolchain that matured while we were busy shipping. That post was about naming the feeling and regaining perspective. Plenty of readers wrote back with the natural next question: “Okay, I get it — the map is huge and I can’t know everything. But how do I actually find the important stuff before I’ve been doing it wrong for five years?” ...

I’ve been using Linux for more than 15 years. I’ve administered servers, tuned kernels, experimented with filesystems, and read countless articles about swap, virtual memory, caching, and performance. I started with Ubuntu 4.x, spent years on Arch-based distributions, and today most of my work happens on Manjaro and Kubuntu. So I was surprised when I stumbled upon a feature that had apparently been helping my system for years without me realizing it: zswap. ...