Ali SpittelJavaScript (and front-end development in general) can feel intimidating because so many cool things are happening so fast. The language itself is evolving, and so is the ecosystem surrounding it. From frameworks like React, Vue, Angular, and even Hyperapp and their rapidly changing APIs to the bundling systems around them to the language itself, JavaScript is evolving rapidly and it can be tough to keep up. Very few of these tools even existed five years ago. Blog posts like this one outline how hard it is to learn modern JavaScript and stay up to date with everything that's happening.
I started working with JavaScript during perhaps the peak of the chaos in 2015 after working solely on data analysis scripts and computer science coursework previously, and since then, I've had the privilege of teaching hundreds of people the language. So I'm going to be telling a bunch of stories about my JavaScript journey -- and how I decide what to teach -- in hopes that you will make fewer mistakes than I did and that we can make the world of JavaScript a little less scary 😈!
How can we face our JavaScript Fears?
Focus on the fundamentals
The fundamentals of the language are never going to change that dramatically, so being super knowledgeable about the ins and outs of it can only help you.
In JavaScript, especially, knowing intermediate concepts like the call stack, context, scope, the prototype chain, higher order functions, asynchronous programming, and the event loop is invaluable and will help you with anything you do further with the language.
I also really appreciate this comment:
Knowing the fundamentals really well makes frameworks much more helpful and so much easier to learn! Underneath the hood, these frameworks and libraries are just JavaScript anyways -- they aren't magic!
In fact, your project may never need to use a framework -- GitHub runs on vanilla JavaScript and Hacker News runs on 150 lines of unminified JS total. Plus your site will be lighter weight!
I appreciate Dan Abramov's You May Not Need Redux -- I think more libraries and frameworks should have their co-founder be explicit that their tool isn't always the right tool for the job! It's the truth.
Shiny Object Syndrome
Shiny object syndrome is when you see a new thing and immediately want to drop everything and focus on that shiny object. In tech, that may mean that you re-write your applications every time a new library is on the horizon.
I am super guilty of this -- I used to write my blog posts themed around writing an app with a new library or framework each week. I've also worked with JQuery, Angular.js, Angular, Vue, Elm, and React at some level for work. But, that shouldn't be normal or encouraged.
I think my best shiny object syndrome story was when I worked on a team that was using a Chinese library whose documentation hadn't been fully translated to English yet. I remember running Google Translate to try and figure it out. It wasn't productive and Google Translate isn't great with technical docs in case anyone was wondering. Though the library looked cool, using one that was available in the language we spoke would have been a lot better.
So let's talk about how to overcome "shiny object syndrome."
You don't need to know everything
In large part due to imposter's syndrome, a lot of developers feel the need to know everything about everything -- but that's not even possible! There's way too much to know, and nobody knows everything! Keep reminding yourself about that, and don't feel the need to know everything -- even though it's hard.
To quote Dan Abramov about the new React Hooks API:
Hooks are an experimental proposal to React. You don’t need to learn about them right now.
The same is true about everything -- even though it might not feel like it.
Focus on depth over breadth
Once you know one framework or library, it is so much easier to move to the next one. If you understand the component architecture, you are already a quarter way through learning React, Angular, and Vue! You don't need to know all of them. Sure, they're all cool and have different features, but chances are you only need one.
Don't migrate to the newest thing immediately
Also, when you're picking a stack for your project, don't be the first adopter. Sure it may be cool, you may get a blog post out of it, and maybe it will make some pieces of your code easier. But -- then you get stuck on some bug in the library, and you can't progress until it's fixed. Or documentation for what you're trying to do doesn't exist, and it isn't realistic to bring anyone but expert level developers onto your team.
Let somebody else find the bugs first; then you can start using that cool new tool!
Also, it's important to keep progressing and creating modern interfaces for your apps, but if your stack is still working for you, there isn't a need to change or rewrite it from scratch. React just surpassed JQuery in Google searches (src) even though JQuery may feel like ancient history in the JavaScript world!
Choose Wisely
Since you can't learn or use every new framework or library that comes out, you have to also figure out how to choose your tech wisely. A couple of key questions when you are deciding what tool to use for a project or to learn:
- Is it well used? If it has a community behind it then it's more likely to have contributors and frequent iteration on features and bug solving. Also, it's more likely to have staying power.
- Who is the community behind the project? Is it a large company? Do they have a code of conduct? How do they treat new users?
- Is it frequently updated? You don't want to be stuck with bugs that aren't being fixed.
- Are there frequent breaking changes? You don't want to have to make major code updates to keep the tool up to date. Also, it may make researching the tool difficult. Looking at you Elm and Angular.
- What features make this tool better than the alternatives? Does it do something extra? Or solve some problem other tools don't?
- Does it fit your team? If your team is mostly junior developers, for example, does the framework have good learning resources and documentation? If you have mostly functional programmers does the tool fit that paradigm?
- Is the documentation good? This is so important for being able to use the technology easily.
- How does the code look? Does the codebase look well written and maintainable?
- Is the library performant?
There's no singular right answer here -- if the technology works well for your team, it’s the right solution no matter what some thought leader says on Twitter.
How to stay up to date in the JavaScript world
Okay -- so now that we've discussed shiny object syndrome -- how can you stay up to date on the latest updates in a reasonable way?
- Follow JavaScript people on Twitter -- like @dan_abramov, @addyosmani, @getify, @wesbos, and @sarah_edo -- this is normally the quickest way to learn about new tech.
- News Sources -- I follow dev.to, CSS Tricks, Smashing Mag, and JavaScript Weekly as my main resources!
It's not actually not that spooky!
A quick reality check before finishing up this post, JavaScript isn't actually moving at the speed of light. React, Vue, and Angular have all been around for over four years, and so has ES6 which will probably be the largest change at once to JavaScript ever. There isn't actually a new popular framework every week. And even if there was, you don't have to learn that framework. The excellent parts of technologies are usually integrated into their competitors eventually anyways -- just look at how React inherited from Angular.js and then Angular inherited from React in turn -- and Vue learned from both!
Also, I think great that JavaScript and front-end development in general is evolving -- it needs to in order to make development easier and user experience better.
Hopefully, this post made the world of JavaScript a little less spooky and a little more accessible!
Bonus: JavaScript stuff I'm really excited about right now
Keep in Touch
For future readers this was written for a Halloween talk, hence the spooky theming!
I agree about having more fundamental JS knowledge coming in handy. I see JS frameworks having a multiplier effect - the more JS you know beforehand, the more the benefits of a JS framework will be multiplied.
One recent example is my work with the Ember framework at work. The framework gives good patterns for managing component state and related data to this state in their "controllers." But foundational JS knowledge helped me better see the limits in these controllers. A coworker used a combination of import/export, JS classes, and object-oriented programming to better abstract and manage some data complexity in a way that split the code more and made it reusable. It was standard JS used to make even better use of that framework.