For years, modern frontend work has been framed as a choice between major frameworks: React, Vue, Angular, Svelte, and whatever rises next. That framing misses the deeper question. How much of the stack is solving the product problem, and how much is solving problems created by the stack itself?
In a new essay, Guseyn Ismayylov makes the case for building serious web applications with vanilla JavaScript, Web Components, HTML, and CSS. His argument is not that every framework is useless. It is sharper than that. The browser already provides a powerful runtime, and too many teams forget to ask whether another layer is actually earning its place.
The Case Against Automatic Framework Thinking
The strongest part of the essay is the practical context. This is not a toy-counter example. Ismayylov describes building InstruxMusic, a web app for music schools and instructors that handles scheduling, billing, video lessons, file sharing, landing pages, booking, dashboards, messaging, and organization management.
That matters because the usual defense of heavy frontend architecture is scale. Vanilla JavaScript, critics say, is fine for small pages, but serious apps need a framework. His answer is direct: the app is serious, and the browser-native approach still held up.
The broader critique is aimed at automatic complexity. Build pipelines, transpilers, framework lifecycles, state libraries, component conventions, and reactivity models can all be useful. They can also become default costs that teams accept before they understand the trade.
Control Is The Real Issue
Modern frameworks often promise productivity by removing direct interaction with the DOM. In many teams, direct DOM manipulation has become something between a warning sign and a moral failure. But the browser was designed around documents, events, forms, navigation, CSS, and JavaScript controlling the page.
That does not mean every app should be a pile of script tags. It means the native platform should be treated as the baseline, not the escape hatch. Web Components, import maps, modern CSS, standard forms, custom elements, and native browser behavior are no longer primitive in the way they were ten or fifteen years ago.
A framework should win because it reduces real complexity, not because the team forgot what the browser can already do.
The Browser-Native Bet
The phrase that sticks from the essay is simple: the browser is already the framework. That is not literally true in the same way React or Vue is a framework, but strategically it is useful. The browser gives you rendering, events, caching, navigation, accessibility primitives, forms, layout, media handling, storage, modules, and network APIs.
When a team reaches for a framework, it should know which missing capability it is buying. Is it routing? State management? UI consistency? Rendering performance? Developer hiring? Ecosystem support? Those can be valid reasons. But “everyone uses it” is not architecture.
For small teams and long-lived business software, the maintenance angle is especially important. A simpler stack can mean fewer breaking changes, fewer dependency chains, faster debugging, and less onboarding around framework-specific concepts. The tradeoff is that the team has to be disciplined about structure.
Structure Still Matters
The fair criticism of vanilla JavaScript is that it does not impose an application architecture. That freedom can turn into a mess quickly. But the answer is not always to import a large architecture by default. Sometimes the answer is to create local conventions that match the product.
That is where Ismayylov’s approach gets interesting. He built EHTML for templating and e-ui for design system components, both intended to work with native web technology instead of replacing it. In other words, he did build tools. The difference is that the tools are closer to the browser’s model.
That is the real lesson. Vanilla does not mean no structure. It means the structure is explicit, smaller, and closer to the platform.
The Loudernet Take
For business owners and technical leads, the takeaway is not “never use React.” That would be lazy. React, Vue, Svelte, and other frameworks can be excellent choices when the team, product, and ecosystem justify them.
The smarter takeaway is to make framework decisions like business decisions. What does this dependency buy? What does it cost? Who will maintain it in three years? Does it make the product simpler, or does it mainly make the development culture feel familiar?
Vanilla JavaScript is not a rejection of modern development. Done well, it is a bet that the web platform itself is mature enough to carry more of the load.
That bet will not fit every team. But it deserves more respect than it gets, especially for focused products where control, durability, performance, and low operational drag matter more than chasing the dominant hiring keyword.
Source: Guseyn Ismayylov, “Why Vanilla JS,” published July 13, 2026.