JavaScript: more puppy love, less fatigue

JavaScript is everywhere and it is the hottest thing to have on your CV. For now. Python is gaining and Deep Learning is to blame, but I digress. With JavaScript’s hype we also talk a lot about JavaScript fatigue. People feel overwhelmed by the sheer volume of things you can do with it. Or — even more to the point — the amount of work you have to put into setting up your JavaScript environment. And the tools you “need to use to be professional”.

I’m not suffering from JavaScript fatigue. The reason is that I didn’t come in that late. I was lucky enough to see JavaScript grow to what it is now. To me, JavaScript is still that cool rebel of the programming languages world. I remember being laughed at by Java and Perl developers for wasting my time on that toy language that didn’t even come with a package manager. I’m not a purist that says all these things are stupid or unnecessary. Far from it. It is amazing how far we have come in our tooling. But- maybe — we could achieve more with new developers starting out if we started them with Vanilla JavaScript rather than throwing the kitchen sink of tooling at them.

What people hate about JavaScript is the thing I love about it. It is a mess. It is not ready yet and there is still so much it can do.

I feel a kind of neoteny attachment to JavaScript.

neotenyniːˈɒt(ə)ni/noun – the retention of juvenile features in the adult animal

In other words, instead of showing people the current form of JavaScript as a matured, highly domesticated and fierce animal, we should get people to know it as a puppy. That’s how I got to know it. Instead of wondering what packages to install and how to set up my server to run it, I wanted to grab it, cuddle it, play with it and — above all — protect it and its surroundings from harm.

My relationship with JavaScript began very early. So early, that it didn’t do much and we couldn’t do much wrong. That didn’t stop us though from doing wild things. As a web developer, JavaScript itself wasn’t quite as interesting as what it can do in browsers. The years of document.write, framesets and popup windows came first. I had quite some “fun” trying to make things work across browsers. DHTML was the next hype where it was most important to create cool effects — no matter the cost. Considering standard compliance or what technical debt we accumulate was less exciting.

We all knew that JavaScript wasn’t a “real programming language” and that was what made it interesting. You didn’t need to use an IDE, you didn’t need to compile your code or set up an environment for it. You took any editor, wrote your code and the browser did the rest.
Until it didn’t any longer. Around the same time of the bursting of the first dotcom bubble IE stopped reigning supreme. Other browsers started to matter and clients complained about things breaking. JavaScript got less fashionable again. Instead, everybody started betting on Flash. It promised to eradicate cross-browser differences and give you full control.

In the JavaScript world, we sobered up a bit. We realised how brittle the things we built were and started to advocate for a more sensible use of JS. We also had a good reason, as the DOM finally got standardised and things were much more predictable than in the first browser wars.
In 2004, I wrote the self-training course on Unobtrusive JavaScript explaining how you can use JavaScript without relying on it. As an enhancement, it works wonders. As something to rely on, lots of things work against you.

When DOM-1 was available, I followed up with From DHTML to DOM Scripting with detailed advice to not make the same mistakes again.

Things got more solidified with the WASP DOM Scripting Task Force that started in a pub after a conference in London. The most visible influence there was probably Jeremy Keith’s DOM Scripting book.

JavaScript itself didn’t move much though. The language was still what Brendan Eich and others created in a 10 day sprint to have a client-side language. And when things get that frantic, shortcuts happen.

05 December, 1995: AP writes on Microsoft, Netscape, Java, and the forthcoming "JavaScript". [pic.twitter.com/NCjh8MOgB3](https://t.co/NCjh8MOgB3)

— Sampson (@jonathansampson) [July 25, 2018](https://twitter.com/jonathansampson/status/1021993137072472065?ref_src=twsrc%5Etfw) Over the years, we tried to make the language itself better and more predictable. We couldn’t change it as that would break backwards compatibility. So we found clever ways to work around issues. One of the big consumers of these were JavaScript and AJAX frameworks and libraries. YUI, Dojo, jQuery and others were a great test-bed to make JavaScript work for developers but also to fix some of the issues of the language itself.
The [immediately-invoked function expression](https://en.wikipedia.org/wiki/Immediately-invoked_function_expression) was a clever way to work around the global variables issue. Douglas Crockford’s [Module pattern](https://yuiblog.com/blog/2007/06/12/module-pattern/) ensured encapsulation (until eval() also got a scope parameter). I’ve found the Module Pattern annoying to write, so I came up with the “Revealing Module Pattern” later on. Many other patterns and best practices followed. Libraries like mootools and prototype made JavaScript a “proper” object oriented language. At the cost of overriding in-built objects which came back to haunt us now. Other attempts at “fixing” JavaScript were meta languages like Coffeescript and many forgotten ones. Learning from these fixes and libraries the maintainers and creators of JavaScript, the TC39, release JavaScript much more often these days. And with ES5, we finally have a standard that deals with most issues the first editions had and gives us enough syntactic sugar to be effective. JavaScript these days has matured a lot and will become even better. It can not, though, when we hide its inner workings away from the next generation of developers.
You don’t need to be a JavaScript language expert to use it. But it may be a good idea to tell the story how we got to where we are rather than asking people to blindly use what’s on offer right now. It is easy to get disappointed, discouraged and overwhelmed by something new when you use it without understanding it. You also don’t dare to say you don’t get it when your peers all stroke their chins pretending to know everything. Let’s keep introducing JavaScript to people for what it is — a language that is pretty messy but highly accessible as there is no barrier to using it. Once they played a bit and see what it can or can not do, we can move on and show that a lot of what we did by hand these days is better served as a pre-built solution. But let’s keep people playing. If you want to know more, and get a gentle introduction check out my [Skillshare class](https://skl.sh/christian_javascript) about JavaScript and how to deal with the changes it went through. In about an hour of videos you learn what JavaScript is these days, how to deal with the hype and – more importantly – what great advances happened to the language and the ecosystem.