This is a common question among new developers, and it’s a good one to think about. On one hand, robust applications are often built using front-end frameworks. If you want to start building robust apps, it would make sense to cut to the chase and learn the framework.
On the other hand, Javascript is the foundation of all of these frameworks. Maybe it’s good to have some knowledge of that foundation before you try to learn something that’s built on top of that.
When I was getting started in web development, front-end frameworks didn’t have the same mindshare they do now, but I did have to make a similar decision. I had to decide if I should learn vanilla Javascript or jQuery. Here’s what I ended up doing and how it worked out for me.
My "Cart Before the Horse" Story
For anyone who doesn’t know, jQuery is a library that makes working with the DOM (the document object model) in Javascript easier. It also smoothed over a lot of browser compatibility issues that were a real pain to deal with 5-10 years ago. It’s not so relevant these days since we rarely need to support those old browsers with our new builds.
It was so widespread that, even today — well past the peak of its relevance — it’s estimated to be in use on 88% of the top 10,000 web sites. I was eager to get started building, so I decided to learn how to use jQuery with a very rudimentary understanding of Javascript.
This did allow me to get to work much more quickly. Since I could select elements and manipulate the DOM easily with CSS selectors and without having to worry about browser quirks, it let me dive right in. It worked out pretty well… until I had a problem.
An Incomplete Toolset
I didn’t understand a lot of what jQuery was doing because I didn’t have that foundational Javascript knowledge. Why am I calling methods by chaining them off the original element I selected (and how does that actually work)? What is this? If I select an element and assign it to a variable inside a function, why can’t I use that outside the function?
So, even though my toolset seemed adequate while everything was working as expected, as soon as I went off-script, I would inevitably hit a problem I just didn’t have the tools to solve. It meant I could code myself into a lot of problems that I couldn’t get out of. It made me a worse developer because I was trying to take this shortcut to reduce the time it took me to become productive. Instead, it was reducing my productivity.
Righting the Wrong
When I recommitted myself to web development a few years later, I realized this decision had stunted my growth. At the same time, the browsers causing many of the issues jQuery solved were becoming obsolete. I decided to properly learn Javascript.
Not only did this make me a better jQuery developer, but it made me a better developer overall. I understand what’s going on behind the scenes with jQuery, so I can much more easily debug and solve problems when I use it. I can also make a conscious choice not to use it when that makes more sense. Before, that wasn’t an option for me.
Hey there. 👋 All the technical knowledge in the world won’t make you a web developer. I help you bridge the gap between “I know how to build web sites,” and “I get paid to build web sites.” Sign up for a free 30-minute mentoring session at Rad Devon.
What Should You Learn First?
I can’t fault you for wanting to learn React, Angular, or Vue before you really have a good grasp on Javascript. After all, I did virtually the same thing years ago. It seems like you’ll be able to get started on the projects you really want to work on. In practice you’re setting yourself up for a lot of frustration and ultimately failure.
What I’d recommend instead is, if you have a project that you feel needs a framework, either scale back to a smaller project or build a smaller chunk of your existing project with vanilla Javascript. You’ll get your foundational knowledge, and you can always retrofit the project with the framework of your choice later.
Taking things a little slower now, at the beginning of your learning journey will pave the way for you to pick up serious momentum in a few months, once you have the basics down. For the impatient among us, it can be excruciating, but the payoff is worth it. Start with vanilla Javascript, and you’ll be a better developer.
Top comments (17)
I agree with the idea... There are a lot of new developers that go through boot camps or learn on their own and pass quickly over the basic technologies (HTML, CSS, JavaScript) so that they can go straight to frameworks: Bootstrap, jQuery, React, Angular, etc. And that's a valid approach as long as they plan for getting the basics covered along the way.
On the other hand, I think people like you and I had the "unfair" advantage of seeing front-end development evolve into the current state. We grew as developers together with the Web itself. We didn't have to play catch-up as much as new people do today.
Felt the same with catching up when trying out React with JS knowledge but not much ES6:
Oh it uses classes like OOP languages, neat. Let me learn how objects are instantiated in ES6 and the
this... Oh it has functional components too, check. So time for arrow functions and nothis... Now hooks are in the mix too so object destructuring... I want to know React but ES6 has somewhat deepened the learning curve (for me).Yet not all code examples on the web use the same convention or are the most updated. And the build tools are more things to get a hold of. I had to switch mindsets here and there, looking up stuff again and again. It's not so easy to focus and get the gist of React.
Story time!
I worked on a project last year with unique challenges. The short description is: it was a Web API "hub" with many terminals coming off of it. We packaged up entire webpages and sent them down to the clients, which would then send REST commands back to the hub and work. Think old school Client/Server architecture (Though this was about a year ago lol).
Everything that ran in the browser had to be downloaded. Every. Single. File. had to be put into a byte stream and sent.
Size was everything here, and it needed to be fast, and work with poor network connections.
When I started on the project we were using jQuery and Angular. It was minified and sent over the wire on each connection to the hub. Connects and disconnects happened frequently. It was too slow and there was too much traffic being sent over the network.
I ended up refactoring the application with vanilla JavaScript and cut the size down to a minuscule fraction of what it was. I swapped out the jquery stuff with vanilla JS and built a smart framework for it so we didn't need Angular. It ended up being all pure JS. This improved performance greatly. Kilobytes instead of Megabytes.
The point of my rambling here is: There is a place for jQuery (even in 2019) and there's a place for Angular/React/Vue etc. However:
Having the ability to swap things out with Vanilla JS and do the same thing if needed is a very powerful skill to have in your toolbox.
There are times when re-writing everything in JS is a terrible call. You could be just reinventing the wheel and creating catastrophic problems. There are also times when it's a really elegant way to make a system better.
I always jump in first without fundamental knowledge and circle back to fill in those gaps, and that's how I mentor juniors.
I don't think either approach is better than the other.
I think as mentors its easy for us to look back at our journey and say this is what works for me and since its producing positive results when I mentor others it must be the true path.
I think people need to find the mentor they'll stick with no matter the methodology until they can walk on their own.
I agree with the meat of your reply. Definitely if you spend too much time learning the fundamentals without any way to apply them, it's a waste. In the same way, if you spend too much time trying to brute force building something in a framework when you don't understand the underpinnings, a lot of that time is wasted. I think there's a nice balance where you're switching back and forth between the two approaches.
Learning jQuery before understanding Javascript first did work for me, but I'm not sure I'd recommend it. I can see lots of places where I struggled that I wouldn't have had to and where finding the solution didn't lead to much learning because my mental model had so many gaps.
The secret is to scale back what you want to build for your first few builds and fit it into vanilla JS. That way, you're not just learning vanilla JS for the sake of it. You've got a way to start applying it immediately. Graduate to your framework and the bigger app once you've built a couple in that space.
Not to suggest you can't still succeed by flipping this method on its head. That's what I originally did and it worked out fine in the end.
Thanks for reading and taking time to share your thoughts, Andrew.
I think the answer is: both. The difficulty with vanilla is that it's abstract, and people struggle to relate the abstract back to something they want to do or achieve. If you can do both in tandem, that's best. I do agree that you're going to hit a wall quickly without understanding the basics, but I've come to appreciate that there needs to be a desire to learn, and that often comes from implementing something practical and real.
That's exactly what I was going to say. There are a lot of good points in the article. But I feel that the discussion always gets framed as an either/or question when the answer should really be both/and. You can learn all the basics before you start learning a library/framework, but if you stop learning vanilla JS altogether to switch over, you'll stop progressing as a JavaScript developer.
The real crippling thing is to stop learning vanilla when you start learning a framework. But I see no problem in learning one alongside the other. And I frankly think that you can add a framework/library to your learning fairly soon.
I don't think frameworks are absolutely necessary in order to build a scalable, manageable application. I think developers tend to associate frameworks with scale and complexity and a prerequisite to building something meaningful, but that is wrong and not a good approach.
Vanilla JS is amazing these days and can do so much without the need for a framework. I think developers should learn design patterns on top of fundamentals.
It's "Think for Yourself" vs "Reinvent the Wheel." They are completely different things.
Most def. learn JS first. Then some simple framework that is almost pure js (i recommend Backbone.js). After you get fluent in basics and know how to decide when to use frameworks (abstractions), only then learn them.
I see far too many devs that are basically crippled to one true to them framework. They have a hammer and see a nail even in a business card page.
I recently left a project and the new developers were asking where the react files and why I didn't use it.
My response was I used libraries where needed because it was todo with image manipulation which is outside my scope of understanding, the only JS left was showing and hiding elements.
I'm new to this and a freelancer but my previous career taught me to use the right tool for the job and in my limited experience already I'm realising too many people had a sledgehammer to hammer a small nail in mentality!!
Wow, i wrote my comment before reading yours, and we even used the same analogy.
Amazing, how the experiences can be similar when dealing with frameworkloverz :-)
Vanilla before framework... I have dealt with enough JQuery experts who didn't have even basic understanding of how javascript works. And a lot of them are stuck with old low paying jobs because they refused to update their skills and Angular, React etc took over.
Whatever language you choose, forget frameworks, learn the fundamentals of programming.
Learn how to structure data.
How to access that data.
How to loop through it.
How to manipulate it.
How to sort it on different values.
How to find data by different values.
How to filter the data.
etc.
My standard answer to that question is similar:
Get the basics of vanilla js right and then dive into a framework of your choice.
Without those basics, understanding the framework will be much more difficult, but going beyond them will only marginally help.