Javascript Fatigue
From a noob perspective
It seems like a lot of pro developers are exhausted with the state of Javascript programming as it stands in 2016. Recently this article showed up, which exhausts me just to (try to) read it. And Quincy Larson writes some encouragement to keep going for those who are fatigued by Javascript fatigue. Even Eric Clemmons wrote nearly a year ago about the exhaustion that comes with trying to efficiently build in Javascript (especially at scale) with all the frameworks, generators, boilerplates, APIs, etc., that have to be configured and maintained in any given development environment. I see lots of Medium articles and posts on Twitter either touting x as the next big flavor in Javascript development or lamenting disillusionment with the entire Javascript techosystem as hopelessly bloated and unnavigable.
This article is not going to tell you that [insert Angular, React, Node, Ember, etc.] is the [best/only] solution to your Javascript problems. Its also not going to tell you how to fix the over-saturation of less-than-optimal APIs. Why? Because I don’t have a solution to this problem, any more than many more experienced Javascript developers have been able to offer an adequate solution. (Perhaps this techosystem bloat is in indication that the nature of Javascript is such that it can’t be fixed, and we just have to pick the solution that best meets our needs, even if its not the most ideal solution.) No, this post is more of a rant or a “here’s my perspective on the matter, in case it helps anyone else who feels the same as I do” article.
Newbie Perspective
I’d like to start by making it clear who I am and who I’m not. I’m not a professional developer. I work in a pharmacy by day and I study web development daily in my free time. (I would like to score a dev position down the road, in case any recruiters are reading. *wink wink*) I have never used [again insert Angular, React, Node, Ember, npm, Bower, Browserify, etc.]. My experience with programming is mostly limited to HTML, CSS, Javascript, Ruby/Rails, and Bash, and I’d say I’m at a fairly basic level in each of them (with more proficiency going to HTML, CSS, and JS). That being said, I think a newbie perspective on this matter might be enlightening to more experienced developers who came to Javascript at a time when the techosystem was more simple and straightforward. So, here’s mine.
Javascript is intimidating, frightening, and claustrophobic. Not Javascript proper. Not even Javascript + jQuery. When I was researching where I should start learning web dev and asking people for their suggestions, the primary advice I got was: “Javascript is predominant in the industry, with Ruby on Rails not far behind. Focus on learning Javascript real well, and you’ll be well on your way to a dev job.” So I dove into learning some JS and jQuery, confident that I could expend all my study time focusing on one language until I could put together a decent public portfolio.
But taking that dive is a bit like jumping into Alice’s rabbit hole: from the outside you don’t see just how deep the rabbit hole goes. I started studying Javascript proper and supplementing with jQuery, but then I came across countless references to React, Angular, Ember, and so on. And I’d look at web-dev related job postings and see them noted as requirements for a lot of developer positions. Crap. That advice I was given a while back now seems way too simplistic. Now I need to know not only Javascript + jQuery, but also npm, Node, Angular/React/Ember, Bower, Browserify, Gulp, Grunt, Webpack, JSON, Babel, ES2016/ES6/ES5 (and the variations in functionality for each, so you can polyfill when necessary), Typescript, Flux, … *takes a deep breath*. Plus how to configure them, import modules, convert existing projects, etc. And I don’t even know where or how to get started. Or when to use which. Or even why a framework is important.
All of this creates an enormous mental claustrophobia of sorts — there are times when I feel like I’m in a cognitive mineshaft hundreds of feet underground and all the rock above me has collapsed. And learning each new technology is like clearing away some of the rock, but I won’t see sunlight again until I’ve learned all the APIs and frameworks. And I certainly can’t get a job as a web developer until I’ve padded my resume with all the requisite technologies and had a minimum of 3–5 years of experience with each (nevermind the fact that React has only existed since 2013) and built a portfolio that adequately showcases that I actually know how to leverage each technology.
Then the imposter syndrome sets in and that little voice in my head starts saying things like, “You’re never going to be able to learn all that stuff and be good enough at all of them to be a successful web developer”, or “The people who really know this stuff have masters degrees or a natural talent for it; you should just quit and do something you’re more naturally suited for.” And (honest confession): I’m terrified to take part in conversations on Gitter, web forums, Github, or (God forbid!) in person, for fear of asking the wrong question, or asking the right question the wrong way, or having a more experienced JSer condescend in response because my question is too “basic” for a public discussion (real comment on one of my StackOverflow questions):
As the current Question is presented, appears issue is described as “I’m still rather inexperienced with closures, event handlers, and this binding so maybe someone with more experience can shed some light on this for me.” See stackoverflow.com/help/how-to-ask
Github and Open Source Contributing
Let me switch gears here for a minute and discuss another observation I’ve noted that regards contributing to open source repositories. I’m a rather big fan of the philosophy of open source and I look forward to being able to contribute to OS. Many of the learning resources I use to study web development are themselves free and open source and in turn encourage their students to start contributing to projects that are meaningful or useful to them. Resources even exist to help noob contributors find good first-timer bugs to work on.
That’s great!, you say. Where’s the problem?
Let’s say I’ve perused the list of first-time bugs and found one tagged Javascript that I want to try to fix. So I go to the repo, peruse the README and CONTRIBUTING.md files and peruse the code base to get an idea of its structure. 9 times out of ten when I’ve attempted to make a contribution, I’ve been deterred from doing so before forking the project and digging into the code. Where am I being deterred? At the CONTRIBUTING or README (or similar) docs.
Let’s look deeper at why this is the case. Keep in mind that bugs labeled ‘first-time-only’, ‘low-hanging fruit’, ‘easy’, etc. are intended to be worked by contributors who have little or no experience working with collaborative projects. While it is not always the case, often someone who has little or no experience contributing and are drawn by those specific tags are also relatively new to learning programming in general. For the sake of argument, lets assume they’ve been learning Javascript for less than six months. They want to contribute, but the CONTRIBUTING file looks something like, “Fork the project, clone, rebase, branch, configure linter, install dependencies, install Gulp, install Bower, install more dependencies, start database, make your changes, run tests, commit, push, make a pull request, cross your fingers and pray to God someone doesn’t detect the stench of newbie on your code.” Now, is it realistic to expect that someone with less than 6 months of Javascript programming experience is going to understand or know how to do all those steps? Do you really think someone at that level of experience has even been exposed to any of those technologies? More importantly, are they going to understand what they’re doing and why in a way that will make them capable of wielding those same tools on their own? Probably not.
I’m not criticizing any individual repo or even repos in general for having dependencies and test suites and frameworks built in to their projects. I’m criticizing the techosystem of Javascript in general for allowing such a convoluted environment that it makes learning Javascript not exciting and enjoyable, but prohibitive and intimidating.
As a side note: My only critique of repos that do this is if the overhead time and effort for setting up an environment for contribution is not relatively straightforward for new developers, refrain from tagging issues with newbie-targeted tags. If you’re a repo maintainer and you’re tempted to label an issue ‘first-timer-only’ or similar, ask yourself first: is a first-time contributor going to understand how to install all the dependencies we require? Are they going to have been exposed to Angular/React/Ember enough to be able to navigate our code base to fix this error? If you can’t answer that question with a confident ‘yes’, don’t tag it for newbies. (For what it’s worth, this is the reason I stick to contributing only typo/grammatical changes.)
Help Newbies Out
For those of you who are experienced pros at Javascript, I’d like to challenge you to help newbies out. You may be someone who has been programming since Javascript was a baby, or you may have come to Javascript 8+ years ago when the Javascript techosystem was (mostly) limited to straight Javascript and jQuery. You are probably so immersed and fluent in the language that you have the curse of knowledge. You might have forgotten what its like to be a newbie struggling to wrap your brain around closures, this, or object prototyping. But I implore you to stop for a minute and remember what it was like when you were struggling through the basics of the language. Now, add to that struggle the weight of countless confusing and conflicting frameworks, test suites, APIs, modules, etc., that you’ve had the opportunity to tackle one by one after you were already fluent in the base language. Keep in mind that newbies coming to Javascript in 2016 don’t have that luxury: we face the daunting task of having to learn the base language and all the ‘extras’ in a big convoluted heap all at once. We face the dilemma of having a recruiter ask, “What are your thoughts on Ember/React/Angular?” and fearing that “I prefer the base functionality of pure Javascript” is an antiquated, unacceptable answer. So, remember what its like to struggle with the language and the frameworks, and be a mentor to someone less experienced.
In the meantime, lets acknowledge that we all suffer from Javascript fatigue at some point or another. Don’t be too hard on someone if they prefer different frameworks or APIs than you do (maybe they haven’t had a chance to learn your favorite yet), and try to help dig newbies out of the mineshaft so they, too, can see and feel the sunlight of Javascript like you do.
