It's 2013. Our small dev team is on the verge of shipping one of its most impressive client projects to date. I'm at my stand-up desk, skimming through early morning emails. My partner bursts through the office door:
"Something's wrong with our Angular app, man. I've got a
digest is already in progress error popping everywhere, and I can't figure out what's happening," he says, visibly nervous.
And I know all of this thanks to a small robot. Yup, you read that right: a robot.
Rewind to 2011.
But my friends and I had to build a soft real-time, task-oriented robot for one of our classes.
Many peers told me to just find a decent library for my use cases, and pull off some copy/pasting art to get the socket communication job done. And I could've done just that.
But I didn't. Although I didn't know it at the time, that was one of the best early career decisions I made.
In between managing my teammates' impatience and creating a not-so-clean, functional robot codebase, I learned a whole damn lot.
First, what do I mean by JS "frameworks" here?
When I use framework, I put all of the Angular, React, Backbone, Ember, Knockout, Vue, Ext, jQuery, Meteor, Express, Koa, Total, Socket.io, and so on, in the same box. Yes, I know some are quite different. Yes, I know some are "not really a framework, but more of a library and BTW have you seen this thread on HN?".
But please, for the sake of this article, let's declare them equivalent in their primary purpose.
Let me steal an answer from koenpeters on Stack Overflow:
Or, in our case, without additional, fancy frameworks.
"JS frameworks help you out by abstracting hard & complex code."
"JS frameworks help you ship code faster and increase development velocity."
"JS frameworks force you to focus on your app's value rather than its implementation."
These reasons quickly come up whenever we discuss the popularity of JS frameworks. But to me, they are marketing-ish reasons more than anything else. And I'm not ranting against frameworks here. I've actually used quite a few of them throughout my career (see list in previous section).
And I believe the greatest value there is to find in JS frameworks is collaboration. Their consistent interface and methods allow developers from, say, Canada, the US, and Brazil to understand one another and work together.
If you're building an app with [insert your favorite framework], when the time comes, you'll be able to find an experienced developer to hop in the project codebase with confidence. He or she'll be able to start tackling features without you needing to explain every part of your software architecture.
Another key reason to use frameworks is practice. They make you practice, over and over again. And that's good, really! Practice always leads to mastery, whatever you're trying to accomplish.
Why I believe JS frameworks are not THAT awesome
People who work on frameworks implementation are all talented—at least most of them. They do a tremendous job of turning complex things into easy stuff (e.g. providing ruthlessly simple client-side router in IE6). But all of these levels of abstraction can quickly become evil.
Sure, frameworks are useful for small teams working on a single app. Yes, they'll save you some time (unless you're a refactoring addict). But what if you have more than one team working on more than one app? Do you really think all team leaders will agree on a single framework for the whole suite of apps? And what if a new "cool kid" framework comes around in 2017?
Problem is: the moment you settle on a framework, you impact every single upcoming engineering decision. Plus, you chain your team to a technology that will probably soon be deprecated. This stuff blows my mind.
Just think about what "jQuery developers" are doing today: trying to catch up on Angular. Tomorrow, they'll be trying to catch up on React. And the sad, depressing loop goes on.
For me, it brought a lot of positive stuff:
- It helped me deliver a killer set of client features in a super short timeframe for an Ember app, without knowing jacksh*t about Ember.
- It got me a job offer from one of the tech giants because of a very simple library I wrote in my spare time.
- It made me identify bugs in libs implementation and suggest simple solutions really quickly.
So here's my TL;DR for you folks:
- If you don't know the underlying principles of the web, you'll eventually hit a wall thanks to the evolution of the language itself and the constant arrival of new frameworks.
- Knowing pure JS will make you a key engineer who can solve complex problems (reason before frantic searching).
- It'll make you versatile and productive, both on the front-end and back-end.
- It'll give you the toolset to innovate, not just execute.
- It’ll guide you on when to use a framework or not.
- It'll give you a better general understanding of how browsers and computers work.
Using a JS framework can surely bring you somewhere fast. But it won't bring you far if you don't understand the core concepts behind it. Just like learning to play Wonderwall on the guitar won’t teach you how to compose music, but it’ll give you a reason to practice.
And I strongly believe that this "learn the basics/roots first" principle applies to pretty much everything in life. From learning a new programming language to starting a new sport. It requires a lot of practice, but once you master it, the only thing left to do is to get creative with it. And that's where the real fun begins.
A word on getting started with vanilla JS
Always be curious, always read the source material, and always try it yourself.
And some more specific advice:
- Whenever a new JS lib or framework is trending on Echo JS, Hacker News or GitHub, go on and read the sources.
- Every time you write a piece of code, try to think of a plain JS solution that could fit your needs instead of instantly seeking for a lib to integrate.
- Go on Stack Overflow and challenge yourself to answer vanilla JS questions on your own.
Enjoyed the post? Take a second to share it on Twitter! And hit the comments section for questions/suggestions/insults!