Yet Another Framework Syndrome (YAFS)
blog.tastejs.com
blog.tastejs.com
Code can be a very intimate affair. When taking on a new requirement that can be fulfilled by an existing framework, there's a lot more to consider than just "did someone already implement this"?
In the corporate world, we often remind younger developers that most of the cost of the code is in the maintenance, not in the development, of software. Having to tackle feature changes dependent on 3rd party software can be really expensive.
If I'm working on a hobby project, I don't have enough time to do a full evaluation of all options out there, nor do I have time to understand the intricacies of a given framework to meet my unique requirements.
So, often, it takes just as much time to come up with my own mini-framework and build it up as my requirements increase. If I reach a certain level of functionality, then I may have something that I can share with other developers. Everyone always touts the benefits of open source, and I may want to get in on that, too. Besides, there's more glory in starting a project than being the 51st person to contribute.
Disclaimer: I don't have my own framework, and has in the past been the Nth contributor to what was then a de facto standard framework.
JavaScript is the de facto language of the web, so everyone is using it whether it's the right tool for the job or not. The web is also rapidly evolving its capabilities, so web applications are constantly changing in nature.
YAFS is not really the problem, it's a symptom of a massively developed for, single language, massively used platform. I'm sure it's exacerbated a bit by javascript being such a poorly designed language, but this is more minor.
The solution isn't "research and mold what's already out there to your problem", because this is only addressing the symptom. There's an explosion of frameworks because there's an explosion of different use cases and application goals on the web.
Rather than having to choose between 20 different programming languages, you have to choose between 20 frameworks.
Be it IT vendors rediscovering "cloud" concepts that were published in the 70's or a JS developer releasing a new framework that he rewrote using more functional idioms because object orientation is so-yesterday.
Besides it getting boring for us old farts, it feels exactly how the author describes it: more noise than value.
Not only published, I did use cloud computing in the 70's - we called it time sharing. And our keyval, schemaless databases obviously couldn't be called noSQL before the advent of SQL!
Exactly what IBM offered in the late 70's.
Also, transportation hasn't changed in millenia because we're still just humans moving places, and information retrieval hasn't changed since the invention of the written word, because we're still just absorbing information from glyphs on something that has distinct colors.
That's something I see as the sign of a poor / inexperienced developer. Assuming they can do something better than an accepted well tested solution.
Also why I can't sop far get too excited about NoSQL, its the same as Berkley DB was years ago more or less, no?
And they receive pull requests for several MVC frameworks each week demonstrating how to build a to do list in a new framework.
I don't think that you're talking about the same thing here.
I hope people invent lots of new ways to do things, and I hope the go-to software of five years from now is not the go-to software of today. I hope we aren't using jQuery and Mongo in ten years.
So front-end devs , instead of writing libraries that depend on other solid(and maintained) projects, either include dependencies or rewrite stuffs they will not maintain. That's the nature of javascript.
As for the question is there too many frameworks, I disagree. devs will mostly use frameworks that are well documented and maintained. If the last commit in your project was 2 years ago, if you dont have an issue tracker set up or you dont fix bugs, if there is no test other devs aint gona use your library that's a fact.
But again , open source projects are basically free work,so let's not complain. Let's also not forget that Javascript is usually easy to read and to fix. We are not talking about fixing some C++ here...
As a dev it is also your responsability to vet libraries.
While doc-blocks and comments are crucial to all code, and especially crucial to framework code, a framework that relies solely on auto-generated documentation is one without complete documentation. There is more to documentation and the coherency of a framework and its use cases than describing its microscopic parts.
It's very easy to publish a library in the JS world. Just add some boilerplate and everyone can grab it through npm or bower. In the Java world getting it in a repo through maven is a bit harder. But that leads to fewer projects to maintain and focus on, in the JS world it's a bit too "forked" for my taste.
Deleted comment
1) How quickly can a developer who is competent in the language (ie. a non ninja-rock-star) but has never heard of the framework understand what's going on?
2) How hard is it to take the value that I create (ie. the code I write) and move it to a different solution?
Of course the result of these is that the best framework is no framework at all... In the case of PHP, at least.... in JS it may be the case that some minimal framework is required, but as much as possible I think that libraries, more than frameworks, are the key to this issue.
Not trying to claim that everyone that complains is bad/wrong. Rather, the field often acknowledges that learning a new language can help "learn a new way to think." Seems that sometimes we neglect that one needs to learn the way of thinking for the language/framework they have, and less worrying about the language/framework they wish they had.
And I fully acknowledge that this is an art. Knowing when to consider making a change is a tough piece of knowledge to try and hammer down.
It is always a red flag for me when someone starts arguing for less choice, more monolithic frameworks, and the inevitable lock in that comes along with having only one or two options.
Perhaps the problem is that we have a large opportunity before us and it isn't obvious which frameworks are going to win.