Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PayPal releases Kraken, Node.js framework

krakenjs.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: PayPal releases Kraken, Node.js framework

#21

Post by sorich87 »

leokun wrote: post #18
kevincennis wrote: post #14

Earlier quoted context omitted.

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.

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slide... 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 n…

Neither underscore nor lodash use a for loop. Both use the native Object.keys when available. underscore uses native Array#forEach and lodash uses a while loop. So only lodash forEach is actually faster.

lodash is the only one to be performance focused. underscore always uses the native methods when possible.

Re: PayPal releases Kraken, Node.js framework

#22

Post by camus2 »

leokun wrote: post #19
camus2 wrote: post #17

Earlier quoted context omitted.

A framework should at least be template engine agnostic. I hate handlebars and dust.js , why should i use that? I want to use a jinja like templating language. Seems even their i18n component is tied to their view layer. And 0 doc comments in the scripts? how do they document their own code ?

Yeah didn't notice the lack of doc comments. That is nice to have for a library.

That's a huge problem with most javascript libs I hack. No Js doc means wasting a lot of time trying to figure out what is the dev intent. Or they just removed all docs from their scripts ,seems more likely.

Re: PayPal releases Kraken, Node.js framework

#23

Post by jkrems »

leokun wrote: post #18
kevincennis wrote: post #14

Earlier quoted context omitted.

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.

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slide... 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 n…

Actually ran this on Chrome/V8 and the native method was faster. And as someone else wrote: lodash/underscore should normally fall back to the native methods if available.

As for bind - funny that you mention that as a good alternative to using self/closure. Because while it is convenient and powerful, it's also slower than using self/closure.

I don't want to pretend that for either `[].forEach` or `bind` the differences in speed are (in most cases) really that relevant, I just found your argumentation a little confusing here. As for bind vs. closure-self I wouldn't say that either is really better than the other. Both are perfectly fine options. The former is a pretty heavy solution (since it's basically using a special case of partial application) and can be confusing (e.g. calling `a.b()` can have weird behavior even when the implementation of b is known). The latter is less powerful but a little more explicit imho - you really see the this-scope expansion and it's not hidden away. Both solutions obviously can't protect you from "flock of seagull style nested function code" but as you wrote: that's not a problem of the way someones does this-binding, it's a problem with the design.

Re: PayPal releases Kraken, Node.js framework

#24

Post by kevincennis »

leokun wrote: post #18
kevincennis wrote: post #14

Earlier quoted context omitted.

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.

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slide... 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 n…

I think whatever performance cost might exist with Object.keys and Array#forEach vs loops is outweighed in most cases by a pretty significant increase in readability. There are exceptions, of course, but I think the performance card gets played too often in cases where the difference is negligible.

As for self = this, I tend to agree that it's kind of gross in most cases. It's not something I use very often. But unless you're willing to say that you're never going to use anonymous functions, the reality is that sometimes it's useful.

Re: PayPal releases Kraken, Node.js framework

#25

Post by ricardobeat »

leokun wrote: post #18
kevincennis wrote: post #14

Earlier quoted context omitted.

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.

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slide... 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 n…

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

Re: PayPal releases Kraken, Node.js framework

#28

Post by ocfx »

camus2 wrote: post #17
leokun wrote: post #6

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

A framework should at least be template engine agnostic. I hate handlebars and dust.js , why should i use that? I want to use a jinja like templating language. Seems even their i18n component is tied to their view layer. And 0 doc comments in the scripts? how do they document their own code ?

check out nunjucks

Re: PayPal releases Kraken, Node.js framework

#29

Post by leokun »

ricardobeat wrote: post #25
leokun wrote: post #18

Earlier quoted context omitted.

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slide... 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 n…

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

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.

Re: PayPal releases Kraken, Node.js framework

#30

Post by davidmarcus »

moreproductive wrote: post #5

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.

I agree with you. This is one of my biggest pet peeves. But we're working hard on load times. Every call is HTTPS, adds lag. But you'll start to see improvements on the new experiences that will start rolling out in Q1. One thing after another, we're improving the company, its platform, and its engineering culture. I have to say I'm quite proud of the team behind Kraken. This framework is solid.
Post reply on HN