Should I write all code myself, or heavily rely on frameworks, libraries and components written by others?

A question we continue to ask ourselves during software development, how much code should we actually write ourselves? With such an abundance of frameworks, libraries and components available on Github and the likes; why would you spend the time and effort into writing what others have already done (and possibly better)? A fair question to ask, and a question with a different answer depending on the situation you find yourself in. In this blog we discuss some of the reasonings behind writing the code yourself, and making heavy use of code written by others.

PSA: For the sake of purpose, references in this blog heavily lean towards Front-End development; the general reasoning behind it of course does also apply to other forms of software development.

You will never write all the code yourself

Let’s start immediately by taking away a myth, if it even existed for you in the first place. You will probably never write all the code yourself, ever. Unless you are working on the next Rover to land on Mars, or a brand new rocket from SpaceX or Blue Origin, you’re likely always going to rely on some portion of code written by others. And even in those instances, you’ll likely already have a framework ready for you to start using as well.

The best example I can give you here is the fact that the majority of development is done in a Front-End framework of choice. Most of the front-end development we do on a daily basis, is done in the likes of React, Angular, Vue.js and Svelte, among others. So unless you are Evan You or Rich Harris (founders of Vue.js and Svelte respectively), you’re not going to start from scratch on something. And remember that massive node_modules folder? That’s all code you’re already relying on, and then you haven’t even started working on your actual project. It’s just the shell to start writing your code in.

Where do your priorities lie?

So you’ve done the hard part. You now know what framework you will be writing your code in. This means we can start developing straight away, right? Well… yes and no. Now comes the time to set your priorities straight. Because whatever you deem important, has a large impact on how you actually do your development. So what should you be focussing on, and what are the trade-offs for your points of priority?

Feature or project needs to be finished yesterday

A common thing to come across when you are given new features that should be implemented in the project you are working on. When should they be finished? Well, we often joke that the answer is ‘yesterday’. This roughly translates to ‘the sooner the better’. So what do you do when there is a really short timeline? You look for corners to cut. And what better way to cut corners than to rely on every readily available module and component that you can possibly find on Github?

When the focus heavily lies on speed of delivery like in the example above, it is obviously very tempting to start grabbing code left and right and adding it to your project. While this may seem fruitful in the short term, there might definitely come issues in the long run. How are you going to address security updates for all the modules you have included, and what will you do with many breaking changes? Suddenly that speedy development slows down massively, and before you know it there’s a project manager looking over you shoulder waiting for the feature to be delivered.

It needs to perform, even on devices with the power of a potato

Although most of us have the luxury of working on an expensive Apple MacBook, and using the latest mobile phones, not everybody has that same luxury. In certain countries having the latest and greatest devices is more the exception than the rule. So what do you do when you have to or want to support every and any device out there? You focus on the best performance you can offer. How exactly? Well…

The answer to building powerful yet performant applications is not as simple as you might think, and it definitely requires more time and effort to achieve, than just reading the points in this blog. So what are some of those points on building performant apps? For starters what you should be aiming for is one simple thing: control. Because with control you can dictate every single aspect of your project. And the easiest way to lose control is to start using modules and libraries for everything you do. Your app becomes a mish-mash of code written by others, where you might not have a clear understanding of the impact on performance, bundle size and for example security.

I’m not saying that using external modules and libraries is bad here. It can certainly be useful and might take away some of the pain in your search for optimisations that make your app perform as you want it to. But it does require some additional effort into selecting those modules. Be on the lookout for components where the performance is carefully tested, where you can control the bundle size by including only the bits you need, and any other matters that are important to your project. Or, if you want full and complete control, there is always the option to write everything yourself. Allowing you to get the best performance as your hands can possibly write.

Can I do it harder, better, faster, stronger?

For those requiring the explanation, ‘harder, better, faster, stronger’ is a reference to the song bearing the same name, by Daft Punk. The aspect I’m trying to highlight here is the fact that even though externally written components are great. But do they do everything we need them to, do they perform the way we want them to, do we have a more clever solution?

Let’s take a simple slider or carousel as an example component. We have two subjects, subject A and subject B. Subject A is a simple person with a simple goal. They want to have a simple carousel where users can scroll through, Netflix style but a lot simpeler. They have no need for arrows or drag and drop support, don’t care if the carousel ends (no need for wrapping or continuous scrolling) and certainly don’t have a need for lazy-loading of content. Now answer me a simple question: do they really need a fully blown carousel component that supports the whole shabang, or are they better off just writing a simple div, setting inline-block on inside elements and exposing the scroll overflow? You be the judge.

Now, we should not forget about subject B. Because they need everything. And when I say everything, I really mean e-v-e-r-y-t-h-i-n-g. Wrapping, but also lazy loading, with support for arrows and drag and drop, responsive and configurable how many elements are shown and what size they have. In this instance it certainly would make sense to start using a library for carousels, wouldn’t it? All the support they need is ready out of the box, and is also actually getting used in their project. So you’re not losing any performance or get a bundle size that’s unnecessarily big, as all the functionality is actually getting used.

But we are not there yet. Let’s throw in a curveball, shall we? Subject B just got a new requirement in from the PO. It needs to work on televisions. Whoops, they didn’t know that before, of course. And they had just finished implementing the fancy carousel library that they found best fitted their needs! However, suddenly that component doesn’t fit their requirements anymore. It lacks support for focus management and spatial navigation. Now they have to start looking for yet another carousel component that does match all their needs, if there even is any out there that does. What a predicament.

TL;DR; it’s not black and white

Deciding to fully rely on external modules and components or not, is never a black and white question. What you do heavily depends on the situation you find yourself in. Are you desperate for delivery and does it need to be finished as soon as possible, regardless of the downsides it gives? Then the answer probably lies in using as many components as you can find. On the other hand, are you much more focused on performance and security? You might just be better off writing the majority of the code yourself.

The best answer to the question we asked ourselves in the beginning, maybe warrants just a single-word answer: balance. There are many reasons to use libraries, components and frameworks. And there are many reasons to write all the code in-house. The real job for you as developers, is to find the right balance between the two, taking into account all the priorities that you have in front of you. And by doing so, making sure that you get a healthy mix of project delivery speed, application performance and security.