esailija

How do you live in such a bliss ignorance where supposedly an order of magnitude difference in performance between two state of the art browsers doesn't make you reconsider even for a second that you might have not written a working benchmark? :)

Sorry but unless you have deep knowledge of how both engines and browsers work (knowing how `appendChild` is actually implemented for starters), you simply cannot write a working benchmark. Even then, it's very hard and tedious.

If you don't have time to obtain such expertise, you could take a shortcut and compare realistic end-to-end benchmark. E.g. if your game runs at 210-270 fps in firefox but only at 30 fps in chrome, then you could claim that "firefox blows chrome out of the water".

It's very easy (just look at 80%+ of jsperfs) to construct benchmarks that don't look completely broken to the untrained eye but actually are. The common theme is the benchmark missing many aspects of realistic code and being reduced to measuring irrelevant optimizing compiling features. For example the benchmark could only be measuring how thorough the engine's dead code elimination pass is even though what you wanted to benchmark is string concatenation performance.

not if you are using any kind of event emitters. These don't participate in any kind of flow but fire "error" events as side effect sneakily in the background, and if there is no listener on an event emitter for the "error" event, it will crash the server. And almost everything in core is an event emitter.

Also bonus points if the event emitter object is private to some module that doesn't expose it and doesn't attach an "error" event handler to it.

It doesn't matter at all what kind of promise flavor an API returns because promise implementations treat other implementations as interchangeable.

Even the ES6 Promises implementation supports this:

    Promise.all([{
        then: function(r) {
            r(3);
        }
    }]).then(function(result) {
        console.log(result);
    });

Here the plain object with then could have been any promise implementation, even jQuery, and it still works.

With proper bytecode you would have to do bytecode verification so no.

In JavaScript you can't make any backward incompatible changes, let alone remove anything. Because what browser would want to implement stuff that breaks websites for its users?

No reason why it couldn't work on the server: create multiton versions of stores and when a page is ready to be rendered assign the state of the multiton instances to the corresponding singleton instances, call render and return the singleton instances to their previous states. Sure it's hacky as hell but just hide it somewhere, there is no reason to do it manually in application code.

Promise is the best thing an async library method could return because it's always trivial to convert into anything you want (callback, stream, async/await, yield whatever you want) because it's the only thing that's standardized. However, nobody gets the callback contract (https://gist.github.com/CrabDude/10907185) right. Even node core gets the callback contract wrong in different ways in its different APIs.

In practice however most library callback apis resemble the callback contract enough so that one-line promise-wrapping of the entire library is possible.

> If you are using a language where the standard libraries are so poorly implemented that you can easily write better versions, you might want to consider using a different language.

Standard libraries are typically generalized for a wide array of use cases, you can easily write much faster implementation specialized to your needs if you have any idea what you are doing.

Sometimes standard libraries handle such ridiculous cases (e.g. many ES5 array methods and Function.prototype.bind) that your needs don't even need to be that special.

If I am going to add a dependency for some shit like this, it better at least be exceptionally well optimized and have no bugs.

Well look at JavaScript where self (this) works exactly the same way (it's conceptually just another argument to a function) but is passed implicitly and declared as parameter implicitly. People are not very happy with that either...

`async/await` is only for sequencing, it's not gonna replace anything other than `.then` chains. If you have such chains to the extent that you think `async/await` will solve your problems, you should think very hard if every item in the chain is truly depending on the previous item in the chain because you are currently losing a lot of performance to that otherwise. I have often seen examples using generators and `async await` that needlessly turn fast concurrent promise code into slower sequential code.

One is not even a tradeoff* and the other is completely unrelated to having an all async ecosystem.

*Anything available in other languages in place of callbacks (promises, generators, async await etc) is also available in node. If you are using callbacks you are just ignorant (or don't want to deviate from out of the box features in which case node is the worst possible thing for you). Nowadays there is not even a performance benefit so the only credible reason to use callbacks is not even there.

Using any CPU is a fundamental mistake?

I am not sure what you are even saying.

My point is that if the most optimal way would result in some other iteration order, that would be the iteration order experienced by users and that it is just a coincidence that the most optimal way results in insertion order.

It results in different hidden class because the whole point is to be able to reference named fields by fixed offsets from the object location in memory (same as for example reading struct fields in C). If the order changes, so will the offsets too, so same names with different order must have different hidden classes.

Integer keys are not practical to treat as fixed because they are used as array indices 99% of the time which are dynamic. So they should be optimized differently, and they are. They are backed by a dynamically resized array (so it's implemented like Java's ArrayList). And it's not possible to track insertion order in this representation, so integer keys have different iteration order from named keys.

Note that doing hash-tabley things with the objects (like changing their property order constantly, deleting named keys and so on) will change the backing representation to ordered hash table. The ordered hash table emulates the same order that results from the nature of the above optimizations to make it less surprising for user when the representation changes. If it wasn't ordered, it would be very surprising when the iteration order suddenly changed from ascending integer keys and insertion ordered named keys to something completely random.

doubles and SMis have been unboxed in arrays (the internal array that backs the integer key properties of an object) for a long time at least in V8.

JS objects don't have the same property, whatever order you see from iterating JS objects is only a side effect of the standard hidden class optimization, not because there was intention of having a certain order. In fact if you mix integer keys (which are represented differently) you will not get the "expected" iteration order:

    var o = {
        key: 3,
        1: 4,
        value: 10,
        0: 2
    };
    Object.keys(o)
    ["0", "1", "key", "value"]

If iteration order was specified you couldn't do those optimizations, note how even PHP7 is still paying a lot for the iteration order: the 100k element array only takes roughly 25% of the memory in JavaScript. And what is it even for? How often do you even need to iterate integer keys in insertion order over value order?

You can also use Object.create, __proto__ setter or a custom abstraction. However the constructor pattern is in practice used everywhere and I find nothing wrong with it, in fact in the next language version it will get first class syntax through the `class` construct. People need to accept that same keywords mean different things in different languages, just because Javascript `this` and `new` are not like Java `this` and new` doesn't make it better or worse.

Yes, it's actually a wiki page in a node.js project.

V8 can inline getters and setters like it can inline normal functios.

They should just provide an operator like ::, then features that can be implemented without special language support don't need to bloat the spec.

    array::last()

would mean same as

    last.call(array)

that means `last` can just be a regular variable in scope

Indeed the majority of the time the correct way to handle an error is to propagate it up to the caller...no shit. which is why requiring manual plumbing everywhere to do just that is ridiculous. And forgetting this manual check even once is devastating.

And exceptions are not the only thing that do this automatically for you, so this is just flat out horrible design decision.

Challenge accepted https://gist.github.com/petkaantonov/067c5f21395e7fe1f81d

These snippets are not even remotely equal. Leave the former untouched and modify the latter to this and you have somewhat equal semantics:

    function doSomething(null, pushEight);

    function pushEight(err, res) {
        if (err) return error(err);
        try {
            res.push(88);
            pushNine(res);
        }
        catch (e) {
            error(e);
        }
    }

    function pushNine(err, res){
        if (err) return error(err);
        try {
            res.push(99);
            showResults(res);
        }
        catch (e) {
            error(e);
        }
    }

    function showResults(err, res) {
        if (err) return error(err);
        try {
            console.log(res.join(', '));
        }
        catch (e) {
            error(e);
        }
    }

    function error(err) {
        console.error(err.stack);
    }

If you attach a `.catch(function(err){...})` at the end of the promise chain, then replace that function's body with the body of the error callback that just logs the trace.

In mithril promises if you return undefined from then, the promise will fulfill with the previous value, I.E. it behaves like .tap in other promise libraries (because doing this in a .then like mithril does violates the spec - which is evidently surprising)

However, with unbound console.log the code doesn't work at all, this is the case in Chrome for example.

Maybe the code was untested or only tested in firefox or node, where `console.log` is bound (which is sane default for singletons if you ask me)

I made a fix for a mongoose issue that sounds like what you describe and landed it in 1.2.3[1]. Can you verify? And if what you describe is a different issue can you make a github issue? (or is mongoose doing something so crazy that it cannot be helped at all? :P)

[1] https://github.com/petkaantonov/bluebird/commit/70f90c33dd94...

It does work for any library that uses callbacks - a node library that uses callbacks but not the node js callback convention has a bug.

1) There is not much work in promisifying libraries, for example the entire redis library can be promisified using 2 lines:

    var Promise = require("bluebird");
    var redis = require("redis");
    Promise.promisifyAll(redis.RedisClient.prototype);
    Promise.promisifyAll(redis.Multi.prototype);

After those lines all redis client objects have promise-returning versions of the methods. E.g. `redisClient.getAsync()` is the promise-returning version of `redisClient.get()`

2) Mixing callbacks and promises will result in very ugly code, see 1) to avoid it.

3) Forget about .fail(), this is not how promise error handling works. Use `.catch()` like you would use try catch. In your case that means not using it at all - then a full stack trace is automatically logged. Try catch is meant to be used with expected errors like file not existing, not bugs.

jQuery API is nothing like the DOM API.

This library is a list of functions that are nothing but proxies for some other functions which you might as well call directly. Given that the author has written this http://zedshaw.com/essays/indirection_is_not_abstraction.htm... I am sure this is some kind of joke...

I would not say this[1] is a minimal difference :P

[1]: https://github.com/petkaantonov/bluebird/blob/master/benchma...