Who Killed The Tab?
Tags: codequality, javascript, oop, ide
Published: 2020-10-28 03:13:10

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**??_
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s60bawaicfepru5co1c0.jpg)
## 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:
<br/>

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_.
<br/>

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.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ecipi3irtsl9wolcg8ia.jpg)
## 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**??_
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/bio7qwjww7fwo9nql4cb.jpg)
## 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:
<br/>

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...)<br/><br/>

1. **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".<br/><br/>

1. **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_.<br/><br/>

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.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5r3qq7r8ev3exbqi5gqb.jpg)
## 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.<br/>

1. That indentation shall be two - and _only_ two - spaces.<br/>

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?
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/bllaqp0671ftxi7ix6y6.jpg)
## 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.  
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/247e7jrh9p304szcyt3i.jpeg)
## 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_.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ulgh23lczidzp5pi564d.jpg)
## 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.  
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/co8ae0ul4mxtf80l8jo3.jpg)
## 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:

```javascript
// 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...
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/xyg0bxle2kkoutrjv0bi.jpg)
## 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.