Almost every day, we see new libraries, frameworks and tools being released in the JavaScript community — many of which simply reinvent the wheel.

This regular stream of solutions, which opt to create something new rather than improve an existing solution is what we at TodoMVC refer to as ‘Yet Another Framework Syndrome’ — or in more general terms NIH (Not Invented Here). Whilst innovation is something we should all welcome, YAFS can lead to confusion and frustration for users because there’s a big risk of it introducing more noise than value. Just one example is MVC.

Developers often just want to start writing an app but don’t want to manually evaluate 300 different options in order to select something maintainable. There’s currently however almost too much choice when it comes to what to use for structuring your JavaScript application. Part of this problem is fueled by how different JavaScript developers interpret how a scalable JavaScript application should be organized — everyone feels their way is the best. As a community we seem to prefer creating our own silos over improving existing solutions.

It’s not just MVC. Ask yourself how many results pop-up if you’re looking for a templating, routing, charting or Pub/Sub library and you’ll see what we mean. It sometimes feels like trying to find a needle in a haystack. Everyone has a different opinion about how apps should be structured, how libraries or tools should be approached and we favor creating our own silos and getting glory over genuinely improving something that is already there, so how do we solve this problem? Well, we recommend a few steps:

Research. Investigate whether there aren’t already strong options developers already have in the market for the project you’re considering open-sourcing (or working on). Is it possible for you to help improve an existing project rather than creating a brand new one? If it’s meant as just learning or you don’t intend to maintain it, clearly mark it as so. Why not speak to developers involved in similar projects early on to see what they think of your ideas?

They may have input that can help you improve these or save you time in case you’re told someone has already implemented the idea, you just didn’t find it earlier. Involving others in the community early on is always a good thing. Twitter. GitHub gists. Groups. There are plenty of channels for getting feedback early on and you should use them.

Even if you think they’re doing it wrong, there may be good reasons for doing something in a particular way. They may have even started out like you but had to adapt. You have the benefit of learning from others mistakes.

Document. If you go ahead with your project, make sure you document the heck out of what you do release. At TodoMVC, we currently get pull requests for a new MVC framework a few times a week and you would be surprised how many people consider documentation an optional after-thought. It’s not! Documentation is one of those things that can help make the difference between someone using your project and simply skipping over it.

You should argue for how your solution is better than the existing options and why the user should care about it. Demonstrate how it can make their lives easier and why it’s worth them investing their time in it. A lot of the repeated effort we set in the community doesn’t justify itself or try to set itself apart. For example, by promoting your project as AngularJS or Ember in 50 lines of vanilla JavaScript, you’re discounting the underlying complexity and completeness of those solutions. You’re also discounting the efforts that went into architecting and optimizing them without going into detail of how your solution compares performance wise to the exact same set of usecases. It’s more fair to both your audience and other framework authors to be balanced and honest in your claims.

Support. If there are 100 libraries available for achieving one task and only 3 of them are actively maintained with support available (via some channel), developers are going to ignore the other 97 in many cases. Part of open-source is making sure you do your users the service of either maintaining what you put out there, or if you’re unable to do this, saying upfront that this is the case. Your users will thank you in the long-run.

This is what YAFS looks like.

Further reading

A post from Addy, Sindre, Pascal, Stephen and Colin