Item — HN Reader

As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.

The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.

I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?

2 comments

> but worse in every conceivable way

I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?

I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.

I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.

> I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways

If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.