In programming, “mature” is a funny word. When I first started programming, it had negative connotations. A “mature” programming language was boring, had complicated tools, over-complicated design patterns, and would likely die off soon. By contrast, non-mature languages were exciting, free-form, and carving out a new frontier in software.

My opinion has evolved since working as a programmer rather than studying as one. Mature now implies that a language will have have good debuggers and profilers. It will have an established build and testing systems for the language. Its core libraries won’t change midway through a critical project. Most importantly, though, mature languages (tend to) have moved past the same boring old problems that every language ecosystem encounters in its early days.

JavaScript’s history is a good case study for this. I started on JavaScript in its early (IE4) days. Back then, I would open notepad, write a few HTML tags, a <script> tag, and voila I could see stuff happening in my browser that my code put there. Simple.

Unfortunately, it’s unlikely that my code would work in any other browser. The JavaScript language platform was horribly fragmented. Internet explorer’s implementation of browser functionality was non-standard. Even the most trivial DOM manipulation or standard library call would behave differently between IE and Firefox. It was not unusual to have a lot of if(browser === IE) tests throughout a codebase. This made working with JavaScript less simple.

jQuery stabilized JavaScript development somewhat but it wasn’t officially supported as a language standard. Because of that, a large amount of JavaScript libraries ended up with a tangled mess of hidden dependencies on different versions of jQuery. This sometimes resulted in dependency hell. Also, adding jQuery to a website project was considered the “done” thing at this stage in JavaScript’s history. Because of that, you couldn’t just open notepad and write a few tags and some JavaScript, you would also have to import jQuery and become familiar with that. The complexity was creeping in.

Later, Firefox, chrome, and—because of the blockbuster release of the iPhone—safari began to eat away at IE’s market share. They were standards compliant, IE wasn’t. Web developers started to make sites that wouldn’t work in IE, which prompted IE users to install IE’s competitors. The overall effect of this was that a growing share of users started using standards-compliant browsers. JavaScript, the language platform, became (mostly) stable and predictable.

Because of this stability, web developers could build bigger, more complex, sites. Animations, realtime updates, and dashboards became more popular. As a consequence, tools for debugging this complexity became more valuable. In an effort to secure their market share, Chrome and Firefox began to include developer tools which enabled developers to set breakpoints and profile their websites. Having these tools made web development a lot nicer; however, the workflow was now more complex.

The next issue developers encountered was managing libraries and dependencies. Traditionally, libraries would be manually downloaded and included in <script src="..."> tags in the page. However, it was tedious to do this once projects became split over many files. It was also inefficient because the HTTP/1.1 protocol doesn’t suit downloading many small files.

Backend frameworks, notably Rails, began to offer asset pipelines for combining, minifying, and including scripts in websites. This enabled developers to build bigger codebases fragmented over many files; however, they would also need to learn how their build system links files and use appropriate strategies to debug minified files.

Once using a build system with JavaScript became the norm, developers continued to up the ante, creating more complex web applications. However, the JavaScript ecosystem was beginning to crack at the edges under this new complexity. Managing and installing the ever-increasing glut of project dependencies became tedious. bower and npm raced to fill the gap, allowing developers to automatically acquire and install dependencies. It became much easier to install JavaScript libraries; however, you’d have to learn bower or npm.

Now that developers could install many libraries easily and painlessly, they installed many libraries easily and painlessly. The JavaScript language didn’t support declaring dependencies on a module-by-module basis. Consequently, dependency hell ensued. Libraries such as requirejs came along to fix the problem, allowing developers to declaratively state a module’s dependencies. Developers no longer had to reorder <script> tags to make the application work; however, they did need to learn requirejs.

At this stage, JavaScript was beginning to become mired in libraries for doing stuff that the language ought to support. ES6 (/ ES2015+) was specced out to deal with some of those issues. It offered standardized higher-level language abstractions for building bigger systems (classes, getters, setters, proxies), language-level protections (const, Symbol), and declarative library loading (import). However, it also made the language a little more complex.

Today, JavaScript is a (mostly) standardized platform with good debugging and profiling tools, batteries-included libraries for standard operations, a popular dependency manager (npm), and module-level dependency management to prevent namespace pollution (import). It finally has all the features every other old-fogie language has.

However, if I was starting out today, I wouldn’t use JavaScript. Clearly, the future is akewley-lang. It’s amazing. You can open a text editor, write plot my data as a bar chart please and see stuff happening right away. It’s so simple. Now, all I need is to generate that bar chart and have a whizzbang animation when it loads! Luckily, there’s a library for that on the akewley-lang community forum I can download. akewley-lang is so much simpler than JavaScript, ruby, python, C#, F#, java, C++, and C. The designers of those complicated languages (and associated ecosystems) didn’t know what they were doing.