I’ve been thinking a lot about the topic of “JavaScript Fatigue” and have had a number of exchanges with other developers about their opinions and, most importantly, their concerns. The post, How it feels to learn JavaScript in 2016, by Jose Aguinaga kicked off quite a bit of debate of what I feel has been a growing concern to the amount of tooling necessary to build web sites and applications. On one side you have many empathizing with the complexities of building JavaScript apps while the other voicing their support for the evolution of web development.
I tweeted out my perspective on what I think is causing so much angst and it seems to have resonated:
What I think is happening. Devlprs are freaking out cuz theyre looking at what they need to do to stay relevant & it’s hard to pick a route.
— Rey Bango (@reybango) October 4, 2016
Since I only had 140 chars to say that in, let me elaborate a bit.
The Good Old Days
What I mean by this is that many web developers who have been able to hang their hat on a specific technology for “x” years are incredibly concerned by the rate of churn in the JavaScript (and web development) world. They can’t just pick a specific framework and feel that they’ll be in a good spot for the next 5 years. And when you factor in the rate of churn on tooling and workflow technologies, you increase the anxiety of feeling “left behindâ€. I can totally relate to this and have voiced my concerns publicly.
Here are some examples from Twitter:
“@reybango The rest of us are looking for some GD stability. To, you know, make shit. For like a year or two, at least.â€
“Make all the analogies you want, but it’s willfully ignorant to claim the fragmentation & churn of JS tooling isn’t overwhelming to outsidersâ€
“@reybango for beginners i think it is easy, the old dogs, now they have to learn new tricks, difficult but not impossible. 1 step at a timeâ€
“@reybango reminds me society that buys cool shoes every season. Looks silly. Devs should just do their real stuff with less frameworks.â€
“@reybango also stacks keep changing so fast. I’m not a fan of constant “updates”, seems lazy, unplanned and bug-ridden.â€
This reinforces my thoughts that many developers want to be able to pick a route and feel assured that by learning it they’ll have some stability and a sense of relevancy for a decent period of time. I definitely think that’d be nice to have since the churn can be exhausting.
Evolution was Inevitable
John Shewchuk, VP & Technical Fellow at Microsoft, said it nicely in a thread I was on:
This is probably a side effect of the rate of innovation here – and this innovation is often leading other programming environments.
The evolution of tooling for complex web apps was inevitable. JavaScript development has been simplistic compared to other environments which is why it’s had such an attraction to many developers. It’s why so many developers who were used to comprehensive & mature environments would look at JS-development as a regression.
Quincy Larson, founder of Free Code Camp, said:
We are trying to build applications that run right in a dozen browsers, look good on thousands of different devices, load fast enough for impatient commuters in the subway, and are still accessible enough that blind people can use them.
And he’s absolutely right. Web applications are becoming more involved and developers are trying to meet the needs of these applications. This translates to the need for better and more feature-rich tools that are more easily able to solve complex problems. And in many cases, these tools are being built to fill the holes that deployment platforms are missing.
Embracing Evolution
As I’ve been going through the process of learning Node.js & Express, I’ve started to have a better understanding of why this new tooling is important. Like many developers, I’ve experienced the frustration of having to learn about so many new moving parts just to scaffold an application and at times cursed at having to work with so many different tools. But as I’ve continued on, I’ve started to get a better understanding of how and why they’re necessary and appreciate the functionality they provide. I’m not saying that I like having to use so many different tools to build an app but I will admit that I understand the need when you want to push the web forward.
You Don’t Have to Know Everything
A lot of the discomfort we’re feeling is the belief that we need to know how to use every new framework or tool that comes out. It’s really not the case. There will always be someone building a new tool or library and of course you’ll have the early adopters that will flock to it saying that it’s the cool thing that everyone should be using.
My colleague Bill Barnes really articulated this well:
This gets to an important and underappreciated soft skill of development, which is the ability to predict winners. More experienced developers consider a number of factors including:
- Industry trends (both in functionality and implementation)
- Aesthetics in API design
- Currency of maintenance
- Quality of contributors
Experienced developers can simply sense an emerging consensus faster than new developers.
I think the best thing we can do to help new developers is not just guiding them in what to learn, but also helping them understand what factors went into that choice. Let’s teach them to how to fish. And shop.
I agree with this assessment and it ties into the “you don’t have to know everything” statement.
My teammate Aaron Gustafson adds:
One other thing we haven’t really discussed (and was a central conceit of the piece that gets a little lost amid the absurdity) is that we are overcomplicating things. There are absolutely certain instances where an Angular or a React or any other framework or library can be the exact right tool for the job, but I think that folks building for the Web have a tendency to reach for a library or a framework immediately without actually asking if it’s needed. Without going too far down the React/Angular/Flavor of the Month rabbit hole, consider the ubiquity of jQuery. There are many web designers & developers out there who drop it into every project they build without a second though, never asking themselves why. It’s just part of their template. In many cases, the don’t need it.
He’s absolutely correct. We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from. The general consensus is that you should get good at plain ole JS, learn ES6, HTML, CSS and dive into at least one top framework. This gives you the foundational skills of web development that can be easily applied to almost any modern web project.
You Can’t Get Comfortable Anymore
I’ve changed my perspective on being comfortable. A part of me truly longs for the good old days of being able to just use jQuery, HTML & CSS to build a cross-browser site but I know that’s only because I’m comfortable with that stack. You can’t get comfortable if you want to work with JavaScript but you don’t have to know everything. And that’s the key thing that I think many developers need to hear.
I’ve personally chosen to learn Node.js/Express + React + Functional Programming to build apps because that seems to be the the emerging consensus of how to build modern web apps (thanks Bill). That will mean that I’ll need to learn the tooling that goes with it (uncomfortable) but I’m going into it feeling like I have good foundational skills and an understanding that it’s a continuous learning process.
Keep saying this as I learn Node/Express: "Don't stress the syntax, just learn the concepts & flow. Syntax will come with repetition."
— Rey Bango (@reybango) October 6, 2016
I know it can be hard but I’m here to tell you to keep at it. It does get easier with each step. Embrace being uncomfortable and learning new things because the things you’ll build with these new tools can be absolutely amazing.
I think this is a good insight. To me it comes down to this: Do I need to take shortcuts to get a product shipped, or do I do this “The Right Way ™” and write as lean code as possible, while having a clear mental model of the program while clearly documenting that model? When I choose the first, I get a product out, hence I get more money and status. When I choose the second, I invest in myself and my deeper understanding of not only JavaScript and not only programming but in logic, and working problems down. Both routes are necessary for different applications, it seems, in order to maintain a job in the industry while getting better at my skills.
Great perspective, Tyler! I especially love the “invest in myself” comment.
Great comment Tyler. I especially like the “invest in myself” part of it.
It’s difficult to solve real world problems with javascript. The lack of high level objects is a real issue, these objects exist in languages like Java & C# as part of the language. Most javascript people don’t know what they don’t know, and assume javascript is competitive in that respect.
Ignorance is sometimes bliss, but that doesn’t mean that you can’t get a lot done in javascript.
I’ve played around with node before there was express. I’ve been playing around with xhr before there was jquery. I truly confirm that it helps alot if you actually know what certain frameworks do. especially if you use a framework, for a problem, you tried or have solved yourself in the past.
I like ember since it’s built on top of the latest JavaScript / ecmascript spec so you don’t have to use typescript or similar but can use advanced language features of js that are not even implemented in most browsers yet.
I think what it comes down to is “get comfortable in the language, and you’ll never be too uncomfortable in other places.” If you’re comfortable in javascript, if you really and truly know your stuff, then your on-ramp for any of these tooling (etc) technologies becomes much, much shorter. When one knows the language, every point you make in this essay basically melts away. They understand how they would build the technologies they’re looking at, and they understand how (and when, and when not) to use those technologies.
To me, this conversation has always been part of a larger conversation (and I’m using JS here because we’re talking about web development): Because javascript has such a low barrier to entry, it’s very easy to make a nice living as a developer without ever really knowing the language. This is both good for developers to be able to find work at their local ad agency, but bad for team leaders, directors, CTOs etc who are looking to find quality people. If you’re looking for top-shelf people, it’s easy to go months, even as much as a year, before finding the right person. I’ve personally interviewed people who held architect jobs, who couldn’t animate a div across a screen without using jquery.
To borrow a bit from Tyler’s response, you need to know how to do your job The Right Wayâ„¢, even if your actual work means you’re doing the quick and dirty way most of the time.
You know what the biggest issue is for me? Long-term support.
When I write a system, my clients want to keep using it for as long as possible. They want to be still using it in five, even ten years time, and they want it to be maintainable for the duration. The want to be able to change the theme, add features, fix bugs and keep it secure for the full lifetime of the system.
Given that, how can I even consider developing it in a platform where the entire toolchain is being turned on its head every nine months? Where there isn’t any kind of smooth transition from one set of tools to another? And where support for the frameworks and libraries is regularly abandoned with little notice even by major industry players?
I’m fine with learning a new JavaScript framework every so often, but I need to be able to guarantee that those systems I’ve already written in the old framework are going to still be supportable without having to rewrite them every year.