Gull: How does it go against specs?
Schuchmann: Which means it has more to do with how they’re approaching it
Bazinet: Ms7: if the performance of a promise library matters to your code, you’re doing promises wrong
Boone: Which means eventually native promises should have better performance
Allegrucci: Bazinet: to be fair what he linked also mentions using almost 4x as much memory as well
Bazinet: That goes for memory too
Kalb: You’re saying that if you have too many promises you’re doing them wrong?
Meckes: Can you really make a blanket statement like that? what if you’re aggregating data from a bunch of servers for example
Hohaia: Gull: The first answer mentions “Even if V8 implemented the same optimizations as bluebird, it would still be hindered by specification.”
Bazinet: If you’re writing a web robot, you should obviously not allocate a promise for every request
Frische: Games: that was my first thought when reading this, IF native implementations will eventually have better performance. But from reading the discussion in the comments, that doesn’t seem to be the case *because* of ES6 specs
Gull: Aiui, in general you should receive promises from APIs, and rarely create them yourself
Laracuente: Which to me, seems like a bit stubborn. But then again I don’t know jack about ES6 specs. Maybe there is a proper reason.
Kevelin: It’s true that there are things that may seem like a good idea but still cause runtime performance issues
Chiaro: I mean for example it may seem very clean to use recursion endlessly but it never works out well
Bazinet: Well, it works well in languages that implement it correctly
Bazinet: But you wouldn’t write code like that in Java
Walla: ECMAScript: everything implemented incorrectly
Bazinet: The point is that in 99.99% of cases, whatever is behind the promise is going to swamp any issue of promise overhead by orders of magnitude
Felila: The whole issue is the use of new
Creath: Whoa so promisifyAll actaully takes callback’d libraries and makes them use promises instead?
Varnedoe: Games: I just saw that too… :O
Shubrick: Gull: doing that thing now lol, 2d games in unity has caught me eye.
Aldonza: Ms7: yeah that’s pretty awesome. i ****ing love js
Lesniewski: I was able to “extend” this with an “add” button, to attach new li and make these draggable, too. But I just can’t get any “response” from the div id=”trash”, or its “drop” event
Gull: Joakimk: you’re using both this library and jquery-ui?
Silverio: Gull: well, actually, I’m mostly experimenting with all this. Are you asking about the jquery-ui checkbox in the fiddle?
Gull: I was wondering whether the sortable plugin was interfering with the jquery-ui sortable
Mccardle: Gull: I see. I updated the fiddle, and unchecked the UI box. But it doesn’t seem to have any effect. Looking at other examples of similar stuff not using the same specific plugin, though, it seems the code for drop should be quite simple. Do you think I’m on the right track here? Could it be the html5sortable plugin is interfering with the “native” ? jQuery code for the drop?
Philipp: I am a bit puzzled. when adding unit test tools for web dev. should you aim for DOM support in the test tools? or should you only focus on business logic that does not involve DOM manipulations?
Godzik: Squeakytoy: in an ideal world you should aim to test both
Jacquemin: Im just wonderinf its thats a bad practice though