Also, map can side effect.

 
Batalona: Gershkovich: thanks for that :

Siew: I’m having an error in my main.js file, it says “Uncaught ReferenceError: device is not defined” how can I get this to work ?

Wakley: Reaverxai: For help, ask your question. Be patient. Code samples should be pasted in a paste service see !paste. Tell us 1 what you want to happen, 2 what is actually happening, and 3 any error messages you find see !describe and !debug.

Altmark: At this moment, i have a website with a left collapsed navbar for smartphones, and a carousel sliding images using bootstrap. When my navbar is open, if the slider changes his picture, it resizes the whole website to a lower scale, and i dont want it to do it

Hagele: I can’t figure out why this is happening, #web told me it might be javascript stuff, so I went to debug console and saw an error, there’s a small if statement which makes an error

Matarrita: Put up a snippet of code that relates to the if statement

Dzinski: If device.mobile device.tablet{.} but it says that device doesn’t exist

Weisholz: That’s the only line with an error in the .js files

Gershkovich: Xatenev: the person that wrote that article is 1000% wrong. not only is forEach a much better way of writing code but in modern engines it’s actually faster as well

Gershkovich: Xatenev: of course, speed in js doesn’t matter, particularly on the browser side. as soon as you touch the DOM you’re dropping all your performance “”enhancements”” out the window

Simental: I think saying things like that is harmful

Albriton: It suggests that there’s some magic to DOM that suddenly slows down all your JS

Gershkovich: Xnil: because basically there is

Philmore: When in reality, there is not. DOM manipulations are expensive, and so too can be js operations

Gershkovich: Working with the DOM is slow, any performance enhancement you make unless it’s to work with the DOM less is not going to save you much at all

Linzie: Xnil: unfortunately optimization is a complicated subject that is hard to summarize in terms of discussion lines

Modero: I understand what you mean to suggest

Speirs: Gershkovich: that’s hardly true at all.

Gershkovich: Then not to mention the fact that the time you’ve saved if any is offset when six months down the line the engines change and your code is slower again

Linzie: While we’d all like to be absolutely correct at all times, it is simpler to go with generalizations

Gershkovich: And now you also don’t understand how it works!

Linzie: Xnil: Also no one benchmarks properly so they have no idea why or what they’re optimizing for

Linzie: On the other hand, I’ve always hated the implied idea that you should write slow code because it doesn’t matter

Gershkovich: Xnil: surely you agree that using a for loop over map or forEach purely because it’s faster *right now* is a bad “optimisation”?

Lisee: Buu: i think it’s easier to say that “dom manipulations usually are the overhead anyways” instead of “dom manipulations are the only things that can be slow”

Linzie: Also both for;; and array.forEach are ugly clumsy ****ing language constructs that should be shot out of a plane

Buegler: Gershkovich: depends on the application. prematurely, yes.

Gershkovich: We are probably not going to agree then

Linzie: Xnil: We’ll appoint you official ‘explainer of the theory of optimizing the right spot’ to people

Linzie: But seriously, who thought ar.foreach was a reasonable thing that should continue to exist

Pexsa: Buu, What would you use instead?

Gershkovich: Xnil: we’re talking side effecting work here

Gershkovich: Why not just make map a monad

Linzie: Pexsa: Part of it is just writing function is a lot of redundant characters =

Lamott: Gershkovich: why not?

Gershkovich: Buu: come to the es6 side

Lewman: Also, map can side effect in js i believe