Coffeekup | Hacker News Reader

Coffeekup

coffeekup.org

134 pointsfranckcuny66 comments

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?

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.

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.

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

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.

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)

Yeah, but this only goes well for smallish projects. If you have files that start to reach 2000 lines, the last thing you'll want is a mixture of model, view, and controller logic in a single file. PHP had this back in 1999, and I don't think we want to go there again.

Project organization is your responsibility. How is this different from other modern frameworks? That CoffeeKup allows you to organize your projects as you see fit should be a point for its favor, not against.

(That is, unless you use Rails and believe in underlying organizational standards for everything. ;) )

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

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

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

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, and html2haml already produces pretty much exactly the same haml I would have produced if I had done the conversion manually.

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.

You are of course correct, this was a horrible idea!

I don't know if this reply was read as being sarcasm, but It honestly wasn't. I was wrong about the whole idea, it would never work.

Eh, it's an interesting line of thinking.

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.

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

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.

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

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

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.

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.

i cannot wait

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.

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.

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.

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

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.

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

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.

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

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.

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

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.

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

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

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.

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.

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.

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>

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

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.

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.

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

This is so stupid.

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.

Agreed, we should write everything in binary

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 their own preference.

IMHO, abstractions become apparent if needed. Abstractions should never be thought of first.

Read GEB - covers it indirectly ( http://en.wikipedia.org/wiki/G%C3%B6del%2C_Escher%2C_Bach )

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.

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

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

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

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

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.

"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

Reply on news.ycombinator.com