DEV Community: vinesh eg

I Built a Browser-Native AI App With No Backend — Here’s What I Learned

vinesh eg — Wed, 25 Feb 2026 15:36:28 +0000

Combining Chrome's new WebMCP API with Transformers.js taught me that AI development isn't just a backend problem anymore

When most people think about adding AI to a web app, they picture the same architecture: a frontend that sends requests to a backend that calls OpenAI or Anthropic, and a response that travels back the same way. It works. But it also means API bills, latency, data leaving the device, and infrastructure to maintain.

I wanted to challenge that assumption. So I built a document analysis app where everything — the AI model, the tool execution, the agent reasoning — runs entirely in the browser. No backend. No API keys. No cloud inference.

Two tools made it possible: Transformers.js and Chrome's WebMCP API. They solve different problems, and combining them produced something more interesting than either could alone.

Transformers.js: The Model Comes to the Browser

Transformers.js is Hugging Face's JavaScript library for running AI models locally in the browser. It uses ONNX format models, accelerated by WebAssembly, with optional WebGPU support for faster inference where available.

The model I used was Qwen2.5-0.5B-Instruct — a 0.5 billion parameter instruction-tuned model, quantised to 4-bit (~300MB download). It downloads once, caches in the browser, and runs completely offline from that point on.

The critical engineering decision is where the model runs: a Web Worker. This keeps inference off the main thread entirely, so the UI stays responsive while the model is generating. Without this, the page would freeze for every token generated.

What surprised me was how capable the model is for focused tasks. Summarisation, keyword extraction, document Q&A, deciding which tool to call — Qwen2.5-0.5B handles all of these well. It's not GPT-4. But for scoped, well-defined tasks it's genuinely useful, and it's free to run after the initial download.

What Transformers.js is good for:

Privacy-sensitive workflows where data can't leave the device
Offline-capable applications
High-volume internal tools where per-token API costs add up fast
Any task where you want instant responses without a network round trip

Chrome WebMCP: Making Your Web App Agent-Ready

WebMCP is newer and less understood. It's a W3C browser standard, currently in Chrome 146 Canary behind a feature flag, co-developed by engineers at Google and Microsoft.

The core idea: websites can register structured, callable tools directly in the browser using a new API called navigator.modelContext. Any AI agent that has access to the browser session — via Chrome's DevTools protocol or a connected MCP client — can discover those tools and call them as typed function calls.

// Register a tool that any AI agent can call
navigator.modelContext.registerTool({
  name: "count_words",
  description: "Count words and estimate reading time for the loaded document",
  inputSchema: {},
  execute: async () => ({ wordCount: 423, readingTime: "2 min" })
})

This is a significant shift from how browser-based AI agents work today. Current approaches require agents to visually interpret pages — taking screenshots, reading the DOM, simulating clicks. It's brittle. Every redesign breaks the agent's understanding of the page.

WebMCP replaces visual guessing with a semantic contract. Your page declares what it can do, in terms AI agents already understand.

What WebMCP is not — it's not for your app talking to an AI. It's for an AI agent talking to your app. The direction of the call is reversed from what most developers expect.

What Happens When You Combine Them

Here's where it gets interesting. These two tools solve genuinely different problems:

Transformers.js provides local AI intelligence — the ability to reason, summarise, and decide
WebMCP provides agent interoperability — the ability for external agents to interact with your app through a typed interface

In the POC I built, they work together as a complete agent loop:

User: "What are the main topics in this document?"
         ↓
Qwen2.5 (local, Transformers.js) — Pass 1
  Reads tool descriptions, decides: call extract_keywords({ topN: 8 })
         ↓
toolRegistry.execute("extract_keywords")  ← WebMCP handler
  Returns: [{ word: "transformer", count: 8 }, ...]
         ↓
Qwen2.5 (local, Transformers.js) — Pass 2
  Reads the JSON result, writes natural language answer
         ↓
"The main topics are transformers, attention mechanisms, and neural networks..."

The model runs twice per agent turn — once to decide which tool to call, once to turn the tool result into a human answer. WebMCP provides the structured bridge in between. Neither step touches a server.

The UI makes the whole loop visible: a three-panel layout with the document on the left, AI summary in the middle, and an agent chat console on the right where you can see the navigator.modelContext tool call cards — showing the exact JSON request and response — alongside the natural language answer.

The Practical Difference Between the Two APIs

One thing worth being precise about: WebMCP's navigator.modelContext is a write-only registration API from your own page's perspective. You register tools. External agents call them. There's no getTools() method — you can't call your own registered tools back through the navigator API.

In the POC, I solved this by maintaining a parallel toolRegistry — a simple JavaScript object that stores each tool's execute function. The WebMCP registration exposes tools to external agents, while the registry ref lets the local agent console call the same functions directly.

Each tool registers in two places:
  1. navigator.modelContext.registerTool()  → for external AI agents
  2. toolRegistry["tool_name"] = fn        → for local agent loop

Same logic, same output. One is the external interface, one is the internal wiring.

The Real Use Cases This Unlocks

Working through this POC made the practical applications obvious:

Legal and medical document review — documents never leave the device, no compliance questions about data egress, AI assistance is still fully functional.

Internal enterprise tools — no per-token API costs, no rate limits, works on restricted networks. A tool used by a hundred people all day costs the same as one person using it for five minutes.

Agent-ready web apps — with WebMCP, your web app becomes part of the broader AI agent ecosystem automatically. When Claude in Chrome, Cursor, or any MCP-compatible agent visits your page, it gets a clean typed API instead of having to scrape your UI.

Offline-first applications — once the model is cached, everything works without connectivity. Field tools, healthcare applications, anything that needs to work in low-connectivity environments.

The Honest Trade-offs

Model capability: A 0.5B parameter model is good at focused tasks but not at complex multi-step reasoning. If you need GPT-4 level capability, you still need a cloud model. Browser-native AI is excellent for scoped, well-defined tasks.

First load: ~300MB is a real UX consideration. Users need to see clear progress and understand what's happening. After the first download it's instant.

WebMCP maturity: Chrome 146 Canary only, behind a flag. No Firefox or Safari signals yet. The @mcp-b/global polyfill bridges the gap for demos and development, but native agent discovery requires Chrome Canary for now.

WebGPU on Windows: GPU driver crashes with WebGPU are common on Windows right now. WASM is the stable fallback — slower but reliable everywhere.

The Bigger Picture

What this combination demonstrates is that AI development has a new axis to reason about: not just which model, but where the model runs and how your app exposes itself to agents. For a long time, "frontend developer" and "AI developer" were different job descriptions. Transformers.js and WebMCP are collapsing that gap. A frontend developer who understands these two APIs can now ship a complete AI-powered workflow — with local inference, structured tool use, and agent interoperability — without touching a backend. The web page is becoming an AI-native surface. Not just a UI for humans, but a typed interface for agents. WebMCP is the standard that makes that possible without giving up the browser's security model or the user's privacy.

WebMCP: Your AI, Every Website — The Web’s New Power Shift

vinesh eg — Mon, 16 Feb 2026 16:02:30 +0000

The Paradigm Shift: Users Control AI, Not Developers

Chrome 146 has officially introduced WebMCP, fundamentally changing who holds the keys to AI on the web.

The Old Way: Developers choose the AI. You visit a site, you use their model, their API, and follow their privacy rules.
The WebMCP Way: You choose the AI. You bring your preferred assistant—whether it's a local Llama model or a cloud-based Claude—to every website you visit.

Think of it like the early web: Websites used to dictate which browser you needed. Now, browsers are universal. WebMCP does the same for AI—your AI now works everywhere.

What exactly is WebMCP?

WebMCP is a browser API that allows websites to expose their internal functions (tools) to a user's chosen AI assistant.

The Developer's Implementation:

Instead of complex SDKs, you simply register tools:

// Websites register what they can do
navigator.modelContext.registerTool({
  name: 'search_products',
  description: "'Search our product catalog',"
  execute: async (params) => {
    return fetch(`/api/search?q=${params.query}`);
  }
});

The website says, "I can search products." Your AI (configured in your browser) sees that capability and uses it to fulfill your requests.

Why This Wins (For Everyone)

Stakeholder	Benefit
Users	Privacy & Choice. Process medical or financial data using a local model (like Gemini Nano) so data never leaves your machine.
Developers	Zero Cost. Stop paying $500/month in OpenAI API fees. Users bring their own "compute" and "intelligence."
Architects	Separation of Concerns. Your app provides the capabilities; the browser handles the orchestration.

Real-World Scenario: The "One-Command" Shopping

Imagine visiting a retail site and telling your browser AI:

"Find me wireless headphones under $100 and add the best-reviewed pair to my cart."

The site exposes search_products and add_to_cart via WebMCP.
Your AI discovers these tools.
Your AI executes the search, parses the reviews, and hits the "add to cart" function.

The developer didn't have to build a chatbot; they just had to expose their API.

Testing WebMCP: Building a Task Manager POC

To validate WebMCP's real-world viability, I built a proof-of-concept task management application. Here's what I learned:

The Setup (Chrome Canary 146+)

WebMCP is currently experimental:

Download Chrome Canary
Enable chrome://flags/#enable-experimental-web-platform-features
Restart browser

The Implementation

Instead of integrating an AI SDK, I registered six tools:

navigator.modelContext.registerTool({
  name: 'add_task',
  description: 'Add a new task to the list',
  inputSchema: {
    type: 'object',
    properties: {
      taskText: { type: 'string', description: 'Task description' }
    },
    required: ['taskText']
  },
  execute: async (args) => {
    tasks.push({ 
      id: Date.now(), 
      text: args.taskText, 
      completed: false 
    });
    updateUI();
    return { success: true, message: `Task added: ${args.taskText}` };
  }
});

Result: Users could say "Add a task to buy groceries" and their AI (whichever they configured) would execute the function—no prompt engineering, no model selection, no API costs on my end.

Key Learnings from the POC

1. The Mental Shift is Real
As a developer, you stop thinking "How do I integrate AI?" and start thinking "What capabilities should I expose?" It's liberating.

2. Fallback Strategy Required
Only Chrome Canary 146+ supports WebMCP currently. Feature detection is essential:

if ('modelContext' in navigator) {
  // Use WebMCP
  initWebMCPTools();
} else {
  // Fallback to traditional AI integration
  initGeminiAPI();
}

3. Performance Varies by User's Choice

User with local AI: 10-50ms response time
User with cloud AI: 500-1500ms response time
Developer's API cost: $0 in both cases

4. Privacy is Verifiable
When testing with local AI models, network monitoring confirmed zero external API calls. Data truly stayed on the device—perfect for sensitive applications.

5. Tool Documentation Becomes Your API
Your tool descriptions are critical. They're the only "interface" the AI has. Clear, precise descriptions determine whether the AI can use your tools effectively:

// ❌ Bad: Vague description
description: 'Does task stuff'

// ✅ Good: Clear, actionable description
description: 'Add a new task to the user\'s task list with the provided text'

The Reality Check: Security & Implementation

Input Validation is Critical

Just because an AI called your tool doesn't mean the input is safe:

execute: async (args) => {
  // ✅ Always validate
  if (!args.taskText || typeof args.taskText !== 'string') {
    throw new Error('Invalid task text');
  }

  // ✅ Sanitize for XSS
  const sanitized = sanitizeHTML(args.taskText);

  // ✅ Check business rules
  if (sanitized.length > 500) {
    throw new Error('Task text too long');
  }

  return performAction(sanitized);
}

Rate Limiting Still Matters

Even though you're not paying for AI inference, prevent abuse:

const rateLimiter = new Map();

function checkRateLimit(userId) {
  const requests = rateLimiter.get(userId) || [];
  const recentRequests = requests.filter(t => Date.now() - t < 60000);

  if (recentRequests.length > 100) {
    throw new Error('Rate limit exceeded');
  }

  recentRequests.push(Date.now());
  rateLimiter.set(userId, recentRequests);
}

Performance Considerations

Variable latency: A local model might respond in 10ms, a cloud model in 2 seconds. Build UIs with loading states and optimistic updates.
The BYOM risk: Users' AI quality varies. Their model might misinterpret your tools. Robust error handling and clear tool descriptions are essential.

Bottom Line

WebMCP isn't just an API; it's a decentralization of intelligence. It moves AI from a B2B product (sold to devs) to a B2C utility (owned by users).

My POC Proved Three Things:

Developer experience is simpler — No SDK bloat, no API key management, just expose your capabilities
Cost savings are real — $1,800/year eliminated for a modest-traffic app
User control is genuine — Privacy, model choice, and performance tradeoffs shift to where they belong: the user

Within two years, saying "Our site is AI-enabled" will sound as redundant as "Our site has buttons." The web is becoming AI-native, and for the first time, the user is in control.

Ready to build? Start by auditing your app's core functions. What could an AI do for your users if it had the right "tools"?

Try it yourself: My task manager POC is open source. Clone it, enable WebMCP in Chrome Canary, and experience the future of web development firsthand. See README for setup instructions.

Note: content created with the help of AI!

Stop Wasting Time on Dev Tooling Setup: Meet dev-forge

vinesh eg — Tue, 10 Feb 2026 14:35:30 +0000

The Problem Every Developer Faces

Picture this: You're excited to start a new project. You create a new repository, run npm init, and then... the dreaded tooling setup begins.

npm install --save-dev eslint prettier husky lint-staged
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
npm install --save-dev stylelint stylelint-config-standard
npm install --save-dev commitlint @commitlint/config-conventional
# ... 20 more packages and counting

Then comes the configuration files:

.eslintrc.json
.prettierrc
.huskyrc
.lintstagedrc
.stylelintrc
commitlint.config.js

Each with dozens of configuration options. Each needing to work together. Each requiring maintenance.

Two hours later, you still haven't written a single line of actual code.

Sound familiar?

The Real Cost of Developer Tooling

Let's be honest about what this costs:

Time Lost: 2-4 hours per project setup
Inconsistency: Every project configured slightly differently
Maintenance Burden: Updating 10+ dependencies regularly
Onboarding Friction: New team members confused by configuration
Cognitive Load: Remembering what all these tools do

For a team of 5 developers starting 10 projects a year:

100-200 hours spent just on tooling setup
That's 2.5-5 weeks of productive development time lost

And that's just setup. Add maintenance, debugging configuration conflicts, and keeping up with best practices? The real cost is even higher.

Introducing @vinesheg/dev-forge

What if you could get enterprise-grade developer tooling with a single command?

npm install --save-dev @vinesheg/dev-forge
npx forge init

That's it. 30 seconds and you're done.

dev-forge is a zero-configuration developer toolkit that bundles and pre-configures six essential development tools into one package:

Biome - Lightning-fast linting and formatting (10-100x faster than ESLint)
Knip - Find unused files, dependencies, and exports
Lefthook - High-performance Git hooks (faster than Husky)
Commitlint - Enforce conventional commit messages
Stylelint - Professional CSS/SCSS linting
npm-package-json-lint - Validate your package.json structure

Why This Matters

1. Zero Configuration

No configuration files to create. No options to remember. No decisions to make. It just works.

The package includes battle-tested defaults that follow industry best practices. You can override anything if needed, but 95% of projects won't need to.

2. Single Dependency

Instead of installing and managing 10+ packages:

Before:

{
  "devDependencies": {
    "eslint": "^8.0.0",
    "prettier": "^3.0.0",
    "husky": "^8.0.0",
    "lint-staged": "^13.0.0",
    "@typescript-eslint/parser": "^6.0.0",
    "@typescript-eslint/eslint-plugin": "^6.0.0",
    "eslint-config-prettier": "^9.0.0",
    "stylelint": "^15.0.0",
    "stylelint-config-standard": "^34.0.0",
    "@commitlint/cli": "^17.0.0",
    "@commitlint/config-conventional": "^17.0.0"
  }
}

After:

{
  "devDependencies": {
    "@vinesheg/dev-forge": "^1.0.0"
  }
}

3. Built on Speed

dev-forge uses the fastest tools available:

Biome (written in Rust) is 10-100x faster than ESLint
Lefthook (written in Go) outperforms Husky significantly
Parallel execution by default for even faster checks

On a medium-sized project:

ESLint + Prettier: ~8 seconds
Biome: ~0.5 seconds

That's a 16x speedup on every commit, every save, every check.

4. Automatic Git Hooks

Git hooks are installed automatically and run on every commit:

Pre-commit hook:

✅ Lints and formats staged files
✅ Checks CSS/SCSS
✅ Validates package.json if changed
✅ Auto-fixes issues when possible

Commit-msg hook:

✅ Enforces Conventional Commits
✅ Ensures clean commit history
✅ Enables automatic changelog generation

No bad code reaches your repository. Ever.

5. Team Consistency

Every developer on your team gets the same setup:

# New team member joins
git clone your-repo
npm install  # Automatically runs 'forge init'
# ✅ Fully configured, ready to code

No more "works on my machine" issues. No more style debates. No more inconsistent code.

Real-World Impact

Before dev-forge:

Monday 9:00 AM: Start new microservice
Monday 9:05 AM: npm init
Monday 9:10 AM: Install ESLint, Prettier, Husky...
Monday 9:30 AM: Configure ESLint
Monday 10:00 AM: Configure Prettier
Monday 10:30 AM: Set up Husky + lint-staged
Monday 11:00 AM: Configure commitlint
Monday 11:30 AM: Fight with ESLint/Prettier conflicts
Monday 12:00 PM: Finally start coding

After dev-forge:

Monday 9:00 AM: Start new microservice
Monday 9:05 AM: npm install --save-dev @vinesheg/dev-forge
Monday 9:06 AM: npx forge init
Monday 9:07 AM: Start coding

Time saved: 2 hours 53 minutes

How It Works

dev-forge uses a smart "extends" pattern for maximum flexibility:

Installation creates minimal local configs that extend the toolkit's defaults
All tools run from the toolkit's own dependencies
Zero maintenance - update one package, update everything
Customization - override any setting by editing the generated configs

Example generated biome.json:

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "extends": ["./node_modules/@vinesheg/dev-forge/configs/biome.json"]
}

Want to disable a rule? Just add it:

{
  "extends": ["./node_modules/@vinesheg/dev-forge/configs/biome.json"],
  "linter": {
    "rules": {
      "suspicious": {
        "noExplicitAny": "off"
      }
    }
  }
}

Usage

Initialize in a New Project

npm install --save-dev @vinesheg/dev-forge
npx forge init

Add to package.json Scripts

{
  "scripts": {
    "lint": "forge check",
    "lint:fix": "forge fix"
  }
}

Run Checks

npm run lint      # Check all files
npm run lint:fix  # Auto-fix issues

Git Hooks Run Automatically

git add .
git commit -m "feat: add user authentication"
# ✅ Pre-commit hook checks your code
# ✅ Commit message validated
# ✅ Commit succeeds if all pass

CI/CD Integration

Add to GitHub Actions:

- name: Quality Checks
  run: npx forge check

That's it. All your quality checks in one command.

Who Should Use This?

Individual Developers

✅ Side projects
✅ Portfolio work
✅ Learning projects
✅ Open source contributions

Benefit: Spend time coding, not configuring

Startups

✅ Move fast without sacrificing quality
✅ Consistent standards from day one
✅ Easy onboarding for new hires

Benefit: Scale from 2 to 20 developers seamlessly

Established Teams

✅ Standardize across all projects
✅ Reduce maintenance burden
✅ Modernize legacy tooling

Benefit: Reduce tool setup time by 80%+

Open Source Projects

✅ Lower barrier for contributors
✅ Enforce quality automatically
✅ Modern, fast tooling

Benefit: More contributions, higher quality

Technical Details

Built With

Biome - Rust-based linter/formatter
Lefthook - Go-based Git hooks
Modern, maintained packages only

Requirements

Node.js ≥ 18.0.0
Git (for hooks)

File Size

Package: ~2 MB
With dependencies: ~50 MB
Negligible impact on project size

Performance

Initialization: < 1 second
Check command: 2-5 seconds (medium project)
Git hooks: < 1 second

Comparison with Alternatives

Feature	Manual Setup	ESLint+Prettier+Husky	dev-forge
Setup time	2-4 hours	1-2 hours	30 seconds
Packages to install	10+	6-8	1
Config files	5-7	4-5	5 (auto-generated)
Linting speed	Fast	Slow	Very fast
Maintenance	High	Medium	Low
Best practices	Maybe	Depends	Built-in
Git hooks	Manual	Manual	Automatic
Dead code detection	No	No	Yes
Package.json validation	No	No	Yes

Getting Started Today

Install:

   npm install --save-dev @vinesheg/dev-forge

Initialize:

   npx forge init

Start coding:
- Git hooks are installed
- All tools configured
- Quality checks automatic

The Philosophy

dev-forge follows three core principles:

Convention over Configuration - Sensible defaults that just work
Speed Matters - Use the fastest tools available
Developer Experience First - Make the right thing the easy thing

We believe developers should spend time solving problems, not configuring tools.

What's Next?

We're working on:

🔌 Plugin System - Add custom tools easily
📚 More Tools - Additional quality checks and automation

Try It Now

Don't let tooling setup slow you down. Try dev-forge in your next project:

npm install --save-dev @vinesheg/dev-forge
npx forge init

It takes 30 seconds. Your future self will thank you.

Published under MIT License. Free to use, modify, and share.