The next step in your JavaScript journey 🐛 → 🦋

Balloons by ian dooley on Unsplash

The journey we call JavaScript is full of surprises. Developers like you and I, all have different experiences and yet still all of us arrive at some similar truths.

The one most universal truth I can think of:

“We all want to suck less.”

If you’re coding JavaScript for over a year or two, most of us are at a place where:

• we’ve written a few web apps/sites
• are familiar with Vue, React or Angular
• feel like there’s not much we can’t do with JavaScript
• are quite good at debugging with the chrome developer console
• are fairly confident about JavaScript skills in general

Yet we know that there is still so much we can improve on.

Let’s face it, we can quickly mock up any kind of component and play around with it in the browser. But before you know it, over 50% of our time is spent on debugging what we made yesterday… 😕

People say

Ok, people say: “You just gotta write them tests!”
But that’s easier said than done, especially if your apps are mostly the components you code with your framework. Also while we do have some benefit from central state management, having to mock your entire store’s state is exhausting. While other actions are async and even more difficult to test…

Ok, people say: “It’s 2019 and you’re still not using TypeScript?”
And while this does sometimes sounds appealing, again, where do we start. We’d have to go through hoops, rely on some typescript plugins for our framework and refactor more than 50% of the code for every single component…

The idealistic developer roadmap 🗺

There’s this really cool developer roadmap that depicts the journey most of us front-end developers took, even if we weren’t aware of it.

However, I’ve personally been writing JavaScript for over 3 years and I gotta say:

That roadmap is a lot more idealistic than real life.

Especially when you get to the parts that say “Testing your apps, PWAs, Typing, SSR, …” Sure, we can do all those things, because these days it’s just executing a single command in our framework’s CLI, right? But, hey, it usually doesn’t take long since you hit a bug after the framework did its magic, and those are often even more difficult to debug…

I mean, are we really that confident to call ourself good developers because of the powers our frameworks give us? Aren’t we more often than not, struggling with “just making things work” while we (secretly) don’t fully understand how things work in the first place?

If you’ve been there, let me tell you something cool: We’ve all been there buddy. We’ve stuck our hands too deep in the framework jar. 🍪

Take a step back

Let me dispense some of the advice I wish someone told me when I was your JavaScript age. I will tell you something that I had to find out on myself that made it possible for me personally to grow a lot.

Remember how fun and easy JavaScript was when we were just learning what a function was. A function is one of the most basic building blocks yet it’s actually our most powerful tool we have.

If you want to write better code with less bugs, the biggest advice I can give you is:

“Modularise your JavaScript”

Yes this is a quote… I said that.
But I bet so did any other developer at one day in his life. 😀

Anyway, what I’m trying to say is than if you write small modular code — functions that just takes some params and return something else — everything will become much simpler.

Don’t worry about adding tests to your framework now. Don’t worry about rewriting your app in TypeScript. This is all way too hard to do from one day to the other.
Just start small writing small modular functions.

Give me the baby steps 🔰

It’s very simple

1. Go look at the code of your latest app you are building and find the longest function or action you wrote.
2. If it changes values outside of the function itself, do that only at the very bottom of that function.
3. Now extract the actual logic into a separate file and have it:
   — take params
   — do not rely on anything outside of the params it takes
   — only modify those params
   — only return params and change nothing outside the function
4. In your original function you can call the extracted function, receive the results, then update any values you wanted to update

This is just one example of extracting logic from your app and it has countless of benefits that will make you write waaaaay better code.

When you have extracted a function it’s so much easier to test this function, make sure it works well whatever you throw at it, and heck, maybe even apply some type checking for those params? 😄

When you have extracted some logic out of your code into a stand alone function, you’ve essentially written your very first module! Welcome to modular JavaScript! And trust me, this is where the fun just begins!!

Good luck on all your JavaScript adventures! 🎉

Also see my other post on

• 📖 making your modules easy to use with documentation magic

Yours truly,
- Luca Ban (github)

Luca Ban (@Mesqueeb) | Twitter

PS: For the time being, if you want to read more about modular JavaScript, check out this post of Sindre Sorhus: Small Focused Modules