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.
I felt like I had to prove myself right away, otherwise what value was I providing to the team? I tried to jump right in. Since I have experience working in other Javascript frameworks and a strong vanilla JS background, I figured I could tough my way through it. But the task was still daunting.
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.
I was relieved and energized. I knew that ActiveCampaign championed a culture of learning, but this was one of the first times that I really felt what that meant. The people here understand that everyone can’t be an expert at everything. If you need to learn something new, you’re given the space to do so. It also turns out that learning a new Javascript framework is pretty common at ActiveCampaign since we employ a number of front-end frameworks across different parts of our application. From Ember to Vue to React, it’s likely that a front-end engineer working here will touch code in at least one Javascript framework at some point.
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.
I’ve realized that there are certain things you can do to learn a framework that aren’t specific to that framework—they can help you learn any front-end framework. While I’m still learning every day, I feel that my approach to learning a new Javascript framework has paid off. Feel free to pick and choose to create a plan that works for you, but in this post, I’ll share what I’ve found helpful.
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!)
If this sounds obvious, it’s because it is. But it’s worth noting, because it’s tempting to want to jump into some code without reading the basics. Each Javascript framework has a different guiding philosophy and takes a slightly unique approach to building web apps:
- 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.”
Now compare that to this quote from React’s intro: “React is a declarative, efficient, and flexible JavaScript library for building user interfaces. It lets you compose complex UIs from small and isolated pieces of code called “components”.”
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.
Only you know how you learn best, so the type of Javascript tutorial is important here. Do you prefer to follow along with a video series or a written tutorial? Would you rather start from a project template or from scratch? There’s a tutorial for you no matter which way you prefer to learn.
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.
Your teammates will likely be a huge resource to you here. They should be able to help you get the project set up as well as give you a tour. Still, it’s worth exploring on your own. Here are some Javascript FAQs to ponder as you familiarize yourself with the code:
- 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
Ask to shadow or pair with a Javascript engineer to get some first-hand experience working on a bug or feature. This is likely how you’ll learn the fastest, and you’ll already be armed with a basic understanding of how the framework operates, giving you the chance to ask questions that will make sense.
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?
- As someone who is still learning this Javascript framework and codebase, how can I make this better?
- 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
Once you have a handle on the framework and codebase you’re working in, it’s easy to get wrapped up in it and forget to continue learning. Don’t forget about the community! No matter the size or popularity, you’re sure to find that each Javascript framework has a community of people writing blog posts and sharing code. By keeping up with the community, you’ll not only continue learning, but learn new ideas and concepts that you can eventually bring into your own projects.
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.
If there’s one thing I could tell my past self on my first day on a new team with zero Ember knowledge, it would be to have confidence in your ability to learn. It might take time, but learning a new Javascript framework isn’t as impossible as it might seem. And when you’re surrounded by a culture of engineers and managers who value and—more importantly—invest in your growth, there’s no telling what you’ll be able to accomplish.