Coffeekup

by franckcuny • 15 years ago

134 66 15 years ago

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

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

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

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.

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

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.

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

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

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

naz• 15 years ago

Agreed, we should write everything in binary

chrisjsmith4• 15 years ago

rephrase - un-necessary abstration.

ulisesroche• 15 years ago

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.

raganwald• 15 years ago

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

http://en.wikipedia.org/wiki/Abstraction_layer

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

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 for example Java does, they cut it to the root.

chrisjsmith4• 15 years ago

Likewise. It's an excellent piece of rethinking.

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

rkalla• 15 years ago

I was just about to type something along those lines, but then I thought for a second and realized that a lot of these insane JavaScript projects coming out may never become the next <whatever is cool with the kids>, but the technical achievements made in each of these projects inspires the NEXT group of hackers that might be working on <next awesome thing>.

So I think there is a lot of value to these hack projects even if Facebook isn't going to roll it out in it's next update.

Engineering is like art... we all look at what each other is doing, get inspired and move the entire discipline forward.

What I love about that is you never know when you are going to inspire something, not with a project, but maybe just with a particularly nice snippet of code or data model that is SO intuitive, they feel compelled to work it into something.

Equally cool, you never know when YOU will get inspired. I know I've honestly read class definitions or parser implementations that were so intuitive and elegant that I have developed a compulsion to go code something that uses the same technique because it is so pretty.

I don't know why, but I think that is what makes this line of work so great. It's technical AND artistic... and it doesn't always make practical sense ;)

clintjhill• 15 years ago

Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.

Thank you for that. I've been looking for this concise a statement to make in debates I've had in the past.

technomancy• 15 years ago

"Abstractions are like tacos; I don't mind a little leaking so long as they hold together till I'm done." - https://twitter.com/MarkusQ/status/86136160652496896

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.

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?

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.

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

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

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

iambot• 15 years ago

i cannot wait

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

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

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.

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.

shimonamit• 15 years ago

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

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

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

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>

dualogy2• 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. :)

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.

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

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

Cushman3• 15 years ago

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

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

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.

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.

zentechen• 15 years ago

This is so stupid.

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.

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.

Coffeekup

Related Stories