3 ms·

yeah I agree #8 in particular should elicit a lot more debate in the js community. Back when I used to be into RoR I would get a ton of flack in interviews for

by fat0wl 12y ago

yeah I agree #8 in particular should elicit a lot more debate in the js community. Back when I used to be into RoR I would get a ton of flack in interviews for writing pure js rather than Coffeescript, pure css rather than Sass. There are legitimate cases where a pre-processor is useful (Coffeescript demos show several cases where a lot of code can be simplified) but unless you are writing a math/list-heavy app, I feel these advantages don't apply so much. I don't perceive a need for these tools in most projects that are about dom manipulation, it can instead be achieved through pure libs (jQuery) which will eliminate a build step and should allow for some easier testing. This is a fundamental programming debate that I don't see a lot of discussion of... since I like CLojure I see some talk of how "transparent" it is as a wrapper over JVM types but a lot of the pre-processor style of transcompilers gloss over this idea (I guess just preferring 2 independent stages of static/lint analysis?).

debacle 12y ago
Firstly, I don't pool LESS/SASS with Coffescript and the like because CSS is a content description language, not a programming language, though as someone who is an expert on none of the above, I would hear arguments against them. Secondly, most people wouldn't. If someone is using Coffeescript they don't want to hear that they shouldn't be using Coffeescript because they want to use Coffeescript, and most people (and in 2014 "most programmers" are a microcosm of "most people") don't like listening to opinions that deviate from their own. All of the "great" parts of Coffeescript can be implemented in JavaScript with a library like underscore. Clojure is a bit different since it is interacting directly with the JVM.
- fat0wl 12y ago
  good points, but yeah the reason i lump them together (even though I agree that C preprocessors vs. css vs. js vs. jvm abstraction are obviously very different technologies) is that in the context of this discussion, i see them as a layer of abstraction that basically mangles the ability for code analysis (whether it be static or in debugging) to happen in a way that feels comprehensive for some technologies this is being alleviated with source maps, but it still feels like over-complication when there are library alternatives available (Underscore, as you point out). Because when it comes down to it you will need to debug & understand some language paradigms/quirks of the language you are transcompiling to, so it would behoove the developer to be as fluent in the target language as possible (& of course, coding natively in it to begin with promotes fluency...) as the tools become stronger the danger disappears, yet the base language has simultaneously matured to the point where this extra technology may be nearing obsolescence... i understand in js there is some lag with web standards boards etc., but taking Java as an example, annotations and other language functions were added while simultaneously the libraries/containers (web frameworks, Spring, EE) got more powerful. It is a pretty strong & mature toolset probably mainly due to the language evolution always being forced back toward the core. From the limited amount I know, the other JVM languages are implemented against the JVM spec which is matured in a similar way, thus facilitating easier implementation of language features & interoperability.

by fat0wl 12y ago

debacle 12y ago

Firstly, I don't pool LESS/SASS with Coffescript and the like because CSS is a content description language, not a programming language, though as someone who is an expert on none of the above, I would hear arguments against them. Secondly, most people wouldn't. If someone is using Coffeescript they don't want to hear that they shouldn't be using Coffeescript because they want to use Coffeescript, and most people (and in 2014 "most programmers" are a microcosm of "most people") don't like listening to opinions that deviate from their own. All of the "great" parts of Coffeescript can be implemented in JavaScript with a library like underscore. Clojure is a bit different since it is interacting directly with the JVM.

fat0wl 12y ago
good points, but yeah the reason i lump them together (even though I agree that C preprocessors vs. css vs. js vs. jvm abstraction are obviously very different technologies) is that in the context of this discussion, i see them as a layer of abstraction that basically mangles the ability for code analysis (whether it be static or in debugging) to happen in a way that feels comprehensive for some technologies this is being alleviated with source maps, but it still feels like over-complication when there are library alternatives available (Underscore, as you point out). Because when it comes down to it you will need to debug & understand some language paradigms/quirks of the language you are transcompiling to, so it would behoove the developer to be as fluent in the target language as possible (& of course, coding natively in it to begin with promotes fluency...) as the tools become stronger the danger disappears, yet the base language has simultaneously matured to the point where this extra technology may be nearing obsolescence... i understand in js there is some lag with web standards boards etc., but taking Java as an example, annotations and other language functions were added while simultaneously the libraries/containers (web frameworks, Spring, EE) got more powerful. It is a pretty strong & mature toolset probably mainly due to the language evolution always being forced back toward the core. From the limited amount I know, the other JVM languages are implemented against the JVM spec which is matured in a similar way, thus facilitating easier implementation of language features & interoperability.