Who Killed The Tab?

Yeah... I'm going there. I know I shouldn't. I know this is one of the most irrational and arbitrary subjects in all of software development. But this has been pinging around my brain ever since I started blogging and it was only a matter of time before it burst out.

This is not a treatise for-or-against spaces - or tabs. This is not an attempt to change your mind on this most-divisive of subjects. (I know, from painful experience, that there is no changing of anyone's mind on this subject.) Instead, this is my honest attempt to figure out: How did we get here??

Some Anecdotal History

I don't pretend that my view of history will, in any way, match your view of the same history. But I can say, with empirical confidence, that I tend to have a longer view of history than most of my colleagues. Because, in this career field, staring down 50 often makes you 10-15 years older than most of your coworkers. So... here's my (ancient) perspective on this matter:

Although I wrote my first programs in the 80s (in GW-BASIC, on a Coleco Adam - with a tape drive), I didn't really become a "programmer", in any professional sense, until the latter half of the 90s. I had my first web-based business by 1997. I wasn't actually paid - by an outside employer - until 2001. But I was starting to write code, in excess of 40 hours per week, as early as 1997.

Back in those days, there were really only two types of developers (that I knew about). They were:

1. The pros. They typically only wrote in one of several languages: C, C++, or Java. (The real "old-timers" wrote in COBOL.) They spent endless hours arguing about memory management, and pointers, and garbage collection. And as far as I knew, every single one of them used tabs.

2. Everyone else. This included anyone who was writing on the nascent internet. There were no "JavaScript developers" at that time. But there were definitely some more "hardcore" guys who were doing Perl. Then PHP birthed a whole ecosystem of what the "pros" derisively called script kiddies. But as far as I knew, every single Perl/PHP developer used tabs.
   
   

Although I'd been working as a developer (for myself) for several years, I wasn't welcomed into the world of corporate IT until 2001. Through some odd confluence of factors, I ended up writing a lot of ColdFusion from 2001 through 2007. (I'm not particularly proud of it - but it paid the bills and allowed me to build a resume.) In the ColdFusion shop in which I worked (which included as many as 90 developers), we all used tabs.

At some magical point in time, JavaScript finally grew into its own "thing". And when it did, it apparently sprung forth from the mind of Brendan Eich, intent on one sole purpose: To eradicate the tab.

I don't think I started paying serious attention to JavaScript until, oh... 2012 or so. By then, it was already clear that there was "something" about my development that was sadly out-of-date. Even back in 2012, it was obvious that my preferred tabs were putting me in conflict with other dogmatic developers.

But I was confused - soooo confused. How had it happened that, seemingly overnight, the "standard" for indentation had flipped? And it had flipped in such a way that devs across the world were lining up with pitchforks and torches! It simply didn't make sense to me. In fact... it still doesn't.

The Language Conundrum

If the entire programming community had decided that "tabs are bad" and "spaces are good", I might've had an easier time accepting the paradigm shift. If you've been around dev long enough, you realize that sometimes these kinds of things happen. Standards evolve. "Best practices" emerge. Sometimes... that thing you were doing for years is now viewed as an anti-pattern. And for the most part, that's... OK. I get it.

But as far as I can tell, the "spaces-over-tabs revolution" is far from universal. In fact, it seems to be particularly ensconced in front-end languages. I could point my finger solely at JS, but I believe it's more generic than that.

It "feels" (to me) that most of the "space fanboys" are centered upon frontend technologies. (Many frontend technologies are centered upon JS - but not all of them.) And most of the "tab fanboys" are centered upon more old-skool, compiled, backend-kinda technologies.

Just a few years ago, I was working for a large health insurance clearinghouse. They had a lot of backend Java code - that I was responsible for working on. And they had a lot of frontend JS code - that I was also responsible for working on.

The frontend (JS) code was, without question, always written with space-based indentation. The backend (Java) code was, without question, always written with tab-based indentation. Maybe that doesn't sound "odd" to you. Maybe you're nodding your head thinking, "Yeah... so??" But for me, this struck me as being incredibly... arbitrary.

I mean, if tabs have truly been deemed as "bad", then why were they still acceptable in our Java code?? (With modern IDEs, you could convert the entire codebase in mere minutes.) And if the older, more stable, "industrial-grade" Java code was just fine with tabs, why was it considered so obvious that spaces were the default choice in our JS code??

The more I've gone down this rabbit hole, the more I'm flummoxed by the idea that, in one language, tabs are inherently evil. Yet, in another language, tabs aren't just acceptable - they're the standard.

Maybe this analogy doesn't fit. But in pretty much every OOP language I've used, there's been a movement over the last decade-or-so to favor composition over inheritance. That movement doesn't only apply to Java. Or C#. Or any other OOP language.

We don't use composition over inheritance in Java, and inheritance over composition in C#. If you believe in composition over inheritance, you try to use it... everywhere. It's a design imperative that programmers have come to accept - regardless of which OOP language you're using.

But when it comes to the the age-old, contentious question of tabs-vs-spaces, it seems to come down to language-based standards. Trends. As though a tab makes perfect sense in one language - but is unconscionable in another language.

But again, I come back to my central question: How did we get here??

The Petty Rules Lawyers

For awhile, I was frustrated by some of the downright silly arguments I read to justify spaces over tabs. Some of these half-baked ideas include:

1. Efficiency - You've probably seen some of those skits where one programmer starts hitting the SPACE bar repeatedly to accomplish indentation. The other one is only hitting the TAB key. And eventually, they start arguing with each other to point of throwing furniture and slamming doors. But here's the thing: No one (that I've ever met) actually uses the SPACE bar to do indentation. Every single time I've watched another developer code, they always use the TAB key. They just configure their IDE to insert X number of spaces every time they hit TAB. So "space fanboys" and "tab fanboys" are using the exact-same number of keystrokes. (But "space fanboys" are convinced that tabs are evil - even though they always use the TAB key. Hmm...)
   
   

2. Memory/Bandwidth - IDEs and source control systems have been able to strip trailing spaces for the better part of the last two decades. They are also capable of storing consecutive characters without having to allocate memory for every member in the sequence. So I can't, for the life of me, understand how anyone can argue, with a straight face in this modern day, that either approach presents a memory/bandwidth "issue".
   
   

3. Consistency - The "space fanboys" indent their code blocks - every single time - with a set number of spaces. Nested blocks are represented by indentSpaces = nestedLayers x standardSpacesPerIndent. It's consistent. The "tab fanboys" indent their code blocks - every single time - with a single tab. Nested blocks are represented by indentTabs = nestedLayers. It's consistent.
   
   

I could go on, plowing through a pile of arbitrary arguments used to justify one-or-the-other. But the point is that none of these arguments really seem to indicate exactly why someone prefers one over the other. People throw up these flimsy points - but it's pretty clear that they're really arguing in favor of their own preference.

At this point, I've yet to hear anyone give me an empirical, logically-consistent argument in this debate. When I realized that all of the "logical" arguments on either side of this Holy War were, well... illogical, I started looking to broader influences to explain the switch.

Evil Corporations

For a time, I blamed the Evil Corporations for this divisive Holy War. Specifically, I pointed my bony finger of judgment at Airbnb and Google. Even more specifically, I ranted against their all-too-ubiquitous style guides. These style guides decreed (amongst many other things):

1. Thou shalt only use space-based indentation.
   

2. That indentation shall be two - and only two - spaces.
   

At this point, I should probably come clean about one critical point. If you'd ever like to get me fired by enticing me to take a swing at you, the most effective approach would probably be to tell me, "Well, the Airbnb style guide says that we should..." or "The Google style guide says that we should..."

It's not that I have a problem with style guides, per se. And if your particular style-guide-of-choice is the Airbnb style guide or the Google style guide, then... great! Run with that! Standards are almost always a good thing.

What I do have a problem with is when otherwise-intelligent programmers abandon rational thought and hand over the reins of their critical thinking to some nebulous "standard". I understand that you can't be bothered to think deeply about every minute detail in the Airbnb/Google style guides. But if your only rationale for doing things a certain way is: That's what's outlined in the style guide. Well, then... you should probably learn to tie your shoes on your own and exercise some of your own brain cells.

I'm sure I'm being somewhat dramatic here, but for a while in the mid-10s, I truly felt like nearly every aesthetic coding decision in JavaScript would be distilled down to "Well, the style guide says we should do it this way..." If someone had managed to hack the Airbnb Style Guide site, and insert a rule stating that every-other line of code must be a comment that reads: // fnord!!!, we would've started seeing those comments in production code within weeks.

Alas, despite my cranky-old-guy propensity to rage against the machine, I eventually realized that spaces-vs-tabs predated the Airbnb/Google style guides. It's tempting to blame them for codifying two-space indents. But it's misplaced to assume that they started this debate - or that they settled it. They just put down, in (digital) writing, what had already been percolating across many dev communities.

So if we can't blame the big bad corporate bullies for this Holy War, how do we explain the rise of this endless, amorphous debate?

Combatting Chaos

When I broadened my focus, beyond the easy boogeymen of Airbnb or Google, I started thinking about the nature of the web. And the way in which JavaScript came of age - and the way in which it proliferates.

Remember when I said that, in a previous job, all of our Java code used tabs? Well... nearly everyone in the company used Eclipse as their IDE. Do you want to take a guess as to what the default indentation is when you install Eclipse??

C# is almost always written with 4-space indentation. Quite different from the defaults we see in Eclipse. In fact, it's quite unique from many other languages that are out there. But why is this the go-to default for C#?? Well... the vast majority of C# code is written in Visual Studio. (We could give a slight nod here to the rising popularity of VS Code. But the simple fact is that "plain old" Visual Studio is still the hands-down choice in nearly all professional dev shops for writing C#.) Do you want to take a guess as to what the default indentation is when you install Visual Studio??

Now let's think about JavaScript. Despite the rise of several dominant platforms (like, VS Code), there has never been a "default" IDE for writing JS. And there still is no such thing. The devs in your shop may all use a given tool. But JS devs across the world still use a variety of starkly different IDEs to complete their work. And each of those IDEs come with their own unique defaults.

As I'll explain, I don't think the "chaotic" and distributed nature of web (JS) development entirely explains the trend to force two-space indentation on everyone. But I think it's a good starting point. From the earliest days of the language, there was no "default" IDE for JS development. Therefore, there was no default setting for indentation.

But there's more to this picture. Chaos may explain the lack of standards in early JS dev. But it can't explain the heavy-handed enforcement of new standards.

Collaboration Spawns Conformity

JavaScript was first released in 1995. In 1995, I don't remember anyone arguing about tabs-vs-spaces. I especially don't remember any such discussion regarding JavaScript.

That's easy enough to explain. For the first 10-or-so years of JS's existence, there really were no "professional" JS devs. During its first decade, calling yourself "a developer - who specializes in JS" was akin to calling yourself "an architect - who specializes in building virtual homes in Second Life." JS was a toy. It was rarely used in "real" dev projects and, when it was, it was typically written by some lonely soul unattached from a broader dev team.

Those limitations started to melt away in 2006. That's when jQuery was released. Granted, devs weren't falling all over themselves to embrace JS in 2006. But jQuery's release marked the beginning of a swift evolution - one where "JS Developer" graduated from being an under-your-breath joke, to a full-fledged career path.

What does any of this have to do with tabs-vs-spaces?? Well... I'm glad you asked.

When you're writing code by yourself, with the dev tools that you've personally chosen, no one much cares how you indent your code. Heck... when you're only writing code by yourself, it doesn't even matter much whether you indent your code at all. When you're a maverick, you can do whatever the hell you want.

But once jQuery started gaining serious traction (I'll arbitrarily peg that date as: 2008), we started to see something entirely new in the JS community. We started to see professional teams of JS devs, working and collaborating together. While this was nothing novel for, say, a Java developer. It was an entirely new development for all those JS script kiddies.

You could put 100 mad geniuses in 100 separate caves to write 100 separate codebases. And since they're all geniuses, you could assume that all of their code is brilliant. Revolutionary, even. But that doesn't mean it would be consistent, or even compatible.

Even for those "mad geniuses", if you forced them to start sharing their code so they could collaborate on it, you'd be sure to run into some... issues. It'd be like asking 100 musical ingenues to write 100 songs. They might all be amazing - but they wouldn't sound good together.

So I imagine that there were a ton of headaches amongst the nascent JS community when companies started forming "real" dev teams. All the C# guys were already using 4-space indents. All the Java guys were already using tabs. But all the JS guys? Well... they were using... a whole bunch of different approaches. And when all those "approaches" get checked in - to the same project - well, it creates chaos. And chaos does not mix well with collaboration.

Why TWO Spaces???

If you accept my premises above, this explains why the JS community felt the need to implement some kind of standard for indentation. JS devs the world over were using a hodgepodge of different tools with different defaults. No one had a consistent idea of the "right" indentation. And once you start collaborating on that code, things get... messy.

But that doesn't tell us how we ended up, very specifically, with TWO spaces. Not four spaces. Not tabs. But TWO spaces. My readers (either of them) can correct me on this, but I'm not familiar with any other language that adopted two-space indents as a de facto standard. So why is that the de facto standard in JS?

This is where I point my bony finger of guilt, not at jQuery, but at Git. Git was released in 2005. In other words, it was released only shortly before jQuery. And for the web/open-source community, it quickly became the go-to solution for team-based code collaboration.

But I'm not focused so much on Git, as I am on GitHub. You see, Git is just a command-line tool. (Yeah... there are various GUIs for it now - but for most of its life, it's been, almost exclusively, a command-line tool.) When you're using that command-line tool, you probably aren't paying much attention to which files use 2-indent spaces, versus those that use 4-indent spaces, versus those that use tabs. You're just crossing your fingers and hoping for no merge conflicts.

Git Hub, however, is a different beast altogether...

GitHub was one of the first tools that allowed distributed teams to easily browse everyone else's code, and everyone else's branches, in the ever-present viewport that we've all come to know as a "browser". There probably were some other source control tools at that time that allowed you to peruse others' code on the web - but I'm not aware of them. GitHub was the first time that I remember logging into a web-based portal and browsing through commits.

GitHub was released in 2008. In other words, by the time that GitHub first started to gain massive traction amongst the digerati, jQuery was in full swing, and true honest-to-goodness professional JS dev teams were starting to collaborate over the web.

Why do I connect the rise of GitHub to the implementation of 2-space indentation?? Well... have you ever looked at tab-indented code files on GitHub? As a web-based client, GitHub used the default representation of tabs in HTML. In other words, GitHub always displayed tabs as taking up 8 spaces.

Furthermore, since many people were (and still are) writing JS in relatively-narrow viewports, I believe there was this natural pressure to make the code as "skinny" as possible. In the width-restricted world of web-based portals, even a luxury as simple as a 4-space indentation can feel unwarranted.

No one likes scrolling horizontally. And web-based portals are too-often squeezed into narrow viewports. So, from this perspective, it almost seems natural that the JS community - children of the web - would coalesce around a 2-space indentation standard.

To be clear, I'm not asking you to agree with me. And I'd love for someone to "set me straight" on this. But as far as I can tell, I truly believe that GitHub, more than any other factor, is responsible for spurring the 2-space indentation standard that we see today in sooooo many JS projects.

2-Space Frustration

Despite my (well-earned) cranky-old-guy reputation, the fact is that I do not lay awake at night gnashing my teeth over tabs-vs-spaces. If you haven't figured it out by now, I really prefer tabs. But no one really gives a s*&t what I prefer. And I get that. So on most days, on most projects, I just allow the editorconfig file to dictate to me how my code will be formatted - and I move on.

But this is my blog. And my readers (both of them) deserve to get a healthy dose of my whining and griping. So FWIW, I'm gonna close by pointing out some things about the 2-space indentation standard that make me frequently bite my tongue.

Accessibility
Oh, man... I hate having to spell this out, because it just proves how friggin old I've become. But the more JS code I look at, the more it's clear to me that these two examples are not the same:

// Example 1
const doSomething = (trials = 0) => {
  for (let i = 0; i < trials; i++) {
    const data = getTrialData(trial);
    if (data.length) {
      const filteredData = data.filter(datum => {
        return getConstant(datum.someProperty);
      });
    }
  }
}

// Example 2
const doSomething = (trials = 0) => {
   for (let i = 0; i < trials; i++) {
      const data = getTrialData(trial);
      if (data.length) {
         const filteredData = data.filter(datum => {
            return getConstant(datum.someProperty);
         });
      }
   }
}

If you look at those examples carefully, you'll quickly realize that there is no functional difference between them. They both have the same code. The only difference between Examples 1 & 2 is that Example 2 is indented with 3 spaces. Example 1 is only indented with 2 spaces.

Why does that matter??

Well... it probably doesn't - to you. Unfortunately, I can tell you with absolute certainty that it's harder for my eye to follow the nested logic in Example 1 versus the logic in Example 2.

I've been through this 1,000 times. I've adjusted 1,000 different settings in my IDE. But no matter what I try to tweak, there are still times when my eye gets "lost" trying to follow nested 2-space indentation.

When I've been in codebases that used tabs, this was never a problem. Because I could set my own personal IDE settings to display tabs at any width that was comfortable for me. But when a file uses 2-space indentation, I'm pretty much stuck viewing it in the exact same way. And I'm pretty much resigned to having to spend more time reading and understanding the code.

For me, there's just something about having that extra space in the indentation that makes it sooooo much easier for me to read. Unfortunately, the "powers that be" that want to impose 2-space indentation upon all of us couldn't care less. In fact, more than a few of my coworkers have been downright dismissive and insulting when I try to explain this to them.

Antiquated Comparisons
When I've been foolish enough to talk to someone about tabs-vs-spaces, I can't tell you how many times I've run into this (completely antiquated) idea that tabs are somehow ridiculous to view. In other words, they're still subconsciously referring back to the way that tabs are rendered, by default, in a browser (as in, when they're viewing the code in a GitHub browser window).

Even though they claim that tabs are just oh-so-horrible to visually parse, they can't show me how these tabs look so horrible on their screen. This happens because, on their screen, they're viewing the code in their IDE - and their IDE does not display tabs as taking up 8 spaces.

In fact, I've noticed over the years that almost all code reading happens on a dev's individual screen, in their IDE. In other words, they almost never see tabs represented as 8 spaces. But they still seem to have this vestigial distaste for what might happen if they ever chose to view the code in a browser window.

Tool Ignorance
I know there was a time in GitHub when mixing tabs-and-spaces could cause havoc. Specifically, it could drag you into a morass of merge conflicts. But I've noticed that a shocking number of current-day devs really have no idea of the inner workings of Git. Specifically, they seem to assume that any whitespace change will cause a merge conflict - or will screw up their code reviews. Of course, these same devs typically misrepresent what Git can currently do.

A few years ago, I was working with a guy who was a complete, pedantic, Grade-A jerk. I'd submitted a pull request (on a section of code that he never would have any reason to touch) - and he declined it.

What was my offense? The files contained tabs. He threw his hands up in the air (literally) and said, "There's no way I can review this. Because the diff thinks that you've changed every line in the file."

I replied to him, "The diff says I've changed every line in the file after you've told it to ignore whitespace???" He looked at me with that perfect blend of annoyance, and confusion, and exasperation. I honestly think it's the first time he'd ever realized that there was such an option in GitHub.

But the issue really had nothing to do with GitHub's "ignore whitespace" option. The issue had everything to do with the fact that my code had a tab in it - and he was gonna teach me a lesson.

The Stack Overflow Curse
By now, we've all seen the reports. Some years ago, Stack Overflow, in the midst of their broad all-dev survey, "discovered" that devs who use spaces make more money than devs who use tabs.

Honestly, that one "study" has caused more headaches for me than they could ever imagine. Suddenly, every snot-nosed junior dev who used spaces could look at me with some smug holier-than-thou expression and say, "Well, you know... devs who use spaces are paid more."

The problem is that those snot-noses can't tell you why they're paid more. They want to believe that the mere act of using spaces-over-tabs somehow makes you more valuable in the workplace.

No one ever stopped to consider that, for the last decade-or-so, "frontend" development (which used to be dismissed as somehow "lesser"), has moved to the forefront in many job marketplaces. And since JS now, for quite some time, has already adopted space-based indentation as a standard, it only stands to reason that they are getting paid more.

They're not paid more because they use spaces-over-tabs. They're paid more because they have a skillset that's in higher demand - a skillset that's just-so-happened to have coalesced around space-based indentation. But don't try explaining that to any of the sycophants who want to sing the holy praises of 2-space indentation...

Conclusion

In the end, I don't really think this article has anything to do with tabs or spaces or any other standard for indentation. My deeper interest is in how trends blossom and take hold. How they proliferate. How they become "standards" - even at times when there is no empirical evidence to support them.

I understand (I really do) that, sometimes, you just pick a "standard" - any standard. Because it can be preferable to having no standard at all. But after a quarter century in this game, it still sometimes frustrates me to see the haphazard way in which certain standards are adopted - and others are thoughtlessly discarded.