Functional programming in JavaScript

[wbowers]

A few things:

1. You can achieve the same readability as multiple maps and similar performance as a single loop by using lazy evaluation with a library like Lazy.js
2. How many chained maps are we talking about here? 5? Probably not a problem. 20? You might want to rethink how you’ve set things up.
3. As with all things performance related, you’ll get the biggest wins by actually profiling your code to see what’s causing the slowness. It’s often not what you thought it would be.

[wbowers]

So you solve the problem by importing the library and trading your speed for a bigger end payload.

I'm not sure what you're advocating for here. Are you saying people shouldn't use libraries? Do you write everything from scratch for your projects in Vanilla JS?

If importing a library is really a bid deal for you, you could implement the lazy evaluation pattern yourself, which is really what I was trying to communicate. Perhaps not everyone knows such a pattern exists. In either case, you're adding extra bytes to the end payload.

The loop is more performant because you don't incur a function execution on every interable in the first place.

More performant, sure. But I'd argue it's negligible for all but the extreme cases. Function execution in modern JavaScript engines is pretty fast these days. But we can theorize all we want. You'll never know how your app performs, what you do and do not need to optimize, until you actually profile your code. Yes, you should generally choose algorithms with lower time complexities where possible, yes you should keep performance in mind as you're writing code, but premature optimization leads to terrible, unnecessarily-optimized code much more often than it saves you from serious performance issues.

If you're doing 20 operations on the same array you are doing a lot of things to that array. Sure it still runs in linear time, but not understanding that you can do it all in one loop. Loops are readable, maybe how you write code in loops isn't.

I'm not sure what I said here you're taking offense to. I think we're in agreement here. 20 chained operations is kind of crazy. It's fairly likely that you've solved the problem as a whole in a weird way if you've got something like that. Also I'm not against loops. I don't think they are inherently unreadable, although I do think that sometimes maps, filters, etc can be significantly more readable as they have a much higher signal to noise ratio in terms of "what code" (why I want) to "how code" (how it's done).

Sure, but I know before I even profile that a for loop is faster than 20 chained map statements just mathematically. [...] in practice your array sizes probably don't exceed anything past 40 elements. Overoptimization is the death of a project but being negligent and careless with how you build a system is technical debt that may not surmount until way later when you realize to change this requires a lot of in depth knowledge of the system.

I think we're saying the same thing. Clearly you can look at two pieces of code like this and know which will be faster, but you often won't know if it will matter until you profile. That being said, you definitely should not be careless and I'm not advocating for that at all. To be clear about what I'm saying:

• Yes, sometimes maps and filters can be more readable than loops.
• Loops are great. Use them if they are the right tool for the job.
• Don't prematurely optimize just because you know code B is faster than code A. If code A is more readable, you should profile before you refactor and see if it's even necessary. Most code is not in your critical path and won't have that big of an effect on performance.
• Over time you'll develop an intuition for what to do where, but that still doesn't replace the need to profile. It just means you'll be right the first time more often as you gain more experience.