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
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.
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
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
officially supported as a language standard. Because of that, a
hidden dependencies on different versions of jQuery. This sometimes
resulted in dependency hell. Also, adding jQuery to a website project
history. Because of that, you couldn’t just open notepad and write a
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
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.
continued to up the ante, creating more complex web
at the edges under this new complexity. Managing and installing the
ever-increasing glut of project dependencies became tedious.
npm raced to fill the gap, allowing developers to automatically
acquire and install dependencies. It became much easier to install
Now that developers could install many libraries easily and
painlessly, they installed many libraries easily and painlessly. The
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.
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.
debugging and profiling tools, batteries-included libraries for
standard operations, a popular dependency manager (
module-level dependency management to prevent namespace pollution
import). It finally has all the features every other old-fogie
However, if I was starting out today, I wouldn’t use
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
community forum I can download.
akewley-lang is so much simpler
of those complicated languages (and associated ecosystems) didn’t know
what they were doing.