Live data from Hacker News

Coffeekup

coffeekup.org

31–40 of 69 posts

Re: Coffeekup

#31

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

I too have no problem writing a single . 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 ... 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. :)

Re: Coffeekup

#32
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?

Re: Coffeekup

#33

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.

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.

Re: Coffeekup

#34
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/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.

Re: Coffeekup

#35
post #30

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?

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 i…

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

Re: Coffeekup

#36
post #19
post #4

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…

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.

Re: Coffeekup

#37

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?

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.

Re: Coffeekup

#40
post #37

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?

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.
Post reply on HN