Another in a long line of posts eschewing JavaScript frameworks has hit the web and the community response has been predictably dichotomous.
Being a programmer, I of course have an opinion on this. But I try to retain a bit of nuance when looking at questions like this.
I think it’s only fair that we acknowledge that the Moot folks are being nuanced as well. I mean, they’re not advocating total vanilla JS where everything is bespoke, artisanal, hand-crafted code. They do use libraries. They’re just avoiding frameworks. But the argument can often take on a similar form. To the average developer someone eschewing frameworks appears very close to a Luddite.
The arguments against this position are fairly simple and obvious. Why take on extra work when someone else has done it for you? Why reinvent the wheel? Why waste the effort, experience, and wisdom that are baked into a framework? Every discipline has tools, it’s foolish to insist on working with your hands when a power tool gets the job done faster, and often better. Et cetera.
But again, the position isn’t to avoid all prepackaged code. It’s to avoid a particular type of abstraction that takes away responsibility from the developer for a whole class of design decisions. Choosing a framework makes an opinionated statement, whether intentionally or not, about what the structure of the solution should look like. The problem, as identified by Moot and their compatriots, is that it this delegates the details of that statement to a third party, relinquishing a large degree of design control that could have a dramatic impact on the evolution of your application.
Realistically speaking, eschewing all frameworks means you have a lot more to do to reach the same point as a team who starts off with a framework. The difference is that you’ll be able to tailor your code to your needs in nearly every aspect (with the qualifier “given enough time” often going unstated.) The framework users on the other hand will be taking on a lot of noise that can very easily obscure the core points of the solution they are building for the problem they are tackling. It can make it harder to look at the codebase and pick out what exactly is being accomplished by all the code, because most of the hand-written code is gluing different things together. The thing that is most prominent is not the solution, but rather the structures mandated by the frameworks.
These are all great points. The problem I see with it is that the trade-off isn’t usually truly between slow, steady, and fitted versus rapid, noisy, and constrained, as it’s represented to be. A huge factor in how these different strategies play out is time available, and team skill level. Frameworks may create noise, and impedance mismatches, and encourage you to fit your code into structures that weren’t meant to fit your specific problems (e.g. not every screen benefits from MVVM, as opposed to MVC, or Passive View). But having no frameworks means you need to have the experience and wisdom available on your team to know how to put together the patterns you need, and when to use what. Not to mention that building infrastructure to streamline these things is not exactly a trivial task either.
There’s a place in the world for folks who want to lovingly hand-craft every line of code that they can. But it’s likely always going to be a niche. These are often the folks who explore and push the boundaries, finding new economies and elegant simplicity, or even new patterns. But for the rest of the developers, frameworks are tools. If they help deliver features to customers, then they aren’t going anywhere, and there’s nothing wrong with that. Realistically, no one thinks that framework X is the alpha and omega of solutions to problem Y. This too will pass and be improved upon.
The best and most experienced engineers will, absent other constraint, likely choose to start somewhere in the middle.
