JavaScript fatigue

Today, I'd like to dig into something that has been bothering me lately: why I often feel tired of JavaScript (and even sometimes programming in general). I'm not alone in this, there's even a name for this JavaScript fatigue. Here I'll give my personal thoughts on this (and probably rant a bit).

As developers, we do live in a fast moving world. It's even more true in the world of frontend development and JavaScript: it seems a new framework or practice appears every day and everything seems to force us to know about it and to learn it because it is so new and so cool and so much better than everything else that came before it.

This doesn't come from nowhere: with the rise of NodeJS and interactive apps, JavaScript is more and more used and so its community is expanding. Fast, very fast. This means the number of developers using the language, contributing to it and its ecosystem is increasing too. Quickly, very quickly because of the need for these skills and the "hype effect".

Add to that the fact that not so long ago (before Chrome and V8 and the evolution ES2015/ES6 of the language), JavaScript was still lacking what I'd call "important features to be productive" and was seen more as a side language to add some interactions in the browser. So there were some frameworks but nothing that got a real big momentum and pretty much everything still had to be built. This means, in this space, we are all using recent tech. This is quite unlike what we had (and still have) in the Python world for instance with frameworks like Django (first released in 2005) or Flask (first released in 2010) or in the Ruby world with Ruby on Rails (first released in 2005). Even if nodeJS itself was release in 2009, it takes time for an ecosystem to raise and mature with all of its libraries and frameworks and then for developers to adopt it (beyond the early adopters of course). In the frontend side of things, I think it really started with AngularJS in 2009 which was the first attempt (that I know of at least and that really became popular) for a framework to allow you to build a true SPA that became really popular. It was then followed by React in 2013, Vue.js in 2014, Angular in 2016 and Aurelia in 2016 to name only the most known. They are of course many others, most of them will probably remain experiments.

You can object that some of the projects I listed earlier are more or less as recent as the JS ones, after all both AngularJS and NodeJS were first released in 2009. However, they have share an important difference: they were built on concepts and rely on technologies that are much older, mainly:

• The MVC model which dates from 1978.
• SQL which dates from 1974. Of course both PostgreSQL and MySQL are more recent: 1996 with sources in the INGRES project way back in the 70s and 1995 respectively. But since they are at least 25 years old, they are kind of venerable now.
• Python or Ruby which date from 1991 and 1995 respectively.

And even if the projects can be new, they are based on "old" tech and concepts that matured before these projects came to be. And they are more or less 10 years older than most framework we use today in the frontend. These concepts evolved and were refined over time which took time. We were able to test many possibilities, to fail, to learn before getting where we are now: mature stuff that works in many cases and are stable.

Contrast this with Express.js which was 1st released the year after Node was or the NoSQL movement which really starts near 2009 (MongoDB was release this year and the first NoSQL convention happened), like NodeJS and AngularJS. Or JavaScript itself which added "basic" feature only recently (like the import system in 2015). You can of course argue the root of NoSQL is older but my point is it gained momentum and was formalized very recently (at least in the form we know and use).

So, I feel we are still missing maturity for frontend tech. The technologies are all recent, evolving fast and don't seem close to a stabilization (I hope this will change in the future). The fact that there is so many developers using it and wanting to bring their ideas to it doesn't help either.

Which leads to the situation I was describing in introduction: we see a lot of experimentation, technologies move fast, become deprecated quickly and we have a lot to learn just to stay up to date. This can lead to a feeling of exhaustion because no matter what we do, even if we try to only stay relevant, we still feel out of date without any clue to what we should learn, what would be most valuable, what will last. That applies to tech that have been around for some time like React: they recently introduced hooks which are a brand new and very different from what we did until then to manage state. And we are expected to by peer pressure (on social media or internally where we work) and to pass interviews (mostly at the latest trendy startup but that where the cool kids go, isn't?). And if like me you like learning things and experimenting, this can be daunting and exhausting.

Of course, they are things we can do to mitigate this:

• Only take a close look at tech that is popular and that passed the trial of time. This way, we only look at tech that had time to mature. But it can already be perceived as obsolete and it can still be evolving (I'm thinking of React Hooks that were introduced recently).
• If we want to look at some latest stuff to have fun, we can, just do it only once or twice per year and don't dive all in since we probably won't use it anyway (or it will just disappear). And remember that we are learning it for fun not to use it in production.
• Reduce our usage social media where we can be submerged by the hype wave and where it looks like everybody gives their opinion even if they haven't though on the matter and where people can be quite enthusiastic about anything, making ou feel bad your are not and giving us the false impression the thing we are looking at is very popular and that we just must use it (and that everybody already is). The problem is also similar at conferences but I can't really advise not to go at one or watch their recorded videos because they are a magnificent way to learn. And they have a big difference: when you go to a conference, you can talk to people to get a more nuance picture.
• Remember about cognitive bias: speakers are most likely normal folk too and many of them are just average. That's just statistics. Speaking at a conference doesn't make them heroes we must follow no matter what.
• Remember even those cool folks have to maintain legacy code and don't always do the cool stuff they talk about. But that's easier said than done. And, like most of us, they'll talk about the cool stuff they are doing.

That's good and that can help. It can still be hard to do, if like me, you like to experiment and learn new things. Since as developers we all work with our brain and are attracted to technology, I think it's the case for many of us.

But it's only part of the solution and making it only rely on people, on us personally, can make us feel bad and worsen the problem. Even if that's what our culture incite us to do. I want to emphasize that it's also a global context. And the big pressure to follow the hype will still be there and each time we'll go to a meetup or a conference. It's also present in how we make job interviews. And if we don't work in a big company or a startup where we can test, experiment and work the latest stuff during work hours, it's even harder because we must do it all on our valuable spare time. So I feel like we need to collectively do something and stop chasing the brand new thing, for us and for others. Here is a small list of things we can do:

• Stop reinventing the wheel because we didn't to it or because we think we could do it a bit better.
• Stop blaming and criticizing the old tech and the users of old tech:
  • The tech may be old but it doesn't meant it's irrelevant. We can even learn things from it and become better developers (and dare I say like it?).
  • It's maybe a much better match for what they are doing than the shiny stuff (whose main quality is often to be new and shiny).
  • The user of old tech may just not be following the hype and be convinced for very good reasons that the tech they use is good for their problem. Even if it has some defects and it's not prefect, the issues and imperfections are known and very often can be dealt with. They know how to be productive with it and keep the software going with few bugs.
  • They may also not have a choice and have to maintain a big legacy project.
  • There is a place for proven tech even outside legacy systems.
  • Please note that I'm not advising never to learn, experiment or move forward. Don't get stuck into your habits: think about them and make them evolve when needed. Don't choose an old tech because you're used to it but because you know it is good. New tech can spawn great values. This implies to read books and experiment from time to time. It just doesn't need to happen at a fast pace and for everything that happens out there. Focus on the basis and high level architecture, it can be reused across languages and tech so it always pays off.
• Accept we are no all working at Google, Facebook or any other very big player. We don't need to work exactly like they do, with their tech and their procedures.
  • We will probably be more productive if we don't. Most of what they do is design for the enormous load they have and for the huge number of developers that work for them.
  • Even in a startup with big ambitions, we are likely to miss something that will prevent your architecture to scale correctly and force you to rewrite it. Even if the software was written with all the latest shiny tech and separated in µ-services. And let's face it, the startup is very likely to disappear anyway. So maybe we should try to build a product that works and get customers before thinking about scaling at the level of Google.
  • We will probably apply the visible stuff without all the technical rigour that comes into it. This will result in us building a big mess of little balls of mud that will shine it meetups but prevents us to deliver.
  • So maybe try to build a good product following proven code advise (like those described in the book Clean Code) and it will be easier to you to pivot or scale should it be needed. And if we have to rewrite it, do it. If our software was done properly, it will take time, but it will be doable (normally at least, we all hope and we all fear the tech debt ^^).
  • Old stuff is always a pain to maintain anyway, whether written in a shiny new µ-service architecture or in a big monolith.
• Accept that the hype is the hype and probably isn't mature enough to be used in the real world just yet for most companies.
  • Most of us can't afford to rewrite everything each time something new – a framework or a version of a framework – comes along. Don't blame anyone for not being into it. They may have other priorities and they don't have the resources (the army of developers and the billions of dollars) to make it happen anyway.
• Find a job that allows you to learn and stay relevant during work hours to better enjoy your spare time.
• Accept that old tech with known tradeoffs can be a good thing.
• Don't forget that most of the common problems with "old" can be mitigated because we understand the tech so well with decades of experience with it.
• Don't forget old tech evolves. For instance recent versions PostgreSQL has astonishing support for JSON and can help you apply schema migrations without downtime. So bringing this as a hammer argument for MongoDB may not be relevant.
• Don't forget some issues with old tech comes for a particular framework, lib, or software. For instance, PostgreSQL supports array and has for a very long time unlike MySQL (which as far as I know still doesn't). Arrays are even in the SQL standard, so criticizing SQL for this is in fact criticizing MySQL. Take care of this. And they too can evolve and provide those features, so you may not need change them.
• We need time to understand the tradeoffs of new tech. Embracing it too early can lead to bigger problems in the long run that using old and proven tech. It is cool that some can do it and find these issues. Not everybody can do it though, and for many solutions that brings money to a company, it's not a good fit. And we may encounter problems nobody has before and nobody knows how to solve which may put us in a delicate solution.
• In the real word, behind the buzzword, many are probably not doing like the Big Ones and building a big ball of µ-services or fail at understanding a problem correctly even if they proudly display their state of the art practices. Even in the big ones, I sure the reality is a bit less interesting than what they present at conferences.
• Stop blaming people when we ask genuine questions about new tech because we don't understand their tradeoffs yet and don't fully grasp their advantages. It takes time to correctly understand a subject and build an intuition about when, how to use it and whether it's a good fit for our project and my team. Just replying with You're just resistant to change is neither helpful nor mature. They can be valid reasons for a change (even proposed by Facebook) to be bad so don't use the argument of authority It's made at Facebook or Google, try to convince us with good arguments instead. And don't forget the goodness of a change may not be obvious at first.
• Don't forget that something good for one team may not be for another. For instance, take µ-services: they are very interesting to structure big teams. If you're just 2 or 3, I think it's overkill. Or write a application in a language nobody knows in your team because you think it may be a good fit for it. But if we think about it, the advantages it brings are not that obvious. The languages you know may not be the best theoretical fit, but you know them and the ecosystem around it, which gives it a very clear advantages. So unlike it is obviously not a good choice, you should use it. Making your team to a new language and learn about its ecosystem takes time, don't forget it!
• Must stop idolizing Facebook, Google, Netflix and co. They can do shitty things and mistakes or at least things that don't match our needs and our teams. Stay critical. Don't use in a discussion That's what Google does or It's made by the bright folks at Facebook. Even bright teams can make mistakes and this tech or this way of doing things may not be a good fit for your team. See my point above.
• Can use other languages or framework other than the most popular ones and still be awesome persons and developers. Not everybody has to use JS everywhere every time. For instance, I like Python, some may like Ruby, others Java. Find something you like, use it in your day job if you can. Diversity in languages and frameworks is a good thing. Learn something else than what you are currently using so proudly. It can help you get a new perspective on things and make us better developers.

Thanks for reading! Keep coding and learning and be nice and empathic ;-) Don't hesitate to react in the comment.