Switch to hard tabs for indentation

[Cherry]

First of all, so excited for this release! I'm barely 1/10th done reading through the source 👀

---

Prior precedent:

• Switch to hard tabs for indentation workers-sdk#1298
• refactor: switch to hard tabs for indentation templates#76
• https://twitter.com/threepointone/status/1541713676180361218

Everyone has their own opinions about how much visual indentation they want in their code. Some prefer 2 spaces, some prefer 4, and then some users may be visually impaired and need higher font sizes with smaller tab widths, etc.

There's been a tonne of debate over the years about which is better, and it's always come to down to arguments that are opinion based, but the one major and consequential difference between the two is this:

Tabs allow individuals in the same codebase to select their indentation widths across every tool.

To affirm the accessibility issue, I'd recommend reading through https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/:

coworkers who unfortunately are highly visually impaired, and each has a different visual impairment:

• one of them uses tab-width 1 because he uses such a gigantic font-size
• the other uses tab-width 8 and a really wide monitor
• these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing

Other references:

• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/
• https://alexandersandberg.com/tabs-for-accessibility/
• https://adamtuttle.codes/blog/2021/tabs-vs-spaces-its-an-accessibility-issue/

In the JavaScript ecosystem, Prettier is likely to switch to useTabs by default with the next major version too, for this exact reason: prettier/prettier#7475

Other than the obvious code change differences, shipping an .editorconfig in this repo for some sensible defaults would probably be a good idea too, to combat one of the most common counters to this, which is how some tools render tabs by default. This way, tools like GitHub can render tabs with a 4 character width by default instead of the usual 8, but folks can still customise this themselves if they so choose. Something like this:

# http://editorconfig.org
root = true

[*]
indent_style = tab
tab_width = 4

I'd like to avoid any debate around personal preference here and focus on the accessibility issue of continuing to indent code with spaces.

[tomByrer]

Tabs allow individuals in the same codebase to select their indentation widths across every tool.

Helpful for those who are sight-impaired & have atypical font & indentation sizes.

[kentonv]

Hi @Cherry,

I appreciate your detailed discussion, and you make some good points. Ultimately, though, just as technology has overcome the problems that tabs had in the past (when too many editors treated them as always 8-space), technology can also overcome the problems with spaces (most editors are able to deduce the indentation stops and treat spaces the same as they would tabs). At the end of the day, these are simply two different encodings of the same semantic information, and if they behave any differently in editors at all, that is a problem to fix in the editor. There is no reason an editor cannot adjust indentation widths when the indentation happens to be encoded with spaces.

Meanwhile:

• Coordinating a change would be a significant amount of work for us, considering that many engineers have changes in-flight at all times and modifying every line of code would lead to conflicts with those changes. We would need to build a process to get this through without disruption, and that process would be a lot of work, taking away engineering-hours from other things.
• Our major dependencies, Cap'n Proto and V8, also use 2-space indents. While Cap'n Proto is under our control and could potentially be updated too, V8 is not. Our engineers commonly have to cross between these codebases, and using different editor settings in each would be disorienting.

So, it doesn't make sense to us to make any changes at this time.

Eventually, we would like to adopt auto-formatting, although our experiments with ClangFormat so far have not produced acceptable output. Assuming we can fix the issues, then an auto-formatted codebase would make it even easier for everyone to use whatever they personally prefer -- you can always auto-format files to your preferred format, make your changes, and auto-format back before committing. (Hopefully, editors can do this automatically.)

[Cherry]

While this is disappointing, and I wish I shared your optimism here, I understand. Thank you for the response.

I'll pin this for revisit again in the future.