Malling: Chrissonar: you can use reduce on any browser
Cone: Array.prototype.reduce is part of ES
Cone: I don’t know when it appeared though
Deshazer: Seitzinger but why is it that I can’t find anything about it here: http://www.w3schools.com/jsref/jsref_obj_array.asphttp://www.w3schools.com/jsref/jsref_obj_array.asp
Werdlow: Is the doc totally outdated then?
Tedrow: Don’t use w3schools lol
Derobertis: If you want js docs just use MDN
Imoto: Generally anything in the docs on MDN is going to be the same accross browsers
Obi: Unless its marked experimental
Desiga: Cone, thanks! pick is almost what I need, I have to call keys on pick result to have exactly what I need
Keitsock: P4trix: missing: an example, some code.really *any* details at all
Lu: Chrome extensions are made in JS?
Mcmahon: Keitsock, thank you. I got it to work. JSON.stringfy did the trick :
Maletz: Is itpossible to make extension that will read all css files ,or get css properties from DOM, and change all white backgrounds to something darker?
Wry: Any quick way to disable the console.log calls in production?
Camelin: It’s kinda strange. If put the string on my own, it doesnt work. But with JSON.strinfy it works. And its the exact same string :S. I did console.log it .
Wallwork: I come from Java and Python land where there’s logging libraries and you configure the logging level
Buchholz: How do you guys handle this?
Nodarse: Tomorrow__: DEBUG && console.log — poor man’s logging level
Keitsock: Tomorrow__: use a wrapping function that no-ops the calls in prod
Nodarse: Also there logging libraries a lot of
Keitsock: Log’foo’ – console.log in dev, nothing in prod
Keitsock: Really it doesn’t matter anyway since in production the end user won’t likely have the console open
Pele: Keitsock: Nod****: OK, thanks
Ricci: Keitsock: does logging impact performance in any significant way?
Keitsock: Afaik if the console isn’t open console.log is a no-op anyway
Guempel: Nod****: Keitsock: good to know
Paszkiewicz: Tomorrow__: note that the function calls may or may not get DCE’d. If there’s no constant propagation, then you get a function call overhead, and a jne check. Those are *not* anything you should worry about in most cases, but they’re that with runtime checks.
Tinger: Macros can fix that, but that requires compiling from Sweet.js
Nodarse: Day when I would care about no-op console.log overhead is the day when I’ll switch to another language
Credit: Tomorrow__: oh, also, without macros, things like: console.logJSON.stringifyfoo will always have the JSON.stringify overhead.
Seher: How can I have the effect similar to mouse-over on elements in a page with JS or Jquery ?
Lacava: That *might* be major, depending on the work you’re doing before calling the function. So you may want to look out for that. With macros it’s not something you need to worry about.
Keitsock: M2n: mouseenter is the event
Keitsock: You can bind it to any node, or the do***ent itself
Nodarse: With macros you need to worry about macros, yeah
Seher: Keitsock, let me google it . thanks.
Cother: Nod****: you don’t really need logging functions being first cl***, so there’s nothing to worry about there.
Nodarse: M2n: what do you mean in “effect similar to mouse-over”?
Seher: Like suppose we move mouse over the a tag we see the underline. I am trying to do similar stuff with js.
Mojardin: Thanks btw for the explanation
Weagraff: Tomorrow__: a branching test depending on some value’s equality.
Feerick: I would avoid logging too much for that stuff
Feerick: Not because of performance but if you’re logging at the rate where it effects performance