Fast.js
Languages and libraries
javascript utility library
SHOW HN2014
How HN took it
8 positive, 20 neutral or asking, 3 mixed, 31 critical, out of 62 comments about the project. Thread score -0.37.
Execution: 2 for, 12 againstPerformance: 2 for, 11 againstIdea: 3 for, 4 againstDocs: 0 for, 4 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Useful for performance-sensitive algorithms using typed arrays and loops
From 1 comment
I used this in a Firefox OS app, inside an implementation of Dijkstra's algorithm and an accompanying binary heap, and while I haven't run any rigorous benchmarks, I can say the…
thegeomaster on HN
Objections
Skips spec edge cases such as sparse arrays without documenting them
From 3 comments
I'm interested in what those edge cases are, to say it works in 99% of the cases but provide no caveats makes me think that I might be surprised by something if I use it.
cordite on HNIt would have been nice though if they would have documented exactly which edge cases they're neglecting.
gpvos on HNI think the forEach issue is a bad example, and something that could (and arguably should) be handled by the native implementation. The reason they get faster execution here is…
peterkelly on HN
Benchmarks use tiny inputs and lack comparison with Lo-Dash
From 2 comments
Amazing, the "performance tests" here operate on a list of only ten items long: https://github.com/codemix/fast.js/blob/master/bench/for-each.js I'm sure that is a statistically…
grhmc on HNCan you provide benchmarks against Lo-Dash?
idbehold on HN
Speedup mostly comes from ignoring holes, so it is not a real native replacement
From 2 comments
As a person who works on a JS engine I can say that a lot of the speed up in this library is the failure to handle holes correctly - it's surprisingly expensive to do a hole…
olliej on HNSo the forEach magic that is so much faster is... a normal for loop: ``` exports.forEach = function fastForEach (subject, fn, thisContext) { var length = subject.length, i; for…
Kiro on HN
Requests
Benchmarks against lodash and larger input sizes
From 3 comments
Can you provide benchmarks against Lo-Dash?
idbehold on HNAmazing, the "performance tests" here operate on a list of only ten items long: https://github.com/codemix/fast.js/blob/master/bench/for-each.js I'm sure that is a statistically…
grhmc on HNHere's a jsperf of fast.js / lodash / native: http://jsperf.com/fast-vs-lodash
jrajav on HN
Document the edge cases the library ignores
From 2 comments
It would have been nice though if they would have documented exactly which edge cases they're neglecting.
gpvos on HNI'm interested in what those edge cases are, to say it works in 99% of the cases but provide no caveats makes me think that I might be surprised by something if I use it.
cordite on HN
Questions
How can a JS reimplementation beat the native function?
From 2 comments
Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
aikah on HN> there is essentially no performance difference between native functions and their JavaScript equivalents > native functions often have to cover complicated edge cases from the…
dabernathy89 on HN
Alternatives named
lodash / underscore.js
From 2 comments
This is actually unlikely to be a problem. The edge cases ignored here are actually the same as those ignored by underscore.js, which is obviously a very popular library.
phpnode on HNCan you provide benchmarks against Lo-Dash?
idbehold on HN
Bluebird
From 1 comment
Reminds me of this comment by Petka Antonov on native V8 Promises being way slower than Bluebird[1]: >I'd expect native browser methods to be an order of magnitude faster.…
danabramov on HN