Maybe JavaScript Fatigue makes you scream too.

Are you annoyed with the constantly changing JavaScript environment?  Do you wish things could just settle down for a bit?  Have you decided that you won’t learn anything new because there will just be something new to learn tomorrow?

Welcome to JavaScript Fatigue.

But frankly, unlike many people who talk about JavaScript Fatigue, I see JavaScript Fatigue and the much broader subject of language fatigue as a symptom of a much larger problem that has less to do with JavaScript and more to do with human psychology and the state of the programming community at large.

What is JavaScript Fatigue

JavaScript Fatigue is the belief that there are so many ways of assembling a JavaScript project that instead of just having to learn JavaScript, you have to learn several other related technologies. It is in essence, more about decision overload than it is about JavaScript specifically.

Think about the average JavaScript project that goes beyond the (now) old school “Augment my form with some jQuery.”

Here are a sample of decisions that need to be made:

• Should you use a JavaScript framework, or just write native JavaScript?
• If you decide to use a framework, which one should you use?
• What tool(s) will you use to bundle, minify, cache bust, and tree shake your code?
• Should you bother lazy loading?
• Will you use MVVM, MVC, Redux or something else as a basic architecture?
• How do you plan on dealing with AJAX calls? Callback hell? Promises? RxJS? Something yet to be created?
• What directory structure will you use?
• What component libraries will you use?
• How will you style your application? Raw CSS? Bootstrap? Material Design?
• What development environment will you use?
• Oh and by the way, to use most of these tools you’ll need to learn node and may need to decide between NPM and YARN.

I recently heard that for a basic React application there are about 40 different decisions of this kind that need to be made.

Why JavaScript Fatigue Is Considered a Problem

If you are working on your own, or working in a small shop without any clear architectural direction, the choices can seem overwhelming.

For that matter, if you are an architect, this is still a pretty long list of things that you need to learn well enough to evaluate.

But the reason JavaScript fatigue is a problem is because it triggers emotions of fear, anger, and depression.

It all starts with fear. You look at all the stuff that you “need to learn” and think, “I can’t possibly learn all of that. And even if I do, there will be something newer tomorrow that I’ll need to learn.”

And so your fear turns to anger. I’m not talking rage kind of anger. Just that mild, “I’m not in control here and I’m feeling a bit uncomfortable” kind of anger. And this point, the next most logical thing most of us attempt to do is to try to get some sort of control over the situation. But in this case, the beast can’t be tamed. So, we resign ourselves to the situation and decide that since we can’t control any of it, we’ll give it a name and in really extreme situations give up learning any of it.

Yes, I’ve actually read comments and had conversations with people who have told me as much. “Too much new stuff to keep track of, I’ve just given up.”

Hey, OK. 

Don’t complain to me when you can’t get a job though.

How to Fix JavaScript Fatigue

I used to think that the people who had given up like this had either lost their love of learning, or were so distracted by the bright and shiny that they had hit overload and couldn’t continue. I now see that the real problem is depression. A natural extension of anger.

But, suppose there was a different way of looking at all this JavaScript Fatigue stuff?

Yes, there is a lot of stuff to learn. A lot of stuff you could learn. And you see, that’s the first step. There is a world of difference from NEEDing to learn all that is out there and having that all be things you could learn.

I doubt you evaluated all the possible languages you could use prior to using the first language you used. Maybe it was chosen for you by your first job. Maybe it was the language you were most attracted to. In my case, I tried three different languages prior to my first job and when I started my first job, I wasn’t using any of them.

Even today. How many languages are there? How many do you know?

The point is, you don’t HAVE to know everything about anything. You really only need to know enough to get your work done. Sure, there will be something new and shiny. Take your time and evaluate if it is even worth looking at. Dip your toes in. Does what you’ve seen so far make sense? Go further.

Recently, YARN has become the “hot new thing.” I tried it. It didn’t work in my current environment. At least for now, we are sticking with NPM. We’ll take another look when it matures a bit further.

I love learning. But, I also realize I can only learn one thing at a time. I can’t be awesome at everything. So, I focus. Everything else I might need to know, I learn well enough to get the core thing done.

Conclusion

And so, the cure for JavaScript Fatigue lies not outside of us, but within. Fix your perspective. Focus on what you need to know now. Learn bits at a time. Don’t worry about what is coming. There will always be new stuff. Not just with JavaScript but in the programming world in general. Even in the world at large.

Don’t worry, be happy!

Several weeks ago, I was talking to a programmer and we got into a discussion about the importance of software architecture. I maintained that having a defined architecture is important regardless of the team size, the person I was talking to asserted that architecture wasn’t necessary when there was just one person involved.

But here’s the thing. All software has an architecture. Even the most junior of programmers has an idea of how code should fit together. At issue isn’t really about architecture. It is about having a defined architecture, based on experience and best practices, that will allow the team to develop the software in question as efficiently as possible. Software architecture, at its core, says, “this is how we build software.”

To find the reasons why software architecture matters, it is helpful to think about what happens when there isn’t any defined architecture in place.  For the purposes of this article, I’m going to generalize on how architecture impacts teams and where appropriate show why that is also important when your team is just you.

Photo via VisualHunt

Read More

Over the past week, I’ve listened to and read several articles that have started me thinking more about the Psychology of Programming.

Not that I haven’t been thinking about this for a while. I’ve been quite intrigued by human behavior for a while now. But more recently, there was this podcast over on dotNetRocks about “Punishment Driven Development”. And this comment:

The happiest people in my experience are those that have options. They have transferable skills, see their employment as a personal choice, have self-confidence that they are providing value to the company and are in a position professionally and personally where they could change job if they needed. The feeling of being trapped in a position from which you can’t escape (either a dissatisfying job, bad manager or whatever) will lead to negativity.

Which I almost agree with, except I think it is the negativity that leads to feeling trapped. And then there is the book I am reading, “Influence: The Psychology of Persuasion” which goes into detail on why we make decisions that seem to go against our better judgment.

Then there is another podcast that discusses the decisions we make as we start a new JavaScript project.

And all of this culminates into the following thoughts:

Read More

This past week, while working on a new project, I discovered some secrets to styling Angular2 that I don’t think are very well-known.

There are two specific issues I needed to solve this week that took a bit of digging. The first was that I wanted my routes to fade in and out as I move between routes. The second was that I was using a grid control from a third party and I needed to style an inner component. We will cover both as well as some more basic operations.

Read More

I’ve been studying topics related to social science recently and one item that keeps popping up in various places is the idea of luck. It turns out that lucky people aren’t really all that lucky. There life has been arranged either by them directly or indirectly by their environment so they end up having more chances of good things happening to them.

How can we apply this to programming? How can you be a lucky programmer?

Photo Gaertringen via Visual Hunt

Read More

I’ve been working with Angular2 now since RC0 and I’ve learned quite a few things about Angular2 DOM tips, tricks, and warnings that you’ll want to pay attention to as you get started.

Read More

The first time a programmer who was trained in the classical procedural/object oriented history is confronted with the concept of making everything immutable, the first question that comes to mind is, “won’t that make my application slow?”  This is because of how most programmers have been trained.  Making everything immutable generally means that we must copy a lot of memory from one place to another.  Moving memory around is generally considered slow.

And so, most programmers dismiss the whole idea as crazy talk.  But is it really all that crazy?

Read More

Over the last several months, I’ve seen a lot of whining, complaining a fear regarding Angular 2 in particular and the JavaScript platform in general.

Terms like “JavaScript fatigue” are indicative of the attitude.

Another place I see this is with the recent announcement from the Angular team stating there will be another major point release every six months.  Like this is a bad thing? Or the general attitude that particular (modern) design decisions that have been made in some of the more recent frameworks that have been released are bad for JavaScript.

And I look at that and honestly wonder why these people are programming in the first place.  If change bothers you, you are really in the wrong industry.

Read More

On the subject of Angular2 Architecture, the perception is that Angular 2 is a highly-opinionated architecture. But even though there is a style guide for Angular 2, there are a lot of decisions that still need to be made when working on any but the most trivial of applications. And even then, since most applications take on a life of their own, one could make the case that you need to make these decisions for any application you are building regardless of the initial size. Applications grow up. But, that’s another blog post

I’ve identified, and have formed opinions about 5 areas that Angular 2 leaves open for decisions. Areas that if you don’t spend time considering the choices and making decisions could cost you in the future

The five areas I’ve identified are:

1. Handling Forms
2. Page State Management
3. Component State Management
4. Data Flow
5. Client Side Data

Read More

In the new world of Angular 2, and even in the world of Angular.js, you might feel like the concept of a module is the most difficult to wrap your head around.

This is especially if you’ve only ever written client side JavaScript code. Once you’ve learned why you need a module, the temptation is to use one module for all your code. I am guilty of doing that myself when I first started. But, many times using one module for your entire application is the wrong thing to do because it reduces the ability to reuse your code in other modules. Once you understand why modules exist, you’ll begin to reason about how to use modules appropriately.

Read More