Welcome back! Or welcome if you missed the first part of this tip series. In this series I am trying to help Fullstack Developers make the metamorphosis from being a developer who is only paying lip service to their javascript development into an official beard carrying, Mac owning, coffee shop working member of the JS community.

Well, ok, maybe it won’t change who you are per-say but at very least it should help you to navigate around the dangerous pitfalls and gotchas, as well as the unique ways in which they manifest themselves in Javascript.

This series is an attempt to help keep you focused on what’s important as you gain Javascript ninja status. And; by taking the most direct road to greatness, we might even help you in avoiding the looming threat of “Javascript fatigue”. Let’s get started on this weeks topic!

Dependencies. What have they done for you LATELY?!

I would never be so bold as to claim that I invented this one from scratch. The ideals behind it are straight out of Uncle Bob Martin’s bible “Clean Code” which if you haven’t read, you need to stop reading this article right now! There’s no time to waste here you’ve got a book to buy and reading to do!

Bob suggests that you should always be terrified about letting your code get poisoned by third party dependencies. He thinks that you should never surrender yourself to the whims of a third party developer. Don’t let someone else break your code, always put third party dependencies behind abstractions to avoid become a slave to these dependencies; is basically the essence of this argument.

In my own development I implement a flavour of this sentiment. Whilst there are a great number of dependencies that I do hide behind abstractions, like hiding ORMs behind the Repository pattern for example, there are an equal a number of dependencies that I simply accept as a dependencies that I’m going to have to live or die by, e.g. React or Dependency Injection Frameworks.

But overall, I still hold a healthy skepticism towards taking on new dependencies. Bob is right, taking on dependencies that aren’t hidden behind abstractions are a trust fall into unknown hands on the internet. I don’t think I need to overemphasize how risky that can be, left-pad anyone?! Further to this the problem is exacerbated in javascript because your ways to provide abstractions to hide these dependencies in a simple way are limited.

Taking all this into account, here is my advice around dependencies in modern javascript development: belly-ache over taking on dependencies, like…really…belly-ache. You need to be doing the awake staring at the roof at 3am asking if you’re “really that into” the dependency you’ve been thinking of asking into your code base or if it’s just a “honeymoon period”. Do you really need it? The reality is that most often you don’t, the sooner you come to terms with that fact the better off you’ll be.

 

Dependencies….Dependencies everywhere

Obviously Bob was talking about Java in Clean Code and the statements he made were talking about OO programming languages so you might be wondering how this relates to modern javascript development? Well, In the modern javascript sphere this mind set has never been more relevant and it’s applicable in special ways that are unique to the current state of javascript development.

In a world where packages like left-pad can exist I think that we can all afford to be a little more prudent about the dependencies that we take in our software. The fact is that the ever present danger of repo abandonment, someone pulling their package of npm or just plain old breaking changes is very real and so much more pronounced when you can bring in 10 new dependencies in a single command line statement.

The abundance of packages and the breadth of functionality they can provide means if you get too dependency happy then it’s very easy to find yourself in a situation where you might find yourself surveying your laundry list of a package.json file and thinking to yourself a horrible, horrible question, “I wonder if I still use X package”.

The sad state of affairs is, you probably don’t, but are you going to go scour your code to find out? Nope. So you’re package.json will inevitably bloat and bloat until, eventually, you’re brave enough to try and do a clean out and I don’t need to tell you how that goes now do I?

Look, I don’t intend this to be another sensationalist “You might not need jQuery (or insert other insanely useful tool here)” type posts. But the fact is, most often, you might not. Might.

I’m not saying that should never take a dependency and that you should reinvent every wheel you come across. I’m just saying that you should be using dependencies to release pressure on your workflow which should allow you to reinvest that productivity back into your project. What you shouldn’t do is introduce Redux into your Clock app because your mate Dave told you how cool it was!

To give you a rock solid example: I have had a number of people contact me on the comments of my app building videos on the reactionary youtube channel. I want to say these comments are very helpful and welcome. So before I continue I’ll say explicitly, I’m certainly not trying to be negative towards the people making these comments.

Anyway, what they asked was if I was aware of a package called react-bootstrap that I could’ve used instead of manually using the css classes to create the bootstrap based UIs that I made in those videos. My answer to this question is always the same; yes, I’m aware or react-bootstrap but I didn’t use it in this application because the scope of the application didn’t call for it.

In my opinion little applications like the ones I build in my App building series don’t need to be making those sorts of gambles on dependencies. React-bootstrap, in this instance, just doesn’t cut enough complexity to justify the risk. What risk? The risk that taking that dependency might come back to burn me in the future. A dependency you don’t take can break your software right?

 

Where’s the advice?!

Let’s try to put a bow on everything I’m saying here. A decent analogy for how to draw dependencies into your project is to treat building your app like you’re building a high performance vehicle.

Hear me out, if your code base was the stock car then sure it could go alright around the race track. But if you really want to light up the track you’ll have to add on some third party high performance parts and systems, which in the apps case means take dependencies.

Sure you’ll add some parts but you aren’t about to add every high performance part that some bloke on the internet cobbled together in his garage! And one of the latest SpaceX rocket engines is probably going to do more harm than good.

You see some dependencies are definitely a good thing. But too much of a good thing ain’t a good thing, eventually you’re either just going to degrade performance or maintainability or extensibility or all three!

So in a line here’s the advice:

An ideal list of past lovers and and ideal list of dependencies have the same criteria: a short list of high quality.

 

More to come

Well, I hope I was able to make all the resonant with you. It would be great to see less developers hopeless chained by unruly and overgrown dependency chains and if we all adopt the mindset above then I think this utopia could be in our future.

If you enjoyed this article and would like to continue to the conversation, please feel free to contact me at any of the social media links at the top of the page or in the comments below. I look forward to releasing the next installment for you where I talk about approaches to take towards the effective construction of componentised UIs with React. This topic will hopefully have a number of analogs to general modular development with javascript as well. See you next time!