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.

Mcfate: I’m using “html5sortable” jQuery plugin to make the li of an ol draggable. However, I want to extend this with a “delete” functionality: drop li onto div id=”trash”. But I need some help getting started with the necessary javascript/jQuery. Please have a look at http://jsfiddle.net/jokke/uxp12bjv/

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?

Eiselman: Is ***erting DOM manipulations a good idea for testing JavaScript logic? or should you only focus on testing business logic?

Godzik: Squeakytoy: in an ideal world you should aim to test both

Jacquemin: Im just wonderinf its thats a bad practice though