

Coffeekup - franckcuny
http://coffeekup.org/

======
mikemaccana
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?

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

~~~
pygy_
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)

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

~~~
gcr
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. ;) )

------
nzoschke
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
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
One of the goals of CoffeeScript is to produce only well-formed, compliant JS.
JS to CS conversion would go against that.

~~~
bergie
There is <http://ricostacruz.com/js2coffee/>

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

------
alecbenzer
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
I prefer <http://jade-lang.com/> why ? because no '->' at the end of each line

~~~
danenania
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
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
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
> 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
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
Voilà: <https://github.com/sstephenson/eco>

------
tptacek
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?

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

~~~
bergie
There is a HAML parser. <http://howtonode.org/haml-for-javascript>

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

------
wallrat
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
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
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
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
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
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
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
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
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
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
I just noticed the example is editable! Thumbs up for a great demonstration.

------
zentechen
This is so stupid.

------
chrisjsmith
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
Agreed, we should write everything in binary

~~~
chrisjsmith
rephrase - un-necessary abstration.

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

~~~
chrisjsmith
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> )

