There is No Wizard Behind the Curtain

As the Age of Open Source matures, it often seems like technology is moving faster than anyone can keep up. Just as Knockout was becoming a widely accepted platform, AngularJS emerged and became the new paradigm. After only a few short years, Angular 2 was announced and brought in a change to how that project was used. It seems every few days, a new library gains traction that will make some part of our lives easier. This isn’t limited only to front-end development as the .NET tool NuGet allows for an infinite number of libraries to become available to ease server side coding as well.
With so many choices before us, we are presented with a dilemma as we begin a new project, or rework an existing solution. As deadlines continue to get tighter, it is very easy to grab at every little advantage we can in order to save some work. However, caution should still be used before jumping on too many bandwagons. At one time it may have seemed like all the common libraries available to us were tested and in use across multiple applications. Now, new “bleeding edge” packages are just as easy to find as the reliable frameworks.
One of the things I always ask when discovering a new library is simply “Why?” OK, what I’m really asking is “What does this package do that will make my life easier, and how will it make things harder?” A new widget that (for example) promises to build a table in JavaScript in only two lines of code sure would make coding this website easier!
However, I’ve rarely had a project where I’ve implemented UI components and then the customer was happy with it forever. There’s almost always that conversation a week or six months later where they say “This new page makes our lives so much easier, but it would be nice if we could make this table do…” It’s at this point where the true cost of saving the time at the beginning comes due.
Oftentimes, especially with front end packages, the tools are made to “just work”. Someone has a great idea on how to solve a problem that they’ve encountered, and they were nice enough to share it with other people. However, just because it fit their needs doesn’t mean that it will fit anyone else’s. The other scenario is when it works phenomenally, but configuring it for “one little change” probably requires editing their source code, which causes problems if their library gets updated. You could also add a wrapper but then the potential exists for the next change to cause complications. Perhaps there’s another library out there that does most of what you’re looking for, but it’s missing something from the original package. Then the effort to rework everywhere you’ve created that table would take too long, and potentially introduce bugs.
Something important to remember (or learn depending on your skillset) is that there is (rarely) any “magic” going on within these packages. There are some packages that intertwine IL code in .NET, or have been written to hide the browser irregularities for a decade, but most of the time those aren’t ones we need to tweak. Even the most seemingly complex tool like Bootstrap is just a collection of CSS with some JavaScript tied in. In most circumstances, that library is perfect for everything you’d need in a project, but there aren’t any sufficiently difficult practices there that should prevent you from rolling your own version for some controls or specific features you need. Often new frameworks are incorporated just because the project lacks the developer bandwidth but many of the features it provides are not applicable.
There are many places to find new libraries. A simple search of the language you want to use, and the problem you are solving will reveal numerous blog posts, GitHub repositories, Stack Overflow questions, etc. that can begin your search. Once you have found a potential solution, there are a few things you should look at to help determine if this is a reliable fit. Number of downloads for a GitHub or NuGet package will be a solid indicator of its quality. The last time a release was made, and how many open bugs are reported on a GitHub repository will help ensure that newly discovered problems are getting fixed. Solid documentation is always helpful to gauge the author’s commitment for helping others use their package.
Another thing to consider when evaluating whether to use a new library: If the library is creating a feature that you don’t know how to implement, and you have the time, take a look at their source for inspiration and try to solve it for yourself. Under no circumstances should you copy it verbatim, but use some of their techniques to get you started on your own. Even if your solution doesn’t seem as elegant as a package you’ve found, you’re still improving your skillset, and you could probably solve that or another problem better in the future. You also gain the benefit of understanding exactly what the code is doing so that if you do need to add another feature down the line, you know where to add that in.
And of course, there’s nothing wrong with keeping that new library you created in your pocket just in case you can’t quite get it figured out. At the very least, you’ll have gained some experience that may help you with the next widget or server side process you need to create.

Share on

Facebook sharing Linkedin sharing button Twitter sharing button

Ready to get started?

Enter your information to keep the conversation going.
Location image
4 Sentry Parkway East, Suite 300, Blue Bell PA, 19422

Email Image

Phono Image610 239 8100

Location Image4 Sentry Parkway East, Suite 300, Blue Bell PA, 19422
Phono Image610 239 8100