Coffeekup

Coffeekup(coffeekup.org)

134 points by franckcuny 15 years ago | 66 comments

mikemaccana 15 years ago |

I love CoffeeScript but I don't understand this. HTML / HAML / SHPAML are document languages. CoffeeScript is a programming language.

An element that contains another element isn't a function. I don't see any reason to make it one.

If you want a templating language, why not use one, rather than having an unnecessary 'space dash greater than' to indicate elements are contained within each other?

maxwell 15 years ago | |

These are arbitrary distinctions; as Heidegger said, language is language. As long as they're Turing complete, the only difference between "programming" and "templating" (and "natural") languages are what they're used/optimized for.

Element A containing Element B can be generated by function A taking Element B.

The CoffeScript program converts a set syntax/grammar into JavaScript; but the syntax is just syntax, and its clean, smart design lends itself well for compiling code other than JavaScript, just as JSON is a useful serialization format in other langs. There are benefits in using the same syntax for representing structure, content, and presentation, as long as the concerns are still properly separated.

akdetrick 15 years ago | | |

The "language is language" argument has shifted my thinking a bit from my initial reaction to this project.

In that line of thinking, it's also raised a new question in my mind. CoffeeKup seems to be optimized for baking logic into the template. It is not too different, but too much like most "templating" languages for me to completely get behind it.

This is however, a really cool project that's well executed. I'm just hoping that the idea of further separating logic from templates takes hold (something like mustache, perhaps).

gcr 15 years ago | |

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}
        '''
        coffeescript ->
          draw = (ctx, x, y) ->
            circle = (ctx, x, y) ->
              ctx.beginPath()
              ctx.arc x, y, 100, 0, 2*Math.PI, false
              ctx.stroke()
              ctx.strokeStyle = 'rgba(255,40,20,0.7)'
            circle ctx, x, y
            for angle in [0...2*Math.PI] by 1/3*Math.PI
              circle ctx, x+100*Math.cos(angle),
                          y+100*Math.sin(angle)
          window.onload = ->
            canvas = document.getElementById 'drawCanvas'
            context = canvas.getContext '2d'
            draw context , 300, 200
      body ->
        header -> h1 'Seed of Life'
        canvas id: 'drawCanvas', width: 600, height: 400
  
  http = require 'http'
  server = http.createServer (req, res) ->
  show "#{req.client.remoteAddress} #{req.method} #{req.url}"
  res.writeHead 200, 'Content -Type': 'text/html'
  res.write webpage
  res.end()
  server.listen 3389
  show 'Server running at'
  show server.address()

Notice something missing?

- There's no separate file for the HTML template

- There's no separate file for the javascript inside

- There's no separate file for the web server

It's just "node circles.coffee" and you're good to go. CoffeeKup makes this sort of one-shot webapp experiment scripts particularly easy. Now you don't need an entire folder for each of your sandbox projects.

benbeltran 15 years ago | | |

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.

DanielRibeiro 15 years ago | | |

Bonus points: it works on bookmarklets, browser plugins and greasemonkey scripts.

Even more added points: it can be refactored like any other code.

gosub 15 years ago | |

a markup language like html is not made of elements that containts other elements, that is just an artifact of the syntax. A tag is more like a "semantic modifier" of its argument/the thing that it contains. How is <i>Lorem ipsum</i> different from (italicize "Lorem ipsum") or italicize :: string -> adorned-graphic-text ?

edit: also, I think having one entire application expressed with only language (coffeescript vs html+css+javascript) is an advantage.

nzoschke 15 years ago |

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.

Sapient 15 years ago | |

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.

Cushman 15 years ago | | |

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

iloveponies 15 years ago | | |

I can see such a conversion like that leading to a scenario where someone writes some broken markup and the conversion to and from formats only makes the situation worse.

joeyespo 15 years ago | |

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.

jarin 15 years ago | | |

Most of the "I hate Haml" arguments can easily be solved by use of filters (e.g. :markdown, :textile, :javascript, :plain, :erb, etc) and/or proper use of helpers or cells (I prefer cells).

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

nzoschke 15 years ago | | |

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 code and this offers a lot of benefits. It's just hard to get everyone to buy into it on a team.

alecbenzer 15 years ago |

While 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

etaty 15 years ago |

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

danenania 15 years ago | |

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.

coenhyde 15 years ago |

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.

rpearl 15 years ago | |

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/Hydrogen bytecode, the relevant engine can JIT it.

On a slightly related note, a friend of mine is working on this: https://wiki.mozilla.org/DevTools/Features/SourceMap

Which, while not compiling directly, will allow you to map the generated JS directly back to the coffeescript source.

mraleph 15 years ago | | |

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

dualogy 15 years ago | |

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.

coenhyde 15 years ago | | |

I was more thinking coffee script development for nodejs. The browsers on a whole have only just got javascript sorted. I think it's too much to ask for native coffee script support in the browser.

iambot 15 years ago | |

i cannot wait

lysol 15 years ago |

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.

jashkenas 15 years ago | |

Voilà: https://github.com/sstephenson/eco

jjm 15 years ago | |

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.

tptacek 15 years ago |

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?

nolanw 15 years ago | |

It uses CoffeeScript's grammar, so there's no need to learn a new one or switch between two different grammars as you work.

It's also way less code than Haml. CoffeeKup's src folder is 240 lines of code.

jarin 15 years ago | |

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.

catch23 15 years ago | | |

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.

Cushman 15 years ago | |

Not sure what you mean here-- it's raw CoffeeScript syntax. The templates it produces are JavaScript functions.

wallrat 15 years ago |

Looks pragmatic and useful. I've been experimenting with a similar implementation inspired by Clojure's Hiccup, but Coffekup looks mature enough to consider adopting.

yuvadam 15 years ago | |

It's comforting to know that nowadays 300 watches and 20 forks on github are enough to consider software "mature".

(Nothing personal, just a reflection...)

jedschmidt 15 years ago |

This exploits CoffeeScript syntax in the same way that (fab) exploits JavaScript syntax:

https://github.com/jed/fab/blob/browser/demo.html

(I'm biased, but am a fan of making markup "just code".)

johnlaudun 15 years ago |

I like the thinking that go into efforts such as this, but like other commenters I do on occasion end up wondering about the fragmentation that this leads to. That worry noted, the thinking is the important point and CoffeeKup is very cool.

mtogo 15 years ago |

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.

chetan51 15 years ago |

Looks interesting. A suggestion: there's no example anywhere for something like

  <div class="content">

Please add that to the example on the landing page.

emehrkay 15 years ago |

This may be a bit "get off of my lawn," but I would never use this. I respect the effort put into making it work, but I have no problem writing <div></div>

dualogy 15 years ago | |

I too have no problem writing a single <div></div>. But trust me it gets old. In a new from-scratch project (which is completely stand-alone and won't need to "integrate" with anything or be touched by other coders who "can do html but not coffeescript") after having done the first 10-15 templates I was looking at my CoffeeScripts... then back at my <html/><templates/> ... then rewrote them all to the tune of:

  renderTemplate: ->
    "div":
      "span .some-class":
        _: ["Hello, "]
      "strong #dyn_id":
        _: ["#{@getName()}!"]
    "subTemplate":
      foo: bar
  subTemplate: (args) ->
    blockquote:
      _: args.foo
  getName: ->
    "user name from DB or whatever"

(Then hand-rolled my own very simple JSON-to-HTML "renderer" in 20 minutes plus generating a CS class file to be compiled to JS for each template -- all really simple stuff.)

Looks scary coming from years of HTML coding right? But HTML looked scary at first too.

Now: stylesheets are Stylus, templates and logic are CoffeeScript both server-side and client-side. I haven't been such a happy coder for a decade. Config files are a simplified Stylus/Coffee-like format that gets transformed to JSON. I'm actually using the CoffeeScript compiler here so in effect each config file gets transformed into a node.js "module". That means they could be turned into config "scripts" if necessary.

What I loved about Lisp in theory: code is data, data is code. Only the parens sucked for me. Now we're approaching this ideal again, slowly and emergently but surely. :)

denysonique 15 years ago |

This is wonderful. I am looking forward to someone creating a Coffeekup Gem. I will use this in my next Rails project. Thank you for this awesomeness.

anonymous 15 years ago |

What a great idea! Now i can write html that nobody understands but me. This will keep those pesky designers from messing with my codes.

shimonamit 15 years ago |

I just noticed the example is editable! Thumbs up for a great demonstration.

zentechen 15 years ago |

This is so stupid.

chrisjsmith 15 years ago |

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.