Asynchronous document support

[balupton]

Importing: mauricemach/coffeekup#101

A feature CoffeeKup is definitely in need of is asynchronous rendering, this should look like:

div (done) ->
    setTimeout(
        ->
            text 'waited 5 seconds'
            done()
        5000
    )

It would enable far more powerful templating abilities especially when combined with CMSs such as DocPad

[gradus]

Interesting idea. I do like it.
@balupton are you interested in trying to implement this or just requesting a feature?
We are trying to make additions of new features minimal and be very selective about them.
CoffeeCup feels like it should remain a minimalist template rendering engine and not something feature rich like jade.
We are leaning towards the idea of keeping new features out of CoffeeCup and trying to allow them to be added as separate plugins. What are your thoughts on approaching asynchronous rendering in CoffeeCup aside from how it would look? I would be interested in playing around with the idea.

[gradus]

@twilson63 what are your thoughts on this? After sleeping on it, I really see this as something that could prove useful. Is it worth baking in to CoffeeCup as a feature? I am thinking of a plugin. regardless, it will be at least a week before I can get to working on something like this. Just wanted to get a little more feedback.

[aseemk]

You forgot to call done in the timeout?

[balupton]

@aseemk haha yep, updated the example

[aseemk]

=)

[twilson63]

It would be nice to see a test case on how this feature would be expected to be used on both the browser and server, is the purpose of the feature to support partials, or is it completely different? What would be the main advantage of doing an async call while rendering html?

[alist]

Well, if I'm wanting to do async file-io, parse a .md file into html elements and include them in the dom, async rendering might be useful.

However, it's important to question how slow that solution actually is compared to containing the .md in a database. In the circumstance of database, usually you'll fetch the data, then you'll render the template. So perhaps it's an equal amount of time to display a page, but more time is spent within the render buffer write-out.

It's my opinion that there should be no substantial branching logic within the template, which is required if the async returns errors, unexpected data, or fails. This gets really messy if there are crashing or-non returning asyncs, for example, would we set watchdogs on the asyncs, how many seconds would they be? What happens if it fails, do we still render the buffer? Which component will receive the errors, and will we pass an error callback with the render command?

I believe this should be closed. Instead, people should collect all prerequisite data before calling render.

[alist]

In the future, we might enjoy a plugin that allowed async data to be populated down an already-rendered template via socket-io. Meteor seems to be doing it.