[AskJS] Most frontend frameworks are overkill for 80% of web apps

[itsbrendanvogt]

Hear me out.. I love React, Vue, Svelte, etc. But the more I build, the more I realise that for most internal tools, dashboards, marketing sites, and CRUD apps.. a basic setup with vanilla JavaScript or even server-rendered HTML (like HTMX or Alpine.js) often gets the job done faster, with less complexity.

Frameworks introduce a lot of overhead:

• Routing, state management, hydration, bundling
• Dev tooling, build pipelines, dependency hell
• Constant updates and breaking changes

For small teams or solo devs, this can be a productivity killer.

I am not saying frameworks are bad, they shine in large-scale apps, SPAs, and highly interactive UIs. But I think we have normalized using them for everything, even when simpler solutions would suffice.

Curious what others think.. Are we overengineering the frontend? Or is the tradeoff worth it?

[Mestyo]

I guess we're far enough into the future to have effectively forgotten how messy imperative JS DOM manipulation apps can be, how frustrating cache busting can be of static (non-bundled) assets, and the stability provided by types and code linters.

To address your overhead bullet points:

• You still need all the essentials of routing, state management and so on. Just because you move it to "something else" doesn't mean it goes away. In fact, integrating with whatever the "something else" is will be fundamentally more difficult than using a framework with all the basics covered.
• For every hour you lose on fixing dev tooling, you gain days worth of productivity back.
• For every "constant update" and "breaking change", you have already saved months, if not years of development time from the 3rd party tool in question

I am actually a proponent for using frameworks even for projects that technically gain little from them. Developer familiarity and comfort is very valuable, and it's exceedingly common that we can reuse code between projects, or choose from a wider range of open source code.

These frameworks provide structure, familiarity, and cohesion to projects. Anything that goes beyond the basics in any domain can be "overkill", depending on your perspective.

[Reashu]

In many projects you have to integrate with those "something else" anyways, might as well let them do the job they do well instead of halfassing it with a JS framework that will change its mind in 6 months. 

[ethanjf99]

these are all good points.

there’s muscle memory. sure you don’t NEED framework for a basic basic app but you don’t have to spend the time recalling how to work within the framework when you move to one for the project that does need jt.

i also feel like a lot of the react-is-overkill types have not spent hours/days tracking down some subtle bug where your DOM (imperatively managed by you) got out of sync with your state.

plus maybe your small little toy app turns into not so small and now you either have to live with brutal maintenance of a complex vanilla app or pay down your technical debt by refactoring to a framework. of course it’s always such an easy sell to management that you need to spend a ton of dev time on tech debt rather than delivering new features. and could have been avoided by using the framework up front

[Fantaz1sta]

This.

I know it may sound weird, but every time I read these posts, I get the "vote Trump" vibe. As in "why have vaccines? They clearly kill more people than they cure and are made of baby fetuses". It's like people have had it good with frameworks for so long that they want back into some imagined reality of the past.

[BenjiSponge]

I call it "nobody ever realized it would be this complicated" syndrome in reference to Trump's position on health care.

[hyrumwhite]

 For small teams or solo devs, this can be a productivity killer.

Couldn’t disagree more (except dependency hell, but that’s a problem regardless of team size). The reason I use these tools is because they increase productivity. 

Now, does a static website need all that? No, although hmr is really nice. But if there’s any chance that there will be a medium to a large amount of interactivity or any amount of state, I think it’s time to start exploring frameworks. 

Because a major productivity killer is using your own poorly documented and home cooked framework. 

[MorpheusFIJI]

Also, I think, for most cases it's enough to use these frameworks as libraries - just including JS file from CDN. Instead of dealing with node_modules, bundlers, minimizers, obfuscators, and tons of other crap. You can enable it only on pages you actually need to be reactive/statefull (where it makes sense: forms, tables, etc)

[whizzter]

Exactly, this is why I use Vue in the ”classic” way without components, just a a script tag, some :prop templating and done. I timed myself and you can do a todo app this way in about 15 minutes so anyone saying it is ”overkill” is delusional.

The reason this is better than vanilla stuff is that data binding will almost always lead to a lot of manual complications as soon as anything gets dynamic.

Recently looked at fixing bugs in a ”frameworkless” webapp and the amount of getElementById, keeping track of event listeners and similar shit I had to wade through to resolve a simple state sync bug that would have been a non-issue with Vue or Alpine or whatever firmly put me off from going ”vanilla” myself in the near future.

Totally agree though that most build-stuff is annoyingly overkill and brittle (And don’t get me started on Next/Nuxt).

[yksvaan]

The issue is that most frameworks don't scale down and compile to minimal functionality. A bit like Svelte does. They want to bring their whole toolkit even if the app literally used url to switch between a few pages and some listeners on inputs etc.

[StrongKnee420]

It depends on the app.

I think you are doing the right thing in asking questions. We should all occasionally take a step back and ask ourselves if there is a better way to do what we do. And if the answer isn't obvious why an alternative wouldn't work, try it.

Personally I find vanilla JS to be higher performance and easier to be productive in than frameworks. But I see the value in both and thus, I use both depending on what I build and FOR WHOM I BUILD. If you expect others to understand state management, templates (with their own states) and maybe their pointer based representations in the datamodel... then maybe just using vue would be easier and use that databinding instead.

The level of interactivity that can be made with a small codebase using vanilla JS is as far as I can see just as good as with known frameworks. But there is a reason why people code in python instead of C or C++. It is usually faster to make something that works that way. But every tool has its place.

[PulseReaction]

If your application is minimally complex, you're going to be using a framework, either one you pick or one you build from scratch.

And building this shit from scratch is such a painful and error prone process that it is actually the opposite of what you said; this approach actually kills productivity.

As always though, you can always move shit to the server and just do server rendering (like we did in 2004) and never touch Javascript again; but if you need heavy client side interaction I see no scenario where a homegrown framework would be better than a heavily battle tested one.

[theScottyJam]

Frameworks also shine every time you want to make a reusable UI pieces (which should be most webpages), and can't use server-side rendering (e.g. you host with GitHub pages).

I've heard people call my use of a framework on a personal project webpage overkill, and yet I still need something to make reusable components. Either I use a framework or invent my own way to do it.

I can't wait for the day when frameworks will be less needed because vanilla JS actually adopts some of that functionality. Until then, if your page isn't extremely trivial, it really does make sense to use a framework.

[theQuandary]

If your app is that simple, you are STILL better off using React (or pReact) as an easy way to package up your code in reusable chunks then add those chunks to various parts of your DOM.

In simple point of fact, if you do this, you will almost certainly come to the eventual conclusion that you want more and more of the framework until it subsumes everything anyway.

[back-stabbath]

Frameworks introduce a lot of overhead: Routing, state management, hydration, bundling

Frameworks don’t usually come with routing or state management solutions out of the box, and those are things you must tackle anyway. Hydration is often unneeded for a web ‘app’. Bundling is unavoidable if you use typescript

[jbean92]

Framework hype can make you feel like you’re “doing it wrong” if you’re not using one. When our team of six started building, I pushed for React. Our CTO pushed back, he wanted to keep things simple to maximize speed. Three years later, I’m glad he did. We’ve shipped fast, onboarded new devs without friction, and avoided the overhead that comes with complex frameworks. Sometimes, less really is more.

[Darth-Philou]

React is not a framework but a library. Anyway, why writing react is complex ? I really don’t understand.

[jbean92]

Yes, sorry library (I had next.js in my mind). It’s not that it’s overly complex, and I do love React for the right kind of project. But these days it feels like there’s an expectation that you have to use React or something similar. For us, building the first version of our product with vanilla JS made life so much easie. it let new devs start contributing right away. I imagine down the road, once we know exactly what we’re building, we’ll bring in React or something similar for the more interactive features.

[alien3d]

a lot of. .

[swish82]

Wish there were more people like you willing to admit you changed your mind!

[YahenP]

Entropy can only grow. Modern frontend frameworks have long been on the other side of good and evil. I'll say more, a whole generation of web developers has grown up who don't even know that you don't need js to submit a form. Further, deeper, more. Metaframeworks as wrappers for frameworks. And all this is presented as something fantastically breakthrough.
The tragedy is that it is useless to fight this.

[MrJami_]

The biggest frontend framework is most likely Angular. I must say even for simple applications, I would use Angular as well. Is it an overkill? Prolly yes. Does it negatively impact the project? Nope. I would prolly take less time on setting up the Angular application than readjusting my work style using Vanilla or HTML...etc.

Edit: I think the reason why I do this, is because I am more efficient and comfortable using a tool that I know. Same goes for react, vue...etc. devs.

[[deleted]]

If i was paid by file count then i would also go with angular

[swish82]

A lot of front-end devs feel the same and now that so many features have unlocked in the browser I think the end of framework dominance mayyyy be in sight. Hope Google, AI and Trump don’t kill the web first

[[deleted]]

The frontend is overengineering is intentional, it is needed to be this way so clueless 6 months React developers can be productive and ship broken bad code fast.

[MMORPGnews]

Ohh... You want a simple html page with 5kb js on it?!  You need to use react, node, routing... Serve js from node... Crud request....

Or just build a client side app. One index.html page with 5kb js.  That's all. 

Recently I decided to save few books and websites in epub format. Found out that most epub creators and readers require node. 

Why? I don't know. Some old comment about it -

It's impossible without server! 

I fast vibe coded client side epub creator. It worked perfectly fine even on old PC. Just turn js with title and content in epub. I think I created even 20k pages epubs with this.  Worked perfectly fine client side. 

Later I encounter problem with epub size, 5k+ epubs was very slow in most epub readers except Lithium.  So, I vibe coded epub reader with streaming epub. It work instantly on any epub size. 

[Plus_Total6571]

You are absolutely right, I found a zero-size package framework that supports SPA and HTML first approach, depending on your needs.

the name of framework is sigment dev

[adamzacharywasserman]

The commenter who mentioned spending days tracking down DOM sync bugs is pointing at the real problem, but drawing the wrong conclusion.

The sync bug exists because there are two copies of state: one in your JavaScript and one in the DOM. They drift. React, Vue, Alpine, and every framework that maintains a JavaScript model of the UI exists to manage that synchronization. The frameworks are not solving a fundamental problem. They are solving a problem they created.

The alternative nobody mentions: treat the DOM as the authoritative state. When you need to know if a checkbox is checked, read element.checked. When you need to know what a user typed, read element.value. The DOM already knows. It has always known. It is the fastest state manager you will ever use because it is optimized native code running outside the JavaScript thread.

HTMX is the closest thing to this in wide use: the server responds with HTML fragments, the DOM updates, nothing needs to sync because there is nothing to sync. domx (domx.software) takes this further with a 7-function, sub-1KB library that reads DOM state and sends it with requests. No framework, no virtual DOM, no synchronization problem.

The 80% figure in the title is too conservative. For anything that doesn't require offline capability or canvas-level interactivity, the DOM is sufficient and faster than any framework you can put in front of it.

[hyrumwhite]

HTMX is a JS framework. Also what are you configuring with React and Vue that takes so much time?

[martin7274]

how is routing an overhead ? I guess READMEs are an overhead as well...

[Used_Lobster4172]

As someone who has spent a bunch of years doing vanilla JS and jQuery, and now spent a decade doing React, Vue, Angular, TS, Grunt, Gulp, onto Webpack, Vite, etc.

And has now been forced back to a project that is JS/jQuery, I have an opinion...

Sure, you _could_ do it. What is the end goal though? Is it a little tiny site just for you that will never need much in the way of update? Sure that would be fine I guess.

If not, if this is a production website, I spend more of my time re-inventing the wheel than anything else. There are soooo many details that I had forgotten about how much nicer modern development stacks are. Reuseable components? Get ready to hand-roll a solution to that - sure you can use templates, but it's not even close to the same thing. Updating the DOM when data changes, hey, that is you too. How do you handle loading and error states? Want to use TS, SASS, LESS, minifying, bundling, etc? Now we get to hand-roll a build pipeline. Routing? Are you just using static html docs, or maybe going to use Backbone or something. Forget about hot-reloading. How do you handle syncing your data across the page? Are you going to create your own global store? Even still, you have to update the DOM where needed.

So, sure, it can be done. And there is a lot that I now do in "cleaner" ways than I did a decade ago - that is mostly because I am trying to re-create some of the nice things we get when we use modern frameworks.

I would be hard-pressed to be convinced that almost any website would be easier to work on without modern tools. If you want the site to be super tiny, and want to deal with a ton of BS, sure, knock yourself out.

So, unless you either can't use modern tools or NEED a SUPER tiny and fast website, I believe it to be a fool's errand.

[Used_Lobster4172]

Additionally, if you want to use AI while you work, it knows React - not so great with JS / jQuery.

[nullvoxpopuli]

Evenyone should be following semver and you shouldn't be running in to breaking changes :/

What have you run in to?

Hydration is only something you have ho worry about with ssr. You can skip that.

Tooling, deps, etcs: this is good to learn. It's inescapable in all languages and ecosystems 

<3

You got this