There are different vectors of attack when it comes to optimization.
The point of CS is to optimize for developer productivity and happiness, so I think your questions are largely missing the point. It's like asking "well that's a good screwdriver, but does it hammer nails?".
The correct question to ask is: what do I get from this syntactic sugar, and what do I trade. Or to stick with our metaphor:
"What does this screwdriver bring to the table, and does it INTERFERE with the hammering of nails etc?".
So as stated, CS lets you write code faster, express yourself more clearly, and removes headaches common to Javascript. These headaches are problems that are largely not addressed by other tools like jQuery (which have different goals).
To answer your questions:
> Does it fix browser incompatibilities for you
Yes, but only in terms of the language. CS compiles to lowest common denominator Javascript, so you know the compiled code will run just about anywhere.
So you don't have to worry about whether or not the browser's JS engine supports list comprehensions, because you're using CS.
The question is not so much "Does it fix browser incompatibilities for you".... but "Does it introduce browser incompatibilities?". To that, the answer is no.
>Does it optimize Javascript to run faster?
CS allows you to write really expressive code that gets compiled down to simple (but verbose) forms. This has the side-effect that CS code will generally be faster than Vanilla JS code that is written with a similar expressiveness.
In Vanilla JS you would generally have to introduce a library to get the same expressiveness, and that has a run-time penalty. For example: Something that is compiled to a simple for-loop in CS would require a bunch of function calls in a library in vanilla JS, adding a lot of overhead.
CS is not a tool to optimize code, so asking if it optimizes code misses the point. The real question is whether or not it introduces inefficiency, because if it does....that's a drawback that needs to be contrasted to it's benefits.
In this case, no it doesn't...and the code it produces is sometimes faster than similar vanilla JS code.
>Does it have a kick-ass library that's optimized for it?
CS is not meant to fill the same role as a library.
The question is not "does it have a library"...but "what's the implications of using CS vis a vis libraries?" The answer is CS interacts with JS seamlessly, use any library you like.
>Is it easier to debug?
No, because that's not the point of CS. CS is not a debugging tool. The right question is: "is it harder to debug?".
Here we hit what imho is the only real trade-off involved in CS.
Some will hem and haw about having an explicit compilation step; but the tooling support for CS is great and any serious JS developer can fit it into their dev process seamlessly (via commit hooks, watch, build scripts, etc).
Debugging problems is a legit concern, but in my experience it does not add significant problems. Errors in CS syntax are generally caught during compilation and other errors can often be easier to find because the CS code is cleaner and it's easier to catch errors in logic.
I think beginners will often hit problems with debugging and CS because it adds a layer to confuse them. Experienced JS devs on the other hand should be able to cleanly separate the layers and debug them effectively.
The tooling for debugging CS in the future looks promising and will improve the situation.
As for your suggestion that you could just improve your text-editor, use macros, etc....I think that's a good tool to have in your belt but it just doesn't compare to what CS brings to the table.
Either you'd be duplicating CS's efforts ...or you'd not hit the same level of capability...
In the first case, it'd be a pointless re-inventing of the wheel, but your wheel would have drawbacks CS lacks.
With CS there is:
- Lot's of editor support. Your suggestion is tied to 1 editor.
- Lot's of tooling support. There is framework support, and possible browser support in the future...etc etc. Yours would have none, or would need it written.
- Widespread use. Lots of coders will understand my CS
code right off the bat, or can learn it easily. Not only will no one understand your crazy macros etc, there's little incentive to learn them.
In the latter case, it's not a valid comparison.
The real question here is what does CS bring to the table, and what do you trade for it. CS had demonstrable benefits and demonstrable drawbacks.
It's my opinion that the benefits dramatically outweigh the drawbacks, but that's a question every developer must ask and answer for themselves.
I get that your contention is somehow, "well if it doesn't do these specific things, it's not 'life changing'", but that seems a pretty arbitrary line to me.
I don't see how you can say developer productivity is not a vital factor in development....and that something that improves productivity, readability, development speed, etc...is not "life-changing", at least as much so as the other factors you mentioned.
When judged in terms of what it's goals are, I think CS is highly effective and far from "pure syntactic sugar" (which to me implies something that simply saves typing).