DEV Community: Alexander Thalhammer

Agentic Engineering: What Do AI Coding Tools Do With Your Code?

Alexander Thalhammer — Fri, 05 Jun 2026 08:00:00 +0000

In the first post of this five-part series, I wrote about the LLMs I currently like to use for Angular development. In the second post, I looked at the apps and harnesses around those models: Codex, Claude desktop app, Cursor, Antigravity, VS Code, WebStorm, and a few more. In the third post, I focused on money: subscriptions, API costs, enterprise plans, token usage, reasoning levels, and cost control. I originally planned to squeeze all of this into that costs post, but it quickly became too much for one article, so both topics now get their own. This fourth part is about the less comfortable question behind all of that:

What do we actually share when we use agentic coding tools?

This is where pricing, privacy, enterprise rules, EU regulations, and the very common sentence "We are not allowed to use AI here" all meet.

Is our code safe?

Before I dive in, the usual disclaimer: this is not legal advice, not procurement advice, and not a replacement for your company's security review by an expert. It is my practical view as an Angular builder and coach who cares about using agentic coding professionally without pretending that data protection is somebody else's problem.

TL;DR: Do Not Ban AI, Approve Safe Paths

If you only have thirty seconds, my practical view is this:

personal subscriptions are great for learning, but not automatically fine for proprietary code
"not used for training" does not mean "not retained"
secrets, production data, customer data, and regulated personal data need clear rules
agents don't just read code, they run commands and can be tricked into leaking it, so limit them
companies should approve a few safe tools instead of forcing unofficial workarounds
every generated diff still needs human review

This Is Not a Legal Guide

Same disclaimer as in the previous posts: this is not a scientific benchmark and not a universal buying guide. It is my current opinion as of June 2026, based on my own work with Angular projects, workshops, experiments, and too much time spent reading vendor documentation.

And these details change fast. Vendors change plans, defaults, retention settings, enterprise controls, and subprocessors, sometimes within weeks. While I was writing this series, 3 new models got released (Gemini 3.5 Flash, Composer 2.5 and Opus 4.8). The next model will be out next week I guess (we're waiting for GPT 5.6, right?). Google is folding Gemini CLI and Gemini Code Assist for individual users into Antigravity CLI, while enterprise access remains unchanged. So please check the official pages again before you decide anything for real, and read this as a practical field report.

What Do We Actually Share?

This was the part where I had to do the most research because it is easy to have a strong opinion here without knowing the details. When you use an AI coding agent, you might share much more than the prompt in the chat box.

Depending on the tool and settings, the provider or tool vendor may receive:

your prompt
selected code snippets
open and neighboring files
search results from your repository
diffs
terminal commands and outputs
stack traces
package names and dependency versions
file paths
screenshots
browser state
issue, pull request, and review text
telemetry about accepted suggestions

This does not automatically mean that the provider trains on all of that. Training is a separate question. But AI coding is still a real data-processing workflow.

For an Angular project, this can include product logic, internal architecture, API names, feature flags, business rules, test fixtures, local logs, screenshots, and sometimes personal data.

So the basic rule is simple:

Do not send secrets, production data, customer data, or regulated personal data to AI tools unless your legal and technical setup explicitly allows it.

Agents can see terminal output and files. If your .env files, logs, database dumps, screenshots, or test fixtures contain sensitive data, the agent might see them too – researchers have shown that Codex, Claude Code, and Cursor walk the working directory and can read .env files that .gitignore would normally keep out of sight.

What I Found in Vendor Docs

The exact wording differs between vendors, plans, products, and regions, so I would not treat the links below as a permanent legal answer. But they show why teams have to distinguish between training, retention, product telemetry, enterprise terms, and the actual tool context an agent can see.

Consumer Plans vs Business Plans

This is the most important distinction I found. Consumer plans often have data controls, but you need to check and configure them. Business, enterprise, and API products usually have stronger defaults, especially around model training.

OpenAI's help page on how data is used to improve model performance says individual services such as ChatGPT and Codex may use content to train models unless you opt out, but that it does not train on business products, ChatGPT Enterprise, and the API by default. The Codex plan usage article says the same for Codex.

Anthropic's Claude Code data usage page makes a similar distinction. Free, Pro, and Max users can allow data use for model improvement; for Team, Enterprise, API, third-party platforms, and Claude Gov, Anthropic says it does not train generative models on Claude Code prompts or code under commercial terms unless the customer opts in.

Cursor's pricing page says Privacy Mode, when enabled in settings or by a team admin, keeps code data from being stored by model providers or used for training. The security page adds that it is available to anyone, enabled by default for team members, and backed by technical controls and contractual terms such as zero data retention with model providers; the data-use overview spells out what is and isn't stored.

Google's consumer Gemini story also differs from the Google Cloud one. The Gemini Apps Privacy Hub warns users not to enter confidential information they would not want reviewed or used to improve services. In contrast, the Gemini for Google Cloud data governance docs say it does not use prompts or responses to train models, and the Gemini Code Assist Standard/Enterprise security docs describe coding context as Customer Data.

GitHub Copilot just made this split concrete. In March 2026, GitHub changed its defaults so interaction data from Free, Pro, and Pro+ users can train its models unless you opt out, while Business and Enterprise stay excluded. Independent reporting spelled out what that means for regulated industries, and the Copilot Trust Center holds the current details. Same lesson, fresh example.

So my practical conclusion is:

A personal €20 subscription is great for learning and experimentation, but it is not automatically the right setup for proprietary enterprise code.

Maybe it is allowed in your company after opt-out and review. Maybe it is not. But you should not guess.

No Training Is Not the Same as No Retention

Another thing that is easy to mix up: "not used for training" does not mean "not retained".

Providers may still retain data for abuse monitoring, security, debugging, billing, legal obligations, or product functionality. Some enterprise plans allow custom retention, some API setups offer zero data retention, and some consumer products keep conversation history unless you delete it or use temporary modes.

For example, Anthropic's privacy center says consumer users who do not allow data use for model improvement have 30-day retention, while those who do have 5-year retention.

OpenAI says individual users can opt out of training, and Temporary Chat will not appear in history, create memories, or be used to train models, though feedback may still be used.

Google Cloud says Gemini Code Assist Standard and Enterprise are stateless Google Cloud services and do not store prompts and responses in Google Cloud unless you configure logging.

For a serious company rollout, I would ask every vendor boring but important questions:

Is our code used for training by default?
Can we opt out organization-wide?
What is retained, where, and for how long?
Can we configure retention or use zero data retention?
Do you offer EU or regional processing?
Which subprocessors are involved?
Are human reviewers involved?
How are prompts, responses, diffs, screenshots, terminal outputs, and telemetry treated?
Can admins disable connectors, browser access, MCP servers, cloud agents, or external network access?

If a vendor cannot answer these questions clearly, I would not roll it out broadly in a regulated company.

EU and Regulatory Considerations

Since I work in Europe, I also care about the EU side. For many companies, GDPR is the main topic; depending on the use case, works councils, vendor management, data residency, contractual confidentiality, and the EU AI Act can also become relevant.

The EU AI Act entered into force in 2024 and applies gradually. The European Commission's implementation timeline shows obligations for general-purpose AI models started in 2025, and the Commission's enforcement powers start August 2, 2026 – not far away. For a normal Angular developer using a coding assistant, GDPR and confidentiality are probably more immediate than the AI Act.

In the DACH region, the practical questions are usually a data processing agreement (Auftragsverarbeitung) and EU data residency – German write-ups like this DSGVO comparison of ChatGPT, Copilot, and Gemini and this Claude Code AVV walkthrough are a decent starting point. But if your company builds AI features into products, uses agents in regulated workflows, or lets AI systems influence decisions, the AI Act becomes much more relevant.

For coding agents inside a company, I would keep the policy practical:

classify which repositories may be used with which AI tools
ban secrets and production data in AI context
require approved business, team, enterprise, or API terms for proprietary code
document approved vendors and subprocessors
require human review for generated code
educate developers on prompt privacy and tool permissions

The goal should not be bureaucracy, we have got enough of that.
The goal should be to make AI usage possible without pushing developers into unofficial workarounds.

Green, Yellow, Red

If I had to explain the policy to developers, I would use a very simple traffic-light model.
Not because it covers every legal edge case, but because people actually remember it.

Most real enterprise Angular work lives in the yellow zone. That is why a blanket ban is too blunt, but "just use whatever" is too naive.

"We Are Not Allowed to Use AI"

This is the part where I will be a bit opinionated.

I hear "we are not allowed to use AI" more and more often. Sometimes that is justified: if a company has no vendor review, no DPA, no data policy, no security story, and developers paste sensitive code into random tools, somebody should stop that. But a blanket "no AI" policy is not a serious long-term strategy. It has a hidden cost: the company becomes slower while competitors learn to use these tools safely. Long-term, I don't think that is survivable.

I believe professional software teams need agentic coding to stay competitive. Not because AI magically replaces good engineers. It does not. But because the baseline speed of software work is changing.

If one team can modernize code, write tests, review changes, and explore refactorings faster, the other team cannot keep working exactly as before and expect no consequences.

For Angular teams this is especially relevant. Enterprise Angular projects often have large, complex codebases, old RxJS flows, inconsistent test coverage, slow migrations, and a lot of technical debt – a lot of boring (I personally love it!) but important modernization work. Agentic coding helps with exactly that – if we keep strong human-in-the-loop review and a sophisticated Angular Coding Style Guide.

So I would not argue for "let everybody use everything". I would argue for this:

Do not ban AI. Approve a small number of safe paths and teach people to use them professionally.

That is the better security posture.

A Simple Company Policy

If I had to write a first version of an AI coding policy for an Angular company, I would keep it short:

Use approved tools only (might have to approve them first, a lot of work, but AI can help 😏).
Use business, team, enterprise, or approved API terms for proprietary code.
Use personal consumer accounts only for learning, public code, or explicitly approved use cases.
Do not send secrets, credentials, production data, customer data, or sensitive personal data.
Human review of every generated diff.
Treat AI-generated tests as useful, but not as proof that the implementation is correct.
Control command execution, browser, network, MCP, plugin, and connector access.
Track cost and usage during rollout.
Review the policy every quarter because the tools change too quickly.

That is not perfect, but it is better than either "everything is forbidden" or "everybody can use whatever they want".

My Personal Verdict

For individual developers, my recommendation is simple: use personal subscriptions for learning, experiments, public code, and approved professional work. But do not assume the same subscription is automatically fine for proprietary enterprise code.

For companies, I would not start with a blanket ban. I would start with the safest option developers will actually use: one or two approved business/enterprise tools, a clear data policy, and a serious pilot.

For policy work, I would not try to predict every possible AI use case. I would define a few safe paths, educate developers, and review the setup every quarter.

Agentic Engineering Workshop

This is also why I don't think about privacy and policy in isolation: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, the Angular Skills, and the review workflow belong together.

If you want to learn how to use agentic coding safely with proprietary Angular code – the data flow, the guardrails, and a policy your developers will actually follow – make sure to join our Agentic Engineering Workshop, both in English and German.

In this workshop, advanced Angular developers learn how to move from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

AI coding tools are not just chat boxes. They can read files, search repositories, inspect diffs, run commands, see terminal output, connect to other systems and resolve nasty merge conflicts. That is what makes them useful, but it is also why privacy and governance matter.

For individual developers, the practical rule is simple: do not send secrets, production data, customer data, or regulated personal data unless the setup explicitly allows it. For companies, the practical rule is also simple: do not only say no. Approve a few safe paths, define clear boundaries, and make the official workflow better than the unofficial workaround.

Because the teams that learn to use agentic coding professionally will not only write code faster.
They modernize faster, test faster, review faster, and learn faster – while the teams that refuse to adapt slowly fall behind, until falling behind turns into going broke.

In the next and final post of this series, I'll pull all the threads together – models, harnesses, costs, and privacy – into the agentic coding setup I would actually choose today.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Agentic Engineering: What Does AI Coding Really Cost?

Alexander Thalhammer — Thu, 04 Jun 2026 12:12:26 +0000

In my first post of this five-part series, I wrote about the LLMs I currently like to use for Angular development. In the second post, I looked at the apps and harnesses around those models: Codex, Claude desktop app, Cursor, Antigravity, VS Code, WebStorm, and a few more. This third part is about the annoying but important topic: money.

Actually, money is only one part of the story. The other part is what data we share with these tools and which setups companies can actually use. I first had all of that in this post too, but it became too much for one article. So this part stays focused on costs, and I will cover the data and policy side in the next post.

And yeah, spoiler: if one of the subsidized subscriptions (or in my case all four of them) works for your setup, that is by far the best deal you can currently get. Before I dive in, let me be clear about one thing: I am not trying to sell you anything here, except, well, my brand new Agentic Engineering Workshop 😅. So this post is primarily about informing you about the options that actually exist, so you can make your own decision.

One thought runs through this whole post, so let me say it up front: what matters in the end is not the price per token. It is the cost per accepted, reviewed, merged change. More on that later.

There is also a bigger reason I keep writing about this. In my opinion, too many European teams are still too slow to adopt agentic coding seriously – and that gap will only get bigger. So please help me spread the word, and share these posts with your friends and colleagues!

This Is Still Not a Benchmark

Same disclaimer as in the previous two posts: this is not a scientific benchmark and not a universal buying guide. It is my current opinion as of June 1, 2026, based on my own work with Angular projects, workshops, experiments, and a lot of time spent playing around in Codex and the Claude desktop app.

I also spend some time in Cursor because it is a serious candidate – even more so since Elon is going to buy Cursor later this year (I bet he will), and I want to keep checking where it is going. Antigravity, on the other hand, is more of a tool I test from time to time. I don't use it seriously for my daily Angular work yet, because it still does not feel mature enough compared with Codex, Claude desktop app, and lately also Cursor.

The subscription prices themselves have been pretty stable so far. What changes more often is what you actually get: model access, included usage, rate limits, fast modes, and sometimes the hidden routing behind the scenes. For API and enterprise setups, longer agent runs can also change the real cost directly.

So if you read this in a few months, check the linked pricing pages again. The included usage and enterprise/API details might have changed. One more note on the numbers: the providers list their prices in US dollars, so the euro figures in this post are approximate, not the exact amounts on your invoice. But the general shape of the cost problem will probably stay the same:

subsidized subscriptions are amazing value when they fit your setup
API pricing is much more transparent, but can get expensive quickly
enterprise plans cost more, but also solve a different problem

So please read this as a practical field report, not as procurement advice.

TL;DR: Start With €40 or €60, Upgrade Only Where You Hit Limits

If you are an individual developer, freelancer, trainer, consultant, or working in a setup where these tools are available, I would not start with one tool. If you have no access yet, I would buy at least the €20 subscription from OpenAI and the €20 subscription from Anthropic. That is €40/month, and for me that is currently the most useful starting point.

If you can afford another €20, I would also add Cursor for a month. Then you are at €60/month and you can compare not only the models, but also the apps around them: Codex, Claude desktop app, and Cursor. That is much more useful than reading another benchmark table.

The current pattern is roughly this:

€40/month: OpenAI Plus and Anthropic Pro, the minimum setup I would recommend for serious experiments
€60/month: add Cursor Pro if you want to compare a third strong app workflow
+€80/month per provider: upgrade OpenAI or Anthropic from the €20 tier to the €100 tier when that specific tool becomes your bottleneck
+€100/month more after that: move the same provider from the €100 tier to the €200 tier when you really need the 20x-style heavy-user tier
Cursor upgrades: separate ladder, with €20 Pro, €60 Pro+, €200 Ultra, and €40/user/month Teams
Enterprise: different billing, contracts, usage pools, overages, and usually much more expensive

If you are new to agentic coding, don't worry about the higher tiers on day one. Start with the base subscriptions, learn the apps, and upgrade only where you actually hit limits. That is what I did too.

Today my setup is heavier: OpenAI and Anthropic on the €100 tier, Cursor and Google both on the €20 tier. I don't need all of them every day, but I want to compare them quickly because this space changes so fast.

Why Subscriptions Are Such a Good Deal

These subscriptions are not just API pricing with a nicer UI. They are subsidized product bundles, and agentic coding involves a lot of hidden work: file reads, searches, tool calls, tests, terminal output, diffs, edits, and context compaction. At raw API prices, you would notice that quickly.

That is why subscriptions are so attractive. The providers want developers in their ecosystem, and right now we benefit from that. But the catch is important: these plans are usually meant for humans using the product, not as a cheap backend for your company, CI pipeline, or SaaS product. In larger companies, personal consumer subscriptions also do not match procurement, billing, reporting, and cost control.

So the real first question is not:

Which model is cheapest per token?

The real first cost question is:

Can we use the subsidized app subscription, or do we need a business, enterprise, or API setup?

That one question can easily change the cost calculation by a factor of 10 or more.

The €20 Tier Is for Getting Started

For me, the €20 tier is not only about "cheap access to a model". It is the entry ticket into the whole product around the model. That is why I would not buy only one subscription if I had no access yet. I would buy OpenAI and Anthropic first, and maybe Cursor too.

The important comparison is not only GPT versus Claude versus Composer or Gemini. The important comparison is Codex versus Claude desktop app versus Cursor. These are the super apps where the real workflow happens: repository search, file editing, tool calls, terminal output, diffs, review, cloud tasks, local tasks, and all the little product decisions that make an agent useful or annoying.

So my recommendation is simple: spend €40 or €60 for one month and run the same real Angular tasks through the tools:

migrate a component to signal-based input() and output(), and rewrite a template from *ngIf and *ngFor to @if and @for
add tests for a service with a few dependencies
ask for a code review of a real pull request
try a Git workflow like rebasing one branch onto another and resolving a pile of merge conflicts
describe a bug by explaining the current behavior and the desired behavior, and ask the agent to find and fix it

Then look at the diffs, the review experience, the terminal usage, the verification, and how much steering you had to do. After two or three evenings, you will usually know much more than any pricing table can tell you.

The Current Pricing Picture

Let's look at that pricing table anyway, but only briefly. Again, please check the official pages before you make a real decision, because these numbers are moving targets.

Nothing special to see here. Roughly all three Frontier Labs – OpenAI, Anthropic, and Cursor (SpaceXAI) – have the same pricing, with the minor exception of Cursor offering you the 3x plan for €60.

OpenAI / Codex

For Codex, check the Codex pricing page and ChatGPT pricing page.

Anthropic / Claude

For Claude Code, check Anthropic's Claude pricing page.

Cursor

For Cursor, check the Cursor pricing page.

Google / Gemini / Antigravity

For Google, check the Gemini subscriptions page and the Google AI subscription update.

Copilot

Meh, I would not build a 2026 setup around Copilot anymore. And the pricing story is getting weaker too: GitHub has moved Copilot to usage-based billing today (June 1, 2026), replacing premium request units with AI Credits. So Microsoft's heavy subsidizing of frontier-model usage inside Copilot is over. On top of that, the frontier LLMs are being limited more and more in Copilot. But the bigger point is simple: Copilot is just not the best harness for agentic coding. If you're forced to use it in your company, try starting a revolution. In the end, you might just be securing your employer's survival. Hopefully this post series can support you with that.

Enterprise Is a Different Game

It is easy to look at a €20 subscription and ask why a company should pay so much more. I get that reaction, but enterprise is not "more Plus". It is a different cost model: seats, pooled usage, overages, central billing, usage reports, admin controls, support, and predictable invoices.

The real question is what happens when 50 developers use the tool every day. Tight limits can turn cheap plans into overages, waiting time, retrying, and cleanup.

So I would start with a small pilot. Give a few strong developers two paid setups for four weeks, use them on real Angular work, and measure cost, accepted changes, review time, PR cycle time, and limits.

API Usage: Paying the Real Cost

Subscriptions and enterprise plans hide cost. API usage does not. The official OpenAI API pricing page and Claude API pricing docs currently list USD prices. Converted roughly for comparison, GPT 5.5 is about €5 per million input tokens and €30 per million output tokens, while Claude Opus 4.8 is about €5 input and €25 output.

Per million tokens that sounds manageable, and output tokens are usually much more expensive than input tokens.

Here is the current API price snapshot I would use for agentic coding discussions. Most official pricing pages still quote USD, so treat this as a practical comparison and check billing currency, VAT, and enterprise discounts before you make a procurement decision.

All prices are per million tokens, sourced from each provider's API pricing. The table is deliberately simple: no batch discount, no extra tool-call fees, no VAT, no currency conversion, no enterprise discount.

For IDE-heavy teams, BYOK (bring your own key) can be interesting, no matter whether you live in WebStorm or VS Code. On the JetBrains side, the JetBrains AI plans and Junie BYOK docs allow it, and most VS Code AI extensions offer the same idea: keep the IDE, connect provider keys, pay the provider.

But the catch is how many tokens an agent actually moves per task – and that is the real cost driver I look at next.

Token Usage Is the Real Cost Driver

OpenAI's help page on tokens says one token is roughly four characters of English text. For a coding agent, 200,000 input tokens are not some crazy edge case. Repository instructions, tool schemas, file excerpts, diffs, terminal output, and chat history pile up fast. Anthropic's pricing docs say the quiet part too: tool names, schemas, calls, and results are billed.

At current API prices, one turn with 200,000 input tokens and 20,000 output tokens costs roughly €1.60 on GPT 5.5 and €1.50 on Claude Opus 4.8. Fine once. Annoying after 20 turns. Expensive if the agent starts doing laps.

Prompt caching helps, but it does not make output cheap and it definitely does not fix a messy workflow. So I would not worship token price. A more expensive model can still be cheaper if it gets the work done in fewer turns.

So the number that matters is not cost per token. It is cost per accepted, reviewed, merged change.

The DeepSWE benchmark is the one I currently trust the most. Higher percentages mean stronger benchmark results; further right means better cost efficiency. Sadly it's missing Composer due to the lack of a public API.

This second chart includes Composer – and here it is the most efficient model by far, the best ROI in this comparison. Definitely an option to watch for API usage.

Low, Medium, High, Extra

If token volume is the real cost, the reasoning level is the first dial that changes it. Most tools now have some reasoning setting: low, medium, high, extra, max, and so on. The rule is simple: use the cheapest level that reliably solves the task.

For Angular work: low for tiny edits, medium for normal implementation, high for tricky bugs, component creation and refactorings, and extra/Pro/Max when a bad result would cost much more than the model usage.

In practice, I often just use High as my default (for GPT and Opus), because it is usually good enough and I don't want to waste time tuning. I know I will get hate for this, but the truth is that my time is precious and I don't care as much since I can use the subsidized subscription anyway. And I still have the option to upgrade my sub if necessary 😏

Fast Mode

Reasoning level is one dial; fast mode is the other. Fast mode is interesting because speed matters. If an agent is too slow, I lose focus. But fast mode is also a cost feature. In Codex, speed configurations increase credit consumption. In the Claude API, Fast mode gives faster Opus responses at a premium.

So I would definitely try it, experiment with it, and if your time is really precious, just use it.

How I Would Control Costs in a Team

Cost control is mostly workflow control. I would define simple rules from the beginning:

start with medium reasoning for normal implementation work
use high/extra only when the task deserves it
keep tasks focused
start a fresh thread when the context becomes messy
keep project instructions short and useful
watch terminal output size
keep humans responsible for the final review

This is not only about saving money. Agents are better when the task is clear.

Agentic Engineering Workshop

This is also why I don't think about costs in isolation: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, the Angular Skills, and the review workflow belong together.

If you want to learn how to keep AI coding costs under control and optimize for cost per accepted, reviewed, merged change instead of price per token, make sure to join our Agentic Engineering Workshop, both in English and German.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

The cheapest serious setup today is still a subsidized individual subscription. If you have no access yet, I would start with OpenAI and Anthropic for roughly €40/month, and maybe add Cursor for another €20 for one month. That gives you Codex, Claude desktop app, and Cursor on real Angular tasks, which is much more useful than reading another benchmark table.

Then keep what actually changes your daily workflow. If you hit limits, upgrade the tool that is limiting you: OpenAI or Anthropic from €20 to €100, and only then maybe to €200 for serious heavy use. For companies, the answer may be business or enterprise seats, pooled credits, API usage, or an IDE-based setup with your own provider keys – WebStorm with AI Assistant and Junie, or VS Code with its AI extensions.

So my recommendation is not "buy tool X". Build a small, serious AI coding workflow now, measure cost per accepted, reviewed, merged change, and keep humans responsible for quality.

Teams that learn this professionally will not only write code faster. They will modernize faster, test faster, review faster, and learn faster.

In the next post, I will look at the other half of the question: what we actually share with AI coding tools, and how I would think about privacy, retention, EU regulation, and company policy.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Agentic: Which App/Harness Is Best for Angular Development?

Alexander Thalhammer — Tue, 02 Jun 2026 07:14:46 +0000

In my last post, published yesterday, I wrote about which LLMs I currently like to use for Angular development and promised a follow-up about the apps and harnesses around them. This is that follow-up.

It is the second post in this five-part series. The follow-ups look at costs and the data and privacy side of agentic coding, before a final post pulls everything together into my overall verdict.

From Models to Agent Harnesses

Picking the model is only half the picture. The same Opus 4.7 behaves very differently in a JetBrains chat window, in Claude Code on the terminal, or wrapped in Cursor's agent mode. The harness decides how the model sees your code, how it edits files, how it runs tools, how much it verifies, and whether it feels like autocomplete, a helpful assistant, or a real agent. For serious Angular work, that part matters at least as much as the underlying model.

So this post is about the other half: the apps, IDE integrations, and agentic coding tools I've used over the last few months. I'll move from classic Copilot-style autocomplete to IDE agents and today's super apps, and then explain where Codex, Claude desktop app, Cursor, Antigravity, VS Code, and WebStorm currently fit (or don't) into my daily Angular workflow. I also want to look a little bit at the product philosophy behind these tools, because that often explains the day-to-day experience better than a feature checklist.

This Is Not a Benchmark

Before we go any further, one important disclaimer: this is not a scientific benchmark, not a universal ranking, and definitely not the final truth about AI coding tools. It is my subjective opinion based on my own daily work with Angular projects, workshops, code reviews, refactorings, and experiments over the last few months.

The sketch above is a very simplified overview of the different tools and how I see them in terms of their capabilities and my personal preferences. It is not meant to be an objective comparison, but rather a visual aid to understand my current opinion of these apps and harnesses.

Your workflow might be different. Your team might have different constraints. Your preferred IDE, operating system, budget, company policies, and tolerance for agentic autonomy might lead to a completely different result.

So please, read this post as a practical field report from my current setup, not as a neutral lab test.

TL;DR: My Current Setup

If you only have thirty seconds: my daily drivers for Angular work are currently Codex (with GPT 5.5) and the Claude desktop app (with Opus 4.7), used roughly interchangeably. Codex has the more polished app experience, while the Claude desktop app gives me access to the Opus models I trust most for architecture, design, and larger refactorings. Cursor with Composer 2.5 is a strong third option, especially when speed, cost, IDE integration, or cloud agents matter. Antigravity is interesting but, in my opinion, not yet on the same level. And whenever I do real handcrafting, I still happily switch back to WebStorm.

All of this assumes a strict human-in-the-loop workflow: I review every diff, and I expect every line of generated code to look as if I had written it myself.

My AI Coding Journey

To explain where I ended up, I first need to show the path that got me there. I'll start with the more traditional IDE integrations and then move on to the newer agentic coding apps.

WebStorm + GitHub Copilot

For over a decade PhpStorm (starting in my WordPress era) and later WebStorm have been my main IDEs for web development. So when GitHub Copilot launched, it was a natural choice to try it out in WebStorm. It was one of the first AI coding tools I used, and it had a big impact on how I thought about AI-assisted coding.

I just looked up in my GitHub Billing History and noticed that I've been using Copilot since 2023-10-27. That's exactly 31 months ago. What a journey. For the most part of that time – let's say the first 25 months, I used GitHub Copilot in WebStorm (and VS Code), which was a great way to get started with AI-assisted coding. It felt like a natural extension of the IDE's existing autocomplete features, and it worked well for small code snippets and boilerplate.

However, it also had its limitations. It often struggled with larger code contexts, complex Angular patterns, and multi-file refactorings. In particular, it was usually a step or two behind modern Angular APIs: it kept suggesting NgModule-based code long after standalone components had become the default, leaned on *ngIf and *ngFor instead of the new control flow syntax, and rarely reached for signals, input() or output() on its own. It was more of a helper for writing code than a partner for driving larger coding workflows. And sometimes it just was pretty annoying, suggesting irrelevant or incorrect code that I had to manually reject.

In 2025, I also experimented quite a bit with Cursor. However, I still didn't like the VS Code clone too much and preferred to stay in my beloved JetBrains editors.

WebStorm + AI Assistant + Junie + Opus 4.5

Switch to November 2025 when Opus 4.5 was released. People on social platforms got pretty excited and also some of my friends pushed me to try the new model. So again, I followed the easy path and I started to use the new model through AI Assistant and Junie in WebStorm.

For context: JetBrains AI Assistant is the AI layer built directly into JetBrains IDEs like WebStorm. It gives you the typical IDE-integrated AI features: chat, code explanations, code generation, documentation help, code completion, and smaller edits in the context of the project. The same AI Assistant interface is also becoming more of a hub for different agents and providers, so depending on your setup you can use tools like Junie, Claude, Codex or even Cursor and a lot more from inside the JetBrains workflow.

Junie is JetBrains' own more agentic coding tool. Instead of only answering questions or completing snippets, it can take a task, create a plan, edit multiple files, run commands or tests if you allow it, and iterate inside the IDE.

But then, since I was using Claude Opus 4.6 most of the time, I wanted to experiment with different harnesses for that model. So I came to a new workflow where I used VS Code with the Claude Code extension for my agentic coding.

VS Code + Claude Code + Opus 4.6

A few weeks after Opus 4.6 was released to the public, I think it was around the end of February, I started to look more seriously for the best harness for that model. Until then, I mostly thought about the model itself: is it good enough, fast enough, and useful enough for real Angular work? But the more I compared the different tools, the more obvious it became that the surrounding app matters a lot.

VS Code was a natural candidate for that experiment. I never loved it as much as my JetBrains IDEs, but I knew it well from the work in my Angular Architects workshops, where many participants use it as their main editor. And with the Claude Code extension in VS Code, I had the first setup where Opus really felt stronger because of the harness around it. Suddenly Opus could read across an entire Angular feature folder, follow a signal from computed() back to its source, and propose multi-file edits that respected my standalone-component setup, my routing, and even my providedIn: 'root' services without me having to spoon-feed it the context.

That was the moment where I started to think: OK, this is not only about the LLM anymore. Well and that was even before I tried the Agentic coding apps or what I like to call them super apps for the first time.

Beyond IDE: Agentic Coding Apps (Super Apps)

After using VS Code for my agentic coding for about a month or so, I was ready to start a new journey.

In the screenshot above, you can see the four main apps I currently use for agentic coding: Claude desktop app, Codex, Cursor, and Antigravity. Oh boy, they really look the same, don't they?

To be clear, I strictly follow a human-in-the-loop workflow here. That is because I care a lot about clean code and high-quality code. Some people think that the quality of the codebase does not, or will not, matter anymore in the future. I strongly disagree with that view, although I accept it as a fair point that challenges my own position.

At first glance, these tools look like different skins around the same idea. But the more I use them, the more I think they are actually making different bets. The Claude desktop app feels terminal-first and model-first: give a strong model a lot of tool access and let it work. Codex feels app-first and verification-first: keep the interface calm, use the local environment when possible, and make the agent prove more of its work. Cursor feels IDE- and cloud-first: keep the editor close, but also make it possible to run agents somewhere else and bring the result back into the team workflow.

Claude desktop app + Opus 4.7

That is why I really care about reviewing everything these tools do, and I want every line of code to look exactly as if I had handcrafted it. Since the Claude desktop app and the VS Code extension share the same underlying Claude Code agent harness, the app already felt familiar to me. The Claude CLI is the canonical surface; the desktop app and the VS Code/JetBrains extensions are different front-ends that drive that same harness.

To be honest, I have never been much of a CLI guy (nor Linux – I prefer macOS – but I love Android), so I really prefer using a fancy desktop app. But I fully understand that this is a pure personal preference. And yeah, that's all I can say to that.

So basically, the first one of these super apps that I really used on a day-to-day basis was the Claude desktop app. By the way, it also offers a Co-working tab, which is supposed to be the right choice for knowledge workers, while the Code tab is the choice for us developers.

The big strength of Claude Code is still the terminal story. It met developers where many of them already live, and that is probably one reason why adoption was so fast. The downside is that this also shapes the whole product: images, rich UI, visual verification, and desktop-app polish will always feel a bit different when the canonical workflow is the CLI. I also notice that Claude Code is very willing to spend tokens if that makes the agent feel more capable, for example with subagents or larger parallel explorations. That can be great for difficult tasks, but it is something I want to keep an eye on when cost and focus matter.

For Angular work specifically, Claude Code with Opus 4.7 is the harness I trust most when a task spans the whole stack: introducing a new feature module, migrating an older area to standalone components and signals, or refactoring a non-trivial RxJS pipeline into a cleaner mix of signals and toSignal(). It also handles the boring-but-important parts well, like keeping app.config.ts, route definitions, and lazy-loaded feature routes in sync after a rename.

Codex + GPT 5.5

And that is already a big difference compared with the Codex app by OpenAI, because Codex does not split these workflows into separate apps. Instead, it combines coding and co-working in just one app.

Again, starting to use Codex at the end of April felt familiar because it more or less had the same interface as the Claude desktop app. But from day one, I had the feeling that there were fewer bugs and that the Codex app, and therefore the GPT harness, just worked most of the time.

What I like about Codex is that it usually feels less theatrical. There is less visual noise, fewer little productivity animations, and more focus on the task, the diff, the terminal output, and the verification. That sounds boring, but for me boring is often good when I work on real code. I especially like the direction around using the machine and environment I already have configured instead of pretending that every project is easy to run in a clean cloud sandbox. For an Angular application with local setup, browser checks, environment variables, internal packages, and maybe a slightly weird test configuration, that matters a lot.

And there is another practical detail I really like: Codex can now be controlled from the smartphone while it still uses the desktop machine as the actual working environment. So I can start or continue a task from the couch, the train, or wherever, without moving the whole project into a cloud runner. Of course, I still review the diff properly later, but for keeping an agent moving this is very convenient.

So my personal verdict would be that the Codex app is superior to the Claude desktop app. However, the underlying models in the Claude desktop app, Opus 4.5, 4.6, and 4.7, are still superior to GPT 5.5 in many cases, especially in the fields I mentioned in the last post, such as architecture, design, and more.

In day-to-day Angular tasks, though, the gap is often smaller than the model benchmarks suggest. Codex with GPT 5.5 is very strong at the kind of work that fills most of my week: writing or updating standalone components, generating Vitest or Jasmine specs that actually use TestBed, scaffolding signal-based stores, and producing usable Signal Forms code. Where I still reach for the Claude desktop app is the harder, more design-heavy work, for example shaping a new feature's component tree or untangling a legacy service.

Cursor + Composer 2.5

Once I decided to do a workshop about agentic coding, I realized I had to try out all the available options and not just use my favorite ones. So of course, one candidate for the best super app, or in other words, agentic coding app, is Cursor.

Cursor, basically a VS Code fork, was one of the first IDEs to really focus on agentic coding and agentic workflows, and many people started to use these workflows much earlier than I did. But in the past, let's say at the beginning of 2025, I had the feeling that the code generation was not really good enough for my requirements.

Nevertheless, Cursor recently announced a major deal with SpaceXAI that gives SpaceXAI the option to acquire Cursor for 60 billion dollars, or to pay 10 billion dollars for their partnership instead. So this is no longer only a small IDE story.

So why are Cursor and SpaceXAI such a good match? Because SpaceXAI has huge compute with Colossus 2, while Cursor has strong product usage signals and developer workflow telemetry. Together, they are about to enter, or have already entered, the frontier stage of agentic coding.

By the way, Cursor and Composer 2.5 are also super fast, and they can be a cheap alternative if you really have to pay for the tokens and cannot use the subsidized OpenAI or Anthropic subscription model. But more on the costs of using these tools in the next post.

The part I had underestimated is Cursor's cloud story. I used to think of Cursor mostly as the AI-first VS Code clone. That is still part of it, of course, but the more interesting direction is letting agents run away from my local machine and come back with a result. If your team wants to trigger work from Slack, run several agents in parallel, or give non-developers a safe way to start small engineering tasks, Cursor's cloud agents become much more interesting than the editor alone. Of course, this also makes the data and policy side more important.

For Angular specifically, I found Composer 2.5 most useful for the mechanical kind of refactor: renaming a service across an entire feature, converting a class-based @Input() to the new input() signal API, or rewriting a template from *ngIf/*ngFor to the new @if/@for control flow. It is fast enough to feel interactive, and that speed changes how often you actually run a refactor instead of postponing it.

Antigravity + Gemini 3.5 Flash

A little more than a week ago, Google also announced a new release at Google I/O, where they presented the new agentic coding app called Antigravity 2.0. The interesting thing is that they transformed Antigravity from an IDE with an included agentic coding workflow into a super app similar to the Claude desktop app and Codex. If you compare the user interface to Codex, it almost feels like a one-to-one copy, which is good because I think Codex currently has the best user interface of all the options.

The former IDE is now kind of an integrated sub-app that can be triggered from the Antigravity app whenever needed. This is actually a really good idea, and I like it very much. The same idea already exists in Codex, where you can open your preferred IDE. In my case, that would be WebStorm, of course. For whatever reason, the Claude desktop app is missing that feature.

So while this 2.0 release is definitely a big step in the right direction, I personally don't think Antigravity is competitive with the other options yet. There are two reasons for that. First, the app still feels clunky and buggy, and it has fewer settings than the other apps, so it just does not feel as mature. Second, yes, you can use other models, but I think the real point of using Antigravity is to use it with Gemini models, especially Gemini 3.5 Flash in the new Antigravity 2.0 setup. Usage for models like Opus 4.6 has recently been reduced, and I guess it will be reduced even more in the future.

On Angular tasks, Gemini 3.5 Flash is genuinely capable, and its speed is useful when you want fast iterations over a whole feature module or a long template. But in practice I still see it default to slightly older Angular idioms more often than Opus 4.7 or GPT 5.5, especially around signals and the new control flow. With clear guardrails it gets there, but it currently needs more steering than the other two.

Open Source Alternatives to the Big Ones

Beyond the big names, I would also keep an eye on OpenCode and T3 Code. OpenCode is a solid open-source, terminal-first option if you want a model-agnostic agent and bring your own provider setup. T3 Code is interesting for the opposite reason: it gives you an open-source GUI on top of the agents you may already pay for, like Claude Code, Codex CLI, OpenCode, or Cursor.

But I'm super happy with working in the terminal

Fair enough. If you love the terminal, you can absolutely keep using it, but I no longer think it is obviously the best default for agentic coding. Apps make it easier to review diffs, manage several agents, use screenshots or browser checks, continue from the phone, and turn work into PRs. But that is personal preference, and I don't want to force anybody into my workflow.

If you are still happiest in the terminal, Pi is probably the option I would suggest trying first. It is a minimal terminal coding harness with AGENTS.md support, skills, extensions, tree-structured sessions, and many model providers. It feels less like a sealed product and more like something you can adapt to your own workflow.

Which Coding Agent Harness Would I Choose Today?

Okay, that was either a lot of information to digest, or you were already familiar with all the super apps and IDEs I mentioned. So let's try to summarize the current state of my workflow and which harnesses I prefer for different tasks.

My two favorite tools are definitely Codex and the Claude desktop app. I would put them roughly on par. I use them daily for almost everything, and I feel really lucky that I can use these tools through subsidized subscription models. More on costs in the next post.

While preparing the upcoming workshop, I also found out that Cursor has really become a super app and that it supports agentic workflows very well. All three are capable of code generation, code review, modernization, refactoring, and writing tests in your Angular codebases.

The practical difference is not only which one can solve a given prompt. It is also how it tries to solve it. Claude Code is great when I want to give a strong model a lot of freedom and let it explore. Codex is great when I want a calmer engineering tool that uses my local setup and keeps verification close to the work. Cursor is great when the work should move beyond my own machine into an IDE, browser, cloud, or team workflow.

For Antigravity, however, I still see a lot of work for the Google teams before it reaches the level of the other three apps. And of course, those other apps will continue to improve as well.

For my beloved IDE WebStorm, I see difficult times ahead. I hope the JetBrains team will be able to catch up with the other apps in terms of productivity and usability when using these models for agentic tasks. There is still a big benefit to using IDEs, and they also allow you to choose between several model providers. Even Cursor allows you to do that, whereas Codex and the Claude desktop app want to lock you into one LLM provider.

So today, I'll still stick with Codex and the Claude desktop app. But maybe in a month or so, I might already be switching to the next super app. We will see.

Agentic Engineering Workshop

This is also why I don't think about harnesses in isolation: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, the Angular Skills, and the review workflow belong together.

If you want to learn how to pick the right harness and build a strict human-in-the-loop workflow where every generated line of Angular code looks handcrafted, make sure to join our Agentic Engineering Workshop, both in English and German.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

The main takeaway is simple: the harness matters. A great model in a weak app can feel surprisingly limited, while the same model in a strong agentic workflow can become much more useful for real Angular work. That is why Angular teams should not only ask which model is best, but also which harness, review process, and engineering workflow actually help them ship better code.

For my current workflow, Codex and the Claude desktop app are still my daily drivers. Codex currently feels like the more polished app to me, while the Claude desktop app gives me access to the Opus models that I trust most for architecture, design, and complex reasoning. By the way, Anthropic has since released Opus 4.8, which only underlines the point of this post: the model underneath keeps improving, while the harness around it is what I actually commit to. Cursor deserves a serious look when speed, cost, an IDE-like workflow, or cloud agents matter, and Antigravity is worth watching, but for now it still feels like it needs more time. When I do careful handcrafting, I still switch back to WebStorm.

One thing I learned quickly: don't force the same workflow onto every tool. Codex, the Claude desktop app, Cursor, and even the smaller open-source options work best when you let them shape your workflow a little bit.

So don't get too attached to one app, one IDE, or one vendor workflow. These tools are changing too quickly, so it is worth trying new harnesses regularly and switching when they make your real project work better.

In the costs post, I look at pricing, subscriptions, and cost per accepted change. In the privacy post, I look at what these tools actually receive from your codebase and how I would think about company policy.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Agentic Engineering: Which LLM Is Best for Angular Development?

Alexander Thalhammer — Mon, 01 Jun 2026 20:40:36 +0000

My AI Coding Journey

It's almost six months since my last post on this blog. In that time, my daily work changed rapidly and completely. Until November 2025, I thought AI was not useful for my work in complex enterprise Angular projects, where code quality has to be very high.

But then Opus 4.5 was released to the public on November 24, 2025. I started to experiment with it and quickly found that it could help with real work: code generation, code review, documentation, modernization, refactoring, and a lot more.

The quality surprised me first. Some generated Angular code looked close to how I would have written it myself. The speed surprised me next. Naturally, I felt a bit obsolete, but it was and still is pretty exciting.

The biggest change is not that the latest models write better code. The bigger shift is that using them has become much easier: I no longer need to craft a perfect prompt upfront and hope that the result matches my intent. Instead, the interaction feels much closer to talking to a senior developer: I can describe the problem, add constraints, answer questions, clarify the spec, and let the model help discover what we actually want to build.

If you've been working with AI every day for months, there might not be much new for you in this post. But if you are rather new to Agentic Engineering and want to understand which LLM is best for Angular development, this post is for you.

Comparison from November 2025 (Outdated!)

BTW: SWE-bench itself is also showing its age. I will use more recent coding-agent benchmarks from Artificial Analysis later in this post.

I started using Opus 4.5 through my favorite IDE, WebStorm. But in this post, I don't want to talk about IDE integration, harnesses, and tools yet. That part of the journey deserves its own post. Here, I want to stay focused on one question: which LLM is the best fit for Angular development?

There is no public Angular benchmark, so we have to combine two imperfect sources: existing public coding benchmarks and personal experience from real Angular work. I want to start with the public benchmarks and then move to my own verdict.

TL;DR: My Current Ranking

Which Frontier LLMs Are Relevant for Angular in May 2026?

I personally want to use the best and latest LLMs that I can realistically use for Angular development, so I will mostly talk about frontier models that are generally available through common developer tools, APIs, or IDE integrations.

In my subjective opinion, the most relevant frontier LLMs for Angular development currently are (sorted by release date – earliest to latest):

Opus 4.7 by Anthropic, April 16, 2026
GPT 5.5 by OpenAI, April 23, 2026
Composer 2.5 by Cursor, May 18, 2026
Gemini 3.5 Flash by Google, May 19, 2026

The last two were released to the public only a few days before I wrote this, so I have not had the chance to experiment with them a lot yet. Still, I think Opus 4.7, GPT 5.5, and Composer 2.5 are the current candidates for the best LLM for Angular development. Gemini 3.5 Flash is included here because it is new and interesting, but my first impression is that it is not really a challenger to the other three models in this post. I'm still pretty sure Gemini 3.5 Pro will be a serious contender once it is released.

Public Benchmarks

At Google I/O in May 2026, Google released a bunch of new AI updates. One of those releases was Google Gemini 3.5 Flash, and the release notes included some benchmarks:

I see at least two problems here:

This is vendor-provided marketing material for Gemini 3.5 Flash, so it is not really objective.
We don't know enough about what the benchmarks are, how they were conducted, and what the results really mean for Angular development.

So what can we use instead? My favorite benchmarks are done by Artificial Analysis. They are still not Angular-specific, but they give us a better baseline for comparing model capability, speed, and token usage.

Artificial Analysis Benchmarks

I want to show you three views from Artificial Analysis: the "Coding Agent Index" for overall coding-agent performance, "Execution Time" for active agent runtime, and "Token Usage" for how much context and output the models need to solve tasks. The screenshots below were captured on May 26, 2026, so check the live leaderboard for the latest numbers.

Strictly speaking, these are coding-agent benchmarks, not pure LLM benchmarks. The harness matters a lot: the same model can behave differently in Claude Code, Cursor, Codex, OpenCode, an IDE integration, or a custom agent setup. That is why I cover harnesses and integrations separately; here I only use these numbers as a rough signal for model quality.

The Artificial Analysis Coding Agent Index is a composite score built from SWE-Bench-Pro-Hard-AA, Terminal-Bench v2, and SWE-Atlas-QnA. You can read their coding-agent benchmark methodology for the details.

It is useful for quick comparison, but it should be read alongside the per-eval breakdowns. Two agents with similar index values can still have different strengths across repository tasks, terminal workflows, and rubric-based evaluations.

Mean agent wall time per task. Lower is better.

Mean input, cache, and output tokens per task.

DeepSWE Benchmark

Update May 31st (including Opus 4.8): Another recent benchmark that matches my day-to-day impression more closely is DeepSWE. In this leaderboard, GPT 5.5 reaches 70%, GPT 5.4 56%, Opus 4.8 58%, Opus 4.7 54%, Opus 4.6 28%, and Gemini 3.5 Flash reaches 28%. That lines up with my current feeling: GPT 5.5 and Opus 4.8 are both strong for serious coding work, while Gemini 3.5 Flash still feels more experimental for Angular development.

What I like about this benchmark is that it focuses more on the kind of work that matters in real agentic workflows: can the agent take a short behavioral prompt, find the right area of the codebase, and implement the change cleanly without me spelling out every file, module, and function? That is exactly the kind of workflow where traditional SWE-Bench results can feel disconnected from daily coding experience.

Composer 2.5 is unfortunately not part of this comparison, probably because it is mostly available through Cursor surfaces and not as a normal standalone model API.

What the Benchmarks Suggest

In these benchmark results, Gemini 3.1 Pro – still the current Pro tier, since Gemini 3.5 Pro has not shipped yet – does not look competitive with the other models. Gemini 3.5 Flash looks more interesting, but the public data is still very fresh and not specific to our framework.

My personal Angular impression is similar, but not identical: Gemini 3.5 Flash is sometimes fast and sometimes not, and it does not yet feel like a real challenger to my top three for my work. Gemini 3.5 Pro might become the more serious candidate here, but we don't have enough data yet.

In this benchmark snapshot, GPT 5.5 wins overall and is more efficient. So let me be upfront about the tension: the benchmarks I trust most currently lean GPT 5.5, yet my own Angular verdict below still puts Opus on top. That gap between leaderboard and lived experience is exactly why I read these numbers as useful signals, not final answers.

I don't want to look at cost in detail here. That deserves its own follow-up after the tools and harnesses post, because cost depends heavily on how you access these models. For this post, the central question is still the same: which model gives Angular developers the best mix of quality, speed, and practical usefulness?

I also don't want to pretend that this post is a real benchmark. The deeper Angular evidence behind my preferences comes from my own daily work experience with modernization tasks, refactorings, code reviews, testing workflows, and brownfield scenarios. In our Agentic Engineering Workshop, I will show practical examples of why these models became my current favorites for professional Angular work.

Before I move to my personal verdict, there are four side questions worth clearing up because they often come up when comparing current LLMs: Chinese models, European models, local models, and whether any of them are actually open source.

But what about the Chinese LLMs?

As of May 2026, Chinese LLMs like DeepSeek V4, Qwen 3.6, and Kimi K2.6 are absolutely worth watching, especially because they are pushing very hard on coding quality, open weights, and low cost. But for serious Angular development, I have not seen enough evidence yet to put them in the same tier as Opus 4.7, GPT 5.5, or Composer 2.5, so for now they are interesting to observe, not models I would bet my enterprise work on.

And what about the European LLMs?

As of May 2026, European LLMs are mostly a Mistral story for me, with Mistral Large 3 as the latest model worth tracking: interesting, improving, and relevant when data residency, EU vendors, or open-weight deployment matter. But for raw coding capability in my Angular work, I would not rank them with the frontier labs right now, so I would treat them as strategic options rather than serious candidates for the best model.

And what about local LLMs?

As of May 2026, local LLMs are no longer just toys, but we have to be precise about what "local" means. Running a model on my MacBook Pro is very different from self-hosting a huge open-weight MoE (Mixture of Experts) model on serious GPU infrastructure.

For local or self-hosted coding workflows, Qwen 3.6 is probably the most interesting family to watch right now, especially because the Qwen team explicitly focuses on agentic coding, repository-level reasoning, and local deployment via Transformers, llama.cpp, MLX, vLLM, and SGLang. DeepSeek V4 is also very relevant in the open-weight space, but the larger variants are more realistic for server-side self-hosting than for a normal developer machine. From Europe, Mistral 3 is interesting because Mistral Large 3 and the smaller Ministral 3 models are open-weight, with the smaller models explicitly targeting edge and local use cases.

For my professional Angular work, I would not put local models in the same tier as my current favorites yet. The gap is not only raw model quality, but also tool use, long-running agent reliability, context handling, and integration quality. Still, local models are becoming useful for privacy- or regulatory-sensitive work, CI helpers, and teams that want more control over where their code goes. I would not ignore them anymore, but I also would not make them my choice for enterprise Angular development today.

Are any of these models open source?

This is where the wording gets a bit tricky, because with LLMs people often say "open source" when they really mean "open weights". Claude, GPT, Gemini, and Composer 2.5 are not open source models in the practical sense, although Composer is based on Moonshot's open Kimi checkpoint. DeepSeek, Qwen, Kimi, and some Mistral models are much closer to that world because their weights are available under permissive or semi-permissive licenses. Still, even there, we usually don't get the full training data, training code, and recipe, so I would call them open-weight models rather than fully open source models.

My Subjective Verdict

With that context out of the way, I want to move to my own experience with these LLMs. For me, the real question is not only which model wins a benchmark, but which model fits which part of an Angular workflow. This part is purely subjective, and I'm open to other opinions and experiences. If you disagree with me, please let me know in the comments on X or Reddit.

My #1 for Angular: Opus 4.7 by Anthropic

My favorite model is Opus 4.7. It is the best LLM for Angular development in my opinion because it has the strongest code quality, the best overall performance, and still feels fast enough for serious agentic work.

It is also the most versatile LLM. The big shift for me is that Opus 4.7 no longer feels like a junior helper that needs tiny step-by-step prompts, but more like a senior partner that works best when I give it context, constraints, and good questions.

I think this model is currently the most capable one for complex enterprise Angular applications. It's also the most expensive one, especially in Extra and Max Mode, but I think it's worth it for the quality of the results.

I really like doing agentic work with this model, especially for tasks where I want it to explore trade-offs, challenge assumptions, and come back with a concrete implementation plan. In the follow-up post about tools and harnesses, I show how I use it in practice.

My #1 all-rounder: GPT 5.5 by OpenAI

GPT 5.5 is also a great LLM for Angular development, and OpenAI's introduction matches what I see in practice: its real strength is focused implementation work. It writes excellent code and is very token-efficient, especially when you do not force the highest reasoning level. However, it is not as versatile as Opus 4.7, and I find it more sensitive to context: if it starts from the wrong assumption, I often get better results by opening a fresh thread with clearer constraints instead of trying to steer the old one back.

That efficiency matters because GPT 5.5 is expensive per token, but it often needs fewer tokens to finish a task than competing frontier models. For practical work, I would start with lower or medium reasoning and only move up when the task really needs it.

For everyday chat use cases, I really like this model. I use it for a variety of tasks, especially when I want to think through a problem by asking a series of focused questions, then start a clean implementation thread once the direction is clear. For example, if I need help fixing the language of this blog post, I will definitely choose GPT 5.5, but I also (currently) prefer it for modernization and refactoring of Angular projects. Have you tried resolving hard merge conflicts? Oh boy, that's really a relief. Hard to trust though because it's so fast. I think it's kind of a senior engineer while Opus 4.7 is the better architect, but that's for sure subjective.

My #1 newcomer: Composer 2.5 by Cursor

Composer 2.5 is a very interesting LLM for Angular development because it combines good code quality with very high speed. The most interesting claim from the current discussion around it is that Cursor distilled it from Moonshot's Kimi K2.5 open-weight checkpoint and, on Cursor's own benchmark, got surprisingly close to GPT 5.5 and Opus 4.7 at a much lower cost. The important caveat is that this is still hard to verify independently because Composer is mostly available through Cursor surfaces, not as a normal model API.

If costs are important to you and you cannot rely on generous included usage in paid plans such as Claude Code or Codex, Composer 2.5 might be the best option for your setup, but only if Cursor fits your workflow. I cover tools and harnesses in the follow-up post, and then come back to costs and access models in a dedicated follow-up.

Candidate to watch: Gemini 3.5 Flash now, Gemini 3.5 Pro later

Gemini 3.5 Flash is interesting, but my first impression is mixed: sometimes it is fast, sometimes it is not, and for Angular development it does not yet feel like a real challenger to Opus 4.7, GPT 5.5, or Composer 2.5. I still need more hands-on time and better external benchmark data before I can recommend it with confidence. Gemini 3.5 Pro might become the more serious candidate here, especially if it combines stronger coding quality with more consistent speed.

But Alex, what about the new model(s)?

Only two days after publishing this post, Anthropic released Claude Opus 4.8. So does that mean this post was already outdated two or three days later?

I don't think so.

There is probably some improvement from Opus 4.7 to Opus 4.8, and Anthropic's benchmark numbers are impressive. The new model, and the next ones after it, might beat other models such as GPT 5.5 on several benchmarks. But that does not change the main point of this post: benchmark wins are useful signals, not final answers.

For real Angular work, the best model is still the one that fits your workflow best. Try the new models when they arrive, but judge them in your own codebase, with your own tasks, your own tools, and your own review standards.

Agentic Engineering Workshop

This is also why I don't think about LLMs in isolation anymore: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, the Angular Skills, and the review workflow belong together.

If you want to learn how to choose the right model for your Angular work – and actually put it to work on real modernization, refactoring, testing, and review tasks – make sure to join our Agentic Engineering Workshop, both in English and German.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

The real shift is not that these models can generate code. The real shift is that they can participate in the engineering workflow: asking questions, clarifying requirements, exploring trade-offs, and helping us move from vague intent to working Angular code.

For serious Angular work, my current recommendation is simple: start with Opus 4.7 when quality, architecture, and complex agentic work matter most. Use GPT 5.5 when you want a very strong all-rounder that is efficient, pleasant to work with, and great for writing, modernization, and focused implementation tasks.

Watch Composer 2.5 closely, especially if you already work in Cursor and care a lot about speed and cost. Treat Gemini 3.5 Flash as experimental for now, and revisit once Gemini 3.5 Pro ships.

As the Opus 4.8 update above already shows, this space changes too quickly for fixed rankings to stay perfect for long. So whatever model you choose, don't rely on benchmarks alone: the real test is still whether the model helps you ship better Angular code in your own codebase.

In the next post, I look at the other half of the story: which apps, IDE integrations, and agentic coding harnesses actually make these models useful in daily Angular work. After that, I go deeper into AI coding costs and what AI coding tools do with your code.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Why Angular ARIA in v21 is pretty neat

Alexander Thalhammer — Mon, 01 Dec 2025 21:48:45 +0000

Angular ARIA is a collection of headless, accessible directives that implement common WAI-ARIA patterns. The directives handle keyboard interactions, ARIA attributes, focus management, and screen reader support. All you have to do is provide the HTML structure, CSS styling, and business logic!

You feel like you've already read this before? Perfectly possible, because I've just copied and pasted the paragraph from the official Angular ARIA docs. Why should I reinvent the wheel, right? It perfectly summarizes the concept.

So the Angular team just (together with v21 on Nov 19th, 2025) released a brand-new collection of components – I mean directives – that implement common web patterns while letting you choose your own HTML, styling (CSS, SCSS, or even Tailwind), and business logic (I'd suggest TypeScript).

This is pretty much the opposite approach of Angular Material, which is an opinionated Plug & Play Design System. Both are built on top of the Angular CDK A11y package. So what do we get here?

Components

In the first release with v21, the following 12 components / directives / UI patterns are available:

search and select	navigation / menu	content organization
Autocomplete	Menu	Accordion
Listbox	Menubar	Tabs
Select & Multiselect	Toolbar	Tree
Combobox		Grid

There are – of course – plans to extend this in the future 😏

Why is this neat?

Using the Angular ARIA directives is a great way to build Angular apps by offloading some of the heavy lifting to the Angular team while still allowing full customization and user-interface branding. BTW: Check out Jessica's talk at ViteConf on YT for other things in NG v21 that are neat.

When to use Angular ARIA?

You know how to style things (at least Senior in CSS)
You build a custom Design System or an enterprise component library
You don't use any Design System and instead handcraft everything yourself

When to avoid Angular ARIA?

You don't know how to style (Junior in CSS – join my NG Styling Workshop 🎨)
You use a Design System or an enterprise component library (should be covered there)
You don't care about accessibility (come on – don't be a jerk!)

Angular Styling Best Choices Matrix

Level	Angular Material 🔌	3rd-party DS 🎨	Angular ARIA ♿	Custom UI 🛠️	Custom DS 🏢
Design	🎨 Very opinionated	⚡ Plug & Play	🤷 Depends on you	🤷 Depends on you	🤷 Depends on you
Accessibility	⚡ Plug & Play	🙂 Usually okay	⭐ Best Choice	🤷 Depends on you	🤷 Depends on you
Effort	⭐ Very low	🙂 Medium	😬 High	😅 Only if 1 app	💀 Boss will kill ya
CSS Skills	🟢 None	🟡 Junior	🔴 Senior	🔴 Senior	🟣 Master
Customization	🔒 Hard	🤷 Depends	✔ Included	♾️ No limits	⭐ Best Choice
NG Updates	🚫 Don’t customize	😬 Sometimes painful	🙂 Smooth	😎 Very smooth	😵 A lot of work
Use it for	🚀 Prototypes & demos	💸 Low-budget/legacy	🌱 Greenfield	🎨 Hobbies	🏢 Enterprise apps

Stay tuned for my next blog post comparing popular 3rd party Design Systems for Angular vs. Angular Material.

Workshops

If you want to deep-dive into Angular, we offer a variety of workshops – in English and German.

Best Practices Workshop 📈 (including Design Systems & ARIA)
NG Styling Workshop 🎨 (including Design Systems)
Accessibility Workshop ♿ (including WAI ARIA)
Performance Workshop 🚀 (because it's neat)

Conclusion

Angular ARIA delivers headless, accessible building blocks for fully customizable Angular components. It shifts complexity – keyboard handling, ARIA attributes, focus management – to the Angular team, making it ideal for custom Design Systems and tailored UIs without relying on heavy, opinionated frameworks.

This blog post was written by Alexander Thalhammer. Comment it LinkedIn, bsky, X or Reddit.

Enhancing A11y with Angular CDK

Alexander Thalhammer — Thu, 05 Jun 2025 10:00:00 +0000

The @angular/cdk/a11y package is part of the Angular Component Dev Kit (CDK) and provides a collection of services, directives, SASS mixins, and other utilities to improve the Accessibility (A11y) of your Angular apps.

These tools are invaluable when building reusable, presentation-focused components with screen-reader announcements, robust keyboard and focus support, high-contrast theming, and more. They’re especially useful if you’re creating an Angular Component Library or a Design System.

Below are some of my favorites, along with brief code examples.

LiveAnnouncer for Screen Readers

The first service we want to highlight is the LiveAnnouncer. It allows you to announce messages to screen readers, which is particularly useful for providing feedback after user interactions. It's so simple: I often replace my console.log calls with announcements.

Here's an example of that:

private readonly liveAnnouncer = inject(LiveAnnouncer);

if (this.flights().length > 0) {
  // console.log('Found ' + this.flights().length + ' flights');
  this.liveAnnouncer.announce('Found ' + this.flights().length + ' flights');
} else {
  // console.log('No flights found');
  this.liveAnnouncer.announce('No flights found');
}

Make sure to test your announcements with the use of a screen reader.

Focus Tools

The Angular CDK also includes several tools supporting your focus management.

Focus Trap

The FocusTrap Directive allows you to trap focus within a specific element, ensuring that keyboard navigation remains within that element until the user explicitly exits it.

This is particularly useful for modal dialogs or pop-ups:

<dialog class="awesome-dialog" cdkTrapFocus>
  <!–- Yay, focus won't leave this element! -->
</dialog>

If you want focus to jump in automatically, enable the cdkTrapFocusAutoCapture flag:

<dialog class="awesome-dialog" cdkTrapFocus [cdkTrapFocusAutoCapture]="true">
  <!–- Yay, focus won't leave this element! -->
</dialog>

With this flag set to true, the focus will automatically be captured when the dialog opens. However, it may not always be the best choice to have an element automatically capture focus, so we can avoid this with a trick:

<dialog class="awesome-dialog" cdkTrapFocus [cdkTrapFocusAutoCapture]="true">
  <h3 class="awesome-dialog__title" tabindex="-1" cdkFocusInitial>...</h3>
  <!–- Yay, focus won't leave this element! -->
</dialog>

By adding cdkFocusInitial the title will be secretly focused initially. Since it has tabindex -1, it won't be focusable by keyboard navigation afterward.

Focus Regions

The Regions are a powerful tool that allows you to define a specific area of your application where focus should be managed. This is particularly useful for complex components like dropdowns or menus, where you want to ensure that focus remains within the component while it is open.

cdkFocusRegionStart
cdkFocusRegionEnd and optionally
cdkFocusInitial

Here's an example of how to use the Regions:

<nav>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusRegionStart>Focus region start</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page">Another focusable link</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusInitial>Initially focused</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusRegionEnd>Focus region end</a></li>
</nav>

Note: To learn about the ariaCurrentWhenActive please read my post on Accessible Angular Routes

Focus Monitor

The FocusMonitor is a service that allows you to monitor focus changes within your application. It can be used to track when an element gains or loses focus, which is particularly useful for debugging focus-related issues.

This service can be injected into your components or services, and you can subscribe to focus changes:

import { Component, DestroyRef, effect, ElementRef, inject, viewChild } from '@angular/core';
import { FocusMonitor, FocusOrigin } from '@angular/cdk/a11y';

@Component({
  selector: 'app-navbar',
  template: `<nav #observed class="awesome-nav-cnt"><!-- children --></nav>`,
})
export class AwesomeFocusMonitorComponent {
  private readonly destroyRef = inject(DestroyRef);
  private readonly focusMonitor = inject(FocusMonitor);
  private readonly observedElementRef = viewChild.required<ElementRef<HTMLElement>>('observed');

  constructor() {
    effect(() => {
      const observedElementRef = this.observedElementRef(); // effect will run when the view is initialized
      this.focusMonitor.monitor(observedElementRef, true).subscribe((origin: FocusOrigin) => console.log(origin));
      this.destroyRef.onDestroy(() => this.focusMonitor.stopMonitoring(observedElementRef));
    });
  }
}

This is particularly useful for debugging focus-related issues, as it allows you to see when an element gains or loses focus.

FocusOrigin can be one of the following:

'mouse' the element was focused with the mouse
'keyboard' it was focused with the keyboard
'touch' it was focused by touching on a touchscreen
'program' it was focused programmatically, whereas
null indicates the element was blurred

So, this is also useful to check if a touch device is being used 😏

Styling utilities

The Angular A11y package also includes two useful Sass mixins.

Hidden Elements

Screen readers and other assistive technology skip elements that have display: none, visibility: hidden, opacity: 0, height: 0, or width: 0. In some cases, you may need to visually hide an element while keeping it available to assistive technology (e.g. Screen Readers).

@use '@angular/cdk';

@include cdk.a11y-visually-hidden();

<div class="awesome-toggle">
  <input type="checkbox" class="cdk-visually-hidden" />
</div>

High Contrast Mode

Some operating systems and/or devices include a High Contrast Mode. The Angular A11y package provides a Sass mixin that lets you define styles that only apply in high contrast mode. To create a high contrast style, just wrap it into the high-contrast mixin.

@use '@angular/cdk';

button {
  @include cdk.high-contrast {
    outline: 3px solid gold;
  }
}

The mixin works by targeting the forced-colors media query.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

With these tools, you can significantly enhance the accessibility of your Angular Apps. They help ensure that your components are not only functional but also user-friendly for everyone, including those with disabilities.

One last thing: In this Code lab by Google, you can find some exercises on the most important Angular CDK A11y tools https://codelabs.developers.google.com/angular-a11y#8

That's all folks!

This is the last edition of our A11y series. I hope you found it helpful and learned something new about making your Angular Apps more accessible and user-friendly for all of us, and that you are ready for the European Accessibility Act (EAA). If uncertain, please go back to the start of the A11y blog series.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

Angular CDK Accessibility – official docs
Google codelab on A11y by Emma Twersky

Building Accessible Forms with Angular

Alexander Thalhammer — Mon, 02 Jun 2025 10:00:00 +0000

Accessible Angular Forms are essential to ensure that all our users – including those with disabilities – can interact with our Angular App effectively. By implementing forms with Accessibility (A11y) in mind, we meet legal (EAA 2025 ♿) and ethical standards, and create a more inclusive experience. Accessible forms work better with screen readers, keyboard navigation, and assistive technologies – which not only helps users with impairments but also enhances the overall UX of our Angular Apps.

Angular Forms

In Angular, we have two types of forms:

Template-driven Forms: These are simpler and more declarative, relying on Angular Directives to create forms. They are built around the NgModel directive and generally used for simple forms. As the name suggests, these are implemented in the template through attributes.
Reactive Forms: These are more powerful and flexible, allowing for complex form structures and dynamic validation. They are built in the component class around the FormGroup and FormControl classes. Most often the FormBuilder service is used to create the forms.

In 2025, the Angular team is expected to work on Signal integration for Angular Forms.

However, no matter which type of form you choose – and whether you migrate from Observables to Signals or not – the goal is to ensure that your forms are accessible to all users. This includes providing proper labels, error messages, and keyboard navigation. To keep the focus on A11y, we will use the simpler template-driven approach without any reactivity in our examples.

Keyboard Navigation & Tab Focus

Keyboard navigation is a critical part of form A11y. Many users rely on the keyboard – rather than a mouse – to move through a form using the Tab, Shift + Tab, Arrow, and Enter keys. Ensuring a logical tab order, using semantic HTML elements like <label>, <input>, <button>, and avoiding custom controls that break default behavior, helps users navigate efficiently. You should not change the order. However, you can add tabindex="0" to include non-interactive elements or custom components, and use tabindex="-1" to remove elements from the tab order.

Additionally, visual focus indicators (like outlines, at least 2 if not 3px width) should be clearly visible to show which element is currently active. When done right, keyboard-friendly forms not only improve A11y but also lead to a smoother and more intuitive experience for all users 😎

Form Fields

Labels & type attribute

To ensure A11y, always associate <label> elements with their corresponding form controls using the for and id attributes. This improves support for screen readers and enables better keyboard navigation – clicking a label should focus the related input. Make sure each id is unique, especially when using multiple forms on the same page. Additionally, specify the correct type for all <input> and <button> elements to ensure proper behavior, like submitting a form when pressing Enter on a <button type="submit">.

<label for="from">From</label> <input type="text" name="from" id="from" [...] />

Grouping fields

When we have a group of related inputs, especially radio buttons or checkboxes, screen readers benefit from extra semantic context by <fieldset> and <legend>:

<fieldset>
  <legend>Flight Class</legend>
  <label for="economy">Economy</label>
  <input type="radio" name="class" id="economy" value="economy" />
  <label for="business">Business</label>
  <input type="radio" name="class" id="business" value="business" />
</fieldset>

This provides context for assistive tech. Without this, users may hear "Economy" and "Business" without understanding they are part of a group. The <fieldset> element groups related controls, while the <legend> provides a caption for the group.

Required fields

When a form element (like <input>, <select>, or <textarea>) must have a value, use the required attribute. This prevents form submission unless the required fields are filled out, and helps users with assistive technologies understand which fields need valid content. For example, add the required attribute to both input fields in your form, and consider adding an asterisk (*) as an additional visual indicator.

<label for="name">Name (*)</label> <input type="text" name="name" id="name" required />

Autocomplete

The autocomplete attribute is a powerful tool for improving the user experience in forms. It allows browsers to remember and suggest previously entered values, making it easier for users to fill out forms quickly. By using the autocomplete attribute, you can specify the type of data expected in each field, such as name, email, or address. This not only enhances usability but also helps with A11y by providing clear context for screen readers and assistive technologies.

<input type="text" name="phone" autocomplete="phone" />

To avoid autocomplete, we should set the autocomplete attribute to off. This is especially useful for sensitive information like passwords or when you want to ensure that users enter fresh data.

<input type="password" name="password" autocomplete="off" />

ARIA attributes

ARIA attributes (more on them in our last post) can enhance the A11y of our Angular Forms by providing additional context to assistive technologies when native HTML alone isn’t enough. Attributes like aria-label or aria-labelledby can offer accessible names for form controls when visible labels aren’t practical. While ARIA should never replace semantic HTML, it’s a powerful tool to bridge A11y gaps and ensure all users can understand and interact with your forms effectively.

<input type="search" name="search" aria-label="Search flights" placeholder="Search..." />

For validation, aria-invalid="true" can indicate a validation error and aria-describedby can provide additional context or instructions. For example, if a user enters an invalid email address, you can set aria-invalid="true" on the input field and use aria-describedby to point to an error message that explains the issue.

@let hasFromErrors = flightSearchForm.controls['from'] && flightSearchForm.controls['from'].touched && flightSearchForm.controls['from'].errors;

<input type="text" name="from" id="from" required [attr.aria-invalid]="!!hasFromErrors" [attr.aria-describedby]="hasFromErrors ? 'from_error' : null" />

Speaking about error messages, let's take a look at how to handle them.

Error messages

Accessible error messages help all users understand and correct form issues. Use aria-describedby (as in the example above) to link inputs to their error messages, and add aria-live="polite" to ensure screen readers announce them when they appear. Messages should be clear, concise, and not rely on color alone – always provide text or icons for better clarity.

Personal preferences of error messages:

only after user interaction with the form: on blur ("touched" in Angular) or after submitting.
focus on the first invalid control (see code example below) upon submitting.
inline with the form fields, not at the top or bottom of the form.
after the form field, not before.
in (dark) red and with an icon (e.g., ❌) to make them more visible.

export class FlightSearchComponent {
  private readonly document = inject(DOCUMENT); // for the focus
  private readonly flightSearchForm = viewChild.required<NgForm>('flightSearchForm');

  protected onSearch(): void {
    if (this.flightSearchForm()?.invalid) {
      this.markFormGroupTouched(this.flightSearchForm());
      this.focusFirstInvalidControl(this.flightSearchForm());
      return;
    }

    // do the search
  }

  private markFormGroupTouched(formGroup: FormGroup): void {
    for (const key of Object.keys(formGroup.controls)) {
      const control = formGroup.get(key);
      if (control instanceof FormGroup) {
        this.markFormGroupTouched(control);
      } else {
        control?.markAsTouched();
      }
    });
  }

  private focusFirstInvalidControl(formGroup: FormGroup): void {
    for (const key of Object.keys(formGroup.controls)) {
      const control = formGroup.get(key);
      if (control?.invalid) {
        const invalidControl = this.document.querySelector(`[name="${key}"]`);
        (invalidControl as HTMLElement)?.focus();
        break;
      }
    }
  }
}

<form #flightSearchForm="ngForm">
  <label for="fromAirport">From (*)</label>

  @let hasFromErrors = flightSearchForm.controls['from'] && flightSearchForm.controls['from'].touched && flightSearchForm.controls['from'].errors;

  <input
    type="text"
    name="from"
    id="fromAirport"
    required
    [minlength]="minLength"
    [maxlength]="maxLength"
    [pattern]="pattern"
    [attr.aria-invalid]="!!hasFromErrors"
    [attr.aria-describedby]="hasFromErrors ? 'fromErrors' : null"
    [(ngModel)]="from"
  />

  @if (hasFromErrors) {
  <app-flight-validation-errors id="fromErrors" [errors]="flightSearchForm.controls['from'].errors" fieldLabel="From" />
  }
</form>

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

Building accessible forms in Angular is not just a best practice – it’s a commitment to creating better experiences for everyone. With just a few thoughtful choices, you can make your forms inclusive, intuitive, and ready for the future. For more information on Angular and Accessibility, check out my A11y blog series.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

ARIA roles and attributes in Angular

Alexander Thalhammer — Fri, 30 May 2025 13:34:52 +0000

ARIA (short for Accessible Rich Internet Applications) roles and attributes are used to improve Accessibility of our Angular apps – especially for users who rely on assistive technologies like screen readers, voice control, or alternative input devices. Using ARIA is essential for building inclusive, user-friendly web apps.

About ARIA

ARIA was developed by the World Wide Web Consortium’s Web Accessibility Initiative (WAI) to enhance the accessibility of dynamic web content. The WAI also is the organization behind the Web Content Accessibility Guidelines (WCAG), which provide a comprehensive framework for A11y – more about WCAG in the intro of this A11y blog series.

Originating in the early 2000s, ARIA was created to bridge the gaps in native HTML, ensuring that modern, interactive and single-page applications are usable by people with disabilities ♿

ARIA in Angular

In Angular, ARIA roles and attributes can be easily integrated into your components. You can use them directly in your HTML view templates, just like any other HTML attribute. Angular also provides built-in support for ARIA through directives and bindings, making it easier to manage ARIA properties dynamically.

When using static values, you can simply add them to your HTML elements or components:

<!-- Static ARIA attributes require no extra -->
<button type="button" aria-label="Close">X</button>

However, when you want to bind ARIA attributes dynamically, you should use Angular's property binding syntax ("[]" square brackets) including the "attr." prefix:

<!-- Dynamic ARIA attribute property binding with "attr." prefix -->
<button type="button" [attr.aria-label]="myActionLabel">…</button>

ARIA vs. Semantic HTML

While ARIA is a powerful tool for enhancing accessibility, it should be used as a last resort. Native semantic HTML elements and attributes are preferred whenever possible, as they provide built-in accessibility features that ARIA does not have to replicate. Always prefer native elements like <button>, <label>, <nav> and <header> over their ARIA counterparts. For example, instead of using role="button" on a <div>, use a <button> element.

ARIA Roles

Speaking about ARIA roles, they define what an HTML element is or how it should behave – when native HTML elements are not applicable. They tell assistive technologies how to interpret an element and its purpose within the page. Roles are particularly useful for custom components that don’t have native semantic meaning.

Most commonly used ARIA roles

Here is a not exhaustive list of some ot the most commonly used ARIA roles:

role="button" (prefer <button>) indicates an interactive element that triggers an action.
role="main" (prefer <main>) the main content of your app – typically <router-outlet />.
role="complementary" (prefer <aside>) denotes content that complements – like a sidebar.
role="navigation" (prefer <nav>) denotes a section of navigation links – like your route nav.
role="alert" used for important messages that should be immediately announced.
role="dialog" signifies a modal or popup window.
role="listbox" used for a widget that allows the user to select from a list of options.
role="tablist" composes a tabbed interface.
role="tab" represents a selectable tab in a tabbed interface.
role="tabpanel" the container for the content associated with a tab.

Find a comprehensive list of all ARIA roles by MDN.

Examples

This could be a <app-dialog> component:

<app-dialog role="dialog" aria-labelledby="dialogTitle" aria-modal="true" cdkFocusTrap>
  <h2 id="dialogTitle">{{ dialogTitle() }}</h2>
  <p>{{ dialogContent() }}</p>
  <button type="button" (click)="onClose()">Close</button>
</app-dialog>

In this simple example, the role="dialog" indicates that this is a dialog window. The aria-labelledby attribute associates the dialog with its title, and aria-modal="true" indicates that the dialog is modal, meaning it prevents interaction with the rest of the page until closed. Note that we also use the cdkFocusTrap directive to ensure that (keyboard navigation) focus is trapped within the dialog while it is open.

Another example could be a tab interface:

<app-tablist role="tablist">
  @for (tab of tabs(); track tab.id) {
    <button role="tab" aria-controls="panel_{{ tab.id }}" id="tab_{{ tab.id }}"
            [attr.aria-selected]="activeTab() === tab.id ? 'true' : 'false'">
      {{ tab.label }}
    </button>
  } @empty {
    No tabs available.
  }
</app-tablist>
@for (tab of tabs(); track tab.id) {
  <app-tab role="tabpanel" aria-labelledby="tab_{{ tab.id }}" id="panel_{{ tab.id }}">
    {{ tab.content }}
  </app-tab>
}

In this example, we have a tabbed interface. The role="tablist" indicates that this is a list of tabs. Each tab has the role="tab" and is associated with its corresponding panel using aria-controls. The aria-selected attribute indicates which tab is currently selected. The panels have the role="tabpanel" and are associated with their respective tabs using aria-labelledby.

ARIA Attributes

ARIA attributes provide additional details about an HTML element’s state, properties or relationships. They enhance the semantic meaning of your Angular components and other HTML elements, especially when default HTML does not fully describe an element’s behavior.

We distinguish between states and properties. States are dynamic and can change over time, while properties are static and describe the element's characteristics.

Most commonly used ARIA attributes

Widget attributes (states and properties)

aria-disabled (state/property): indicates whether an element is disabled or not – not necessary if native disabled is used.
aria-required (property): indicates that user input is required before submitting a form – not necessary if native required is used.
aria-expanded (state): communicates whether an element, such as a collapsible menu, is expanded or collapsed.
aria-hidden (state): indicates whether an element should be exposed to assistive technologies.
aria-invalid (state): indicates whether the value of an input field is valid or invalid.

Live region attributes (states)

aria-live: specifies how updates to content should be announced to the user (e.g., assertive for error messages).
aria-busy: indicates whether an element is currently being updated (e.g., loading spinner).

Drag-and-Drop attributes (states)

aria-grabbed: indicates whether an element is currently being dragged (e.g., true when dragging).

Relationship attributes (properties)

aria-label: provides a text alternative for elements that may not have visible text.
aria-labelledby: identifies an element (or elements) that labels the current element.
aria-describedby: identifies an element (or elements) that describes the current element.
aria-controls (state): references the element(s) whose content is controlled by the current element.

And here is again the full list of all ARIA attributes by MDN.

Examples

A toggle button using aria-label and aria-expanded:

<button
  type="button"
  aria-label="Toggle navigation menu"
  [attr.aria-expanded]="isMenuOpen() ? 'true' : 'false'"
  (click)="onToggleNav()">
  <i class="icon-menu"></i>
</button>

In this simple example, the aria-label attribute provides a text alternative for the button, indicating its purpose. The aria-expanded attribute indicates whether the navigation menu is currently open or closed. This is important for screen reader users, as it helps them understand the state of the button.

Using aria-live combined with role="alert" for an error message:

@let showFromErrors =
  flightSearchForm.controls.from.errors &&
  flightSearchForm.controls.from.touched;

<input
  [...]
  id="fromAirport"
  [attr.aria-invalid]="!!showFromErrors"
  [attr.aria-describedby]="showFromErrors ? 'fromAirportErrors' : null"
/>
@if (showFromErrors) {
  <app-flight-validation-errors
    aria-live="assertive"
    role="alert"
    id="fromAirportErrors"
    fieldLabel="From"
    [errors]="flightSearchForm.controls.from.errors"
  />
}

In this example, the aria-live attribute is set to assertive, which means that the screen reader will announce the error message immediately when it appears. The role="alert" indicates that this is an important message. Additionally, the aria-invalid attribute is used to indicate that the input field has validation errors and the aria-describedby attribute is used to associate the error message with the input field. Note that the aria-describedby attribute is set to null when there are no errors. This ensures that it's not present in the rendered DOM when not needed.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

Implementing ARIA in Angular is essential for building web apps that are both accessible and inclusive. By leveraging ARIA roles and attributes appropriately, developers can bridge gaps where native HTML falls short, ensuring that all users have a positive experience. This approach not only meets accessibility standards but also lays the foundation for user-centric and future-proof design.

In the next edition of our A11y blog series, we'll cover Accessible Angular Forms.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

Accessibility in Angular Applications by Zama Khan Mohammed
Accessibility in Angular 17 by Amir Saeed
ariaCurrentWhenActive – official docs
ARIA roles
ARIA attributes

Accessible Angular Routes

Alexander Thalhammer — Tue, 27 May 2025 15:29:04 +0000

This article explains how to use Angular Router features to achieve quick wins in improving Accessibility (A11y). It is the third edition of our A11y blog series. If you want to enhance your Angular A11y skills, please make sure to read the other articles in this series as well.

Page Titles

Does your Angular App look like this if you open it in multiple tabs?

If it does, you should definitely consider adding unique page titles for each route. The very easy-to-use Route.title feature shipped with Angular v14 in 2022, yet many Angular Developers are still not using it 😱. Please take a look and adopt it in your Angular Apps.

Route.title

Use this built-in Router feature to automatically update the page <title> after each successful navigation, enhancing both accessibility and UX for all of us. To enable it in your primary <router-outlet />, you only need to set the title property in your routes configuration array:

export const routes: Routes = [
  {
    path: 'demo',
    title: 'Look how easy it is to use',
    component: DemoComponent,
  },
];

This will update the page title in the browser tab and make it accessible to screen readers.

In larger Angular Apps, setting page titles can become inconsistent due to the lack of a common prefix or suffix for routes.

Global Page Title Strategy

To address this, you can extend Angular's abstract TitleStrategy class and implement your custom page title strategy:

// [imports]

@Injectable()
export class PageTitleStrategy extends TitleStrategy {
  private readonly title = inject(Title);

  updateTitle(routerState: RouterStateSnapshot): void {
    const pageTitle = this.buildTitle(routerState);
    if (pageTitle) {
      this.title.setTitle(pageTitle + ' – Demo');
    } else {
      this.title.setTitle('Link to Demo below!');
    }
  }
}

Then add the custom title strategy to your app.config.ts:

// [imports]
import { PageTitleStrategy } from "./page-tite-strategy";

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
    provideExperimentalZonelessChangeDetection(),
    provideRouter(routes),
    { provide: TitleStrategy, useClass: PageTitleStrategy }, // add this line
  ],
};

Dynamic Page Titles using Angular Router Params

To create dynamic page titles using Angular Router parameters, follow these steps:

First, we set up the withComponentInputBinding() function to bind the route parameters to your component inputs:

// [imports]

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
    provideExperimentalZonelessChangeDetection(),
    provideRouter(routes, withComponentInputBinding()), // add feature to router
    { provide: TitleStrategy, useClass: PageTitleStrategy },
  ],
};

Then, we add the parameter to the route definition:

export const routes: Routes = [
  // [...]
  {
    path: 'demo/:id',
    title: 'Demo #id', // note that this will be ignored and replaced by the dynamic title
    loadComponent: () => import('./demo/demo.component'),
  },
];

Now, we can simply add a input signal to the component that will automatically receive the route param (thanks to the withComponentInputBinding() feature):

// [imports & decorator]
export class DemoComponent {
  readonly id = input<number | undefined>();

  // [...]
}

export default DemoComponent;

Finally, we can use an effect on our id input signal to display the dynamic page title:

// [imports & decorator]
export class DemoComponent {
  readonly id = input<number | undefined>();
  private readonly title = inject(Title);

  constructor() {
    effect(() => this.title.setTitle(this.id() !== undefined ? `Page #${this.id()} - Demo` : 'Page - Demo'));
  }
}

export default DemoComponent;

Now, when you navigate to /demo/1, the page title will be set to Page #1 - Demo.

All Together Now

To bring it all together – with the global page title strategy – we add another method to the PageTitleStrategy class and provide it in root:

// page-title-strategy.ts
import { RouterStateSnapshot, TitleStrategy } from '@angular/router';
import { inject, Injectable } from '@angular/core';
import { Title } from '@angular/platform-browser';

@Injectable({
  providedIn: 'root',
})
export class PageTitleStrategy extends TitleStrategy {
  private readonly title = inject(Title);

  updateTitle(routerState: RouterStateSnapshot): void {
    this.setTitle(this.buildTitle(routerState));
  }

  setTitle(pageTitle?: string): void {
    if (pageTitle) {
      this.title.setTitle(`${pageTitle} – Demo`);
    } else {
      this.title.setTitle('Page title like a pro');
    }
  }
}

And here is the final version of the dynamic page title effect in the DemoComponent using our injected PageTitleStrategy:

// demo.component.ts
// [imports & decorator]
export class DemoComponent {
  private readonly pageTitleStrategy = inject(PageTitleStrategy);

  readonly id = input<number | undefined>();

  constructor() {
    effect(() => this.pageTitleStrategy.setTitle(this.id() !== undefined ? `Page #${this.id()}` : 'Page'));
  }
}

export default DemoComponent;

Now you can set the page title depending on the route params and have a consistent suffix for all routes in your Angular App.

Pretty nice, huh? Check out the full source code in the title-strategy branch of my GitHub repo.

RouterLinkActive

The RouterLinkActive directive is another powerful and lightweight tool for indicating the active state of navigation links in your Angular App. It allows you to apply CSS styles to navigation links based on their active state, making it easier to create appealing and accessible menus.

<!-- nav.component.html -->
<nav>
  <a [routerLink]="demo" routerLinkActive="active">Demo</a>
  <!-- ... -->
</nav>

<!-- nav.component.scss -->
nav a.active {
  color: var(--nav-link--active__color);
  text-decoration: none;
}

Fine-tuned control with `routerLinkActiveOptions`

Since Angular v14, you can use the routerLinkActiveOptions directive to fine-tune the active state of your links. Where options will have either the shape of IsActiveMatchOptions:

export declare interface IsActiveMatchOptions {
  fragment: 'exact' | 'ignored';
  matrixParams: 'exact' | 'subset' | 'ignored';
  paths: 'exact' | 'subset';
  queryParams: 'exact' | 'subset' | 'ignored';
}

Or, just a boolean named exact:

{
  exact: boolean
}

To apply exact matching, add the routerLinkActiveOptions directive to your link:

<!-- nav.component.html -->
<nav>
  <a
    routerLink="/demo"
  routerLinkActive="active"
  [routerLinkActiveOptions]="{ exact: true }"
  >
  Demo
  </a>
  <!-- ... -->
</nav>

Indicate current page `ariaCurrentWhenActive`

A final quick win in A11y in Angular is to highlight the current page link in the nav for screen readers via aria-current: We need to add the aria-current="page" attribute. This can easily be done using the ariaCurrentWhenActive input on the routerLinkActive directive by setting its value to "page":

<!-- nav.component.html -->
<nav>
  <a
    routerLink="/demo"
    routerLinkActive="active"
    [routerLinkActiveOptions]="{ exact: true }"
    ariaCurrentWhenActive="page"
  >
    Demo
  </a>
  <!-- ... -->
</nav>

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility related topics)
🚀 Performance Workshop

Conclusion

Implementing Angular's built-in router features is a simple yet powerful way to boost your A11y 🚀

By leveraging dynamic page titles, a global title strategy, and fine-tuning active link indicators with RouterLinkActive and ariaCurrentWhenActive, you can create a more inclusive UX that benefits everyone – from seasoned Devs (like me 😂) to users who rely on assistive technologies. These strategies not only improve UX but also help standardize navigation and page management across all Angular Apps. Back to our example from the beginning, now our browser tab bar looks like this:

I think this is a great example of a quick win! Keep playing with these features and explore the rest of our A11y blog series for more insights on building accessible, high-performing web apps.

In the next edition of our A11y blog series, we'll cover more ARIA roles and attributes.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

GitHub repo of demo, by Alexander Thalhammer
Angular v14 – official blog post by Emma Twersky
Tweet about Route title by Emma Twersky
Page Titles With The Router by Brandon Roberts
Router Link Accessibility Features by Brian Treese
Make it accessible: Navigation in Angular by Daniel Marin
ariaCurrentWhenActive – official docs

Accessibility Testing Tools for Angular

Alexander Thalhammer — Mon, 21 Apr 2025 15:50:52 +0000

Let me introduce you to my curated selection of Accessibility Testing Tools for Angular Apps. This article is the second edition of our A11y blog series. If you want to learn more about Accessibility in Angular, please check out the other articles in this series.

Introduction

Automated testing can never replace manual testing (at least so far, in 2025). There are tools that can identify some or many A11y issues, but no tool can certify that a web app is fully accessible. Manual testing ensures that you test for a breadth of A11y concepts that include logical content order and feature parity.

However, automated testing is fast and - at least to me - some kind of entertaining work 🚀

Chromium Browser

First, please stop using the lame Firefox (slow open-source browser sponsored mainly by Google). I strongly recommend using a Chromium based browser! Safari is okay for people who love their golden Apple cage. Here are some browsers that I can recommend:

Vivaldi (Privacy & Linux)
Brave (Privacy & Ad blocker)
Arc (for something completely different) and even
Edge (for Windows machines without Admin privileges)

Personally, I prefer using a clean Google Chrome on my Macs and my Pixel. Just like I prefer a clean Google Android and have been happily sticking to Nexus (4, 5, 5) and later Pixel (3a, 6a, 9 Pro soon 😎 - review in German) for over a decade now. However, if you don't want to share your data with Google - those Chromium browsers listed above (except Edge) are the better choice for sure.

While the Spaces feature of Arc is pretty interesting, I just use different Chrome users for my different jobs. E.g., one of them for everything related to Angular Architects - like reading this post 🤓

Did you notice that Chromium DevTools have a built-in Accessibility Tree view?

Chromium Extensions

Before we talk about a selection of my favorite Accessibility Tools, please add the following extensions to your browser (at least temporarily):

Angular Dev Tools (should be there already since you're here 😏)
WAVE A11y Testing Tool, 500k users
axe DevTools A11y Testing Tool, 300k users
Accessibility Insights A11y Testing Tool, 100k users
Read Aloud Screen Reader (OS-based Screen Readers listed at the end of the post are better, though)
HeadingsMap (partially related to A11y, for heading structure)

You may need to restart your browser for the just-added extensions to work.

Please note that three of them are used exclusively for A11y testing. Once you've found your favorite A11y weapon of choice, you might want to remove the other two. My personal preference will be mentioned below!

Automated Testing

Identify issues and how to know what to fix

The A11y Testing Tools allow you to quickly and easily check things like the presence of alt text on an image or the contrast ratio of a text color. You can think of these tools as linters; they can recognize that alt text is present, but you must manually check that the content is logical and provides value.

Some tools might find a lot of errors or warnings on your app or web property. Please don't feel overwhelmed in such a case and start improving your A11y step-by-step. Here is a customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2.2 requirements (success criteria) and techniques:

https://www.w3.org/WAI/WCAG22/quickref/

You'll need to find a prioritization for your issues. The WCAG's levels (A, AA and AAA) will help you get started.

Now, finally, the selection of my favorite Accessibility Testing Tools 🥳

Angular ESLint (only for Angular apps)

You can use the Angular ESLint package to lint your code for automatable A11y attributes. In eslint.json, make sure to add the a11y ruleset plugin @angular-eslint/template/accessibility to your HTML templates:

{
  "overrides": [
    /* [...] */
    {
      "files": ["*.html"],
      "extends": [
        "plugin:@angular-eslint/template/recommended",
        /* add the following line */
        "plugin:@angular-eslint/template/accessibility"
      ],
      "rules": {
         /* [...] */
      }
    }
  ]
}

To add Angular ESLint to your own Angular app, simply run:

ng add @angular-eslint/schematics

Note: With the newest version, the plugin @angular-eslint/template/accessibility is included by default.

For more information, see the latest Angular ESLint rules on GitHub.

WAVE Chrome Extension

If you haven't done so already, install the WAVE Chrome extension.
Click on the Wave icon to run the WAVE Ally test on the current page.

WAVE Web Service

If you want to check a public web property, you can also try the WAVE Web Accessibility Evaluation Tool.

Axe Chrome Dev Tools

If you haven't done so already, install the axe DevTools extension.
Open your DevTools and select the axe DevTools tab.
Click Scan all of my page to run an axe Ally scan on the current page.

Lighthouse Dev Tools

Open your DevTools and select the Lighthouse tab.
The options Navigation and Mobile (or Desktop) are okay.
Select the Accessibility checkbox and deselect all other checkboxes.
Click Generate report to run a Lighthouse A11y audit.
Check the results of your audit.

PageSpeed Insights Web Service

Note: For public properties, you can also use Google's PageSpeed Insights to run the lighthouse A11y test.

Accessibility Insights Dev Tools

If you haven't done so already, install the Accessibility Insights extension.
Open it by clicking on the extension icon and selecting Accessibility Insights.
Click FastPass to run a quick first test of your page.

Run A11y Tests

If you haven't done so already, run some automated tests on your machine now 💻

Manual (Auditory) Testing

Besides manual testing, you want to do auditory accessibility tests. You want to turn on your machine's built-in screen reader and navigate through your (Angular) app with keyboard navigation.

Screen Reader

You can use any one of these screen readers:

NVDA (Windows, free & recommended for A11y testers)
Jaws (Windows, expansive & favorite choice of people with handicapped sight)
Narrator (Windows, built-in)
Voice Over (Mac/iOS, built-in but great)
Talkback (Android, built-in but great)
Orca (Linux, free)
Read Aloud Chrome Extension (not so great, IMHO)

Accessibility Workshop

If you want to learn Angular, we offer a variety of workshops – both in English and German.

Accessibility Workshop ♿
Best Practices Workshop 📈 (including accessibility related topics)
Performance Workshop 🚀

Conclusion

Tools are always a matter of personal preference and taste. So, I'd like to invite you to try out some of the recommended tools and choose your own favorite one. Nevertheless, my favorite of all is the WAVE extension and web service. Happy testing!

In the next edition of our A11y blog series, we'll show you how to use the Angular Router for better accessibility.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

Web Accessibility (A11y) in Angular – Introduction

Alexander Thalhammer — Mon, 07 Apr 2025 19:42:24 +0000

This article will get you started into Accessibility in Angular, right on time for the European Accessibility Act (EAA) which will become effective on June 28th 2025, but more on that later. We'll cover the history of Web Accessibility, the Web Content Accessibility Guidelines (WCAG), and of course the EAA itself. So make sure to follow it to be prepared for the EAA and to learn how to make your Angular Apps more accessible.

The article is intended for developers, product owners, and anyone interested in making their Angular Apps more accessible. It's also the first edition kicking of our A11y blog series, which will cover topics such as:

Web Accessibility Introduction (this post): An overview of the history, statistics and regulatory framework of Web Accessibility.
Accessibility Testing Tools: My top picks for testing your Angular app for accessibility issues.
Accessible Angular Routes: Quick wins to enhance your app's accessibility using the Angular Router.
ARIA roles and attributes: Best practices for implementing WAI-ARIA roles and attributes in Angular.
Accessible Angular Forms: Guidelines for building Angular forms that everyone can use.
Enhancing A11y with CDK: Exploring some elements of the Angular CDK a11y package.

Brief History of Web Accessibility

Tim Berners-Lee, the inventor of the World Wide Web, envisioned it as a platform for universal access regardless of physical or cognitive abilities.
The term accessibility (short A11y, like I18n) refers to the design of products, devices, services, or environments for people with disabilities.

Disability Statistics

While estimates suggest that one in four individuals in the EU has some form of disability, finding exact data is challenging. Therefore, we focus on Germany using the numbers of the Statistische Bundesamt (Federal Statistical Office of Germany) from 2023:

7.86m people (9.4% of the pop.) in Germany have a severe disability
1.85m people (2.2% of the pop.) have problems with cerebral disorders, mental and psychological disabilities
1.63m people (2.0% of the pop.) have problems with mobility impairments
329k people (0.4% of the pop.) are considered blind or have severe vision impairment
324k people (0.4% of the pop.) are considered deaf or have severe hearing impairment

Although this data is specific to Germany, they offer insight into the broader prevalence of disabilities across Europe.
However, I think it's important to note that good A11y practices benefit not only people with disabilities but everybody.
For example, captions on videos help non-native speakers and those in noisy environments.
Here is an image by Microsoft showing the benefits of A11y for all kinds of circumstances:

W3C and the Web Accessibility Initiative (WAI)

In 1997, the World Wide Web Consortium (W3C) launched the Web Accessibility Initiative (WAI) to systematically address accessibility issues.
The WAI develops guidelines, called Web Content Accessibility Guidelines (WCAG) – version 1.0 released in 1999 – and continues to provide resources to make the web more accessible.

Web Content Accessibility Guidelines (WCAG)

The WCAG guidelines offer an internationally recognized framework for creating accessible web content and applications. The latest version, WCAG 2.2, was published in December 2023. Both WCAG 2.1 and 2.2 are widely adopted in regulatory standards across Europe and North America.

For a deep dive, check out the WCAG 2.2 Quick Reference. Here are some key points:

The Four Principles

The WCAG 2.2 guidelines are built and structured on four core principles that form the foundation for creating accessible digital content:

👀 Perceivable: Information must be presented in ways that users can perceive.
🕹️ Operable: Interface components must be operable across various devices and inputs.
🧠 Understandable: Content and navigation should be clear and easy to comprehend.
🛡️ Robust: Content must work reliably with current and future technologies, including assistive devices.

Illustration source.

Levels of Conformance

WCAG defines three levels of conformance:

🥉 Level A: The minimum level. It addresses the essential A11y features required for basic interaction. While meeting Level A ensures that essential content is accessible, some barriers may still exist.
🥈 Level AA: Building upon Level A, this level targets the most significant and common barriers. It enhances the UX by improving readability, navigation, and overall usability, and is widely regarded as the standard for many legal and organizational requirements (EAA!).
🥇 Level AAA: Representing the highest standard of A11y, includes the most rigorous criteria. Although achieving AAA ensures maximum accessibility, it may not be feasible for all types of content and is typically applied to specialized cases where the highest level of A11y is required.

So our recommendation (well and the lawmakers also have that opinion) is to aim for Level AA compliance, as it strikes a balance between A11y and practicality (aka affordability).

European Accessibility Act (EAA)

The European Accessibility Act (EAA) is a new (actually it's from 2019) EU directive that has to be fully implemented by June 28th 2025.
Based upon the mentioned WCAG 2.2, the EAA sets clear rules to ensure that web applications, websites, and other online services are accessible to everyone, including people with disabilities.
In essence, digital tools must be designed to remove barriers, allowing all users to access information and services without difficulty.

By focusing on web applications, the EAA pushes businesses and developers to create user-friendly, accessible online experiences.
The law helps people with disabilities have the same opportunities and also encourages innovation in web design and development.
In short, the EAA is a key step toward making the internet a more inclusive and in the end, more enjoyable space for all.

The EAA source (hint: don't follow this link): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32019L0882

National Implementation of the EU Directive

While we won’t cover every detail here, here are some examples of national implementations of the EAA. Interestingly, even though Switzerland is not an EU member, they were the first country implementing the EAA into national law 😀

🇨🇭 Switzerland: Accessibility Standard 3.0 (eCH-0059) – June 2020
- Official Website: ech.ch/en/standards/ech-0059/ (German / French)
🇩🇪 Germany Barrierefreiheitsstärkungsgesetz (BFSG) – July 2022
- Private website about the BFSG: bfsg-gesetz.de (German)
🇦🇹 Austria: Barrierefreiheitsgesetz (BaFG) – July 2023
- Austrian camber of commerce: About the BaFG (German)

Affected online services include

The EAA impacts a variety of digital services, including

📚 E-books: Digital (e.g. academic) books that enable the circulation and consultation of a mostly textual and graphical intellectual work.
🛒 E-commerce: Retail websites and mobile applications that facilitate online transactions are required to meet accessibility standards.
🏦 Online banking: Online and mobile banking platforms must be accessible, ensuring that financial services are usable for everyone.
🚌 Public & transportation services: In some cases, the Act also touches on digital services in areas like transport (e.g., online ticketing and check-in services) and audiovisual media services. However, note that public sector websites and mobile apps are governed by a different EU directive (the Web Accessibility Directive).

Although the EAA covers many services, there are areas where its application may still be ambiguous or unclear. For example, the EAA does not explicitly mention Angular or JavaScript frameworks, but it does require that certain web applications and websites are accessible to everyone.

Make sure to follow our A11y blog series to be prepared for the EAA and to learn how to make your Angular Apps more accessible.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility related topics)
🚀 Performance Workshop

Conclusion

In this post, we explored the fundamentals of web accessibility — from its history and key statistics to the regulatory landscape, including the upcoming European Accessibility Act.
Whether you’re a developer, designer, or business owner, understanding and implementing accessibility best practices is essential for creating inclusive Angular Apps for everyone.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

Complete Guide for Server-Side Rendering (SSR) in Angular

Alexander Thalhammer — Thu, 04 Jul 2024 16:27:24 +0000

Updated on Mar. 23rd, 2025 for Hybrid Rendering & brandnew Incremental Hydration (now including demo) in Angular v19.2.

This comprehensive post includes a quick introduction to SSR, a detailed setup guide and several best practices with Angular v19 (released on Nov 19th, 2024), enhancing the initial load performance and thus the user experience of modern web applications built with Angular.

If you haven't upgraded to v19 yet, then what are you waiting for? In my humble opinion, the new Hybrid Rendering and Incremental Hydration features of v19 can already be used in production, even though they are still in Developer Preview:

See all Angular features in this Angular feature roadmap by Gerome Grignon. By the way, if you want to use Material and/or CDK with SSR, you need at least v18.

The Angular team has recently (well actually for quite some time) been putting in a huge effort and doing a fantastic job to help us improve the initial load time. SSR plays a significant role in achieving that goal for our framework of choice. Read my post from July 2023 to learn why initial load performance is so crucial for your Angular apps.

Essentials

Let's start with the basics. You can, of course, skip this section if you're already familiar with SSR, and continue with the next section about building.

Server-Side Rendering (SSR)

Server-Side Rendering (SSR) is a web development technique where the (in our case node) server generates the HTML content of a web page (in our case with JavaScript), providing faster initial load time. This results in a smoother user experience, especially for those on slower networks (e.g. onboard a train in 🇩🇪 or 🇦🇹 – which I happen to be a lot recently 😏) or low-budget devices. Additionally, it improves SEO and crawlability for Social Media and other bots like the infamous ChatGPT.

New Angular CLI projects will automatically prompt SSR (since Angular v17):

ng new your-fancy-app-name

For existing projects simply run the ng add command (since Angular v17):

ng add @angular/ssr

Warning: You might have to fix stuff manually (like adding imports of CommonJsDependencies) after adding SSR to your project 😬

Follow the angular.dev guide for detailed configuration. However, I'd recommend switching to the new Application Builder, which has SSR and SSG baked in (more on that in the build section below). Let's first clarify what SSG stands for.

Static Site Generation (SSG)

Static Site Generation (SSG) or Prerendering (like the Angular framework likes to call it), is the technique where HTML pages are prerendered at build time and then served as static HTML when a URL is visited. Instead of rendering live on demand, SSG generates the HTML once and serves the same pre-built HTML to all users. This provides even faster load times and further improves the user experience. However, since the HTML is being stored on the server, this approach is limited whenever dynamic content is needed.

Important note: For the use of SSG you don't need a node.js / express server. You can still ship your application from nginx or even Apache.

Full-application Hydration (preview in v16, stable since v17)

Hydration is the process where the prerendered static HTML, generated by SSR or SSG, is enhanced with interactivity on the client side. After the initial HTML is delivered and rendered in the browser, Angular's JavaScript takes over to "hydrate" the static content, attaching event listeners and thus making the page fully interactive. This approach combines the fast initial load times of SSR/SSG with the dynamic capabilities of a SPA, again leading to a better overall user experience.

Before Angular's Hydration feature, the prerendered static DOM would have been destroyed and replaced with the client-side-rendered interactive version, potentially resulting in a layout shift or a full browser window flash aka content flicker – both leading to bad results in performance tools like Lighthouse and WebPageTest. In my opinion, Angular SSR was not production-ready until supporting Non-Destructive Hydration. This has changed in 2023 since this feature has already become stable in Angular v17.

Please note: Since the introduction of Incremental Hydration in v19 (more on that later), the classic Hydration is referred to as Full-application Hydration. By the way, it's super easy to enable Hydration in Angular 💧

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(), // use v16 full-app hydration
  ],
};

If you're still using NgModules (for reasons), it becomes:

@NgModule({
  providers: [provideClientHydration()],
})
export class AppModule {}

Deferrable Views (preview in v17, stable since v18) with @defer

Deferrable Views, also called @defer blocks, are Angular's native primitive for declaratively defer loading components of your application. It can be used as an alternative to the router-based lazy loading through loadComponent() (used with Standalone Components) or loadChildren() (used with another routes definition array and formerly used with NgModules).

The @defer block allows you to specify when a component should be loaded and rendered, which can be based on various triggers like on idle, on viewport, on hover, on interaction etc. This is a great way to improve the initial load performance of your application by deferring the loading of non-critical components – for example everything below-the-fold – until they are needed. It can also be used to lazyload heavy libraries (like charts or complex tables). Learn more about the @defer block in my blog post.

Important: While Deferrable Views work completely independently of SSR, they can be used in combination with SSR to enforce client-side rendering (CSR) for certain components. This is especially useful for user-dependent content, such as user-specific lists or prices. The @defer block will render the placeholder on the server and then load the real content in the browser once it has been triggered.

Deferrable Views Demo

You can find a demo in the deferrable views branch in this repository on GitHub 😏

Event Replay (in preview since v18, but battle-proven by Google)

This example was taken from the official Angular blog. Consider an app that contains a click button like this:

<button type="button" (click)="onClick()">Click</button>

Previously, the event handler (click)="onClick()" would only be called once your application has finished Hydration in the client. With Event Replay enabled, JSAction is listening at the root element of the app. The library will capture events that (natively) bubble up to the root and replay them once Hydration is complete.

If implemented, Angular apps will stop ignoring events before Hydration is complete and allow users to interact with the page while it's still loading. There is no need for developers to do anything special beyond enabling this feature.

And again, it's super comfy to enable Event Replay in your app 🤩

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(
      withEventReplay(), // use hydration with v18 event replay
    ),
  ],
};

Note: At the time of writing, this feature is still in Developer Preview, so use it cautiously. However, I believe it's perfectly ready for production usage.

Hybrid Rendering (in preview since v19)

Angular v19 will introduce Hybrid Rendering to meet modern web demands following this RFC in the Angular GitHup repo. It allows providing additional route information for the server. Details like rendering modes and response headers will provide finer control for SSR.

We can now select the page rendering mode per route:

SSR: The page renders on the server during a request (best for dynamic content that updates quickly)
SSG: The page renders during build time and is served as a static asset (best for UX & performance)
CSR: The page renders in the browser (best for user-based content)

To do this we need to add a serverConfig in app.config.server.ts looking like this:

/* src/app/app.config.server.ts */
// imports [...]

const serverAppConfig: ApplicationConfig = {
  providers: [provideServerRendering(), provideServerRoutesConfig(serverRoutes)],
};

export const serverConfig = mergeApplicationConfig(appConfig, serverAppConfig);

This will be used in our main.server.ts instead of the client appConfig:

/* src/main.server.ts */
// imports [...]

const bootstrap = () => bootstrapApplication(AppComponent, serverConfig);

export default bootstrap;

Next, we can specify the renderMode for each serverRoute:

/* src/app/app.routes.server.ts */
// imports [...]

export const serverRoutes: ServerRoute[] = [
  { path: "ssr", renderMode: RenderMode.Server },
  { path: "ssg", renderMode: RenderMode.Prerender },
  { path: "csr", renderMode: RenderMode.Client },
];

Note: The same routes need to be used in app.routes.ts to become fully functional.

Additionally, some intelligent features like server side 301 redirects or 404 not found errors can be added to the server config.

/* src/app/app.routes.server.ts */
// imports [...]

export const serverRoutes: ServerRoute[] = [
  // [...],
  { path: "redirect", renderMode: RenderMode.Server, status: 301 },
  {
    path: "error",
    renderMode: RenderMode.Server,
    status: 404,
    headers: {
      "Cache-Control": "no-cache",
    },
  },
  { path: "**", renderMode: RenderMode.Server },
];

If you want to play around with this, check out this v19-ssr demo by ma man Matthieu Riegler.

Note: At the time of writing, this feature is still in Developer Preview, so implement it cautiously as the API may still change.

Incremental Hydration (in preview since v19)

Partial Hydration, now called Incremental Hydration, announced at ng-conf and Google I/O 2024, is a technique that allows incremental hydration of an app after server-side rendering, improving the initial load but also runtime performance by loading less JavaScript upfront. It builds upon the fabulous @defer API, in which we all fell in love since Angular v17. It's enabling Angular to render the HTML content on the server and hydrate deferred blocks on the client after they have been triggered to do so.

The Angular team (special thanks goes out to Jessica Janiuk! By the way, watch here presenation of Incremental Hydration in Angular v19 on YouTube) completed the RFC in the Angular GitHup repo and is now actively prototyping this feature, with an experimental release in v19 for all performance-critical applications out there 🥳

To test it simply add withIncrementalHydration() to your app.config.ts:

import { provideClientHydration, withIncrementalHydration } from "@angular/platform-browser";

export const appConfig: ApplicationConfig = {
  providers: [
    // [...]
    provideClientHydration(withIncrementalHydration()),
  ],
};

Please note: Event Replay is automatically enabled when using withIncrementalHydration(), so you can remove that provider.

Next, you can set a Hydration Trigger by choosing either:

hydrate on with a trigger (same as for @defer, see here for a full list of built-in triggers)
hydrate when with a boolean symbol, Signal or function as the trigger
hydrate never component will get rendered on the server but never hydrated (for static content)

hydrate on

@defer (on viewport; prefetch on idle; hydrate on hover) {
  <app-deferred-hydration />
}

The component's static and SSRed HTML will be rendered before coming into the viewport, the corresponding JS bundle will be prefetched on idle (like PreloadingStrategy in the Router) and then finally the JS (all the interactivity, like event handlers) will be hydrated into the browser on hover. This is in stark contrast to the default full-application hydration, where all the components are hydrated at once.

hydrate when

@defer (hydrate when isUserLoggedIn) {
  <app-deferred-hydration />
}

The component will be rendered on idle (default @defer trigger), i.e. after bootstrapping the App is complete, but it will only be hydrated once isUserLoggedIn is true.

hydrate never

@defer (on viewport; hydrate never) {
  <app-deferred-hydration />
}

The component will be rendered on viewport, but it will never be hydrated - so no event handlers will be attached.

Incremental Hydration Demo

Make sure to play around with this fun-tastic feature starting from my Incremental Hydration Demo on GitHub 😏

Give back some love

Since this feature is still in experimental make sure to help further improve it by providing useful feedback to the RFC in the Angular GitHup repo.

Build

Since Angular v17 we have two options for building our Angular app.

Angular's new Application Builder (all-in-one)

As mentioned, I'd recommend switching to the new Application Builder using esbuild and Vite. The advantage of using esbuild over Webpack is that it offers faster build times and more efficient and fine-grained bundling. The significantly smaller bundle also leads to better initial load performance – with or without SSR! Vite is a faster development server supporting extremely fast Hot Module Replacement (HMR).

Additionally, both SSR and Prerendering (SSG) are enabled by default as mentioned in this screenshot from the Angular Docs showing a table of the Angular Builders (note that the @angular-devkit/build-angular:server is missing here):

Simply run ng b to trigger a browser and server build in one step. Angular will automatically process the Router configuration(s) to find all unparameterized routes and prerender them for you. If you want, you can add parameterized routes via a txt file. To migrate, read my automated App Builder migration guide.

If still using Webpack (for reasons)

If – for any reason – you're still committed to using Webpack to build your web app, you need the browser builder to be configured in your angular.json (might be in project.json if you're using Nx). This will, of course, be added automatically once you run ng add @angular/ssr.

{
  "server": {
    "builder": "@angular-devkit/build-angular:server",
    "options": {
      "outputPath": "dist/your-fancy-app-name/server",
      "main": "server.ts",
      "tsConfig": "tsconfig.server.json"
    }
  }
}

Note: The referenced server.ts lies in the project's root and is the entry point of your server application. With this dedicated server builder, there is also a dedicated tsconfig.server.json (whereas the new Application Builder recommended previously merges the two tsconfig files for more convenience) 🤓

Now let's quickly have a look at the build scripts:

Important note: If you haven't started using pnpm, you're missing out. However, of course, both npm run ... and yarn ... will also work instead of pnpm ....

pnpm dev:ssr
ng run your-fancy-app-name:serve-ssr

Similar to ng s, which offers live reload during development, but uses server-side rendering. Altogether, it's a bit slower than ng s and won't be used a lot apart from quickly testing SSR on localhost.

pnpm build:ssr
ng build && ng run your-fancy-app-name:server

Builds both the browser application and the server script in production mode into the dist folder. Use this command when you want to build the project for deployment or run performance tests. For the latter, you could use serve or a similar tool to serve the application on your localhost.

Deploy

You have two options for deployment. While both are technically possible, I'd recommend using the second one.

Using on-demand rendering mode via node server

Starts the server for serving the application with node using SSR.

pnpm serve:ssr
node dist/your-fancy-app-name/server/main.js

I've shown a detailed example Docker container here.

Caution: Angular requires a certain Node.js version to run, for details see the Angular version compatibility matrix.

Using build time SSR with SSG (recommended)

This option doesn't need a node environment on the server and is also way faster than the other one.

pnpm prerender
ng run your-fancy-app-name:prerender

Used to generate an application's prerendered routes. The static HTML files of the prerendered routes will be attached to the browser build, not the server. Now you can deploy your browser build to whatever host you want (e.g. nginx). You're doing the same thing as without SSR with some extra directories (and index.html files).

Important note: If you're using the new (and recommended) Application Builder, you can skip these steps for building and prerendering since they're already included in ng b. In other words, you have zero extra work for building including SSR & SSG – pretty great, huh? 😎

Debug

The first step in debugging is looking for misconfigurations in your angular.json (project.json) or some errors in your server.ts. If both look good, there is no definite way to debug SSR and SSG issues. Feel free to contact me if you're experiencing any troubles.

How to avoid the most common issue

Browser-specific objects like document, window, localStorage, etc., do NOT exist on the server app. Since these objects are not available in a Node.js environment, trying to access them results in errors. This can be avoided by using the document injector or by running code explicitly in the browser:

import { Component, inject, PLATFORM_ID } from "@angular/core";
import { DOCUMENT, isPlatformBrowser, isPlatformServer } from "@angular/common";

export class AppComponent {
  private readonly platform = inject(PLATFORM_ID);
  private readonly document = inject(DOCUMENT);

  constructor() {
    if (isPlatformBrowser(this.platform)) {
      console.warn("browser");
      // Safe to use document, window, localStorage, etc. :-)
      console.log(document);
    }

    if (isPlatformServer(this.platform)) {
      console.warn("server");
      // Not smart to use document here, however, we can inject it ;-)
      console.log(this.document);
    }
  }
}

Browser-Exclusive Render Hooks

An alternative to injecting isPlatformBrowser are the two render hooks afterNextRender and afterRender, which can only be used within the injection context (basically field initializers or the constructor of a component):

The afterNextRender hook, takes a callback function that runs once after the next change detection – a bit similar to the init lifecycle hooks. It's used for performing one-time initializations, such as integrating 3party libs or utilizing browser APIs:

export class MyBrowserComponent {
  constructor() {
    afterNextRender(() => {
      console.log("hello my friend!");
    });
  }
}

If you want to use this outside of the injection context, you'll have to add the injector:

export class MyBrowserComponent {
  private readonly injector = inject(Injector);

  onClick(): void {
    afterNextRender(
      () => {
        console.log("you've just clicked!");
      },
      { injector: this.injector },
    );
  }
}

The afterRender hook, instead, is executed after every upcoming change detection. So use it with extra caution – same as you would do with the ngDoCheck and ng[Content|View]Checked hooks because we know that Change Detection will be triggered a lot in our Angular app – at least until we go zoneless, but that story that will be presented in yet another blog post 😎

export class MyBrowserComponent {
  constructor() {
    afterRender(() => {
      console.log("cd just finished work!");
    });
  }
}

If you'd like to deep dive into these hooks, I recommend reading this blog post by Netanel Basal.

Angular Hydration in DevTools

The awesome Angular collaborator Matthieu Riegler has recently added hydration debugging support to the Angular's DevTools! Which are, besides all Chromium derivatives, also available for Firefox, but then why would somebody still use that Boomer browser? 😏

Note the 💧 for hydrated components. Even though this feature was announced in the Angular v18 update, it also works in past versions.

Other SSR Debugging Best Practices

Here is a collection of some more opinionated debugging recommendations:

DevTools: Besides the updated Angular DevTools tab, inspect your HTML with the Elements tab and your API requests with the Network tab. BTW, you should also simulate a slow connection here when performance testing your app.
Console: I personally like to log everything into my Console. Not interested in a logger lib since I'm fine with console.log() and maybe some other levels. Any console logs will be printed into the terminal where ng b or pnpm dev:ssr or pnpm serve:ssr has been run. We don't need to talk about logging into the browser's console on production, or do we?
Node.js: Start your SSR server with the --inspect flag to get more information: node --inspect dist/server/main.js
Fetching: Ensure all necessary data is available at render time. Use Angular's TransferState to transfer data from the server to the client.
Routing: Make sure all routes are correctly configured and match on both the browser and server builds.
Environments: Ensure environment variables are correctly set up for both browser and server builds.
3rd-party Libs: As always, be very careful about what you include in your project. Some libraries might not be implemented correctly and thus not work in an SSR context. Use conditional imports or platform checks to handle these cases or, even better, get rid of those libs in the first place.

That's all I have got so far. If you've got anything to add, feel super free to contact me!

Advanced

Disable Hydration for Components

Some components may not work properly with hydration enabled due to some issues, like DOM Manipulation. As a workaround, you can add the ngSkipHydration attribute to a component's tag to skip hydrating the entire component.

<app-example ngSkipHydration />

Alternatively, you can set ngSkipHydration as a host binding.

@Component({
  host: { ngSkipHydration: "true" },
})
class DryComponent {}

Please use this carefully and thoughtfully. It is intended as a last-resort workaround. Components that have to skip hydration should be considered bugs that need to be fixed.

Use Fetch API instead of XHR

The Fetch API offers a modern, promise-based approach to making HTTP requests, providing a cleaner and more readable syntax compared to the well-aged XMLHttpRequest. Additionally, it provides better error handling and more powerful features such as support for streaming responses and configurable request options. It's also recommended to be used with SSR by the Angular team.

To enable it, simply add withFetch() to your provideHttpClient():

export const appConfig: ApplicationConfig = {
  providers: [provideHttpClient(withFetch())],
};

If you're still using NgModules (for reasons), this becomes:

@NgModule({
  providers: [provideHttpClient(withFetch())],
})
export class AppModule {}

Configure SSR API Request Cache

The Angular HttpClient will cache all outgoing network requests when running on the server. The responses are serialized and transferred to the browser as part of the server-side HTML. In the browser, HttpClient checks whether it has data in the cache and if so, reuses that instead of making a new HTTP request during the initial load. HttpClient stops using the cache once an application becomes stable in the browser.

By default, HttpClient caches all HEAD and GET requests that don't contain Authorization or Proxy-Authorization headers. You can override those settings by using withHttpTransferCacheOptions when providing hydration:

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(
      withEventReplay(),
      withHttpTransferCacheOptions({
        filter: (req: HttpRequest<unknown>) => true, // to filter
        includeHeaders: [], // to include headers
        includePostRequests: true, // to include POST
        includeRequestsWithAuthHeaders: false, // to include with auth
      }),
    ),
  ],
};

Use Hydration support in Material 18 and CDK 18 💧

Starting with Angular Material 18, all components and primitives are fully SSR and Hydration compatible. For information, read this blog post. On how to upgrade your Angular Material app, consult the docs on migrate from Material 2 to Material 3.

Combine SSR for static & CSR for user content 🤯

As already mentioned above, with Angular v17 Deferrable Views you can easily mix SSR/SSG with CSR 🎉

The usage is pretty straightforward: All @defer components will render their @placeholder on the server and the real content will be loaded and rendered once they have been triggered (by on or when) in the browser. Learn more about how to use and trigger Deferrable Views.

Here are some primitive examples of how to combine SSR and CSR:

Static pages: Use SSR (SSG)
Static content with live updates: Use deferred components for the live content and SSR for the rest
Product list with prices depending on the user: Defer price components and use SSR for the rest
List with items depending on the user: Defer the list component and use SSR for the rest

So basically, everywhere you need CSR (for user-dependent content), you need to @defer those parts. Use the @placeholder (and @loading) to show spinners or equivalents to inform the user that something is still being loaded. Also, make sure to reserve the right amount of space for the deferred components – avoid layout shifts at all costs!

SEO and Social Media Crawling 🔍

If you want to look good on Google and/or social media platforms, make sure to implement all the necessary meta tags in SSR. For a comprehensive list, including some tools and tips, jump here.

export class SeoComponent {
  private readonly title = inject(Title);
  private readonly meta = inject(Meta);

  constructor() {
    // set SEO metadata
    this.title.setTitle("My fancy page/route title. Ideal length 60-70 chars");
    this.meta.addTag({ name: "description", content: "My fancy meta description. Ideal length 120-150 characters." });
  }
}

Use SSR & SSG within AnalogJS 🚀

AnalogJS is the meta-framework built on top of Angular – like Next.js (React), Nuxt (VueJS), SolidStart (Solid). Analog supports SSR during development and building for production. If you want to know more, read the announcement of version 1.0 by Brandon Roberts or wait for my upcoming blog post 😏

Angular SSR & SSG featuring I18n

Since the Angular I18n only works during built-time, it's fairly limited. Therefore, we recommend using Transloco (or NGX-Translate). When adding Transloco by running ng add @jsverse/transloco, you'll be prompted for SSR usage. However, you can also manually add the necessary changes for SSR (see Transloco Docs):

@Injectable({ providedIn: "root" })
export class TranslocoHttpLoader implements TranslocoLoader {
  private readonly http = inject(HttpClient);

  getTranslation(lang: string) {
    return this.http.get<Translation>(`${environment.baseUrl}/assets/i18n/${lang}.json`);
  }
}

export const environment = {
  production: false,
  baseUrl: "http://localhost:4200", // <== provide base URL for each env
};

This will SSR everything in the default language and then switch to the user's language (if different) in the browser. While this generally works, it's definitely not ideal to see the text being swapped. Furthermore, we need to ensure there are no layout shifts upon switching! If you come up with any ideas on how to improve this, please contact me!

SSR and Hydration with Native Federation

The Angular Architects' native federation package now finally supports SSR for the shell app (starting with v18.2.3). This allows you to use Module Federation together with SSR and SSG in your Angular app. Native Federation has the same API as the webpack Module Federation but uses browser-native Import Maps and is thus also working with esbuild – Angular's new Application Builder.

Learn more about this approach and how to get started in this post by the master of module federation Manfred Steyer.

Caution with PWA

Be careful if you are using Angular SSR in combination with the Angular PWA service worker because the behavior deviates from default SSR. The initial request will be server-side rendered as expected. However, subsequent requests are handled by the service worker and thus client-side rendered.

Most of the time that's what you want. Nevertheless, if you want a fresh request you can use the freshness option as Angular PWA navigationRequestStrategy. This approach will try a network request and fall back to the cached version of index.html when offline. For more information, consult the Angular Docs and read this response on Stack Overflow.

Outlook

The next step will be streamed SSR for zoneless apps. To see what’s planned for upcoming Angular releases, check the roadmap:

Angular roadmap on angular.dev

Performance Workshop

If you want to deep dive into Angular, we offer a variety of workshops – both in English and German.

Performance Workshop 🚀
Best Practices Workshop 📈 (including performance related topics)
Accessibility Workshop ♿

Conclusion

In summary, implementing Server-Side Rendering (SSR) in Angular — along with Static Site Generation (SSG), hydration, and event replay — significantly enhances the initial load performance of your Angular applications. With the new Incremental Hydration feature, Angular has taken a significant step toward becoming the framework of choice for building high-performance web applications – something it has not traditionally been known for.

This advancement results in a better user experience, particularly on slower networks or less capable devices, and it also improves your web app’s SEO and crawlability. By following the guidelines and best practices outlined in this guide, you can boost your apps’ load performance with minimal effort. Furthermore, the new Application Builder simplifies the process of building and deploying your projects.

Feel free to contact me for further questions or join our Performance Workshop 🚀 or the Best Practices Workshop 📈to learn more about performance optimization for Angular apps.

This blog post was written by Alexander Thalhammer. Follow me on GitHub, X or LinkedIn.

References

Why is Initial Load Performance so Important? by Alexander Thalhammer
Angular v16 – official blog post by Minko Gechev
Angular Update Guide to V17 incl. migrations by Alexander Thalhammer
Angular v17’s Deferrable Views by Alexander Thalhammer
Angular v18 – official blog post by Minko Gechev
Angular’s after(Next)Render hooks by Netanel Basal
Angular Event Replay blog post by Jatin Ramanathan & Tom Wilkinson
Angular Incremental Hydration on YouTube by Jessica Janiuk
Angular SSR Docker example by Alexander Thalhammer

DEV Community: Alexander Thalhammer

Agentic Engineering: What Do AI Coding Tools Do With Your Code?

TL;DR: Do Not Ban AI, Approve Safe Paths

This Is Not a Legal Guide

What Do We Actually Share?

More Than Reading: Breach and Industrial Espionage

What I Found in Vendor Docs

Consumer Plans vs Business Plans

No Training Is Not the Same as No Retention

EU and Regulatory Considerations

Green, Yellow, Red

"We Are Not Allowed to Use AI"

A Simple Company Policy

My Personal Verdict

Agentic Engineering Workshop

Conclusion

Agentic Engineering: What Does AI Coding Really Cost?

This Is Still Not a Benchmark

TL;DR: Start With €40 or €60, Upgrade Only Where You Hit Limits

Why Subscriptions Are Such a Good Deal

The €20 Tier Is for Getting Started

The Current Pricing Picture

OpenAI / Codex

Anthropic / Claude

Cursor

Google / Gemini / Antigravity

Copilot

Enterprise Is a Different Game

API Usage: Paying the Real Cost

Token Usage Is the Real Cost Driver

Low, Medium, High, Extra

Fast Mode

How I Would Control Costs in a Team

Agentic Engineering Workshop

Conclusion

Agentic: Which App/Harness Is Best for Angular Development?

From Models to Agent Harnesses

This Is Not a Benchmark

TL;DR: My Current Setup

My AI Coding Journey

WebStorm + GitHub Copilot

WebStorm + AI Assistant + Junie + Opus 4.5

VS Code + Claude Code + Opus 4.6

Beyond IDE: Agentic Coding Apps (Super Apps)

Claude desktop app + Opus 4.7

Codex + GPT 5.5

Cursor + Composer 2.5

Antigravity + Gemini 3.5 Flash

Open Source Alternatives to the Big Ones

But I'm super happy with working in the terminal

Which Coding Agent Harness Would I Choose Today?

Agentic Engineering Workshop

Conclusion

Agentic Engineering: Which LLM Is Best for Angular Development?

My AI Coding Journey

Comparison from November 2025 (Outdated!)

TL;DR: My Current Ranking

Which Frontier LLMs Are Relevant for Angular in May 2026?

Public Benchmarks

Artificial Analysis Benchmarks

DeepSWE Benchmark

What the Benchmarks Suggest

But what about the Chinese LLMs?

And what about the European LLMs?

And what about local LLMs?

Are any of these models open source?

My Subjective Verdict

My #1 for Angular: Opus 4.7 by Anthropic

My #1 all-rounder: GPT 5.5 by OpenAI

My #1 newcomer: Composer 2.5 by Cursor

Candidate to watch: Gemini 3.5 Flash now, Gemini 3.5 Pro later

But Alex, what about the new model(s)?

Agentic Engineering Workshop

Conclusion

Why Angular ARIA in v21 is pretty neat

Components

Why is this neat?

When to use Angular ARIA?

When to avoid Angular ARIA?

Angular Styling Best Choices Matrix

Fine-tuned control with `routerLinkActiveOptions`

Indicate current page `ariaCurrentWhenActive`