I think what Klonoar was trying to do was contrast the Javascript generated by Coffeescript with what a Human would write in the same scenario.
Note in both Klonoar's example and the article, we are using jQuery.
In Klonoar's example inputEls is a jQuery object with a collection of input elements, which does have an each method.
When you use a method like .each() jQuery will also apply the function to each element in the collection in turn, so on each execution the context of the function is the element, so Klonoars example is correct.
That said, I think it's obvious that a compiler will not produce code as pretty as what a human would write, and that's generally ok. For the most part you only look at the compiled code for debugging, and as long as the generated code is fairly readable it shouldn't hinder that much.
Though more verbose and a little more ugly, the compiled Coffeescript JS has some benefits over Klonoars example.
In the CS version the crux of the iteration is a for loop which will be pretty fast. In the Vanilla JS version it's using jQuery .each() which will most likely be slower.
It is a good point to bring up though because there is some overlap in the goals and functionality of something like Coffeescript vs many libraries like jQuery. The difference is with Coffeescript you are paying upfront with compilation and with jQuery et al you are paying at runtime.
The cost-benefit analysis is something each developer must run for themselves and continually re-evaluate as they work.
Comments
I think what Klonoar was trying to do was contrast the Javascript generated by Coffeescript with what a Human would write in the same scenario.
Note in both Klonoar's example and the article, we are using jQuery.
In Klonoar's example inputEls is a jQuery object with a collection of input elements, which does have an each method.
When you use a method like .each() jQuery will also apply the function to each element in the collection in turn, so on each execution the context of the function is the element, so Klonoars example is correct.
That said, I think it's obvious that a compiler will not produce code as pretty as what a human would write, and that's generally ok. For the most part you only look at the compiled code for debugging, and as long as the generated code is fairly readable it shouldn't hinder that much.
Though more verbose and a little more ugly, the compiled Coffeescript JS has some benefits over Klonoars example.
In the CS version the crux of the iteration is a for loop which will be pretty fast. In the Vanilla JS version it's using jQuery .each() which will most likely be slower.
It is a good point to bring up though because there is some overlap in the goals and functionality of something like Coffeescript vs many libraries like jQuery. The difference is with Coffeescript you are paying upfront with compilation and with jQuery et al you are paying at runtime.
The cost-benefit analysis is something each developer must run for themselves and continually re-evaluate as they work.