Ask HN: Why do the majority of JS developers prefer spaces over tabs? | Hacker News Reader

Ask HN: Why do the majority of JS developers prefer spaces over tabs?

8 pointsiLoch24 comments

I know this is a hotly debated topic, but I have to ask. Why is it that specifically for Javascript, 4 in 5 developers prefer to use spaces instead of tabs[1]? I've decided to switch from using tabs to 2 spaces because I'd rather convenience other developers than burden them, but I still don't understand the reason. Tabs take up less space in terms of bytes, and are dynamic width allowing the user to set the width to their personal preference. Sounds like a perfect solution to developers agreeing on a specific number of times to hit the space key. So why are spaces so popular?

[1] http://sideeffect.kr/popularconvention/#javascript

View on HN

Because spaces are rendered the same everywhere. Suppose I write this code, indenting using spaces.

    im_a_long_method(argument_no_1,
                     set_indentation_true(...),
                     no_string_cutoff,
                     whatever)

Now suppose I used tabs to indent and my editors tab width is 4 spaces while your is 8 spaces, then the above would look like:

    im_a_long_method(argument_no_1,
                                      set_indentation_true(...),
                                      no_string_cutoff,
                                      whatever)

Since not every editor agrees on how wide a tab character is, you get crappy alignments. Therefore use spaces.

> Because spaces are rendered the same everywhere. Suppose I write this code, indenting using spaces.

Then it'll look wrong in a proportional font; indenting and aligning with non-indented text are different things. Either spaces or tabs indent consistently when used consistently in a source file. Alignment cannot be acheived consistently (with spaces or tabs) unless you also assume a monospaced font, or (with tabs) have elastic tabstops.

...and maybe that's why most popular coding fonts are monospaced?

> ...and maybe that's why most popular coding fonts are monospaced?

Yes, the desire to use alignment without something like elastic tabstops being widespread is the limitation which prevents wide adoption of otherwise-superior proportional fonts in coding.

I really don't get the point of tabs for visual layout in any kind of document be it plain text, source code, or a word processor document. They never seemed to work right for me.

I remember using the tab key to enter tabs back in school to make something like an informal, 2-or3-column table (or whatever I was actually doing). This would have been in Word. Things would line up pretty until I wanted to change some text. If I made it longer I would need to add another tab because the tab had shrunk to nothing. If I made it shorter the tab would jump into the previous section and no longer line up with the other lines.

As far as I can see, the same will happen with this source example if it were using tabs and a proportional font.

Elastic tabstops are so named because the width adjusts based on the content, avoiding that problem. http://nickgravgaard.com/elastictabstops/

> Then it'll look wrong in a proportional font

Programmers don't use proportional fonts. Source code maintenance is hard enough without asking for trouble.

This is a great argument, thanks.

In days gone by (pre git) a lot of devs used to share files via FTP; and the FTP clients back then were garbage; if you were sending files from a unix-like computer to a windows one and back and forth, your tabs might get converted to spaces by the client. Developers would end up with slightly different copies of the same file.

Many people decided to standardize various things (like the use of spaces for indentation) to compensate for this.

These days not a huge deal.

> Tabs take up less space in terms of bytes

Optimizing for size in the primary format for editing isn't that important. For deployment, sure, but you're going to minify for that anyway, right? So spaces vs. tabs makes no difference for that.

I think the fact that tabs take up fewer bytes is basically irrelevant. For anything that matters, the JS will be minified anyway, removing the whitespace.

I decided to use spaces instead of tabs and convert a tab to two spaces because while typing I sometimes alternate between using the space bar and the tab while indenting something or editing code. So it is much easier for me to be consistent as an individual dev with spaces.

I prefer spaces (4 spaces to be precise), because I can write like this:

var abc = something,

    xyz = somethingElse,

    stringOfAbc = abc.toString();

the variable names are neatly aligned on the left side!

I remember once I got an error in an python script, and had to convert all tabs to space. Btw I am JS developer.

This experience is more common than most people realize. A Python program mysteriously stops working, especially after being transferred to a new platform, and the most experienced hands will suspect a mixture of tabs and spaces, and/or tabs being treated differently than expected.

> Why do the majority of JS developers prefer spaces over tabs?

Because, with a fixed-pitch font such as is used in programming, the meaning of a space is unambiguous (unlike tabs). Also, having two indistinguishable whitespace characters is bad, and mixing them in a single file is worse. So one chooses the least problematic of the two.

I'm a Python dev, and it's the same in Python world. I prefer spaces, and so do most other Python devs. This is in line with one of the Python community's core beliefs - "Explicit is better than implicit"

It helps that PEP define that spaces is explicitly correct as well.

"Explicit is better than implicit"

I think making the implicit explicit is also a belief of most logical devs outside of the Python community.

> "Explicit is better than implicit"

Seems like a strong argument for sticking with strongly typed languages.

Python is strongly typed.

Dynamic typing and weak typing are not the same thing.

Python:

    >>>1 + "1"
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: unsupported operand type(s) for +: 'int' and 'str'

PHP:

    >1 + "1"
    2

Except when it comes to closing brackets... sigh

Why would you need those when you have indented blocks as a language feature? Unless you really like one-liners, in which case you should just use Perl or Ruby.

Kind of an old-school thing, I prefer the visual/literal cues of opening/closing brackets in statement groups, I guess I don't really trust encapsulation my mere indentation.

So yeah, I would prefer explicit (brackets) over just implicit (spaces), in python.

Perl and Ruby aren't Python.

Reply on news.ycombinator.com