Ask HN: How does one build large front end apps without a framework like React?
191–197 of 197 posts
Re: Ask HN: How does one build large front end apps without a framework like React?
#192It depends on the target product. I'm working with JS for already 25 years. Tried all of the frameworks, and continue on doing it. And every time I try something new, the refactoring flow turns most of them into NextJS (if it's very UI rich or customer facing or something very web-oriented), or Vite+React+Tailwind (client) and Hono (backend) if it's more of a tinker toy needing more custom solutions. The boilerplate…
The vendor lock-in on NextJS is certainly much more egregious than other frameworks. They have their own undocumented build flag to give different build outputs that Vercel uses vs the build outputs that are documented. Hosting nextjs on your infrastructure is not as simple as sticking it into a docker file as with most frameworks
And I would also push back on the idea that every framework has vendor lock in. Remix was so focused on "using the platform" that it basically willed itself out of existence. It's no longer even a framework. Just part of the react-router library. I've also used Astro which is a framework of similar complexity and feature richness as Nextjs and certainly has no "lock in". At least as far as
Re: Ask HN: How does one build large front end apps without a framework like React?
#193Here’s how I approached it for www.lendcalculator.com, a browser-based financial tool with dozens of calculators and dynamic UI — all built without React, Vue, or Angular. How to Build Large Apps Without a Framework Use native modules + ES6 classes Structure your app like a library: each feature (calculator, modal, form) is its own module. Import/export keeps things clean.
Leverage Web Components (if needed) They’re part of the platform now — encapsulation, lifecycle hooks, and reusability without vendor lock-in.
Use vanilla JS + CSS for UI With querySelector, addEventListener, and fetch, you can build surprisingly rich interfaces. CSS Grid and Flexbox handle layout beautifully.
State management via custom stores or events You don’t need Redux — just use CustomEvent, localStorage, or a simple pub/sub pattern. Routing with History API Use pushState and popstate to manage navigation. Works great for SPAs.
Build tools: Vite, ESBuild, or even just Rollup You can still bundle, minify, and hot-reload without a framework.
Projects to Study Obsidian (as you mentioned)
CodeMirror — complex editor, no framework
LendCalculator — my own project, built with vanilla JS and modular architecture
Re: Ask HN: How does one build large front end apps without a framework like React?
#194And less secure, from having fewer eyes look at it.
> Because there is no "abstraction layer" of a framework,
In a large project, I think you’ll end up developing a framework for use in-house, even if you don’t call it that.
> you also have greater control over your project, and can make performance optimizations at a lower level.
That’s true; you can tweak the framework to match your use case. For an analogy, look at Apple. They have much greater control over their hardware stack than the typical PC manufacturer. Because of it, they can change it to suit their needs.
Re: Ask HN: How does one build large front end apps without a framework like React?
#195Static sites can be done really well. I think gov.uk and GDS provide a solid example of how you can build really high quality sites with very minimal amounts of JS.[1]
If however you do need a reactive UX/UI, but don't want to use a FE framework, my advice would be to use the JavaScript event system and roll your own sub/pub system so components can emit custom events which other components can subscribe and react to.
It's not as powerful as React, but I've used this model to build relatively large apps with reactive UIs using just vanilla JS. With the right amount of abstraction event systems can be very powerful and scale extremely well. But they can quickly become an unmanageable mess if you don't abstract.
Depending on your requirements, you could also expand on the event system add centralised state which your components can use if you have more complex state requirements.
At the end of the day it's all about architecture. React gives you a lot out of the box and has some well established patterns around state management. But there's nothing stopping you from building your own solutions tailored to your own problems.
Personally I strongly agree with Obsidian on using JS frameworks. The only issue for me is that it's hard to find developers who care enough to learn your weird FE and use it correctly. In recent years this has always been the problem I've personally had with rolling my own solution. I think the primary strength of React today is simply the fact it's so popular. A good React dev knows how to build a good React app and that's a huge advantage now products can have large teams of frontend developers.
Honestly, unless you're building something really special I'd just take a look at the popular JS frameworks and pick the one best suited for your product.
--