4 ms·
I'm a bit concerned about this... On one hand, I'm a big proponent of "know your tools". I'll gladly use a fast sort function that falls apart when sorting arr
by nathanb 12y ago
I'm a bit concerned about this...
On one hand, I'm a big proponent of "know your tools". I'll gladly use a fast sort function that falls apart when sorting arrays near UINT32_MAX size if I'm aware of that caveat ahead of time and I use it only in domains where the size of the array is logically limited to something much less than that, for example.
But on the other hand, I write operating system code in C. I need to know that the library functions I call are going to protect me against edge cases so I don't inadvertently introduce security holes or attack vectors.
If I know that some JS I'm interacting with is using fast.js, maybe there will be some input I can craft in order to force the system into a 1% edge case.
The lesson here is probably "don't use this for your shopping cart", but we need to be careful deriding Javascript's builtins for being slow when really they're just being safe.
- VMG 12y agoAt least a list of the corners that are cut here would be nice.
- Isofarro 12y agoAnd a solid suite of unit tests. The current set looks very light.
- phpnode 12y agoThis 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.
- cwmma 12y agolodash is the fast one that pioneered this, underscore for the longest time fell back to slow native ones.
- nathanb 12y agoI agree that it's unlikely to be a problem...until your site gets popular and a .01% corner case becomes a weekly occurrence or until someone sees that you're using fast and exploits an attack vector.
- phpnode 12y agoit's not that kind of edge case. It simply means that some very uncommon constructs are not supported. If you never use those constructs, which basically nobody does, then it will never fail. (and in fact the failure mode is pretty soft and unlikely to crash your application). If your code worked with this once, it will always work.
- tekacs 12y agoI think by all means use this for a shopping cart - it's namespaced by require (say under 'fast' as in the README) - you are, for all intents and purposes, calling just some library which just happens to reimplement JS builtins as its mode of operation. It may even be _easier_ to determine the behaviour of these functions than builtins, since determining how fast works just means reading its source whereas to determine builtins' behaviour you must read the ECMAScript specification and then hope[1] that the browser actually matches it perfectly! [1]: or read the JS engine source, but that's a whole lot more work. :P
- alttab 12y agoI'm not sold that this will provide any user-measurable increase in performance. If you are sold by some personal app benchmark, there is a good chance you are writing too much client side JS. And what is to say of other dependencies like jQuery, Bootstrap, Knockout, Angular, etc that do NOT use fast.js under the hood? It seems that the only real "win" I get is a fast "map" command, which, IFAIK, has NEVER been the problem of writing good software. Now, if fast.js made sure we had the correct requirements, no distractions, clear milestones, and a dedicated team with no turn over, I'd import it in a second.
- tekacs 12y agoI... don't write any client side JS[1]. I'm also not necessarily 'sold' by the benchmark. I just take objection to the perspective given by the parent post on the _safety_ situation surrounding this library. [1]: ... not recently, anyway.
- couchand 12y agoIf you find any library anywhere that provides all of those things please do let me know.