I’m pulling an external sdk.

 
Stanco: Or like, not even standard?

Sawyer: Basically I am using this for a page guide for my app: http://tracelytics.github.io/pageguide/

Sieg: Dekok: you can’t wait for a map that is using await as well?

Sawyer: I need to be able to initialize the guide from JS, not a button click

Saysana: Which part breaks heh

Serpico: Tcsc: keyboard events differ a lot. They’re trying to fix that in DOM 4, but I don’t think that’s implemented yet

Rossmiller: KeyCode has always worked everywhere for me

Risberg: Hopefully no browser ever breaks it

Kalk: I think better standardization would be nice though

Pingitore: And it’s annoying to have to look up keycodes.

Gloeckner: Tcsc: I don’t think they’d remove things from DOM.

Shryock: So even deprecated things are bound to stay around forever. Unless they’re actively bad, like synchronous XHR

Breheny: Lol, that used to be a thing?

Vasilopoulos: Oh woah, thats what the third arg in xhr is

Eliot: Var request = new XMLHttpRequest;

Meiners: Request.open’GET’, ‘/bar/foo.txt’, false; // false makes the request synchronous

Hilderbrand: Oops, sorry for double message

Sawyer: Common Im sure one of you geniuses out there can tell me how to programmatically open this page guide from just looking at this plugin: https://github.com/tracelytics/pageguide/blob/master/js/pageguide.js

Sawyer: I will send you good vibes for helping : :

Kurban: If someone is interested: Ember dev rantins about V8 issues https://twitter.com/stefanpenner/status/641517839371776000 and after that some rants like “anyways touch delay – developers can work around. Perf issues a result of gambling JS == C –developers can’t work around.” and like https://twitter.com/stefanpenner/status/641518791050985472

Goldhahn: Is interesting to see this point of view, it’s the first time that I read a rant like that

Raynoso: Sawyer: you mean calling the open method?

Goodfield: Hannibal_Smith: Ember devs are always saying that, because they write Ruby in JS and get mad that v8 doesn’t run that “fast”

Shamapande: Is gambling js a lib?

Blumenfeld: Idk what Im reading lol

Gobin: Dekok, I think that the interesting point is that Safari js vm can handle thair code without too much problems

Wekenborg: In any case, all JIT VMs for dynamic languages optimise for static use cases. Even the ones for really dynamic languages, like Self, Smalltalk, etc

Geffert: At least this is the message that I got from that discussion

Niebaum: Hannibal_Smith: JSC has special support for some constructs, and is really bad at other things.

Pilbin: Or is it a gamble that js == C?

Pegelow: Higuchi, the discussion was a Chrome dev ranting about the 300ms delay in Safari on iOS, then a Ember dev replyed saying that at least they can have workaroud for that

Gavia: But they can’t do anything if V8 has bugs like https://code.google.com/p/v8/issues/detail?id=2935#c9

Gillmer: Higuchi: that’s how I read that

Maillet: So he later ***ert that V8 like only code that was written like C

Lemaster: The discussion go on with a Safari dev saying that the rant of the Chrome dev is immature

Gazella: And so on, if you are interested

Alex: Not really interested. I’ve been in another discussion with Ember devs that was pretty awful.

Heagy: Dekok, in this discussion was more a Safari dev saying that they prefer to ignore bug reports where that Chrome dev was active

Cavagna: I’m pulling an external sdk. In my script I have to use a setTimeout function because the object isn’t available right away. The vendor told me that I need to ***ign this function to a window.onSeeReady. I’m not sure I understand what technique they are recommending and was wondering if this made since to anybody.