Tim.dev

When I got back into front-end development in 2017 after a one-year absence doing project management, it was time to level up my skills. The JavaScript ecosystem moves crazily fast and can be very overwhelming as the 2016 Hackernoon post by Jose Aguinaga still(!) accurately describes. New tools, libraries and frameworks pop up all the time. In this article, I would like to share my journey as I tried to improve my skills and knowledge over the past year. Disclaimer: this is by no means a guide as to how and in what order you should learn JavaScript.

Where it all began

I initially learned the very basics of vanilla JavaScript as part of my website localisation master’s programme back in 2012-2013. And when I say basics, I mean basics. Some basic String manipulation, writing functions and selecting DOM elements by id and applying styles attributes. I quickly grew to like this language, but soon realised that I had to learn jQuery in order to be more productive with the limited knowledge that I had. So I learned basic jQuery on my own within two weeks with the help of a great Codecademy interactive in-browser course.

jQuery spaghetti: a dish we all ate

At this point, I was ready to efficiently add interactivity to my websites and I all of a sudden had access to a vast collection of jQuery plugins. During my first front-end development job, mainly making websites for small to medium businesses, my main JavaScript file usually followed the same recipe for jQuery spaghetti code: within a jQuery document ready statement, add and initialise some jQuery plugins such as sliders, lightboxes, or accordions, add some custom class toggling for some custom menu animation, and maybe some helper functions here or there plucked from Stack Overflow.

This was more than sufficient for me to get by and realise many cool projects and I eventually started learning more about programming and how to write better-structured code. Being the only front-end developer at my first job, I had no-one to look up to or to learn from within the company, so I constantly needed to push myself to learn and discover new tools and technologies. Eventually, as the projects grew bigger, the jQuery as I had been writing it became more difficult to manage and hard to change for my backend colleagues. So I started learning how to structure my jQuery code by writing my own reusable jQuery plugins and I dove into some more advanced concepts through some CodeSchool advanced jQuery courses such as event delegation, hoisting, scope, and prototypes.

Coming back to a transformed landscape

Returning to front-end development in 2017, I noticed that the javascript ecosystem had changed and that frameworks like React and Angular were more and more widespread and people were doing things in vanilla JavaScript again instead of jQuery. I realized the power of these new frameworks as well as that in the current day and age, you don’t need jQuery anymore. jQuery had been instrumental in the past in writing cross-browser JavaScript for websites that needed to be supported in browsers as antiquated as IE 7 or 8. I joined a team of front-end developers who were just as eager as me to transition away from jQuery as well as pick up React as single page application framework of choice.

Vanilla JS still had its quirks (for me)

Despite the new cross-browser consistency and already being able to think in JavaScript, the transition to vanilla JS in projects where previously I would use jQuery wasn’t all that easy. I ran into various issues on the job as the DOM manipulation API is sometimes not how you expect as opposed to the fairly predictable and polished jQuery API. Luckily there are some great resources out there that helped me transition and solve common gotchas that you are likely to run into. Besides the MDN JavaScript documentation I recommend taking a look at the following assets :

You Might Not Need jQuery
The Vanilla JS Toolkit by Chris Ferdinandi

Besides mastering vanilla JS, not being able to rely on jQuery plugin pattern anymore, I had to focus on learning different vanilla JS design patterns. For non-React projects, our team often works with asynchronous (require.js) modules. In order to master different JavaScript module patterns Learning JavaScript Design Patterns by Addy Osmani has been a great reference.

React and ES6

While ramping up my vanilla JS skills, I also learned React, and coincidentally ES6, at that same time. For a new project, I quickly had to learn React. As I am a visual learner, I turned to CodeSchool again for their great React course by Sergio Cruz. It gave me all the essential knowledge I needed to get started working on real projects. React may seem simple at first, but you definitely need to get some working experience time in doing the same things over and over to fully assimilate the reactive way of programming. But once I did, I never want to go back to the old jQuery way of manipulating the DOM.

As the scope of my first React project expanded, I realised that the basics would still allow me to finish building my app, but it felt like the codebase quickly became less maintainable and scalable. For example, as the app grew, managing and passing down state many layers deep into the component tree or opening a modal component several layers up became ‘problematic’. I felt like there should be better solutions out there to structure React apps and that’s why I wanted to perfect my React skills. I did so by taking an Advanced React.js course by Samer Buna and Building Applications with React and Redux in ES6 by Cory House, both on PluralSight. These were both excellent courses which gave me great insights in how I could structure apps for scalability, use Redux and immutable patterns for easy and predictable state management, improve performance, render my apps server side, get started with unit testing and many more advanced concepts.

What’s next?

Over the past year, I’ve become a big fan of JavaScript SPA development. I plan to devote another article to explain why I love this new way of working in further detail. But to keep on learning, I think it’s most important to build a lot of things, so I’m hoping to work on more JavaScript projects this year. I keep updated on the latest development through blog posts, podcasts, and YouTube videos and I hope to visit one or more conferences this year. At some point, I hope to explore Vue.js and maybe Angular further, but for now, I feel like developing React skills and becoming a specialist is a safe ‘bet’.

But I’m new, where should I start?

My journey is by no means a roadmap and it has been far from ideal. To new learners of JavaScript, I would recommend learning the basics concepts of programming if you haven’t already by learning vanilla JS. I don’t think it’s very relevant to learn jQuery anymore as vanilla JS has gotten much better and is much faster and doesn’t require a dependency to be loaded. If you are making an interactive application, or just several interactive components that get hard to manage and maintain with vanilla JS, consider picking up a lightweight library plugin library like Vue.js or another reactive micro framework that will allow you to work more efficiently. For bigger projects maybe pick up React or Angular. Analyze the problems that need to be solved and choose your tools accordingly.

But frameworks come and go. Instead of learning all new frameworks, try becoming a better programmer in general. Try to understand the concepts behind the libraries or dive into functional programming. But most of all, build lot’s of things and get stuck.. and once you get unstuck, you probably learned something.