Web Programming Language Heirarchy

When I think about programming languages used for the web I tend to automatically group them into one of a number of “tiers”, a hierarchy of languages. Here I’ll talk about what goes where, and why.

What follows here is what Wikipedia would euphemistically call original research. This is how I think of these languages, and my opinions and experience with them. It isn’t meant to be an authoritative document, and contains approximately zero ideas that have been carefully peer reviewed.

I mention that largely because people are amazingly precious about these things. Speaking of which, this also isn’t purely “languages” in the strictest sense, as it includes skills like HTML.

The Tiers

This is the baseline expectation of a web developer, the very beginner knowledge. Examples would be CSS, HTML, and very basic JavaScript. That’s not to say these things are not valuable, nor even to say they’re not complex. If you think about it, that’s essentially all the fancy other languages end up outputting to. But as a starting developer these aren’t things you’d start to learn. They’re things you’d already be expected to know. The chances of landing a professional junior role without at least some familiarity with these tools is vanishingly small.

These are base level languages. They’re critical parts of the development world. These languages form the vast majority of tech stacks on the web today.

This category includes all the usual development mainstays: .NET, PHP, Python, Ruby/Rails, NodeJS, Java. On the frontend it would probably be reasonable to put “modern JavaScript” and frameworks like React in here as well.

This categorisation is not intended to be negative about these languages. The core languages are fundamental and powerful. They are the principle professional web development technologies used by hundreds of thousands of developers around the world. As a result, they have exceptionally high applicability and employability. They deal with highly solvable problems and have widely available help and tooling that makes them an ideal choice for most business needs.

The languages in this category are ones that are often a later choice for more experienced developers. Sometimes they are options that individual developers take up on their own as a matter of interest. Other times companies transition from a core language to one of these because of specific technical requirements, or more often dumbass made-up reasons.

Examples of secondary languages are Elixir, Go, Rust, Kotlin, or Scala. More hesitantly I’d put Elm for frontend.

These languages have a number of key similarities. They are without exception extremely high performance, often 10x that of the core languages - at least in benchmarking. In addition, all but one (Go) is a functional programming language, making them a wildly different mindset to program in. They are highly disciplined, often putting error handling, robustness, and testability well before shiny features or developer experience.

There are a number of other languages that may well come up from time to time because they have use in a particular area of business. Examples are Solidity or Vyper for blockchain development, or R for statistical analysis.

There’s no real need to dwell on these, they’re the kind of thing you only use when you need it.

What does all this mean?

First and most importantly none of this is meant to imply that the secondary languages are actually better. There is no better or worse in development technology — only trade-offs. In fact there are a range of ways that the opposite is true, and the following makes these languages a hard sell.

These languages are typically extremely short on tooling, IDE support, in-depth knowledge repositories, etc. They are even more short on staff. Trying to hire talented developers to work on projects written in even common languages can be a challenge, moving to less common, more obscure ones drastically shrinks the developer pool. And as the talent pool shrinks, the costs rise. The return on investment can be very rough.

It may seem nice to be swimming in that smaller pool, but the fact remains that you won’t be getting a lucrative job unless there actually are jobs. A search for Golang in my town shows only five roles. A search for Elixir showed only one — and that one was a false positive matching on a brand of coffee.

By comparison, PHP and Python both had more than 70 roles listed, and about 30 for Node. There were about 140 for .NET listed. As a random aside, historically PHP and .NET have been closer than that, and Python lower, so I’m surprised to see that level of difference.

Even given that there are huge (often order of magnitude) benchmarked performance benefits for these powerful secondary languages, the actual real-world difference might not be that much. Actual application performance doesn’t help things like slow database queries or constant IO access, and these are typically a bigger factor than the language. Where the application itself is a bottleneck, performance can usually be gained at less expense by more hardware or basic caching. Rewriting the application in another language is rarely a good choice, and at best a specific bottleneck might be a rewrite candidate.

There are countless examples of major companies switching from a Core to a Secondary language. A popular go-to is that Twitter started as a Ruby on Rails application and ended up having to be rewritten first to Java and later to Scala. The takeaway often is that Rails is inherently too slow and you’re better off starting with a faster platform like Scala. For a start this is reductive, a lot of Twitter still is RoR, but more particularly the conclusion itself is flawed. Your application is not Twitter. I’m willing to bet your application does not have nearly the same performance demands as Twitter. And even if it eventually does, let’s be honest: Rails was good enough to allow them to become Twitter. Worry about launching before you worry about scaling.

This is just how I see things and doesn’t necessarily work equally with all languages. As a specific semi-exception, Go/Golang is probably more accurately a Core-Secondary hybrid now. Companies are not uncommonly moving to Go from PHP. Even a place I worked recently as a custom PHP shop is now 100% Go, though if experience is a guide I’d bet money it’s for bad reasons. Jetbrains makes a dedicated IDE for it now. Given a few more years, the downsides of Go may well be mitigated. Including both the job pool for developers and the developer pool for jobs.

What’s the conclusion here?

If you’re a new developer, learn a Core language, not a Secondary one. The job opportunities are simply so much more numerous. You also tread a much more newbie-friendly and well-worn path.

If you’re a well established developer using something like PHP or Ruby maybe it’s time to look at other options and add another string to your bow? Most languages have common “upgrades” that people routinely take. PHP and Python shops typically move to Go. Ruby/Rails developers often take up Elixir.

If you’re a developer working with these secondary languages for the love of God stop recommending them to new developers. At best you give them a steep learning curve with poor or no documentation, at worst you make them borderline unemployable.

Senior Web Developer based in Bangkok, Thailand. Javascript, Web and Blockchain Developer.