I've been building web applications for over a decade now. I've seen frameworks rise and fall, watched bundle sizes explode from kilobytes to megabytes, and debugged performance issues caused by dependency trees so tangled they'd make a sailor weep. So when I recently stumbled upon a Viking name generator that loads in under 200ms without any framework dependencies, I had a realization that kept me up that night: we've overcomplicated the web.
This isn't a hit piece against React, Vue, or whatever shiny framework you're using this week. Those tools solve real problems at scale. But there's a category of web experiences—simple utilities, small tools, quick interactives—where we've collectively lost our minds. We ship 500KB of JavaScript to render a button. We import twelve libraries to format a date. We build SPAs for content that could've been a single HTML file.
The Viking Name Generator on SnapKit (which you can explore as a live demo here: Viking Name Generator) represents something we've largely forgotten how to build: a focused tool that does one thing well, loads instantly, and respects the user's time and bandwidth.
The Bloat Crisis We Don't Talk About
Let me quantify the problem because as developers, we love data.
Average mobile web page size has grown from roughly 1MB in 2015 to over 3MB in 2024. That's a 200% increase in resource weight, driven almost entirely by JavaScript bundles. The median webpage now executes more than 1,000 lines of JavaScript on initial load. We ship more code to render a landing page than the entire Apollo 11 guidance computer had available for the moon landing.
The justification, of course, is interactivity and user experience. Modern web apps need to feel native, respond instantly, handle complex state. But there's a massive gap between "we need interactivity" and "we need 47 npm packages to render a form."
The real cost isn't download size. It's latency, it's parse time, it's the main thread blocking that makes your phone发热 during routine browsing. It's the user on a spotty connection who waits 8 seconds for your "lightweight" tool to become usable. It's the developing market user on mid-range hardware who can't engage with your beautifully-animated experience because their browser runs out of memory.
I've built my share of bloated applications. I'm not immune. But every time I see a simple utility—something that could exist as a single HTML file with inline scripts—packaged as a PWA with service workers and a build pipeline that takes 3 minutes to run, I wonder if we've lost the plot.
What "No Dependencies" Actually Looks Like
Here's what I mean when I say "no dependencies," and why it matters.
When a tool like the Viking Name Generator claims no dependencies, it's making a specific technical statement. There's no React or Vue hydrating the DOM. No Angular bootstrapping an application context. No Webpack or Vite processing the build. No external fonts being fetched from CDNs. No analytics scripts tracking user behavior. No ad networks injecting their code. No third-party widgets adding latency to your latency.
Just HTML, CSS, and JavaScript executing in the browser's native rendering pipeline.
The rendering cycle looks something like this in its most basic form:
Input Event → DOM Update → Style Calculation → Layout → Paint → Composite
Six steps. No virtual DOM diffing. No component re-rendering. No reconciliation algorithm running on every keystroke. When you type your name into the generator, the browser receives the input event, updates the relevant DOM node, recalculates styles for affected elements, performs layout for any size changes, paints the updated pixels, and composites the final frame. That's it.
Contrast this with a typical framework-based implementation:
Input Event → State Update → Component Re-render → Virtual DOM Diff →
Patch Operations → DOM Update → Style Calculation → Layout →
Paint → Composite → (plus any useEffect cleanup, dependency
resolution, context propagation, etc.)
Both paths end up at the same place—the user sees their name on screen. But the second path involves seventeen intermediate steps, multiple passes through JavaScript execution, and several opportunities for frame drops on lower-end devices.
The first path? It takes milliseconds. The second path? It takes milliseconds too, on a good machine, with a cached bundle, on a fast connection. But those milliseconds add up, and they compound in ways that matter.
The Accessibility Argument Nobody Makes
There's a conversation about web accessibility that focuses almost entirely on screen readers and keyboard navigation. Those are important. But there's another accessibility dimension we rarely discuss: device accessibility.
Not everyone has a flagship phone with 12GB of RAM and a desktop-class GPU. Not everyone has unlimited data plans or fiber connections. Not everyone lives in a city with robust network infrastructure. The web we build needs to work for all of those users, not just the ones on bleeding-edge hardware in developed markets.
A tool that loads instantly on 3G, works without JavaScript enabled (progressive enhancement), and doesn't drain the battery is more accessible than a feature-rich SPA that requires modern browser capabilities and sufficient system resources. Period.
The Viking Name Generator is accessible in this broader sense. You can open it on a five-year-old laptop. You can load it on a train with spotty cell coverage. You can use it on a work computer where IT has blocked everything but the basics. It meets users where they are rather than demanding they upgrade to participate.
This isn't nostalgia. It's not "things were better in my day." It's a recognition that the web's original promise—universal access to information—has been compromised by our collective obsession with developer convenience over user experience.
When Complexity Is Justified (And When It's Not)
I want to be clear: I'm not anti-framework. I've built production applications with React that served millions of users. I've shipped features that required the abstraction and state management that frameworks provide. There are genuine problems—complex interactive systems, real-time collaboration, data visualization at scale—that benefit enormously from modern tooling.
But here's the distinction I try to maintain: complexity should be proportional to the problem.
A content-focused website doesn't need client-side routing. A simple utility doesn't need a component library. A single-page tool doesn't need a state management solution that took three sprints to implement. We reach for complex tools by default, then wonder why our applications feel heavy.
The most performant web experiences I've built in recent years have been the ones where I started with "what's the minimum I need to solve this problem?" rather than "what's the standard stack I always use?" That question changes everything. It forces you to evaluate every dependency, every abstraction, every "nice to have" feature against actual user value.
The Viking Name Generator doesn't need a framework. It doesn't need a build pipeline. It doesn't need CI/CD deployments with blue-green environments and feature flags. It needs to take input, process it, and display output. That's it. And it achieves that goal with fewer moving parts than any modern web application I've worked on.
A Call for Intentional Simplicity
I'm not suggesting we abandon everything we've learned about web development. I'm suggesting we be more intentional about what we choose to use and why.
Before you npm install that UI library, ask yourself: what problem does this solve that CSS can't? Before you wrap your entire application in a context provider, ask yourself: is this state actually global, or am I just avoiding proper component composition? Before you spin up a new micro-frontend, ask yourself: would a single HTML file with inline styles work?
These questions feel heretical in an ecosystem that celebrates complexity as sophistication. But I've learned that the best developers I know—the ones whose code I actually want to read and maintain—are the ones who fight complexity at every turn. They add layers reluctantly. They refactor toward simplicity. They build systems that future developers (and future versions of themselves) will actually understand.
The web doesn't need more frameworks. It needs more tools that work. It needs more experiences that respect users. It needs more developers willing to say "this is simple, and that's the point."
If you want to see what I mean, or if you're looking for a clean reference implementation of a no-dependency web tool, check out this live demo: Viking Name Generator
It's not trying to be a showcase of modern web capabilities. It's just trying to work. And in 2024, that feels almost radical.
What simple web tools have you built or encountered that strip away the complexity? Am I just being a grumpy old developer who's forgotten what modern development looks like? Let's discuss in the comments.
Top comments (0)