I sort of like the idea, but think I'd rather just have a CoffeeScript version of EJS. It's hell on my shift key but I still _like_ HTML as it is, after all these years.
Coffeekup
11–20 of 69 posts
Re: Coffeekup
#12Whilst 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.
It's not exactly sudden, you know. We're not using punch-cards anymore, for example. I've haven't done much debugging, since Haml/Sass/Coffeescript write better HTML/CSS/Javascript than I do, but you can always look at the compiled code if you need to.
Re: Coffeekup
#13Whilst 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.
All problems in computer science can be solved by another level of indirection—Butler Lampson
...except for the problem of too many layers of indirection.—David Wheeler
Re: Coffeekup
#14Looks fantastic. With the traction Coffeescript is getting I wouldn't be surprised to see it eventually execute directly inside v8 or similar, bypassing the javascript compilation altogether.
i cannot wait
Re: Coffeekup
#15I sort of like the idea, but think I'd rather just have a CoffeeScript version of EJS. It's hell on my shift key but I still _like_ HTML as it is, after all these years.
Re: Coffeekup
#16I just noticed the example is editable! Thumbs up for a great demonstration.
Re: Coffeekup
#17I sort of like the idea, but think I'd rather just have a CoffeeScript version of EJS. It's hell on my shift key but I still _like_ HTML as it is, after all these years.
I like HTML too, but when I took a look at ECO i thought wow, that's a lot of `%` signs... Then I started thinking about all that big corp JSP I wrote a lifetime ago.
Taking a second look at CoffeeKup made me appreciate what the project is doing, clearly abstracting away useless syntax with the same good'ole functions.
Re: Coffeekup
#18Looks fantastic. With the traction Coffeescript is getting I wouldn't be surprised to see it eventually execute directly inside v8 or similar, bypassing the javascript compilation altogether.
Even if V8 could do this, I'd probably continue to compile my stuff manually (it's so easy) so I wouldn't have to wait for Node / Chrome to update to the newest V8 when there is a new version of the CS compiler that I might need "now".
Also it'd be the only way for me to be sure my CS is compiled by the proper compiler version.
Re: Coffeekup
#19Cute 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, and html2haml already produces pretty much exactly the same haml I would have produced if I had done the conversion manually.
Re: Coffeekup
#20While I agree that it does seem slightly more appropriate to use something like haml that's specifically designed for this purpose, I kind of like this because it removes the somewhat annoying need to learn a new language (assuming you already know coffescript).
I haven't looked at this too much, but I also find that templating languages often try to implement some elements of higher level programming languages, but often end up not having some of the features I want (I'm thinking specifically about liquid right now and it's apparent inability to let the designer declare arrays on their own, and its sort of awkward "filter" mechanism instead of just sticking to function calls, syntactically)
edit: well, actually, nevermind - now that I think about it liquid and haml/erb/etc are different things - liquid is trying to be a programming language and haml/erb are templating markups used with existing programming languages. I guess what I like about this is that it's just one consistent language - the markup parts and the dynamic parts are done via the same thing, as opposed to having a programming language embedded in a markup language