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'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.
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.