HTML Can Do That: Why Native Web Matters for Startups

A post making the rounds right now—"HTML Can Do That"—is striking a nerve with developers for a simple reason: the native web platform has quietly become far more powerful than most teams realize. Features that once required JavaScript libraries, third-party widgets, or entire framework layers can now be handled by plain HTML elements and attributes. For founders investing real capital in product development, this isn't just a developer curiosity. It's a strategic lever.

The Hidden Cost of Over-Engineering

Across the startup ecosystem, there's a persistent pattern we see at IDG when founders come to us mid-build or post-launch: products are dramatically over-engineered on the frontend. Teams reach for React component libraries, complex state management tools, and heavyweight CSS-in-JS solutions for features that the browser itself can handle natively. Date pickers, accordions, modals, form validation, lazy loading—HTML and CSS now cover a remarkable amount of this ground without a single line of JavaScript.

Why does this matter for a founder trying to get to market? Because every unnecessary dependency is a liability. It adds bundle size, which slows your app down. It adds maintenance surface area, which costs engineering hours. It adds security exposure, which creates risk. And it adds cognitive complexity for every new developer who touches the codebase. When you're burning runway, none of that is free.

The best code is the code you don't have to write, maintain, or debug. Modern HTML is giving product teams permission to delete thousands of lines of JavaScript—if they know where to look.

What the Platform Actually Gives You Now

The modern HTML specification includes elements and attributes that handle use cases startups routinely pay to solve with third-party code. The `<dialog>` element provides accessible, focus-trapping modals out of the box. The `<details>` and `<summary>` elements give you disclosure widgets—accordions, expandable sections, FAQ blocks—without a component library. Native form validation attributes like `required`, `pattern`, `min`, `max`, and `type` variants handle a significant portion of input validation before your JavaScript ever runs. The `loading="lazy"` attribute on images and iframes defers offscreen content without an Intersection Observer polyfill.

These aren't experimental features behind browser flags. They're shipping in every major browser today. And yet, we regularly audit codebases where teams have imported tens of thousands of lines of JavaScript to replicate behavior that's built into the platform. The conversation around "HTML Can Do That" is a wake-up call: the gap between what developers assume requires a library and what the browser handles natively has never been wider.

The Strategic Angle Founders Should Care About

For VC-backed companies operating with finite runway and aggressive timelines, frontend architecture decisions have downstream consequences that compound over months and years. Here's where leaning into native web capabilities creates real strategic advantage:

1. Performance Is a Product Feature

Lighter pages load faster. Faster pages convert better. This isn't opinion—it's one of the most consistently demonstrated relationships in web product development. Stripping unnecessary JavaScript in favor of native HTML doesn't just feel cleaner; it directly impacts the metrics that matter to your business: bounce rate, time-to-interactive, Core Web Vitals scores, and SEO ranking signals. If your product is web-delivered, performance is not a backend concern alone.

2. Accessibility by Default

Native HTML elements come with built-in accessibility semantics. A `<button>` is focusable, keyboard-operable, and announced correctly by screen readers. A `<div>` styled to look like a button is none of those things unless your team manually wires up ARIA roles, keyboard handlers, and focus management. Founders building products that need to serve enterprise clients, meet compliance requirements, or simply reach the widest possible audience benefit enormously from teams that default to semantic HTML first. It's cheaper to build it right than to retrofit accessibility later.

3. Reduced Dependency Risk

Every npm package your product depends on is a bet on someone else's maintenance schedule, security practices, and breaking-change philosophy. The native web platform, by contrast, is governed by backward-compatibility guarantees that have held for decades. Code written against the HTML specification today will work in browsers ten years from now. That kind of stability is valuable when you're building a product meant to last beyond your next funding round.

This Doesn't Mean Frameworks Are Dead

Let's be clear: this isn't an argument against React, Vue, Svelte, or any other framework. Complex, highly interactive applications—real-time dashboards, collaborative editing tools, AI-powered interfaces with streaming responses—still benefit enormously from the component model and reactivity that modern frameworks provide. The argument is about proportionality. If your landing page, your marketing site, your onboarding flow, or your settings panel is shipping 400KB of JavaScript to render what amounts to forms and content, something has gone wrong in the architecture decision-making process.

The best engineering teams—and this is something we prioritize across every engagement in our services—make deliberate choices about where complexity is warranted and where the platform itself is the right tool. That judgment is what separates a product that scales gracefully from one that buckles under its own technical debt.

Building Smarter From Day One

At IDG, we build products end to end for founders who can't afford to get the architecture wrong on the first pass. Whether it's an AI-native application, a data platform, or a consumer-facing app that needs to perform at scale, we make opinionated decisions about where to invest engineering complexity—and where to let the platform do the work. That philosophy shows up in the portfolio of products we've shipped for companies ranging from early-stage startups to brands you already know.

The "HTML Can Do That" conversation is a useful reminder of a principle we apply constantly: the goal is never to use the most sophisticated tool. It's to use the right tool. Sometimes that's a custom-trained ML model. Sometimes it's a distributed data pipeline. And sometimes, it's a `<details>` element and zero JavaScript.

If you're planning a build and want a team that makes those calls with your runway and your users in mind, let's talk.