Being a junior frontend web developer is a thrilling journey of learning and growth, building web applications, and collaborating with talented teams. Along the way, I made my fair share of missteps. Looking back now, I like to reflect on the mistakes I made during those formative years and, in this post, I aim to share my experiences, hoping that fellow frontend developers can learn from my failings and avoid these pitfalls on their own path to success.
Most of the details I share here were learnings from my first professional developer role back when I was working as a Junior Frontend Developer at a digital agency called 3pc. The role itself was all the more challenging as it required me to communicate with my colleagues and management in German, adding an extra level of complexity to the challenge. I won't go into any details about the language barrier here, but suffice it to say, it was significant.
What are the most common mistakes of junior frontend developers?
From failing to properly learn the tools of your trade, stubbornly approaching a problem the same way over and over, all the way to misunderstanding fundamental concepts like AJAX requests, Promises, the browser API and more, there are many gotchas in the world of frontend engineering that juniors can fall foul of.
Mistake 1 - Underestimating JavaScript
I thought JavaScript was just a scripting language. But there’s a reason we write JS for the frontend and not Python or Go or C++. Sure, JavaScript is a scripting language, there's no doubt in that. JavaScript is now used in many backend web applications in the form of NodeJS. It has functions, classes (kind of), variables, control flow, and all that good stuff.
But when it comes to frontend development, it also has the Browser API. The way we interact with the browser is baked right into JS making it useful for running on the client side. With the browser API, we can:
- Interact with the DOM
- Respond to user actions
- Get and set items in local storage
- Work with the browser’s IndexedDB
and many more crucial features that make web development so powerful.
It took me a while to unlock the power of JavaScript’s browser APIs, and even as I began to learn, I didn't have a hard-and-fast way to teach myself these concepts. I would stumble upon a feature that I needed by doing some rough searching around what I was attempting to do.
These days, I know that there are resources like MDN and W3CSchools that provide comprehensive lists and guides to all things web-related. If I'm ever in doubt about a certain feature or functioanlity, I head over to one of those sites and update my knowledge.
Mistake 2 - Asynchronous Code
JavaScript is a powerful language in many regards. The ability to deal with asynchronous execution of code brings it to a whole new level. In order to utilise the async functionalities, though, you need to make use of JavaScript Promises.
Promises are essentially just a placeholder for “something is going to be here….eventually”. With Promises, you can wait until the asynchronous call was resolved (success) or rejected (failure). Once the Promise has been settled, the programme can then continue accordingly. If there was a successful outcome, the code can use whatever data was returned from the promise. This is typical with things like AJAX requests. If the promise was rejected, then the programme can deal with the failure.
It took me quite some time to understand JavaScript Promises, but once I did, it improved my abilities as a frontend developer. After all, dealing with API requests is a fundamental feature of most web applications
Mistake 3 - Learning jQuery With JavaScript
In my first role as a frontend developer, I learnt jQuery at the same time as JavaScript. I already had an understanding of both, and was able to pass the technical challenge to get the job but, I'll admit, my jQuery and JavaScript ability was certainly limited. I thought cutting the corner of thoroughly learning JavaScript before diving into jQuery would be acceptable given that I had a job to do.
It wasn't exactly a disaster, but trying to skip ahead caused to have huge blind spots in my frontend skills for a long time to come. jQuery and JavaScript's APIs are different when it comes to practically everything. jQuery has its own shorthand methods for attaching event listeners, it has its own control flow methods, its own DOM traversal methods, its own DOM manipulation methods. By reimplementing some of the raw JavaScript browser API, it muddies the water and in that same muddy water is where I got lost.
Using jQuery is nice and convenient but it becomes a crutch that I got very used to leaning on with my first professional project. I was able to develop quite quickly considering my inexperience but it came at the cost of a compromised understanding.
jQuery calls its methods by wrapping everything in its own objects. Only then can you call those methods. I didn't understand what the difference was between a jQuery object or collection and a DOM node or DOM node list, for example. It took me hundreds of instances of the same error to realise this.
When I came to working on a project that no longer had jQuery, I felt like I was starting from square 1. It might be cliché, but I really should have learnt JavaScript properly before jumping into jQuery.
Mistake 4 - Spaghetti Code JavaScript
Writing all JavaScript code in one file doesn’t cut it. For learning projects, it’s fine because the code is small. But as soon as I started working on a large project in my first role, I soon got pulled up by a colleague for writing horrible spaghetti code. He suggested I take a look at some design patterns to break my code down into different modules and separate the logic from different parts of the site. This has the advantage of adhering to the Single Responsibility Principle for each module, and is also a nicer way to structure the code for future developers.
Back then, I didn’t understand the power of design patterns and I started using the Revealing Module Pattern. It completely revolutionised the way I wrote JavaScript. This particular pattern entails writing Immediately-Invoked Function Expressions (IIFEs) which only expose the functionality to the outside that is required outside of the function. Here is a contrived example to get the point across.
const RevealingModule = (function () {
// Private variables and functions
let privateVar = "I am private!";
function privateFunction() {
console.log("This is a private function!");
}
// Public API - Exposed to the outside world
return {
// Expose a public variable
publicVar: "I am public!",
// Expose a public function
publicFunction: function () {
console.log("This is a public function!");
},
// Access the private variable in a public function
getPrivateVar: function () {
return privateVar;
},
// Access the private function in a public function
callPrivateFunction: function () {
privateFunction();
},
};
})();
console.log(RevealingModule.publicVar); // => 'I am public!'
RevealingModule.publicFunction(); // => 'This is a public function!'
console.log(RevealingModule.getPrivateVar()); // => 'I am private!'
RevealingModule.callPrivateFunction(); // => 'This is a private function!'With this design pattern, I can expose public data and methods to the outside, and hide private implementation, even allowing for access control to private data (i.e. the getPrivateVar method). This resembles the behaviour of classes in JavaScript.
Regardless of the details, the principle behind design patterns is to use battle-tested patterns to produce well-organized, readable and reusable code. Learning design patterns doesn’t take much and I didn’t even learn the details, just what was out there and what they could do. Any time I need to reach for one now, I research which one will give me the power I need in my code base. A simple, yet effective strategy.
Mistake 5 - Debugging Errors
Not knowing how to debug errors proved to be a huge timesink during my first professional role as a frontend developer. Ultimately, it’s all about knowing the tools and creating a systematic approach to troubleshooting.
Errors happen a lot in this industry. During development, but also on production, errors can set a project back a lot if not dealt with early and as swiftly as possible.
I distinctly remember struggling with an error for an entire day as a junior developer. There were two issues really. First, I should have asked for help (I guess some days I couldn’t be bothered speaking German as much as other days). Second, I lacked an effective approach to debugging errors that would allow me to overcome the problem.
In my experience, debugging approaches don't need to be algorithmic like a rigid list of points to track down and solve the error. Instead, they should be more like a heuristic. A rough guide to follow in order to move slowly but surely in the right direction by establishing a good starting point, determining the right path to take, where to look, what to Google and how to hone in on the error and finally to fix it.
The system I created became an invaluable tool in my developer toolbox, without it I wouldn't have had as much success in my software career.
Mistake 6 - Browser Cross-Compatibility
Ignoring cross-browser compatibility seemed so easy in the early days of the project. I was so absorbed by Chrome, I completely forgot that other browsers exist too. But I didn't really care because nobody seemed to notice anyway.
Small differences like input field styling and the way Internet Explorer handled flexbox layouts seem insignificant but they add up quickly and can really degrade UX overall. Add to that the missing JavaScript features (again looking at you, IE) and it quickly became a large issue that I had to deal with eventually.
Fortunately, or unfortunately, there was an experienced QA on the team who pulled me up on all the missing cross-compatibility issues. Without that feedback, it would have taken me quite some time to understand the implications of cross-browser compatibility.
Wrap Up
Starting a career in frontend development is challenging but really rewarding. I often say the best and worst thing about software development is the sheer volume of topics to learn and understand. It can be overwhelming but exhilerating at the same time.
I learnt a lot from my first junior web developer job and, even though I made lots of mistakes, the experience I gained from those mistakes has set up my entire career in software development. Now, as a senior software developer, I'm aiming to share my experiences with juniors following the same path I once walked.