I could craft you unreadable code in any language. Someone removing all of the whitespace between their operators is not going to be producing code that I want to be responsible for maintaining... in any language.
Go has an interesting take on whitespace-around-operators -- it starts removing whitespace around binary operators if there are higher precedence operators in the same expression. So, for example, you get:
x = 2 * y
x = 2*y + 5
This is pretty readable. In fact I think it is more readable than the usual convention of "spaces around every binary operator," but it would be untenable without the existence of gofmt. The most common argument against a convention like this is, "subtle bugs will be introduced if the actual precedence is different than the one implied by whitespace," which is why it's great to have a benevolent formatting overlord telling you when or not your formatting is consistent.
That's why Perl 5 is still an unbeaten champion in terms of managing the complexity of legacy code. Perl::Tidy (and Perl::Critic) is a super-configurable beast to the extent I've not yet seen in other languages.
You could probably do something similar in Javascript or Python, there are many tools that provide you access to the AST, it's just that no one has written such a tool on top of it (or maybe they have, but they never gained traction).
The funny thing is: most languages have a development philosophy completely opposed to TIMTOWTDI, so they are all trying to write a tool for the one perfect formatting style, not a universal tool with enough flexibility for the different styles. The former usually leads to enough segmentation for every effort to die in its infancy, the latter to Perl::Tidy.
This is especially apparent with Python with its PEP8 standard -- most formatting tools only deal with PEP8 compatibility and only in one direction. Especially with Python, automated code formatting is mistaken for beautification and thus there is a remark in PythonTidy's documentation "Python scripts are usually so good looking that no beautification is required".
I tend to think this is exactly the same thinking that has lead Perl into the mess that's slowly being fixed since about 2005 and I cherish the difference between a language community which has had its painful experience with insufficient tooling and learned from it and the one which hasn't.
