After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah.
Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabbed size: 27.3MB. 2MB more of indentation saved! Not significant after compression, but parsing time over billions of starts? Definitely worth it.
Not everyone with vision or vision processing issues is blind. Being able to configure custom tab stops is an easy way to control what level of indentation is useful and clear.
Python has syntactic blocks as well, and editors totally can (and do) muck around with their formatting. I don't see any reason why they couldn't handle customizable indentation.
> The solution is to use tabs for indentation, and spaces for alignment.
It's the second step that drives me nuts. Why can't/doesn't alignment happen at first step? The inconsistencies of alignment using true tabs, in a monospace plain text environment, grosses me out and decrements my faith in the underlying systems. I appreciate editors w/ settings like `insert spaces when pressing tab` and `the number of spaces a tab is equal to`.
This is one of those things that started out as good advice, and then got turned in to an oversimplified parody of the original argument.
If you have something like:
var (
x = foo
other = bar
)
Then clearly you should use spaces to align those "="s, no matter if you use spaces or tabs for indentation. Similarly, "hanging indents" like:
coolFun(arg1,
arg2)
Can only be done correctly with spaces, and it doesn't really matter if you use tabs or spaces for indentation; this will still align correct no matter the tabstop size:
If you had used tabs, changing the tab size would make it align all wrong.
The problem is when you start doing stuff like:
if (one) {
------>if (two)
bar();
------>else
xxx();
}
And then, depending on the tabstop size, things can start looking very misaligned and confusing; this is why Python 3 forbids mixing tabs and spaces in the same function, because it's so easy to make something appear wrong and there are no braces to clarify things.
That's what people mean with "don't mix tabs and spaces", not "if you use tabs then the space shall never appear in the file under any condition".
To understand tabstops properly, you need to throw away the "They always expand to N spaces." idea. If you have access to a mechanical typewriter with tabstops, then go and look at how it works (with tabs being set by protruding pins on the carriage). Tabstops in terminals in the Unix and Linux worlds work this way.
> > If you had used tabs, changing the tab size would make it align all wrong.
> This is clearly false. You said this after giving a perfect example of how it's done with tabs.
I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.
When I made my original comment I thought what I was replying to was an example of "tabs to indent and spaces to align" immediately followed by a statement that the only way to use tabs is to both indent and align.
The basic idea is that you use tabs to align "blocks" (ie, multiple lines at the same indent level), and then spaces from there to align line "elements")
Aligning lines in the same block
____var a; // indented with a tab
____var b; // indented with a tab
Aligning elements of a line with the previous line
____var a, // indented with a tab
____----b, // indented with a tab, then aligned using spaces
The idea being that tabs are used where it makes sense that you could change them for preference and not have things look wonky... and then spaces are used in situations where a specific number of characters is necessary.
Another alternative is elastic tabs, where tabs are used for both of those, but are converted to an indentation/alignment number of characters semantically. I like the idea, but I've yet to see a good implementation.
Personally I'm a fan of all spaces, but that's mostly because every company I've worked at has used that.
> The real problem is that using spaces for indentation is an accessibility issue.
The problem of leading spaces not changing their size can be solved through programming.
Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them.
The use of tabs is detrimental to code bases. Whenever tabs creep in, invariably people use different tab settings and make a dog's breakfast out of the code.
Code exhibits indented sub-structures that are internally indented, but not themselves not aligned to a tab stop, but aligned with something. One kind of example is something like:
function_name_of_random_length(lambda (a, b) {
if (a < b) {
indented();
}
},
arg2);
While that may be true, "spaces for alignment" is nigh unsupported by all editors I've seen. They insist on replacing 8 (or N) spaces with tab even if in an alignment region.
int foobar(int a,
___________int b) // should only ever have spaces (using _ here because HTML)
But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong).
The other issue I have is that diffs break alignment between undented code and anything with tabs because the tabs "eat" the leading space, but unindented lines are offset by one.
When I'm working in Git, Go, or Linux code, Vim (and NeoVim) uses `expandtab` in conjunction with `softtabstop` and converts any `tabstop` spaces into a tab (with `noexpandtab`) regardless of whether or not it is "alignment".
I've not done lots of development with other editors, but Kate didn't do it and the few times I used Visual Studio, it also had similar behaviors (I'm assuming VSCode inherited that stuff).
I used to tout "tabs for indentation, spaces for alignment" until I started working primarily woth lisps. Idiomatic lisp indention isn't compatible with regular tab-stops, so the only solution is to go with spaces (maybe losing accessability) or, preferably, to go elastic.
Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one.
For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors and people just went with it. The people earning more are doing so because those are the seniors who have given up on common sense and just go with the flow of the masses who are unable to grasp "tabs for indentation, spaces for alignment" yet insist on keeping alignment so the (terrible) compromise is just using spaces. And I strongly question whether "alignment" is worth anything, in almost all cases it's just useless and in the rest you're drawing ASCII diagrams in the comments which doesn't affect your code at all.
Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency
How do you work with max-char-per-line limits of coding conventions ?
Does code you write with tabs as 4 spaces follow the convention but then break on Linus computer ?
I personally use a vertical monitor, in Jetbrains that gets me about 130 characters on a line before scrolling, and in VIM it get me about 125. I'll break a long line into shorter lines if they begin to approach the end, but I'm not strict about it. From what's open right now I do have a few lines that get close, and one that goes over. So what? All my coworkers use horizontal monitors and even with gutters and panels open they're not complaining about my line length - and I've not had a complaint about line length since I've started in this industry in 1999. Back then there were no vertical monitors, it was all 4:3 CRTs.
As an interesting note, I now work with the second hard-of-sight developer that I've worked with in my life. They both use normal Jetbrains IDEs, with font sizes and interfaces made huge. Neither of them has ever said a word about my line length. Nor my function length. Nor my long variable and method names. Nor my explicit comments, nor my detailed git commit messages, nor my frequent git commiting, nor my branching preferences, nor my README files, nor my obsessive security practices such as validating types and character length limits on input fields and sanitizing and filtering input and my rejecting of any PR with concatenated outside-data in SQL (even if that outside-data came from the DB itself, for a recent example), and all the other idiosyncrasies that one dev suffers from another.
Line length? Not a problem. Forcing the hard-of-sight dev to indent however _I_ see fit? I wouldn't dream of doing that.
Is there really a value of a max-char rule these days? Editors can scroll, softwrap and usually do neither as screens are large anyway. A max-indent rule makes sense to highlight when you're nested too deep and should refactor, but a long line of code can either be done based on "this looks unusually long" or a formatter that has a set tabwidth.
No, it's incredibly stupid and is missing the point. You use tabs to not be consistent. So that the crazy js person can have a 2-wide indent and the slightly visually impaired person can have an 8-wide indent without reformatting the entire codebase
Are you visually impaired of have you received or read criticisms of this nature from visually impaired persons? Genuine curiosity, because if this is a matter of accessibility I would vouch for tabs.
Thing is that with spaces you can also predict consistently the line length and not have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
In any case, I like spaces but I am impartial to either one. You seem like you have very strong opinions about the matter so I won't push the subject further.
> Thing is that with spaces you can also predict consistently the line length and not
> have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
Spaces force you to worry how that other dev will see the code. Tabs are semantic - you set the editor to display how _you_ like to see it and that other dev sets the editor to display how he likes to see it.
Testimonial: I experienced a significant increase in earnings about 4 months after abandoning tabs for spaces. Cause not known but that’s what happened.
The decision to use a character that is 8 chars wide for indentation of a highly nested code was not a brightest idea either.
I’d love to set up terminal tabstop size, textview tabstop size, github tabstop size, IM tabstop size, HN tabstop size, git gui plugin tabstop size, issue tracker tabstop size, tsv file format tabstop size if I used tabs. It makes you so productive.
English is a bad convention too but we use it because humans don’t need the theoretically best systems to be productive, they need something good enough. Spaces are good enough, tabs are good enough, and anybody who gets emotionally invested in one vs. the other is wasting time.
Alingment is leading whitespace that is expected to match the width of some non-whitespace text above, indentation is leading whitespace that is just expected to match all other indentations (* level). When indentation is scaled through editor reconfiguration, alignment should stay the same.
What I think gp is underestimating is just how much alignment there was in the old days, and how little (compared to now) indentation. From today's perspective, indentation is the norm and alignment is the rare exception. Your question is a good illustration: sounds like you never met alignment, or at least never noticed it. But back then, alignment was a very regular occurrence and the extra diligence required for getting all the tabs and blanks right to look nice on different tab widths, or the ugliness from failing to get the mix right would have been a considerable cost. Avoiding unpredictably wide tabs was a reasonable call.
I wish they had broken down that survey question further to find out _how many_ spaces the highest paid developers use. Then I could finally have a data-driven answer to put in my prettier config!
That's not how statistics work, unless you assume there is a correlation between tab users salary and their willingness to respond to surveys. Which would also be an interesting find
I'm curious if you've actually worked with surveys before, because this is how statistics work. All self-reported data has a bias based on a user's willingness to reply, and considering that predisposition as a variable is required.
This is the exact reason that crime statistics are so crummy, even from anonymous surveys. Very few are compelled to admit to a crime that they haven't been convicted of (and some won't even to admit to that). Or why post-sale NPS scores have a negative bent - you're more likely to respond if you have a complaint.
This was actually a significant issue in a large PHP codebase I used to work on. Client hired a new guy who insisted that we convert everything to spaces, and suddenly it took about twice as long to check the thing out from Subversion.
Or like, cool, this is the code style. I don't care if it's sublime or stinks to heaven. When we get to a total rewrite we'll address that. Which features are you hiring me to implement? Which bugs need to be fixed? How can I not waste my time or yours?
Seriously, this takes yak shaving to a whole new level.
I see your confusion. They said Subversion with a capital S. So the source control system, not the covert destruction of a dev team from within. Easy mistake to make. (... Stupid git.)
Reminds me of Silicon Valley (HBO) where Richard uses “we are a compression company” to justify using tabs over spaces. Ironically once gzip compressed I doubt it would make any difference.
Even on an absolutely gigantic codebase using tabs or spaces will make almost no difference to build or type-checking times. Building an AST is much more overhead than white space considerations and once it’s an AST tabs or spaces are not included in the running of the code.
Does that mean they are not using type checking? That’s the really really slow part of writing TS and es build doesn’t include it, which is why I’ve never seen the point of using esbuild as a compiler.
We are still type checking, it's just not needed as a dependency for our JS outputs. Type checking still happens in tests, and I have CI tasks and VS Code watch tasks which will make sure we are still type checking.
It's not perfectly cut and dry, but mostly. We still need to emit d.ts files for our public API, and the only thing that can do that is tsc, which will type check.
But I tried my best to make the build have fast paths to minimize the development loop as much as possible.
Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabbed size: 27.3MB. 2MB more of indentation saved! Not significant after compression, but parsing time over billions of starts? Definitely worth it.
[1] https://github.com/evanw/esbuild/issues/1126