
PayPal releases Kraken, Node.js framework - bluepnume
http://www.krakenjs.com/
======
moreproductive
Maybe I'm a minority, but I can't really trust anything from a company with a
login screen that says "logging you in securely" for 5000ms before loading me
(sometimes) to my dashboard.

~~~
lighthazard
You are not their target market.

~~~
moreproductive
Explain?

~~~
chaz
This might provide you some insight: [http://thedailywtf.com/Articles/The-
Slow-Down-Loop.aspx](http://thedailywtf.com/Articles/The-Slow-Down-Loop.aspx)

In all seriousness, adding interstitials can provide value. If the login
performance has high variance, it's better to set an expectation that it will
take 5 seconds than leave the user wondering if the click actually worked.
Similarly, Apple has done an amazing job with UI transitions in iOS to mask
the actual load time.

------
ricardobeat
I was honestly expecting something with more added value to warrant it's own
name, maybe a viable competitor to Sails.js, Derby, etc. Lusca is nice,
everything else is more or less what everyone is already doing - runtime
config, controllers, grouped routes, etc, more of a template than a framework.
Good thing they are not reinventing the wheel.

------
leokun
====

Don't like:

dust.js templates instead of handlebars

self = this all over the place

native use of forEach and Object.keys instead of underscore or lowdash

====

I like:

that you can change the template system

grouping routes, I always add this myself, makes it more django like

security stuff like csrf

dev and prod environment awareness

directory layout is cool

apache license

uses grunt

they use Object.create!

one var statement per function

krakens

====

Overall pretty awesome.

p. s. I have no idea how to format text here.

~~~
kevincennis
I'd be interested to hear what you don't like about Object.keys or
Array#forEach. Not looking to start an argument, just genuinely curious why
you prefer a utility library over native methods -- especially in Node, where
you have guaranteed ES5 compatibility.

Also: self = this can be avoided in a lot of cases with Function#bind, but not
always. Seems like a weird criticism to me.

~~~
leokun
Native methods can be slower than simply using a for (Edit: while) loop:

[http://allyoucanleet.com/post/21624742336/jsconf-
us-12-slide...](http://allyoucanleet.com/post/21624742336/jsconf-us-12-slides)

self = this is error prone because it relies on JavaScript's lexical scope to
share a variable across nested functions. It's a gross abuse of closures. It
invalidates the ability to bind or use apply later, since everything is bound
to that local variable self, and it's simply not needed and is probably used
to avoid considerable use of bind, but using bind is only an issue when you
write flock of seagull style nested function code. using self = this is not
the right solution, writing more modular code with smaller functions is.

~~~
ricardobeat
The performance hit of using .bind() instead of `self = this` is much larger
than .forEach() vs loop. Pick your side :)

~~~
leokun
I pick less chance for errors over performance. Referencing variables outside
of local scope is something I avoid. Write beautiful code first, because it's
easier to optimize beautiful code than to beautify optimized code.

------
blhack
Huh: [https://www.kraken.com/](https://www.kraken.com/)

Why this is relevant: kraken is a bitcoin trading platform. Paypal is a
competitor to bitcoin.

~~~
gberger
Huh: [https://kraken.io/](https://kraken.io/)

~~~
gry
Huh: [http://asana.github.io/kraken/](http://asana.github.io/kraken/)

~~~
ricardobeat
Yeah, these days people don't seem to give a shit to preceding OS projects
with the same name. "Ours will be much bigger".

