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-en...
For further actions, you may consider blocking this person and/or reporting abuse
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.
A common thread it seems is that knowing a framework means you know how to build an app. I'm not sure that is true at all.
As a beginner I wanted to side step the question of vanilla Vs framework and learn how to build an app that is robust, future proof and meets user needs.
I definitely agree with this. However, I feel there is a middle-ground between understanding the fundamentals of what you're working on and just getting something out there, even without fully understanding every underlying piece of code. As Jobs once said, "Real artists ship."
I built my first complex production-grade app with Laravel PHP. I had some understanding of PHP before I started, creating some simpler apps. Then, as I scaled up my Laravel knowledge, I found I had to scale up my PHP knowledge to fill in the gaps that Laravel didn't cover.
I guess in my experience, learning isn't so linear, but hopefully you eventually end where you want to be.
I agree with you 100%, Joe. Don't stay in vanilla JS (or anything, for that matter) until you have 100% mastery.
Thanks for reading!