Learn all the things!
Ember, Angular, React or that other thing?
“What should I learn next?”
Its something that I get asked so often that I’ve sort of come up with a stock answer. A lot of the time the stock answer is sort of tailored to the personality of the person asking if I know them well enough, but the core of the answer is generally the same. Having worked in a few agencies over the past 7 years of so, I’ve run into my fair share of developer arch-types. The old school developer who doesn’t see the benefit in changing, the young gun who is always onto the new-shit. The mid-weight developer who is super astute, but always feels like they are a little bit behind the curve and the newbie who has just got their first serious job and looks like they are about to drown in the sea of choices.
In November 2011 I would say that I was definitely the newbie. I was working for a major Agency in London as a junior developer and I felt like I was not only drowning, but I had no real idea how to swim. It was pretty scary, before this job I felt like I knew enough, but upon landed on my first project, I realised that I really knew so little. At this time I made the pilgrimage to Brighton and to the Full Frontal Conference where I heard some amazing talks, but the one that stuck with me was the the talk from Jeremy Ashkenas. He talked about the design decisions in CoffeeScript and within that talk he spoke a bit about Backbone.js. Another talk that day was from Nicholas Zakas about modular JavaScript. Both of these talks combined led me down a deep rabbit hole, of which Im still very much crawling through, of learning and iterating myself and my skills. I read a lot. I studied as if I were going to be tested every single day and I wrote code like a maniac. In December of 2011 I wrote a small framework inspired by both Backbone and the idea of modularity in code. It was a very small backbone-ish like framework where the DOM library could be swapped out at any time. Why? Well, if you’ve every worked with banks you will know that they might not be able to use a certain version of jQuery or they might only be able to use MooTools or a million other reasons you might need to swap out a part. It didn’t go anywhere really, I got the basics down, but as the work pilled on I never really moved the framework forward.
So over the past few years we have had a barrage of tools thrown at our faces and we’ve been lead to believe that we have to choose our Poison. Backbone, Angular, Ember, React, Knockout with Require or Browserify built with Make, Gulp, Grunt, Broccoli or Webpack. (I know — there’s a lot more). For some, the choice might be easy, one or more of them might tie up with your personal philosophy on how things on the web should be built. Maybe you think that Embers conventions lead to better and more maintainable code. Maybe the testability of Angular is something you prefer. Maybe AMD syntax is easier to read for yourself and your team or maybe you’ve just adopted some decent knowledge of Gulp on a previous project and are now using because it just works. But, if you’re new to JavaScript and are having trouble working out what you should learn because you are yet to work on a project that might or might not require some sort of modern front end framework — how do you choose to invest your time when it comes to learning? You’re being told left and right on twitter that Ember is the future or that on /r/javascript that there are 10 Angular jobs for every Backbone job (unconfirmed) or that you should learn all of them. I’ve spoken to a lot of developers who are fairly new and they all say the same thing. It’s daunting to know where to focus their time.
So, whilst I have my own personal preferences of what tools I like to use and what I want to focus on at the moment, let me offer my two cents on what you might want to learn if you’re finding yourself a little lost amongst the options.
ES6 and the future of JavaScript
If I were a relative newcomer to JavaScript, once I felt like I was ready to move on past the basics and wanted to start looking at more complex applications, design patterns, reading ‘The Good Parts…again’ and feeling like I needed to definitely learn something new in order to make myself ready for the onslaught of everything that is to come, I would start learning more about ES6 and the ongoing evolution of JavaScript. New syntax, new features and more are all becoming available to JavaScript. Block scoped variables, Fat arrow syntax, Class Syntax, Module system. All of these things and more are available for you to use now (by using Transipilers to convert from ES6 to ES5) and by learning about all the new features that are coming you are definitely preparing yourself for the foreseeable future of JavaScript development and not tying yourself to a framework that may or may-not be around in a few years (or just completely change everything about the way you build apps with their framework). Some frameworks are already using tooling to help them use some of the upcoming features in ES6 and beyond, so if you do find yourself on a project using it, you shouldn’t find yourself to overwhelmed with new syntax.
There are a lot of good talks on ES6 that will get you rolling a lot quicker than I can in this (or many) posts. The three I can recommend are:
You might find similar ground covered, but it’s well worth the time to just everything hammered home.
Accessibility (A11Y)
So many developers I have worked with and spoken to have little experience with A11Y, yet I strongly believe that its one of the most important skills to hone. Understand that most of the things that we build can be seen by almost anyone with a computer and an internet connection. There’s something really powerful in that thought that maybe we don’t think about too much. Im a big keyboard navigator — not because of some disability, but because I find it a lot quicker and easier most of the time to just use keyboard navigation. I love it when a site is optimised for it, when I can tab-and-space through forms, when I can go through items using HJKL keybindings, but most of the sites I use just aren’t built with this in mind. I know that there probably isn’t any decent data on keyboard-only users and even if they were it would probably be a ‘nice to have’, but I really don’t think that understanding tabbing order or adding some nice navigation via the keyboard is really all that difficult. On top of that we could throw in some nice Aria-tags to enable assistive technologies aid people through our site. We might only be making a brochureware website for some Mayonnaise, but do hard-of-sight people not like condiments? Do people with motor disabilities not want to read about the new [insert car name here]. Whilst we might not be able to test everything, we can at least give some people a chance.
We should be thinking about ‘A11Y-First’ just as much as ‘Mobile-First’ and if you add a little bit of knowledge, you will find yourself a pretty valuable member of any team and will be help make the web just that little bit more accessible for everyone.
A good place to start will be the A11Y Project Resource Page and then check out some of Marcy Suttons talks.
So those are two things that I would (and am) investing some time in. Sure, you’re gonna maybe want to look at every shiny new thing that comes along and of course, sometimes that will be beneficial, but if you don’t know what to spend time looking at right now, right this moment, then take a shot at spending some time on these things. I don’t think that the upfront investment is a lot and I certainly believe that it will be a better payout for yourself in the future.
Shaun Dunne spends far too much time on Reddit and can be found snapchatting at : fearandcoding
