Ignore the Noise

Whether you’re new to the JavaScript ecosystem or have some experience, unless you’re super-human, you’ll inevitably become overwhelmed at the sheer number of frameworks, libraries, build systems, preprocessors, template engines (the list goes on and on) that are available.

What’s worse, as you put a significant chunk of time into a certain stack, there will inevitably be other libraries, frameworks, and tools that gain more popularity than the ones you chose, and likely brand new projects that became the shiny new thing while you were busy getting things done. Before long, you start to feel like you’re suddenly becoming irrelevant.

Joe Gregorio argued in 2014 that we should abandon all frameworks in favor of plain HTML+CSS+JS in his zero framework manifesto:

I think it’s time to rethink the model of JS frameworks. There’s no need to invent yet another way to do something, just use HTML+CSS+JS.

The landscape has only gotten more cluttered since then, so I don’t think the web development community as a whole agrees, probably because that approach may not be practical for everyone and for every project. Still, I think it’s a good starting point. More on that later.

A couple of years ago, I invested quite a bit of time into Backbone.Marionette, and once I had some breathing room and took a step back, I saw that Angular was actually the cool kid on the block. I also used Less and Handlebars (for CSS preprocessing and HTML templating, respectively), although tons of shops prefer Sass and there are many other popular alternatives to Handlebars. It’s easy to feel like you’re not keeping up, and that your skills will soon become irrelevant if you’re not sprinting at top-speed, 24 hours a day. Unfortunately, no matter what you do, at least when it comes to web development, you’re going to be “behind” in one way or another.

All this to say: it doesn’t matter. Ignore the noise.

But that begs the question, how can you determine what path to choose when there’s this vast sea of choices out there? Fortunately, depending on your personal situation, there’s a way through this.

Your Own Projects

For personal projects where you have complete control over your technology stack, I recommend starting with just plain HTML+CSS+JS (which have standards that don’t become outdated very frequently), and only add libraries that fit your needs—as needed. In other words, let the requirements of your project determine its dependencies. If you do want to go with a full-blown framework, take a look at some of the more popular and stable options out there and just go with the one that matches you and your project best and proceed full steam ahead.

Don’t worry about falling behind. Just do some research, choose something, and move forward with with your decisions. The important thing to remember here is that you don’t need to be a pro at everything, or worry if you chose the best thing out there (that’ll change anyway, and probably next week). You’ll end up learning a ton about your chosen stack and that experience alone will be valuable.

I mentioned research, but it’s worth emphasizing. Last year, Jimmy Breck-Mckye wrote about the “State of JavaScript in 2015” and cited “framework churn” as a major problem. Angular, one of the most popular front-end JavaScript frameworks, was used as an example:

At the close of 2014, it’s difficult as a JavaScript developer to back a particular library or technology with confidence. Even the mighty Angular, which seemed set to establish itself as the One True Framework of Single Page Applications, looks destabilized by recent events.

I’m not in the Angular camp, at least not currently, so I have no comment on that in particular, but it’s an interesting perspective from someone who obviously was.

I personally tend to favor the “pick and choose small libraries to fit your needs” over the the “one size fits all” approach of monolithic frameworks, but your mileage (and requirements) may vary. If you do go the monolithic framework route, it’s worth making sure what you choose is actively maintained and has a healthy community around it—unless of course, you plan on maintaining it yourself, which is probably not likely.

Work Requirements

If you’re employed and your company has chosen the stack for you, then you already have your answer. If you don’t have a say-so, you don’t need to worry about drowning in choices because you won’t have one! Spend time learning and improving your skills in Marionette, Angular, React, Backbone or whatever it is your company uses. With your own time, you can choose to develop other skills or improve on your work-mandated ones.

On the other hand, if you’re in a position to have some say in these kinds of decisions, then tackle it as you would with your own projects. Research the actively developed, mature options out there and choose the frameworks and/or libraries that fit your project and team best, ignoring the others (no matter how new and shiny they are) until there’s a problem you can’t solve—or solve well—with the decisions you’ve made.

Developer for Hire

The more difficult scenario is if you’re trying to build up your skills in hopes of getting hired as a JavaScript engineer, and need to decide what the best course of action is to achieve your goal. Unless there’s a specific role you’re targeting, in which case what to learn should be a little more clear, I recommend starting your own open-source project, making it public, and stick with it through completion. When you’re done, you can always choose a different stack for your next project, swap out the pieces that didn’t work well for you, and go from there. Over time, you’ll gain some valuable experience and you’ll not only know enough to be relevant, you’ll be agile enough to adapt to any other stack that’s thrown your way by a future employer. Without a doubt, doing is the best way to learn anything, and that absolutely applies in this field.

Make a Choice

Today, as JavaScript developers, we are flooded with choice. Fortunately, if you can block out the excessive noise and commit to making some decisions, you’ll find that having an abundance of choices can actually be a benefit: there is something for just about anyone, and any project you can think of. The worst choice you can make is no choice at all, allowing decision paralysis to prevent you from getting any meaningful work done out of fear you’ll make the wrong choices and waste a bunch of time.

Don’t fall into that trap. Make decisions. Stick with them. Adapt as needed. Keep moving forward. That is how to stay relevant as a JavaScript developer in today’s tumultuous environment.

To read more entries, visit the archives or subscribe to the RSS feed.