You may not know this but by trade I’m actually a Fullstack .NET developer. I just happen to be one of those weird Fullstack developers who has more of an affinity to the front end than the back end. I’d say among my Fullstack brothers and sisters I am most definitely the exception.

One thing that I’ve been noticing recently, and I think this is a shame, is that many Fullstack developers treat development in the javascript as a second class citizen; an afterthought to the glorious back end application they’ve built.

Oh yeah, I guess the user will have to have something to fire this glorious algorithm, just hook up a button to a jQuery ajax call and let’s go to the pub

-Most fullstack developers

A lot of this mindset is mostly borne of “Javascript fatigue” which seems to be rapidly gathering popularity with fullstack developers as their “go to” excuse for avoiding taking the time to hone their JS skills. Oh! Pang! What was that?! Yes I know, its a hard truth but there it is.

I get it, the javascript has become a gigantic beast that was cultivated in a new wild west world of development ideas and methodologies. There’s no getting around the fact that despite many peoples best efforts during it’s incubation the JS-sphere has become mighty useful in some parts and mighty janky in others.

Over the course of the next couple of weeks I’m going to be releasing a series of posts in which I hope to give you some tips and pointers so that you can focus on the areas of your knowledge that need the most attention at different stages of your personal development.

There’s no particular order for this list, all these post are as important as each other if you want to achieve and maintain a good level of expertise as a modern javascript practitioner. As part of the series I hope to point out some common gotcha’s that sometimes trip up fullstack developers or just newer JS devs brave enough to begin wading into the JS jungle.

I hope that by giving you a point of light to focus on at the edge of the metaphorical forest that you’ll be able to more easily traverse the JS landscape and come out the other side with the hard fought, wel deserved knowledge you desire.

If my tips are good enough you might even gain better appreciation of what’s going on in the JS sphere right now and avoid the dreaded JS fatigue! I hope I can achieve that because it really truly is an exciting time to be getting involved and it’d be great to have more people to enjoy it with.

 

Tip 1. Know your build pipeline, love your build pipeline

A contentious issue with people beginning with modern javascript development is the build pipeline. I can kind of see why as well, it’s a hard pill to swallow when before you’d just write some ES5 whack it on a page and you were done. Now you’ve involved node and any number of npm packages. On top of that the command line has returned to your workflow, WHAT YEAR IS IT?!

The thing that makes people throw their hands in the air the most though is just the sheer amount of time it takes to set up a good build pipeline. There’s so much front loaded effort just to begin writing your code that you begin to wonder if all this fuss is worth it!

This, for a lot of people, is where build pipeline generators like Yeoman or create-react-app come in. Now I have to admit, when I first discovered these tools I had thought to myself, “Having a pipeline generated for you is all well and good but if it doesn’t do what you want it to do out of the box then you’re going to have to edit it anyway. If that’s the case you might as well have just built your own from scratch”.

None the less I gave them a chance and after some time tinkering them into my workflow I’d say that now I’m as enamored by them as most other people are. There’s no denying it, these tools are pretty great.

The rub I had with them in the beginning however still remains and that is this; a build pipeline generator has a tendency to become a black box and this is dangerous for your productivity.

You MUST NOT let your build pipeline become a black box to you.

Let me explain why; On larger more time critical projects if your build pipeline is a black box to you then what is going to happen is you’ll end up finding either a defect or limitation in the pipeline you’re using. This stumbling block will eventually start impacting the accuracy or performance of your pipeline. Maybe not today or tomorrow but it’s going to happen, I guarantee it.

When these defects do come home to roost they may manifest themselves in  outright breakages to your pipeline. This is almost ideal the ideal situation because the nightmare alternative scenario is that this defect or limitation just becomes a bit of a headache but despite this the pipeline still works.  You might have to wait 5 minutes for a build or build 3 or 4 times before it gets working but it will keep working (right after it’s done laughing at you).

You will NOT fix this. You will just sit there and let it jab you in your productivity every time you build. It’s not because you’re a bad or unprofessional developer or anything like that, absolutely not. But you are only human and you’re bound by the same constraints such as there being 24 hours in a day just like the rest of us.

The reason you won’t fix it is because, in reality, there will never be a time when you think, “Now is the right time to waste a sprint getting to know the inner workings of my build pipeline well enough to fix this problem”. You just won’t, who’s got time for that?! Ain’t nobody, is the answer.

 

Oh? You came for advice?

Here it is: use build pipeline generators, they’re great, why hamstring yourself by not using them? But there’s a way to use them and there’s a way not to use them, so I will caveat that by saying, try to standardise on one generator per technology.

Get yourself a “go to” generator for each thing you might sit down to build. To give you an example, my favourite for react is create-react-app. With this in mind, every time I sit down to start developing anything new in react whether it be for work or pleasure I always start by generating myself a new create-react-app pipeline.

By standardising in this way you’re able to become intimate with the internals of the pipelines you choose. You’ll gain a knowledge of how it all hangs together with the technologies it uses.

Sure you’re still going to have to tweak for each project to fit your exact needs but the default core internals remain the same. This means that any project you start work on you start from a position where you’re already very familiar with how your build pipeline hangs together and how it works.

This means that when you do get to the inevitable defect or limitation you’ll be far better tooled to just fix the problem. You won’t have to worry about spending time becoming for familiar with “how this damned beast works” you can just fix it and move on, no fuss.

 

More to come

So that’s it for this week, I know this weeks topic was fairly rudimentary but I felt it needed covering because I’ve seen so many people come into react and hail create-react-app as their lord and saviour and I’m sure those people aren’t taking the time to understand what it does. I worry for this people. I hope I’ve been able to convince you not to be one of these people.

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 seeing for the next installment when I talk about dependency management!