Thoughts on avoiding Web development fatigue

There has been a lot of discussion about people getting tired of learning new libraries/frameworks, setting up their tools, choosing technologies, negativity and developers attitude towards other solutions.

This is how it looks when JavaScript developer chases the current trend.

As an independent Web developer, I have seen quite many workplaces, domains, problems to solve and technologies. This blog post is my take on avoiding the fatigue.

First thing first

Fighting the fatigue is quite similar to dealing with obesity: decrease unhealthy garbage and increase beneficial ingredients.

Avoid:

• unfollow people that use words like "shit", "bad" when talking about work done by others, you won't miss them
• blog posts like "5 Technologies Every Developer Should Know" and "6 Web Design Trends You Must Know for 2015 & 2016"
• aiming for the "final" solution, start simple

Increase:

• understanding of fundamentals instead of libraries
• awareness of services that are great to use, but have not so hip technologies behind it
• follow people that have been in the industry for a long time (Bruce Lawson, Christian Heilmann, etc.)

Those were the high-level adjustments. Now to the root of why we need to learn all this or do we?

Overestimating the problem

When we listen to "loud persons" explaining their solution, the ultimate truth, and follow big companies solving hard problems we start to think that we're going to hit same issues. Issues about scaling, performance or maintainability.

I think it is time to wake and realize that most of the Web developers deal with problems that could be solved with Backbone.js and common sense software development processes. Scott Hanselman talks about Dark Matter Developers which is the 99% of the software developers that silently do the stuff our life dependents on.

If a software developer makes a web service that isn't very hip (no new user-interface innovations, no scaling issues, no thousands of users), then there isn't much to talk about in a conference or meetup. Which in order leads to a distorted sense of reality as we hear only from the people who had an interesting problem, such as very complex user-interface with real-time updates coming from the server.

Take-away: most of the developers are creating quite simple Web applications and probably you're one of them. Don't worry too much that your chosen library/framework can't scale, it's a matter of discipline more than tools.

Libraries & frameworks

The frequently heard sentence: "Something new coming all the time" is true and false at the same time (which is a difficult concept for a programmer).

We tend to think that each framework and library is entirely new, but to put in a sentence: "Same shit different fan".

Most of the libraries are clones with a tiny twist. If we look at the history and the winners of each era:

• jQuery won MooTools, Prototype and other libraries tackling the same issue.
• Backbone.js survived the uprising of clones like Spine.js, Batman.js, and JavaScriptMVC.
• Angular.js competed with Durandal, Knockout.js, and Ember.js, but got a lot more traction than the listed all together.

Back to the present. Which one will be the winner of this "component & virtual DOM" era we're living? Do you have a problem that benefits a solution like that or does it just make simple complex?

If you have a basic app with just simple CRUD operations for different entities then are the new libraries worth the hassle or should you stick with rock-solid libraries.

Spend 30 minutes to learn why the library was created. For example, there are plenty of information about origins of React. Can you relate to the frustration they had? If yes then you might be on a right track.

The tooling is a bit of a mess and causes too much burden. There are far too many bundlers, build systems and plugins for each system. I do like the Unix philosophy when it comes to tools, but now there are just too many tools tackling the same problem. The tools itself are focused on one task, and that's a good thing. I am optimistic about the future, but there will be some changes in best practices when HTTP/2 is more popular.

The Unix philosophy favors composability as opposed to monolithic design.

Picking another language than JavaScript

Why isn't JavaScript enough? Is it lack of static typing that is a showstopper? What is the backend language and could you leverage backend developers expertise? Maybe it is the ES3 that is lacking behind and moving to ES2015 is the solution? Be honest and don't just pick some language because you want to impress someone, or you're satisfying your need and sacrificing what is best for the project.

When CoffeeScript was released, the argument against it was that debugging is hard as a single line of CoffeeScript can produce a hefty amount of plain old JavaScript. I think that problem was exaggerated, and you should not avoid "transpiled languages" aka languages that are converted to other languages, in this case, JavaScript.

Learning programming languages is something I like, but I would not introduce one to the team without good arguments. "JavaScript sucks" isn't enough to convince (sane) people.

Like I said in the first chapter: learn fundamentals. They are old as hell. Most of the fundamentals were introduced in the late 1960s and the 1970s: object-oriented programming (Simula, SmallTalk), systems programming (C), higher-order functions (ALGOL 68) and statically typed functional programming language (ML).

Learning the fundamentals will decrease the fatigue as things don't seem so new anymore.

What is your take on this? Are you tired of chasing the rabbit or do you find the vibrant community and wide variety as a positive thing?