Should You Learn [Insert Shiny New Tool]?

Oh look! Everyone is talking about Webpack! Should I upgrade my workflow to use Webpack?!

“Hmmmmm… Maaaybe I should use PostCSS because expert X highly recommends it. I can’t decide…”

“OH WOW. FACEBOOK USES REACT! REACT MUST BE HAWT! I NEED TO LEARN THAT TOO!”

Sounds familiar? I wouldn't be surprised if they do! New tools pop up in the front-end world incredibly quickly. Whenever something new pops up, people scream about how cool it is. Even industry experts begin using them. Heck, the experts you love and follow may even recommend you to use them!

Do you feel pressured to try all the new tools? Do you feel like a shitty developer if you don’t keep up with the latest tools?

If you do, you’re not alone!

Today, I want to share a simple framework to help you decide if you should learn/switch to [insert shiny tool]. Read on if this sounds interesting to you!

It’s simple. There are five steps:

1. Figure out what [insert tool] does
2. Figure out why your current tool sucks
3. Determine if the new tool is worth the investment
4. Learn it (if it’s worth it)
5. Differentiate opinions from facts

Step 1: What does [insert tool] do?

The first step is to understand what the tool does on a high level. You’ll want to answer these three questions:

1. What does the tool do?
2. What’s so awesome about it?
3. What sucks about it?

More often than not, all you need is a little bit of research to tell what the tool does. The various articles you see in your favorite newsletters and on your social media should be enough to help you through this step.

If you want to, you can dig a little deeper to find out what’s awesome and what sucks about it.

Want some examples? Here we go...

PostCSS:

• What it does: It transforms your CSS so you write lesser code.
• Special power: Write less code + use new CSS things! Yay!
• Sucky areas: Need to evaluate possible plugins.

Webpack:

• What it does: Huge asset bundler with lots of options. Almost like a generic task runner, but specialized for asset bundling. Oh, and there’s a server thingy too.
• Special power: Hot-reload!
• Sucky areas: Hard to understand and configure.

Gulp:

• What it does: Generic task runner that can automate evergthing!
• Special power: Extremely flexible and configurable.
• Sucky areas: Have to wait for maintainers to update their gulp plugins when new versions get released.

React:

• What it does: A special kind of template engine with performance improvements in the browser.
• Special power: Can be used to make amazing + complex apps when combined with React Router and Redux.
• Sucky areas: Shitloads to learn!

Right, the comments are probably a little too short and doesn’t do any of the above tools justice. That's the point — you don’t need to be/can't possibly be an expert in any of these tools at this stage!

Step 2: What's wrong with your current tool?

What about your current workflow makes you unhappy?

• Do you hate PHP? 😆
• Do you hate manually copy/pasting files?
• Do you hate writing JavaScript callbacks?
• Do you hate downloading libraries manually?
• Do you hate stressful deployment situations?

What do you hate about your development processes right now? Once you know what you hate/want to improve, you’ll be able to evaluate tools much more effectively.

For example, let’s say you build amazing Wordpress websites.

If you want to improve your CSS authoring processes, you may want to add Sass or even PostCSS into your workflow.

If you want to use the latest enhancements in JavaScript, you may want to add Babel (or Webpack or Rollup, depending on whether you need to import node packages).

If you’re unhappy with triggering workflows separately, you may want to use Gulp or npm scripts to trigger a chain of build commands for you!

Do you need React, React Router, or even Redux? They don't really fit, do they? See how it becomes much easier once you know what you want to change?

On the flipside, you can’t always tell if a tool is what you need from your current workflow. Sometimes, you need something completely new. Here’s an example:

Let’s say you're familiar with building websites with Wordpress, and you want to learn to build webapps. However, you don’t want to use Wordpress to build your webapp. Maybe you want to use Node (with Express), Python (with Django) or Ruby (with Rails).

Each stack mentioned here works with a completely different (but strangely similar) process and often uses different tools. Understanding these constraints will help you find the most suitable new tools.

Step 3: Is it worth your investment?

Time is the most precious resource you’ll ever have. You want to consider whether it’s worth it to spend time on [insert shiny tool]. Of course, besides time, you also want to make sure you keep your sanity without adding too much unnecessary risks to your projects.

Here are some things you can consider:

1. Will [insert tool] help you reduce errors
2. Will [insert tool] help you write better code?
3. Will [insert tool] prevent stressful deployment situations?
4. Will [insert tool] help improve your new process?
5. Will [insert tool] shorten the development time ( in contrast to your sucky process)?
6. How long do you have to learn [insert tool]?
7. How much can you afford to spend on learning [insert tool]?
8. Is it worth the risk to change to [insert tool] now?

Try to consider all the different possibilitie before you make an decision. Ultimately, what you base your decision on is entirely up to you.

1. It’s okay to change because you want to learn something new.
2. It’s okay to change because the expert you admire tells you to do so.
3. It’s okay to change because you hate your sucky processes right now.

Just remember it’s also okay not to change. There’s no need to feel pressured into changing something that doesn't need to be changed. If you’re building a website with Wordpress right now, and it's working fine, you don't need to shift to a static site generator unless that’s what you want to do.

Don’t worry about what others say. It’s your project. (Of course, talk it through with your team if you have a team!)

Step 4: Learn and implement

If you decide to learn [insert tool], don’t learn halfheartedly. Make sure nothing stops you until you’re equipped with all the knowledge you need (Of course, you should have a reasonable definition of "all the knowledge you need").

When you're really trying to learn something deeply, reading articles on the Internet is most likely not enough. You need to experiment and try new things on your own.

Sometimes, it helps to buy books and enroll in courses that teach the subject more in-depth. They will bring you to where you need to be in half the time.

• Want a CSS layouts course? Consider Rachel Andrew’s CSS Layout Workshop.
• Want to learn ES6? Consider Codementor’s ES6 for everyone.
• Want to learn take your JavaScript to the next level? Consider Josh David Miller's JavaScript Master Class
• Want to learn Animations? Consider signing up for Sarah Drasner and Val head’s web animation workshop.
• Want to learn accessibility? Consider Heydon Pickering’s Smashing mag book, inclusive design patterns.

A lot of these courses allow you to take classes at your own pace. Some of these are highly participatory live classes!

There are tons of books and courses that were created by experts. These books an courses are often quite intense because these experts try to pack all their related knowledge into this one book or course. They're not easy, but you could get up to speed in one short month (as opposed to banging your head on the wall for months and years even).

Now, if you (unfortunately) read a book or took a course that’s not all that helpful, don’t let that lousy experience stop you from learning [insert tool]!

When I started learning Gulp, I bought a book to help me with it. Unfortunately, the book was pretty much a copy of the docs (I know...why did I buy the book in the first place? 😑). Though the book was quite useless, I kept going, and learned a ton from different sources. Now, I use Gulp to automate looooots of stuff!
(And because that book sucked, I wrote another one that’s pretty amazing. Shameless plug! 😜)

Oh! While we’re at it (with shameless plugs), I’m releasing my latest course, Mastering Responsive Typography, next week. It’s a course for front-end developers who want to build beautiful websites and good typography with hacky CSS. Check it out if you geek out in web typography.

Finally! One more step!

Step 5: Differentiate opinions from facts

There are tons of opinions floating around on the Internet (even offline, too!). If you’re not careful, you might succumb to opinions that lead you astray instead of helping you out!

Let me explain by using PostCSS as an example.

If you've heard of PostCSS, you might've wanted to switch from Sass to PostCSS (if you use Sass) at some point. Where did this thought come from?

Maybe you read somewhere that you need to reduce dependencies as much as possible? Sure, the argument may be valid, but where’s the fun in that if you can’t use your favorite Sass libraries like Susy or Typi?! 😉

Or maybe you were misled to believe you must choose between Sass and PostCSS? If that's you, you should probably do a little more homework 😝. You don’t need to choose between them. You can use both of them at the same time — the tool chain looks like this:

Sass -> CSS -> PostCSS -> Final Output (CSS)

Well, maybe PostCSS will replace Sass some day. Maybe, just maybe. But until then, you can use both of them.
One more thing. Don’t blindly choose plugins/tools based on how they're advertised. One example I frown upon is the CSSNext PostCSS plugin.

Don’t get me wrong. CSSNext is great and awesome. There’s only one thing I hate. It claims you can use CSS Variables in your code, but outputs pure values that have nothing to do with CSS Variables! 😡

Wrapping up

That's it!

There’s really no need to feel pressured to change into [shiny new tool]. This “I need to keep up!” pressure causes too much burnout, and it’s probably the origin of the whole JavaScript fatigue thing (did you know that’s a thing?!).

What you can do instead is to evaluate whether you even need [shiny new thing]. Find a good reason to switch (or not switch) and stick by that decision.

If you decide to switch, make sure you learn everything you can. Don’t learn anything halfheartedly because it’ll only do more harm in the long run.
Finally, thanks for being a developer. You’re one of the most wonderful people on the planet that make dreams come true! 💥💥💥

Author's Bio:

Zell writes tutorials to help designers and developers gain knowledge and confidence to build awesome things. He mostly writes tutorials about front-end and back-end development (mostly HTML, CSS, and JavaScript related). You can explore his blog, his libraries, and his books.

This tutorial was originally posted by the author on his blog. This version has been edited for clarity and may appear different from the original post.