1

As I have recently started using ES6 in production, I was going through an ES6 style guide (having more than 350 stars on GitHub). This guide mentions at least three times that "Tabs are evil. Don't use them!"

Also, another very popular JavaScript style guide by AirBnB also recommends using 2 spaces for indentation instead of using hard tabs.

Although I have been using tabs for all my frontend development (ES5 of course), and have no problems till now. I just want to know why tabs are considered evil in ES6? I thought it is completely personal stuff and it shouldn't matter. But are there any special scenarios in which the tabs can really become evil for ES6 development?

closed as primarily opinion-based by gnat, thorsten müller, Andy, Bart van Ingen Schenau, Jörg W Mittag May 9 '17 at 9:19

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Possible duplicate of Why do some languages recommend using spaces rather than tabs? – gnat May 9 '17 at 6:02
  • Oh, gosh... telling people that spaces are better because you're making yourself to do so much more totally unneeded work, but hey, "we saved ourselves 2 minutes configuring the editor and then for 3 years we'll be hitting space key 4 times instead of typing a tab". Progress ;) The topic you linked should be used as a definition of laziness on the wikipedia. And let's not use IDEs, they're much harder to install than Vi. Usually it's smart... to work smart... – Slawek May 9 '17 at 7:45
  • 7
    @Slawek Most IDEs and more advanced text editors allow configurable soft tabs, so using spaces over tabs is no more effort than using hard tabs. – phuzi May 9 '17 at 8:12
  • 1
    Beside it combats most of the advantages of using tabs, like you cannot format code easily anymore, cannot use different tab size for each team member, you need to be counting space characters and people still are making mistakes so code gets formatted incorrectly... – Slawek May 9 '17 at 9:09
  • 2
    This question is off-topic here: we cannot read minds, if you want to know why some random guy on the internet says something, you need to ask that random guy. See also Discuss this ${blog}. – Jörg W Mittag May 9 '17 at 9:20
7

Because some people are unfortunately - stupid, and they still didn't notice it's 2017 not 1987... and they'll make everything to add themselves some work because their IDE/Text Editor is so old or so lame, it cannot properly support stupid, configurable tab char.

And the second part of the issue is that node.js architecture is a DISASTER. All the way. Almost nothing is working like it should. Starting from lack of working scheduler, and writing scheduling code "by hand", to improperly working foreach loops and no usable error support, ending with nested callback code which is WORSE and harder to maintain than goto-spaghetti written in the early days of '90 Microsoft Basic.

I'm not surprised that group of devs comming from an enviroment of people who cannot get a design of stupid "for" loop well - is having issue with a concept so "complicated" as tab character... and to add to the stupididy, all they can say is "tabs are evil". Well that's a great argument ;)

  • Tabs make code easier to read for different people on different devices (especially different screen aspect ratios)
  • Require less typing
  • You don't need to count characters so it's much easier to not make formatting mistakes
  • You don't need to argue like an idiot, about using 2, 4 or 5 spaces... you set it in editor
  • Are designed to indent not to separate words, like space

"Tabs are evil" is like arguing that page breaks shouldn't be used in DTP... let's align using newline.

No, the proper sentence is not "tabs are evil", but "we're too stupid to make our work easier, so we'll be working like in the '90s". It's not some C Kernel code where using spaces is justified at least historically, node is supposed to be "modern" way of programming modern interfaces.

JS is great for UI's developement, and totally SUCKS for the server side. It's interesting how even the "style guide" tells how badly it's designed for serverside code, and how bad this "coding guide" is, because AGAIN... some genius thought that "one size fits all", to propagate this moronic myth of "code which could be used both on client and on the server"... So do yourself a favour, if you're writing serverside - stay away from node. Use golang, scala, c#, php, c++, D... anything!

And don't allow anything related to JS to pollute your coding enviroment too much. These coding "requirements"... that happens when you want to create something that "fits all".... as, eg. using setTimeout it perfectly fine on clientside UI developement, but usually not a very good idea on the server-side.

Although I have been using tabs for all my frontend development

As any sane human being would do nowdays, if he can...

  • 1
    This answer seems overly combative. There's a valid point in there about IDE support, so perhaps an edit is in order? – Andy Hunt May 9 '17 at 8:19
  • 2
    @Slawek omg +999999 for having the guts to say what everyone is thinking!! – Ewan May 9 '17 at 8:31
  • 2
    This answer doesn't answer the question at all. What does the architecture of Node.js have to do with tabs? Why do you recommend using Go (whose official styleguide advocates using spaces over tabs), Scala (whose community styleguides advocate using spaces over tabs) or C♯ (whose community styleguides advocate using spaces over tabs) over ECMAScript (whose community styleguides advocate using spaces over tabs)? – Jörg W Mittag May 9 '17 at 9:17
  • @Jörg W Mittag If you'd saw github spaces vs tabs statistics, you'd realize that golang formatting is "use go fmt which will do it automatically"... and "use spaces only if MUST"... so it's the only language which has i think 99.9% tab usage. I mentioned archietcture, because if something is totally broken from the start... you may use some caution when reading "good programming practices", for a broken architecture. For the other languages, these were designed long time ago, when there were problems with tabs, which we don't face today. goo.gl/MS67ZY – Slawek May 9 '17 at 9:25
  • 1
    "if you're writing serverside - stay away from node. Use golang, scala, c#, php, c++, D..." php? :) – Orangesandlemons May 9 '17 at 10:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.