It was my first day on a new team and the expectations were high: I was joining to bring my design-driven front-end expertise to a new product that was still in beta testing. I had the typical first-day jitters, but I was nervous for another reason: On day one, I’d be jumping into our application built in Ember.js to help push this product out the door.
There was only one problem: I had never written a single line of Ember code before.
Then something changed.
My manager pulled me aside and told me to take the time that I need to ramp up on Ember. He didn’t expect me to start contributing right away. I would be given the time I need to learn the framework properly.
With that in mind, I decided to take a more structured approach to my learning. What could I do to learn this new framework faster and be able to meaningfully contribute more quickly? It turns out, there’s a whole lot you can do, and it goes beyond just learning Ember.js. After over a year of working in Ember, I’ve started to pick up React as well as we begin to build new projects in it.
Here’s how to learn a new JS framework:
- Read the framework’s introductory content (No, really—read it!)
- Do a Hello World tutorial
- Draw comparisons to frameworks you know
- Understand the codebase you will be working in
- Pair on a feature with someone more experienced than you
- Ask for feedback on your work
- Explore the community
- Don’t stop learning!
1. Read the framework’s introductory content (No, really—read it!)
- What was the original purpose of the framework?
- Why was it created?
- Who maintains it?
- What is the guiding philosophy?
These are the questions that the framework’s introduction can answer.
By dedicating 30 to 60 minutes to read the documentation’s introductory content, you’ll be briefed on the core concepts of the framework. These concepts will come up again and again as you learn to build with the framework. It’s important to learn and understand the underlying philosophy that guides a framework, because it will give you something to reference when making architectural and design decisions.
Take this sentence from the intro to Ember’s online documentation, for example: “[Ember provides] developers both with many features that are essential to manage complexity in modern web applications, as well as an integrated development toolkit that enables rapid iteration.”
Big difference! From just this sentence, we’ve learned that Ember attempts to be an all-in-one solution for building a web app, integrating all of the features a developer might need. In contrast, React puts its emphasis on flexibility and composability, emphasising its component-driven architecture.
By digging into these two example blurbs from the introductory documentation of Ember and React, it’s evident that they can give a lot away about the philosophy of the framework. Every design decision stems from the core philosophy, so understanding it is important.
In addition to understanding the core concepts, you will understand where the actual framework starts and ends. It’s important to have an understanding of what the framework consists of vs. what is part of the framework’s ecosystem. For example: React is often used with Redux, but Redux is not part of React. Understanding what is “React code” vs “Redux code” is important for a few reasons:
- You should know whether you need to import Redux or not
- When you have a question, you’ll know exactly which docs to reference to find information. This makes looking something up much faster.
2. Do a Hello World tutorial
It’s finally time to jump into some code! But I suggest holding off on fiddling around in the codebase that you’ll be working on. Instead, try a Hello World tutorial: the bare minimum needed to get an app up and running using the framework.
Some frameworks integrate a tutorial into their introductory content, so step 1 and 2 might be combined in some way. Either way, doing a JS tutorial means you’ll get to put the framework’s concepts into practice with some actual code.
Since you’ll likely be jumping into a project that has already been set up, try not to spend too much time on the setup and configuration aspect. Sometimes it’s worth skipping that altogether and starting with a project on CodePen or CodeSandbox. That way you can dive right into the code.
3. Draw comparisons to frameworks you already know
Once you’ve done a tutorial and written some code using the framework, you should have a good basis for how it feels to use it. You’ll know how to bind data to elements, add event listeners, and structure components. Although you’ve likely already been doing this subconsciously, now is a good time to think about how the framework compares to other frameworks and tools you may have used in the past.
Look for X vs Y posts to understand the new framework in the context of a framework you already know:
- If you’re using Vue, check out this comparison of Vue and other frameworks
- Or read this post about the differences between Ember and Angular
- Or check out a side by side comparison of React and Svelte
By comparing the framework you’re learning to a framework you already have experience in, you’ll be able to draw comparisons that will help you put the new framework in context. For example, if you’re new to React but have experience in Vue, you might compare a React component’s state object to a Vue component’s data function. Both hold information the component owns, and when the information is updated, the change is reflected in the template.
4. Understand the codebase you will be working in
By now, you’ve done your research and have written some code in the framework you’ll be using. It’s finally time to poke around the project you’ll be working on. This will make sure you are set up to learn the framework in the context that it’s being used.
- How are the project files structured? Where do components live? Do components exist in a single file or multiple files?
- What is the build process? Is there a command line tool?
- How is the CSS written? Is there a convention followed for class naming? Does the project use a CSS-in-JS solution?
- Outside of the framework itself, which additional tools or libraries does the project make use of? (A quick scan of the package.json file will give you some insight here. Make sure to do a search for any packages you’re not familiar with to at least know what they do!)
Understanding the way the project is structured and where different files are located is like building yourself a mental map of the project. To add detail to your map, make a couple of obvious changes in a random component and refresh the page to see the change reflected. For example, change the background color of an element or add some text. This will not only help you make sure that your local development environment is set up correctly, but will ensure that your assumptions about the way the project is structured and which files are which are accurate.
5. Pair on a feature with someone more experienced than you
And that’s the other thing: ask tons of questions! Most developers I’ve met love to answer them, so ask away. If the engineer seems to break a JS framework convention that you read about in the guide, ask why they chose to do it that way.
While you’re pairing, be sure to ask if there are any development tools they use that are outside of the code that’s in the project repo. For example, is there a specific browser extension they use to help debug? (Most frameworks have them!)
6. Ask for feedback on your work
When you start to work on a feature on your own, continuously ask for feedback. In my experience, asking for feedback on your work is one of the quickest ways to improve your code quality when learning a new technology. And this doesn’t just mean putting a pull request up for review. You should ask specific questions to indicate that you’re still learning and want to make sure you’re following best practices. Encourage your reviewers to be as nitpicky as they’d like, for the sake of your own learning. Here are some example feedback questions you can use:
- What would you have done differently?
- Am I following JS framework best practices here?
The answers to these questions will likely lead to larger discussions on code reusability and framework conventions, which means you will be able to apply your learnings to future situations outside of the current context of the code you wrote.
7. Explore the community
There are lots of ways to keep up with the community:
- Follow other developers who use the framework on Twitter
- Browse DEV.to and follow your favorite contributors
- Subscribe to a newsletter or RSS feed for updates on the framework and other blog posts written by the community. If the framework has an official newsletter, you should subscribe. Otherwise, find a third-party newsletter or blog that you can follow to stay up to date.
This not only helps you learn, but keeps you engaged: If you continually see new information, you’ll keep learning the framework top of mind and be more likely to stay involved in the community.
8. Don’t stop learning!
Frameworks come and go, but the skill of learning them will stay with you. That’s why focusing on your own learning and taking a structured approach will continue to benefit you as you advance in your career and face new technologies.