That's really your problem. If you think people will stop aligning things in their code because you are in the tiny minority that use proportional fonts, you're crazy.
> Matching up the initializer values for i, j, and k means my eye has to scan way across a sea of whitespace and hopefully remember which line is which when I get there.
Nobody's actually going to do what you just showed in real code. Instead, it would look like this:
var i = 123,
j = 456,
k = 789,
aMuchLongerVariableName = 'foo';
And still look quite good.> Finally, the example with the escaped newlines all in a vertical column does not do at all what he expects! All those extra spaces become part of the string.
Absolutely, but if you are putting HTML in that string (a while other discussion there) 99% of the time the whitespace will not matter. And for all the other cases, this is no different from multiline string behavior in Python and other languages.
They work only in a monospaced font. I code in a proportional font, and none of the column alignment tricks will look right when I view the code.
Even if you like to code in a monospaced font, there's no reason to write code that becomes hard to read in a proportional font. It's very easy to write code that is perfectly readable in both monospaced and proportional fonts: you merely forgo these column alignment tricks.
Also, this style of code is a pain to maintain. If you add a variable with a longer name, you have to go up and down adding spaces in front of all the other = signs.
And I find it hard to read even in a monospaced font, e.g.
Matching up the initializer values for i, j, and k means my eye has to scan way across a sea of whitespace and hopefully remember which line is which when I get there.Finally, the example with the escaped newlines all in a vertical column does not do at all what he expects! All those extra spaces become part of the string.