Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coffeekup

coffeekup.org

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Coffeekup

#61

Post by danenania »

nzoschke wrote: post #27
joeyespo wrote: post #22

Earlier quoted context omitted.

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 former. The first guy that loves Haml a lot has used it on tons of projects, and knows its quirks, has his own clever tricks, etc. Someone else comes along and has to set up a Ruby environment and learn a new syntax (for layout and templating) just to add a new element to the page. That gets frustrating really quickly. Haml and its like are not a nightmare at all. I do appreciate the elegance of the resulting cod…

I don't really get this. Conceptually, haml IS html. Sure the syntax is a bit different, but it's hard for me to imagine that a decent programmer would get hung up on this. Same with coffeescript really. If a cleaner syntax on top of a language scares you, you don't really grok the original language all that well in my opinion. There are certainly arguments for sticking with vanilla html/js, like the potential minor hassles of dealing with file conversions and debugging generated code, etc., but fear of a new syntax that can be learned in 15 minutes is a weak one.

Edit: I do grant that js to coffeescript is a bit more of a leap than html to haml since coffeescript actually introduces some new language concepts.

Re: Coffeekup

#62

Post by danenania »

etaty wrote: post #21

I prefer http://jade-lang.com/ why ? because no '->' at the end of each line

Agreed. I've really come to love minimalism in languages. It's somewhat like economy of words in poetry. There should be sufficient syntax to get the desired meaning across, and nothing more. Even though I haven't used jade yet, it's the cleanest looking markup language I've seen. I would also a appreciate a cleaner alternate syntax for json to complete the picture.

Re: Coffeekup

#63

Post by bergie »

Cushman wrote: post #49
Sapient wrote: post #19

Earlier quoted context omitted.

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…

One of the goals of CoffeeScript is to produce only well-formed, compliant JS. JS to CS conversion would go against that.

There is http://ricostacruz.com/js2coffee/

Re: Coffeekup

#64

Post by bergie »

catch23 wrote: post #51
jarin wrote: post #43

Earlier quoted context omitted.

I think the main advantage is it doesn't require Haml. I use Haml whenever possible, but I could see this being very useful for Node.js or other JS/CS-based apps.

why couldn't one write a haml parser for node.js? That would seem like a better strategy than invent a whole new syntax for markup.

There is a HAML parser. http://howtonode.org/haml-for-javascript

But it is a good thing to experiment with different approaches.

Re: Coffeekup

#65

Post by extension »

benbeltran wrote: post #40
gcr wrote: post #37

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.

So separate them. They can still use the same language.

Re: Coffeekup

#66

Post by mraleph »

rpearl wrote: post #34
coenhyde wrote: post #9

Looks 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.

If you translate your coffeescript to javascript serverside, then there is no overhead on Jaegermonkey or v8 (obviously). Although I doubt that any of the browsers will ever support it directly, porting coffeescript to run directly on top of Jaegermonkey or v8 wouldn't be too hard, since there is a direct translation from coffeescript to javascript. You would only need a new front end--if you emit Spidermonkey/Hydrog…

> if you emit Spidermonkey/Hydrogen bytecode

Hydrogen is not a bytecode, it is highlevel intermediate representation for optimizing compiler generated from AST. There is currently: 1) no frontend in V8 that accepts hydrogen in some serialized form; 2) no way to generate non-optimized (non-specialized) code from hydrogen which is quite crucial to make adaptive optimization pipeline running.

Re: Coffeekup

#67

Post by aslamnd »

I agree. It's a good effort. No doubt. But I personally feel that it makes a simple markup language like rocket science.

I prefer HAML over this once as in HAML I only need to type single (%) character to mark tags where is in this language I need to use two characters (->).

Re: Coffeekup

#68

Post by mtogo »

I have no idea what this is. Shows up as two large empty text boxes under Opera.

After opening it in Firefox, i find it ironic that something that has to do with web standards is so broken in a major browser.

Re: Coffeekup

#69

Post by Cushman »

bergie wrote: post #63
Cushman wrote: post #49

Earlier quoted context omitted.

One of the goals of CoffeeScript is to produce only well-formed, compliant JS. JS to CS conversion would go against that.

There is http://ricostacruz.com/js2coffee/

Yeah, good catch— I didn't mean to say any JS->CS conversion was bad, just that it shouldn't be a part of the core language or of a real workflow.
Post reply on HN