The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.
The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).
* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)
Is it? Because in my experience, this is flat out wrong and it's very easy to verify, and it is a tested hypothesis.
> The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method
You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper. Why would that ever be true? React doesn't do DOM manipulation for funsies, if you foregoe a framework you'll be implementing reactivity, interactivity and performant code yourself. The browser is very barebones in that regard. The framework cost is always lower than rolling your own, and this isn't even the argument people are having. Non-Framework evangelists are arguing performance, never cost.
A framework doesn't come into existence out of thin air. If you choose one, you're working with a community of thousands of developers. I don't have to build my own reactive table, I can use TanStack table. I don't have to build my own playground, I can use stackblitz or storybook to showcase stuff to a client. I don't have to build my own cancellable asynchronous list, I can use a trusted library for that, too. My client doesn't care if I roll my own. They care about effect per hour spent.
First, not using a framework doesn’t mean you have to roll your own (otherwise you’re still using a framework?). Second, this is the claim the parent wants you to substantiate, that not using a framework is always more expensive than using one.
No, I'm not. Nowhere in my comment have I made that claim, nor is there any claim that could even be mistaken for trying to argue one way or the other. It's like you lack the ability see words on a page and understand what's actually being discussed in the remarks you're responding to. (This also explains why, when challenged on succumbing to the industry tendency to make all-vibes arguments instead of evidence—directly in the comments of the article that calls this out—your direct response to that is to restate your claims and arguments and avoid providing any evidence. It's always just hunches and attempts at inductive reasoning, all the time.)
This is something that people who cannot live without frameworks often repeat, but its a fiction of their own creation.
If you plan to sell a digital product or SaaS on the internet and your use case is more complex than a blog or a portfolio site, your „vanilla js purity“ will outgrow the project, fast, and it will become a mess. I‘ve never not seen it end this way.
I do tire of the failure to perform and the endless empty excuses.
If that's true, that's just pointlessly wasteful of your time and effort.
Like most things in life, the best answer for each situation is layered in nuance. There's a reason that it's such a meme for senior engineers to answer most questions with, "it depends."
> This issue is more prevalent in the rust and js ecosystem where instead of writing a few dozens line, the dev brings a whole library for that (almost everyone that uses chalk)
Here's some news: If you build your pretty native binary for your target operating system or the browser, you're using tens of millions of line of code.
For reference, my last job at an industry giant had a frontend-facing monorepo of a million lines or two.
It's not your fault, since most companies don't want to invest resources on properly maintaining their code.
It's not your fault, since assuming the best about people on the internet is not actively rewarded by social media these days.
"I don't use frameworks, y'all can't program" - I mean, good for you, but I want to pay my bills and my clients sure aren't paying me to reinvent the wheel for the 20th time?
We have different wheels for different use cases. You can't use the same wheel for all of them.
You wrote yourself that you roll your own and you insulted every developer who doesn't. The best tool for the job is the one that doesn't unecessarily strain your customers wallet for no extra gain.
It helps when you write software other people want to use and provide good enough documentation.
Your comment completely reaffirms my original comment way at the top in that these frameworks largely exists so that employers can avoid any kind of investment in their developers.
Then it is not complex enough to support the needs of large projects.
You admitted it yourself. You work with a small group of people in small projects, but you got huge opinions.
Building a bespoke framework, for nothing of value except because you want to, isn‘t investing in developers, it‘s creating a huge cost factor for no gain.
I find it very hard to believe you and blaming developers for using trusted library code to not re-solve problems, thereby earning a living, is a pretty harsh statement.
How are you convincing your clients that they should pay a senior to re-engineer solves problems?
So, you just made a bespoke framework with the most inefficient version control system possible.
I'm not understanding why you have the idea that it's a huge drag on productivity and hand rolling the same patterns everyone ends up needing will somehow be more efficient.
Part of the foolishness here is that you are convinced your approach is faster but you have no idea what my approach is. You certainly aren’t measuring anything so even if you were aware of my approach you are still just randomly guessing at the result.
I've seen the situation where underqualified, overambitious programmers build an internal platform that becomes a monster. There isn't the time to mature it, there isn't a standard or docs to point to, it becomes a drain on the company, at worst someone's vanity project.
I've also seen the situation where a team absolutely refuses to build anything themselves out of anxiety, spending enormous amounts of money on an external solution that acts as a rent extractor.
The problem with buy-not-build, is if you do it for too long, you forget how to do the latter. This is great right up until you find a problem you can't buy your way out of.
Sometimes building something half good, is fast enough and educational enough to get you to the next step.
There’s still value in building something from the ground up; you understand the framework that much better. But so long as your needs largely overlap with the community, the benefits of working with the community are real.
My coworkers are very smart -- smarter than me -- so I'm low confidence anyone else could have done significantly better or avoided the pitfalls we fell into.
It really isn't.
> If you can build your own hammer in less time than it takes to drive to the store and back
You can't and your analogy doesn't hold. I've been writing JS frameworks work a decade, as have millions of other developers. They don't "drive to the store", they install their tool of choice in one second. You either build and maintain yours for hours or you copy paste code (which equates to the same).
> people irrationally fear not using frameworks for things not measured.
It is very easy to measure the hours spent.
How would you know? You are choosing conventions over measures. If you measure nothing you have no idea what is faster or not. I have been doing this work for nearly 20 years and many JavaScript developers claim measuring things is easy, but they never do it. When pressed on it they never have and don't know how. Instead they guess at performance to reinforce their own preferences. I have an autistic kiddo that does this and everybody sees right through it.
Because I worked in the industry when we all used jquery and I see the difference in real billable hours to nowadays. The entire industry has measured and shifted. Do you think million- and billion dollar companys shifted towards public shared framework for funsies and parties?
No. I don't have to hire an engineer and teach him our company bespoke framework. I can hire a react developer and he's productive from week one.
That's the best case. Usually it was just thousands of lines of jquery spaghetti.
1. I tried to write vanilla JavaScript once and failed miserably so therefore humanity is completely incapable of accomplishing such
2. I cannot organize instructions to save my life so therefore the result for all developers must always be spaghetti
The unspoken third option is that the people making these claims can’t write software and need to blame something else, however irrationally, because they lack the maturity to find a way forward.
I'm just reflecting what I've seen in the field. Webapps evolve over time and sometimes that has meant just ladling on more kludgy javascript event handling. If there is a homegrown state manager, that's usually better than the alternative. (although the frameworks are mostly just fine)
I suspect your point is that Angular or React must exist as the primary work product for a team to operate, but why? Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do? To me this sounds like you have absolutely no idea how to program or that you have no faith that anybody can program original solutions... except for the people who invent large frameworks.
Your own comments.
> Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do?
No. Not at all. I'm suggesting they're unwise if they do it voluntarily (as in: not constrained by compliance etc.).
> to me this sounds like you have absolutely no idea how to program
I'm not surprised. Surely you roll your own STD as well? Boy, I really hope you never import a function from any library. Otherwise you would be just like us, the stupid idiots who can't write original code. While we're at it, hopefully you don't build upon an operating system as well, since any reasonable dev would be rolling their own. In all seriousness: You and me both build solutions on millions of lines of other people's code. I'm really wondering why you're acting so high and mighty because you're using a couple hundred lines less.
> no faith that anybody can program original solutions
Original solutions can be created just fine with library code.
1. Ad hominem attacks on the original commenter
2. The arrogance and limited viewpoint that ignores the very fact that this can be observed by non-original writers of code, and that this scenario is so common that it coined an original term and spawned an entire industry of clean-uppers.
Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.
They clearly feel personally attacked by your statement. Almost as if there is some truth to it.
That is and has been a very good argument. One thing I do notice though is that, with the emergence of agentic automatic maintenance workflows, that same maintenance surface seems to start shrinking right now.