Trying hard to find something to disagree with in your comment, but no luck :) Seriously, I think I did at least mention in the blog post that the vanilla approach is something I'd mainly advocate for small projects, with few members. The kind of situation where I am myself, at the moment.
The thing is, I see so many reach for the big guns and over-engineer their new, tiny app that they're developing themselves, with a friend or perhaps a small team. And I see overuse of components in general - the tendency to just pull in a new dependency via npm for something completely ridiculuous. This post was not about big, in-house enterprise systems development.
And in fact, thinking about my experience from that financial company mentioned earlier, I would greatly have preferred a standardized, external framework before the in-house developed macro/library mess that worked but was pretty much undocumented and whose inner workings were known to a very small number of people.
> The thing is, I see so many reach for the big guns and over-engineer their new, tiny app that they're developing themselves, with a friend or perhaps a small team. And I see overuse of components in general - the tendency to just pull in a new dependency via npm for something completely ridiculuous. This post was not about big, in-house enterprise systems development.
Because it is much more reassuring having a community back you up in case you get into the edge cases.
DIY? Good luck, you are on your own. Not to mention you have to scaffold all the things that are already taken of by the framework.
It's also a matter of maintainability. If you can successfully predict that the project will always be small, then fast, bespoke code might be great. But it's usually not the case. Prototypes almost always turn permanent.
> Because it is much more reassuring having a community back you up in case you get into the edge cases. DIY? Good luck, you are on your own. Not to mention you have to scaffold all the things that are already taken of by the framework.
And once you're reasonably familiar with a framework it would make sense to use it even for a prototype. Unless you're actually interested in trying out "VanillaJS" or an alternative framework you would just use the tools you already know and get on with the problem you're trying to solve :-)
One reason people reach for the "big guns" is also career progression. Hell, I started learning React recently precisely because of that: I prefer to touch the Web as little as possible, but everything is now eaten by SPAs, so one may as well just bite the bullet and get ready for the next job... The same reasoning currently motivates all but one of my backend co-workers, they're all learning React now. At my previous job (backend/desktop), people too started to learn Angular and React, just to jump on the (perceivably) safer, and much better paid, career path.
The thing is, I see so many reach for the big guns and over-engineer their new, tiny app that they're developing themselves, with a friend or perhaps a small team. And I see overuse of components in general - the tendency to just pull in a new dependency via npm for something completely ridiculuous. This post was not about big, in-house enterprise systems development.
And in fact, thinking about my experience from that financial company mentioned earlier, I would greatly have preferred a standardized, external framework before the in-house developed macro/library mess that worked but was pretty much undocumented and whose inner workings were known to a very small number of people.