41–50 of 69 posts
Just looking at the syntax and thinking about how I would write things in it, this looks strictly inferior to Haml; there's syntax in here that appears to exist solely to shoehorn this into Coffeescript's grammar. What does this do better than Haml to make up for that?
It's also way less code than Haml. CoffeeKup's src folder is 240 lines of code.
Whilst I appreciate the effort that people put into these things, I really don't like this sudden obsession of adding another layer of abstraction over everything. Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.
> Whilst I appreciate the effort that people put into these things, I really don't like this sudden obsession of adding another layer of abstraction over everything. This is one of the reasons I found Google's Go so refreshing, it actually removed layers of abstraction bypassing even libc while providing a clean and portable interface to write my programs. Instead of making the stack of abstractions even higher as fo…
Simplicity equals elegance in my mind. If I can fit the whole product/platform in my mind, I am again powerful and not just a victim of the tyranny of over-abstraction and overwhelming APIs (yes I'm looking at you Java and C#).
Just looking at the syntax and thinking about how I would write things in it, this looks strictly inferior to Haml; there's syntax in here that appears to exist solely to shoehorn this into Coffeescript's grammar. What does this do better than Haml to make up for that?
Cute name and well executed project. But personally, Coffeescript -> Javascript -> HTML sounds way too indirect for my taste. I've seen this patter a few too many times at work now: the new frontend guy loves HAML, and he uses it on a project, and the next couple guys that help maintain it hate it and rewrite everything in straight up HTML.
While I also think this is too indirect for my taste, I'd really like to know why the maintainers hate it. Is it simply because they've never learned HAML and how to debug/maintain it? Or because it truly is a nightmare? I'm interested because I was thinking about trying it. I've been wondering about the maintenance implications though.
The things I most often see people doing wrong are trying to format body text with Haml and putting excessive logic in your Haml templates (which is something to look out for anyway, even if you use erb, slim, or whatever).
Earlier quoted context omitted.
rephrase - un-necessary abstration.
Then the issue becomes determining what abstractions are "necessary". The line is very blurry, and there is plenty of room for a range of reasonable positions on this matter. While there may be some objective truth about which abstractions really are a net benefit to use, there's no easy way for us to determine it (besides deciding between binary and assembly). So arguing about it is mostly pointless. Leave each to t…
Read GEB - covers it indirectly ( http://en.wikipedia.org/wiki/G%C3%B6del%2C_Escher%2C_Bach )
Earlier quoted context omitted.
The example that really made sense for me was from "Smooth Coffeescript" in which the author writes an entire nodejs app in one file. Here, I'll show you: http://autotelicum.github.com/Smooth-CoffeeScript/ webpage = kup.render -> doctype 5 html -> head -> meta charset: 'utf-8' title 'My drawing | My awesome website' style ''' body {font-family: sans-serif} header , nav, section , footer {display: block} ''' coffeescr…
I see how this is cool, but weren't we trying to separate style information from the program logic? ... This seems like a step back into PHP spaghetti code.
It's about logical, not necessarily physical separation. For small apps, having everything in one place is actually very convenient.
See also _why's Camping: http://camping.rubyforge.org/ (nowadays maintained by judofyr a.k.a. Magnus Holm)
Cute name and well executed project. But personally, Coffeescript -> Javascript -> HTML sounds way too indirect for my taste. I've seen this patter a few too many times at work now: the new frontend guy loves HAML, and he uses it on a project, and the next couple guys that help maintain it hate it and rewrite everything in straight up HTML.
Just reading your comment, it occurred to me that this is an editor problem. What we actually need are editors in which you can set you language (haml, slim, less etc), and then those are compiled and saved, in realtime to html, erb, css etc. Not having used too much Coffee Script yet, I don't know what the transformation from CS -> JS -> CS would result in, but I believe HAML -> HTML -> HAML would be pretty much 1:1…
Earlier quoted context omitted.
I see how this is cool, but weren't we trying to separate style information from the program logic? ... This seems like a step back into PHP spaghetti code.
The style is applied through CSS. The CoffeScript is unobtrusive. The template and the sever logic are distinct (but there's an indentation error in the request handling code). It's about logical, not necessarily physical separation. For small apps, having everything in one place is actually very convenient. See also _why's Camping: http://camping.rubyforge.org/ (nowadays maintained by judofyr a.k.a. Magnus Holm)