How to get started with Frontend?
I was talking to a group of developers at the ReactFoo conference recently. There was a panel discussion on how important it is to understand the basics of JavaScript for somebody starting their career in Frontend. The popular belief is that one should know the basics of JavaScript well before they can jump onto any framework like React or Angular. The belief is strongly influenced by the fact that most UI developers today jump directly onto using React, Angular and Vue without understanding the basics well which in turn hurts code quality of the project and adds many bugs in production.
Though I feel in-depth knowledge of the language is needed to contribute to any serious JavaScript project, this expectation is a bit harsh on newcomers to Frontend technology. Since I am from India, I will use an analogy with a game of cricket to explain why I feel so. Doesn’t matter if you don’t understand cricket, you can consider this to be true for any game for that matter. We grew up in early nineties watching the God of Cricket, Sachin Tendulkar, hit the ball out of the stadium with such ease and style. He took Indian cricket to new heights. His influence was such that every other child wanted to be the next Sachin.
Every evening, we would have fun playing cricket with colony friends in the backyard. These two hours of fun time was something we would look forward to everyday. We all enjoyed the sport very much.
But not all of us jumped into learning professional cricket. Not many took to coaching classes on day one. We started with playing ‘Galli (backyard) cricket’ with homemade rules like under arm bowling, one tip one hand catch, ‘out’ if the ball goes for a six!! That too with a rubber ball instead of the hard leather one. The purpose was to have fun and enjoy the game. If twenty children played, hardly one or two got interested to dive further in and took professional coaching classes. This was where they learnt about the nuances of batting — Straight drive, Square cut, Pull shot, Flick. They learnt about how to Leg spin or Off spin the ball. In fact, they learnt about over arm bowling for the first time. When their interests and experience in the game grew further, they learnt advance game techniques like Googly and Yorker. Now rewind back to day one and imagine a little boy or girl who is super excited to play for the first time. What an adrenaline rush it is when they hold the bat and face a bowler. What a fun it is when they just hit the ball “somehow” and get off the mark!
Now reimagine the same first day when their team captain tells them “You know what, you have to know the basics of the game first, and only then can you play. Start with learning straight drive first, go to the corner of the ground alone and shadow practice the posture for a hundred times for the next one week. And only when you get it right should you play your first ball. Otherwise you will be a liability to the team rather than an asset.” The advice is great, but the timing is not. Of course, every player should know the basics of the game very well before they can start playing any professional tournament, but it’s not really the way to start it. That young mind will simply get overwhelmed and bored by the heap of dry rules and postures and leave the sport half way. Who could have been the next Sachin would just go off the field never to return.
This is the problem I see when I find a lot of senior JavaScript developers giving advice to young ones to learn the basics of the language first before jumping onto any framework like React, Angular or Vue. Of course, a great advice, but wrong timing for those new to the UI world. If you ask them to first learn about how prototypal inheritance works, how ‘this’ keyword works in JS, why not to use global variables, how to write clean code — they will soon lose all the interest and leave. These are good advices but dry. There is no fun in learning the intricacies of JavaScript until you are into it.
Why is it not a good advice to jump onto JS basics on day one?
Well, as a starter there is a significant amount of reason for that. JavaScript as a language that we know, was not designed to be a complete language in its initial stage. The first working prototype came out in less than 2 weeks. Its purpose was just to be a scripting language on the browser side. JS’s lifeline was very much unlike those of the more structured and feature rich languages like C, C++, Java and C#, to name a few. As and when more features where needed, they were kind of poured into the language vocabulary. There wasn’t really a defined evolution path for JS.
To add to the nightmare, different browser vendors had their own opinion on which features to support and which not to. Sometimes even the syntax differed for the same feature from browser to browser. That’s when ECMAScript standard was formed to normalize efforts from all browser manufacturers to reach a consensus and implement one way of doing things in JS. A lot of ideas were borrowed from more matured languages and added to JS, for instance the concept of a class, type safety, replacing var with let and const, arrow functions, decorators and many more. Many of these are still under consideration and yet to be added as a standard across browsers.
But the good part with most frameworks like React, Angular, Vue and Ember is that they lean forward and use these new features (or many times invent new features) before they become a part of the standard. The library communities even created frameworks to take care of all building blocks to create a complete site. Their cli makes it so easy and fun to get started. And this is where young guns should begin with. Just get a copy of the angular cli and build your hello world with a single command. Same with create-react-app cli. The tool spits out all files you need to get started. In fact, these sample apps showcase recommended coding practices. It’s a joy when you can just fire a command in terminal and see an entire site working in the browser. Imagine the pleasure and push it gives to beginners who never worked on JS, HTML and CSS before.
Now once the adrenaline settles, they will go through the code of each file and see how the code is structured. Of course, they will need guidance (through a mentor, blog, tutorials, etc.) to understand how these various modules in the app interact with each other. This newly acquired knowledge will now make much more sense since they are hooked up to the UI world. Let them have fun for a while. Let them play around. Now is the time to tell them to dig into basics of JS if they develop interest in the subject. In fact, if they are really interested, more often than not, you will not even have to ask them to dig deep into JS and CSS. They will themselves do it out of curiosity. Many might leave the game mid-way, may be the frontend world didn’t really spark off that interest in them. Nothing better than that if they can find what really interests them. They may find joy in backend technologies, databases, DevOps or even just not coding at all. Let them find out their spark.
Why do senior developers in the team advice to learn the basics first?
Because they have borne the brunt of poor-quality code written by a newbie who simply copied code from Stack Overflow without understanding it in the first place.
This, many a times, lands out of context for the given application causing failed business logic, hidden bugs, non-maintainable code, performance hits, memory leaks or something more dangerous that can give the entire team a nightmare for a week. Typically, if a fresh grad is hired into the team, he or she comes with a lot of enthusiasm to start contributing. The community support around React/Angular gets them excited, they read a getting started blog or tutorial and dive directly into adding features to production.
Since they had not gone deep into the basics of the language constructs, they do not understand a lot of corner cases and take help of ready-made code from Stack Overflow to u̶n̶d̶e̶r̶s̶t̶a̶n̶d̶ copy paste into project.
This is where the problem begins. Immediately after the release when the alien code is running in live, it inevitably causes bugs due to sheer scale of production site and all the corner cases a user might hit. Only if they had done their homework well before contributing to the project, then the live site would have been much healthier. Even if there are no bugs, an inexperienced developer mostly adds unreadable code which makes it difficult to maintain. And with repeated occurrences of similar cases, it gets obvious that understanding basics of JavaScript is more important than understanding any framework. And this is not just with language features of JS. Even advanced framework concepts are difficult to get in the first go. Talking of React, a newbie may not be able to grasp HOC, render props, Context, internals of Virtual DOM, life cycle methods and many more advanced topics, the first time. They will do the same mistake with code involving these features as well.
Is there a midway?
Indeed. Getting started on basics of JS is boring. Contributing without knowing the basics is harmful. So, find a midway. Let them get started with a framework. Give them a lesser impact project to work on — may be an internal tool. Excite them with framework capabilities. Then guide them towards more serious and important aspects of the language. Invest heavily in pair programming or code review in initial phase of contributions so that you can mentor them well and guarantee a cleaner code being pushed to production. Teach the importance of tests. Of course, before they start contributing to serious production apps all by themselves they must be thorough with the intricacies of the language and framework they use. All these require hard work by you, but it’s definitely worthwhile in the long run. Look at it this way, you are helping out somebody in their stepping stone to a glorious UI career.
Understanding JavaScript deep dive is necessary before getting your professional batch on. The concern is with the ordering of what to learn first, the basics of the language or having fun playing with frameworks. I feel the latter is a better start. Let that happen organically, don’t force it onto them.
Have fun first, deep dive will happen anyways.
