Gentleman: Because until you have tests proving it works before and after optimizing, and numbers proving it’s slow and needs optimization, any optimization is a waste of your time.

Kotzen: This snippet i’m writing is in a performance critical part of code, so i’d like something that reduces the amount of memory allocation/garbage collection; it gets called hundreds of times a second.

Gentleman: Zap0: if it’s performance critical, it’ll have tests and profiling.

Piske: Hundreds of times a second is nothing

Gren: Hey guys. Why can’t I seem to use jQuery selectors in a function block? http://jsfiddle.net/72wqm40a/

Gentleman: Zap0: it’s easy to convert a filter to a for loop if it’s actually necessary. but it almost certainly won’t be.

Dewoody: Gentleman: i’ve read like a million things on testing frameworks and stuff, but I still don’t really get where my test should be with front-end code ?

Gentleman: Horita: the same place they are with backend code?

Elvis: Zap0: you can do the filter in place

Gentleman: Horita: 99% of your code shouldn’t interact with the DOM or ajax directly

Warnecke: Gentleman: so you should be using plain js in the backend and TDD with that, and then ‘connect’ to the DOM?

Gentleman: Malphurs: you can. the problem is that you’re not p***ing a function to do***ent.ready – you’re p***ing the *return value* of the UI function.

Gentleman: Malphurs: which is undefined.

Gentleman: Horita: i said tests, not TDD.

Kotzen: Tcsc, not sure what you mean by that, but it sounds good.

Veksler: Gentleman: Oh? How do I p*** a function to onready then?

Gentleman: Horita: but i’m saying that most of your code should be pure functions – and those are easy to test.

Gentleman: Malphurs: UI – not UI

Gentleman: Malphurs: in JS, functions are values, like the number 3

Patellis: If I try without the parenthesis, then get the same result.

Gentleman: Malphurs: the *invokes* the function. which isn’t the same as p***ing it around.

Elvis: Zap0: http://pastie.org/10417023 line 6 to 12 filters the array in place.

Gentleman: Malphurs: because the id is “test” and you’re selecting “#text”

Slaydon: Gentleman: to minimize any more debating on the matter, what should I use for testing? just so i ask no more questions that give me ****ysis paralysis

Gentleman: Malphurs: http://jsfiddle.net/72wqm40a/2/ works fine.

Mostrom: Gentleman: God I’m silly, thanks :-

Gentleman: Horita: personally i like https://npmjs.com/tape

Crews: Oh yeah you’ve recommended that before

Kotzen: Tcsc, ah! i see what it does. nice! very nice! thank you.

Gentleman: Zap0: i still recommend not mutating things. it won’t be slower, trust me.

Gentleman: Noticeably slower, anyways.

Elvis: More importantly, it will introduce nondeterminism

Defusco: Sos if this is a bit thick but I’ve still no idea how I’ve managed to bork this up jsut for firefox http://sendvid.com/7n0vmp8u

Elvis: Because the gc will kick in and run for. well, some nondeterminstic amount of time.

Janocha: Zap0 tcsc is right but the perspective he takes is for things like game loops where stuttering is death

Elvis: Yeah, if you don’t have a frame budget or even if you don’t care about making 60fps and are ok with 30 you shouldn’t worry about it.

Kotzen: Gentleman, i appreciate your concern for writing ‘good code’. i tend to do so most of the time. this snippet is in performance critical path, i’d prefer tcsc’s trick if it’s going to result in deterministic high performance.

Gentleman: Zap0: do what you like, but if you haven’t started with “filter”, profiled it, and then only converted it to the loop when necessary, you’re gonna have a bad time

Gentleman: Performance in JS is never deterministic, because of the JIT.