DEV Community: Phalgun Vaddepalli

3 Ways to Check the Angular Version in Your Browser (Even in Prod)

Phalgun Vaddepalli — Wed, 12 Aug 2026 20:52:04 +0000

When debugging an Angular application in the browser, verifying the exact version of the framework running under the hood is often the first step in troubleshooting.

While you could always check your package.json, sometimes you don't have access to the source code, or you need to confirm that the deployed build matches your expectations.

Here are three ways to extract the Angular version directly from the browser, ranging from the absolute fastest methods to digging into optimized Webpack bundles.

1. The Quickest Way: Inspect the DOM

When Angular bootstraps an application, it automatically stamps the root component with the exact framework version. This is the fastest, most reliable method if the application has successfully rendered.

How to do it:

Open your browser's Developer Tools (F12 or right-click -> Inspect).
Go to the Elements tab.
Locate the root application tag (usually <app-root>).
Look for the ng-version attribute.

You’ll see something like this: <app-root ng-version="21.2.14"></app-root>. That's it!

2. The Console Approach: Querying the Version

If you prefer keeping your hands on the keyboard and out of the Elements tree, you can use a quick JavaScript snippet in the console to pull the exact same attribute.

How to do it:

Open the Console tab in your Developer Tools.
Run the following command:

document.querySelector('[ng-version]').getAttribute('ng-version');

The console will return the version string, such as "21.2.14".

3. The Deep Dive: Searching the Webpack Bundles

Sometimes, you might need to inspect the actual JavaScript bundles—perhaps the app is failing to bootstrap, and the <app-root> tag hasn't been stamped yet.

Older tutorials will tell you to look for a vendor.js file and search for new Version(. However, in modern Angular configurations, this advice is often misleading.

If your angular.json has vendorChunk set to false, or if you are dealing with a build where optimization and output hashing are enabled, Angular doesn't split third-party libraries into a separate vendor file. Instead, everything is bundled into a hashed main file, and the code is minified.

How to find the version in optimized Webpack builds:

Open the Developer Tools and navigate to the Sources tab (or check the Network tab for loaded JS).
Look for your main application bundle. It will typically be named something like main.[hash].js (e.g., main.3b878c28634a75c9.js).
Open this file and press Ctrl + F (or Cmd + F) to open the in-file search.
Because the code is minified, the Version class has likely been aliased to a single letter (like l or e). Instead of searching for the full declaration, search for a partial match:
Type .Version(" or Version(" into the search bar.
You will find a minified snippet that looks something like this:

new l.Version("21.2.14")

The string inside the quotes is your Angular version.

Summary

Whether you are dealing with local development environments or heavily optimized production builds, knowing how to navigate the DOM and your Webpack bundles is a handy debugging skill. For quick checks, rely on the ng-version attribute. For deeper bundle analysis, just remember to adjust your search terms to account for minification!

The invisible anchor: how `@if` breaks when you touch the DOM

Phalgun Vaddepalli — Fri, 07 Aug 2026 14:01:52 +0000

Angular 21 · 7 min read · August 7, 2026

Angular's control-flow directives — @if, @for, @switch — don't just add and remove elements. They leave behind invisible anchor nodes in the DOM, and those anchors are the only way Angular knows where to put content back when a condition changes. If you destroy one, the directive silently breaks — and no error tells you.

What is an anchor node?

When Angular compiles a template with @if, it doesn't simply render or remove your element. It inserts a DOM comment node at the exact position where the conditional content should appear. This comment is the anchor.

When the condition is true, Angular inserts the rendered content before the anchor. When the condition flips to false, Angular removes the content but leaves the anchor in place. That way, when the condition becomes true again, Angular walks to the anchor and re-inserts the content at the correct position.

You can see this for yourself in the demo app.

Toggle show to false and look at the DOM inspector: the paragraph disappears, but a comment node remains. That comment is the anchor, and it's the whole reason the directive can restore content later.

When `appendChild()` is safe

appendChild() adds a new node at the end of the parent's child list. Crucially, it does not touch any existing children. The anchor comment stays right where it was. So after appending, the @if directive still works: toggle the condition off and on, and the paragraph comes back exactly where it should.

This is the key insight: adding nodes is safe; wiping nodes is not. As long as you don't destroy the anchor, Angular's bookkeeping stays intact.

When `replaceChildren()` breaks everything

replaceChildren() is more aggressive. It removes every existing child of the element before inserting its arguments. That includes text nodes, element nodes — and comment nodes. The anchor is gone.

Now flip show to false. Angular removes the paragraph. Then flip it back to true. Angular looks for its anchor to know where to insert the content… and finds nothing. The directive can't place its content, so nothing renders. No error is thrown. No warning is logged. The paragraph is simply gone, and the only way to get it back is to reload the page.

This is what makes the bug so insidious: it's silent. Your application looks broken to the user, but the console is clean. You might spend hours checking your signals, your conditions, your change detection — all while the real problem is a missing DOM comment that was destroyed three interactions ago.

The same trap applies elsewhere

innerHTML = '', removeChild() on the wrong node, textContent = '' — any operation that wipes a container's children will destroy anchor nodes. The @for and @switch directives use the same anchor mechanism, so they're equally vulnerable.

How to recover without a page reload

Once the anchor is destroyed, the @if directive instance is permanently broken. You can't restore the anchor by setting the condition back to true — Angular has no way to recreate it. The only fix is to destroy and recreate the entire directive instance.

In the demo, the Reset button does this by wrapping the host element in a @for loop keyed on a counter. Each reset increments the counter, which forces Angular to tear down the old template — broken @if and all — and build a fresh one with a brand-new anchor. The paragraph comes back immediately, no reload needed.

In a real application, you'd rarely need this. The point is to understand what happened: the directive's internal state was corrupted by an external DOM mutation, and the only recovery is to let Angular rebuild that part of the view from scratch.

The rule

Never call replaceChildren(), innerHTML = '', or any wipe-and-replace operation on an element that Angular manages with control-flow directives. If you need to add content, use appendChild(). If you need to remove content, let Angular handle it through its own reactive state. The DOM inside a directive-managed element is not yours to wipe — it's Angular's, and the anchors are load-bearing.

Why this matters

Modern Angular gives you powerful tools for directly manipulating the DOM when you need them — ViewChild, ElementRef, and raw browser APIs are all available. But with that power comes a contract: the DOM inside directive-managed regions is shared territory. Angular relies on invisible infrastructure — anchor comments, view containers, internal bookkeeping — that lives in the same DOM tree you're touching.

The best defense is understanding what's under the hood. Once you know the anchor is there, you know why appendChild() is safe and replaceChildren() is not. And when something silently stops rendering, you'll know exactly where to look.

Exploring Chrome's Built-In AI APIs: A Hands-On Guide

Phalgun Vaddepalli — Thu, 09 Jul 2026 21:05:22 +0000

Introduction

Chrome's Built-In AI APIs allow web applications to perform selected AI tasks using models managed by the browser.

Unlike traditional cloud-based AI integrations, developers do not need to deploy or operate separate model infrastructure for these workloads.

This guide introduces the major Built-In AI APIs and provides small examples of each API. Complete runnable examples are linked separately.

Getting Started

Chrome's Built-In AI APIs are at different stages of availability. The Language Detector, Translator, and Summarizer APIs are available in stable Chrome on supported desktop devices, while other APIs have different availability and testing requirements.

Enabling Experimental APIs for Local Testing

The required setup depends on the API and Chrome version being tested.

During local testing with Chrome 149, the following flags were enabled:

chrome://flags/#optimization-guide-on-device-model
chrome://flags/#prompt-api-for-gemini-nano
chrome://flags/#prompt-api-for-gemini-nano-multimodal-input
chrome://flags/#writer-api-for-gemini-nano
chrome://flags/#proofreader-api-for-gemini-nano

After changing Chrome flags, fully relaunch the browser.

Note: Chrome's Built-In AI APIs are evolving. Check the current Chrome documentation for the release status and setup requirements of the specific API you are using rather than assuming that every API requires the same configuration.

Language Detector API

The Language Detector API identifies the language of a given text.

Use Cases

Dynamic localization
Query routing
Analytics
Content classification

Example

const detector = await LanguageDetector.create();
const result = await detector.detect("Bonjour tout le monde");
console.log(result);

Complete runnable example: Language Detector API on GitHub Gist

Translator API

The Translator API translates text between supported languages.

Use Cases

Localization
User-generated content translation
Multilingual applications

Example

const translator = await Translator.create({
  sourceLanguage: "en",
  targetLanguage: "ar"
});
const result = await translator.translate("Hello, world!");
console.log(result);

Complete runnable example: Translator API on GitHub Gist

Summarizer API

The Summarizer API generates summaries of text.

Use Cases

Release notes
Article digests
Document summaries
Knowledge management

Example

const summarizer = await Summarizer.create({
  type: "key-points",
  length: "short"
});
const result = await summarizer.summarize(longText);
console.log(result);

Complete runnable example: Summarizer API on GitHub Gist

Prompt API

The Prompt API provides access to Gemini Nano for general-purpose inference.

Use Cases

Metadata extraction
Classification
Structured output generation
Lightweight reasoning

Example

const session = await LanguageModel.create();
const result = await session.prompt(
  "Extract structured data from this text."
);
console.log(result);

Complete runnable example: Prompt API on GitHub Gist

Writer API

The Writer API generates new content based on an input prompt.

Use Cases

Email drafts
Documentation
Support responses

Example

const writer = await Writer.create({
  tone: "neutral",
  length: "short"
});
const result = await writer.write(
  "Write a short introduction to browser-based AI."
);
console.log(result);

Complete runnable example: Writer API on GitHub Gist

Rewriter API

The Rewriter API transforms existing content.

Use Cases

Incident reports
User reviews
Internal communications

Example

const rewriter = await Rewriter.create({
  tone: "more-formal"
});
const result = await rewriter.rewrite(
  "We fixed the issue and everything looks good now."
);
console.log(result);

Complete runnable example: Rewriter API on GitHub Gist

Streaming UI example: Rewriter Streaming on GitHub Gist

Proofreader API

The Proofreader API checks text for writing errors and provides suggested corrections.

Use Cases

Documentation review
Content publishing
User-generated content

Example

const proofreader = await Proofreader.create();
const result = await proofreader.proofread(
  "This sentence have a grammatical error."
);
console.log(result);

Complete runnable example: Proofreader API on GitHub Gist

Security Considerations

On-device inference changes where computation occurs, but it does not eliminate application security risks.

AI-generated output should be treated as untrusted data and validated using the same rigor applied to other untrusted input.

Do not execute generated code or render generated HTML without appropriate validation and sanitization. AI-generated output should also not be trusted to make security-sensitive decisions such as authorization.

Final Thoughts

Chrome's Built-In AI APIs are a practical way to experiment with browser-managed inference.

Task-specific APIs such as translation, language detection, and summarization are particularly well suited to browser-managed inference. For workloads that require broader capabilities or consistent availability across browsers and devices, cloud-hosted models remain an important option, leading to a hybrid approach where local and remote inference coexist.

The most practical architecture is often a hybrid one: use browser-managed AI when the required capability is available, fall back to cloud services when broader capabilities are needed, and use deterministic logic when AI is unnecessary.

DEV Community: Phalgun Vaddepalli

3 Ways to Check the Angular Version in Your Browser (Even in Prod)

1. The Quickest Way: Inspect the DOM

2. The Console Approach: Querying the Version

3. The Deep Dive: Searching the Webpack Bundles

Summary

The invisible anchor: how `@if` breaks when you touch the DOM

What is an anchor node?

When appendChild() is safe

When replaceChildren() breaks everything

How to recover without a page reload

The rule

Why this matters

Exploring Chrome's Built-In AI APIs: A Hands-On Guide

Introduction

Getting Started

Enabling Experimental APIs for Local Testing

Language Detector API

Use Cases

Example

Translator API

Use Cases

Example

Summarizer API

Use Cases

Example

Prompt API

Use Cases

Example

Writer API

Use Cases

Example

Rewriter API

Use Cases

Example

Proofreader API

Use Cases

Example

Security Considerations

Final Thoughts

When `appendChild()` is safe

When `replaceChildren()` breaks everything