3 ms·
I 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, call
by tekacs 12y ago
I 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.