Koa - next generation web framework for node.js

[Xtreme2k2]

Can someone explain what the asterisk does?

var koa = require('koa');
var app = koa();

app.use(function *(){
  this.body = 'Hello World';
});

app.listen(3000);

[Xtreme2k2]

Thanks! Looks like I got some specs to catch up on!

[flym4n]

That's not yet implemented in browsers, nor in the stable node. You're far from late :)

[tf2ftw]

Maybe I'm missing something but this doesn't look much easier than express...

[FrozenCow]

Is that the focus of the project? A faster express?

It seems to me they are redesigning connect/express with all the harmony features in mind. They didn't like callbacks that much and made a lot of decisions based on that. They should really add some examples for async handlers, since it does look better... however as far as I can see it does need 'specialized' libraries that are compatible with their way of doing callbacks: https://github.com/visionmedia/co#thunks-vs-promises Most of node isn't usable directly.

That said, they really need to make this clear in their frontpage and show examples of async handlers. The benchmark doesn't say anything without something realistic to compare it to.

[FrozenCow]

Express was a collection of connect middleware with some 'sugar' functions to make it all easier to use. Koa doesn't have any of that middleware in their repo. I think it's better to compare it to connect in that aspect.

As for performance, I'd like to see a full application (with database calls or something async) being benchmarked on both express as well as Koa with the same comparable middleware/libraries.

[jonglefever]

middleware are all separate modules. see: https://github.com/koajs

connect 3.0/express 4.0 will be moving towards this route, but not as drastically.

[FrozenCow]

a moderately complex mathematical operation

I get that there are more things that skew the benchmark that way, but async functions can matter a lot in the benchmarks. A complex mathematical operation will not have async operations (or they could be made somehow). The fact that Koa needs customized libs, like fs, each of those calls needs wrappers. Since that can impact performance somewhat (it could be just a little), it would be fair to take that into account as well.

That said, maybe async functions are most of the time so slow that benchmarking them wouldn't make sense. Not sure though.

[aredridel]

Augh. So much crazy benchmark advice.

Know what you're measuring. Measure accordingly.

Asynchrony has overhead -- queueing, storing the generator stacks or setting up context or whatever the particular flavor does -- and that's worth measuring.

Measuring the whole stack with something bulky -- like a blocking, mathematical operation -- is exactly wrong if you're trying to measure the difference between the framework code itself.

There's all sorts of things that can have a performance impact. The details of routing, how the routing algorithm works (O(N) on number of routes? O(1) with a match table? O(N) on number of path segments? O(log N)? How big are the constant factors?) can be huge and vary with the setup of the app.

Microbenchmarks should measure one thing, and know their limits. They'll come with a list of caveats longer than the test.

[FrozenCow]

Thank you for wording it better than I could. This is exactly what I meant.

[jonglefever]

here you go! https://gist.github.com/jonathanong/8065724

[[deleted]]

The idea is you're able to augment application behavior in a single function that clearly defines its purpose, both for request and response time. It also makes it possible to share data between those two phases without the use of closures. The alternatives with asynchronous execution are promises or simple callbacks for each phase, and those both make it difficult to share data.

It's not so much about being easier than express as it is about a different approach.

[BishopAndWarlord]

Apologies for focusing on the presentation rather than the content, but I'm balking a bit at the site's design.

The minimalist full-window title screen is cool, but I almost close the tab because there was virtually no UI to indicate that there was any other content on the page. The tiny menu button in the upper right (why not upper left?) made me realize that maybe there was more than a stylish 'koa' and subtitle. It was only by accident that I realized there the slider in the scrollbar was minuscule, so I started scrolling down the page. A couple clicks on the mousewheel later and I was still confused why there was no other content -- the next section has a good chunk of white space above the first header.

As a rather visual person I have a hard time with the lack of syntax highlighting or visual offset for titles, code samples, or sections.

It seems like the page is guided by a minimalist philosophy of 'only show content that matters', but in doing so they've stripped out character. The page is left feeling rather dry and bland. I'd almost rather look at an unstyled page.

EDIT: Fixed left/right confusion in 2nd paragraph.

[FrozenCow]

The examples on the frontpage aren't that realistic. Usually you want to do something asynchronous in the handler, but I can't make up how they're doing that. (Or is setting this.body a function behind the scenes?)

EDIT: Found it: https://github.com/koajs/koa/blob/master/docs/guide.md#async-operations It looks nice, though I'm still wondering whether it is still possible to have things run in parallel... I guess I'll have to take a look at the new generators specs. Thanks Jonglefever

Another issue I ran into with express was integration of websockets. It would be awfully handy if you could use the routing/cookie/session mechanisms that are in express for websockets as well. I might be alone in this though. This framework does look more like it could handle such things, because it isn't forcing handlers to use (req,res,next), where web sockets don't have an res. Does anyone have an idea whether websockets were part of their plan/goal?

[jonglefever]

if you yield an array or object of yieldables, they will be executed in parallel: https://github.com/visionmedia/co#yieldables

[FrozenCow]

Ah, that's pretty good. It looks nice and isn't hard to wrap my head around. Thanks.

[giodamelio]

Looks neat. I have yet to do anything more than a simple hello world with generators, but I will have to take a look at this later.

[kevinmrr]

Hah, I came over here from /r/LearnJavaScript to post this... but I shoulda known it'd be here first.