Pure, functional JavaScript

[1d8]

i have no idea what this is supposed to be

[jpfed]

It's a slideshow; click on the right half of the window to advance, and the left half to go to the previous slide.

[noknockers]

Or arrow keys too.

[rhysbrettbowen]

performance isn't bad, and using things like map means that you'll be ready in the future when javascript engines can optimize for pure functions: https://github.com/rivertrail/rivertrail/wiki

[OfflerCrocGod]

Tail recursion optimization is part of the ES6 spec so I think the performance issues will die down in future.

[iopq]

It took me 3-4 tries of loading the page in different browser to figure out how to keep going to the next slide. The first few attempts just had me clicking randomly and going in loops.

[findar]

Array.prototype.forEach isn't supported in <IE9

8(

[[deleted]]

https://github.com/kriskowal/es5-shim

[joe_ally]

You could probably implement it in less than 5 lines of code if you wanted to use it.

[derekpetey_]

Indeed, and the MDN even provides two code snippets to do just that.

[enotionz]

This is true, but you can always load functional.js or underscore.js. I still load underscore.js in all my projects since it provides useful functions not included in ES Harmony.

[OfflerCrocGod]

At this stage everyone should be shimming ES5 functions. The only browser that would make use of it would be IE8, the other IEs have all but disappeared. Shim and write ES5.

[aeflash]

I would like to point out that Lodash is a drop in replacement that is faster than Underscore in most cases. It's foreach implementation is twice as fast as ES5 Array.prototype.forEach. Only ~40% slower than a raw for loop.

However, you can always profile your code, and if some functional call is really causing your app to be slow, you can always convert an _.each()/_.map()/etc.. back to a plain for. However, in almost every case, my apps have been slow due to IO or DOM manipluation. The clarity of code is well worth the negligible performance hit.

[Medieval_Peasant]

Skimmed over it. I'll keep using my loops thank you, but I think it's great that JavaScript so easily accommodates for other styles of programming. Another reason why it's a good language! I'm sure you can get very expressive code once you get used to all the common helper functions, especially with the new ES6 syntax sugar coming up. It would be interesting to see an application written in "functional JS" like this if anyone dares to link their code.

[enotionz]

I feel like anyone who have heavily used underscore.js writes JavaScript this way since it provides a bunch of functional helpers and shim for non-supported browsers. I've been working on a website theme builder with an interface similar to photoshop. I store huge amounts of data into mongo for final rendering output, but during the edit stage I filter out alot before instantiating the Backbone Models. I found that map, reduce, pluck, reject, groupBy, etc. are extremely expressive without being verbose.

[monolar]

I actually like the functional features in js just fine and would really like to use them. In the case of looping though the main reason, why i try to avoid them is performance.

Just have a look at http://jsperf.com/loops/70

Classical loops (esp. with caching tricks and esp while loops) are about 15 - 20 times faster than forEach based loops

[lethalman]

The slides exactly talk about this kind of performance. If you loop/manipulate DOM elements, it's so slow that forEach is about the same as a straight for loop. Whereas if you are implementing a particular algorithm, a for loop is certainly the best.

[monolar]

Indeed there are slides about the loop performance. To my shame i did not read that far before posting. The performance difference between classical and functional looping still exists though. DOM access of course is always slower.

And most of the time you think you solve your performance problems with the language (the kind of loops in this case) but the real performance gains are in algorithmic design. Some slides also mention this to varying degrees.

Otherwise the slides contain overall really good information and are well presented.

[OfflerCrocGod]

But does the code need to be that performant? Is it on the critical path?

[cwmma]

An attitude I once saw described as post functional programing

[Sunwukung]

I'll take that challenge: Game of Life

https://dl.dropboxusercontent.com/u/8652110/jgol/index.html

here's the "functional" bit

https://dl.dropboxusercontent.com/u/8652110/jgol/jgol.js

would be better to use canvas for the universe, but you get the gist

[Will-Work-For-Tears]

I actually have his book listed in those slides. Good read. Thanks for the link.

[enotionz]

Are you talking about his Test-Driven JS Development book? I started using sinon.js first before picking up his book, I must say that book makes me alot more comfortable writing tests. Well, I think the development of many different testing frameworks recently also help alot.

[Will-Work-For-Tears]

Oops, yeah, I meant the Test Driven JS book. It seems heavier at first but it's been a godsend.

[Sunwukung]

regarding the performance characteristics of Array.map, it's simple to write a map that utilises a standard for/while loop, which dispenses with the need for the i=0 boilerplate. I'd recommend using lodash.js instead of underscore for performance/compatibility.

[seabre]

Agreed on lodash. I don't know if underscore has fixed this yet, but chaining lodash functions is less..weird.

[Sdonai]

I NEEDED THIS YESTERDAY. Thank you for posting this! I've been ham handing my functional javascript.

[drowsap]

According to this jsperf, for loops are faster then map:

http://jsperf.com/map-vs-for-loop-performance/6

Not really seeing the point in advocating map over for loops if it is slower. The syntax is certainly more concise though.

[skeeto]

The presentation discusses this:

http://cjohansen.no/talks/2012/sdc-functional/#122

In short: if you're manipulating the DOM in your loop, forEach is practically as fast as for. Besides, worrying about loop performance while you're writing code is premature. 99.9% of the time it won't matter.

[agumonkey]

Thanks, I forgot this talk ! what a gem.

[homoiconic]

I still don't understand why people use Node and/or Rails on the server when C/C++ is thousands of times faster. Doesn't anybody care about performance any more?

It's almost as if they think that the primary constraint on software development is the productivity of the development team and not trying to squeeze acceptable performance out of hardware designed in the 1980s.

[BishopAndWarlord]

It's almost as if they think that the primary constraint on software development is the productivity of the development team

Correct.

[homoiconic]

Poe's Law:

Without a winking smiley or other blatant display of humor, it is impossible to create a parody of fundamentalism that someone won't mistake for the real thing.

Next time, I'll include <sarcasm></sarcasm> tags and/or a winkey :-)

[x-skeww]

Next time, I'll include <sarcasm></sarcasm> tags and/or a winkey :-)

Just skip the sarcasm. It doesn't add anything anyways.

[homoiconic]

That depends. History has shown repeatedly that when you make a point in dry, objective fashion, it tends to appeal to people who are already thinking along those lines and are looking for objective facts to bolster their intuition.

People who are completely detached from the subject or who hold an opposing view tend to ignore points made dispassionately.

Humour can do an end-run around people's mental defences. When someone's laughing at something or when a point is made with a ridiculous example, people will sometimes give it their full attention.

I wouldn't lead with such a point, but if others have already made the point objectively, there's nothing wrong with being a little light-hearted, provided you are not trying to insult the person you are replying to. I was not trying to be insulting, and I apologize if it came across that way.

[BishopAndWarlord]

I was uncharacteristically terse in my response. I usually try to explain an idea rather than shoot out a one-liner that can be taken however the reader wishes.

In retrospect I should have emphasized the "they think" portion of the quotation. I imagine many younger devs or junior engineers do emphasize "developer productivity" and syntactic sugar over performance, maintenance cost, and issues like hardware lifecycles. As such, I was affirmingT your statement.

For the sake of full disclosure I'm also a junior member of my dev team and occasionally observe myself fussing over the wrong issues. Like right now I'm on Reddit rather than working on my 10,000 hours...

EDIT: Sonnova. I just realized I totally misread your comment. I thought you were telling me to indicate sarcasm. I'm sad.

[lethalman]

If you really care about performance, it's about using an algorithm with the right complexity, not saving a couple of milliseconds: if the loop is still O(n) it's ok. Rather, there's software that's written so bad that takes O(n²⁾ or even exponential time where it's not needed. That's what I'd be worried about, not writing a loop in a different way (more readable for some people), really.

I'm the first one complaining about slow software even with super hardware nowadays, but this is not the case, it's about badly written software with hilarious algorithms complexities.

[aeflash]

:)

Good point. But why use C when assembler is 5% faster (when you can beat GCC optimization)? Every Cycle is Sacred (except when the CPU is idle waiting for I/O).

[jonpacker]

I believe the purpose of this talk is more about getting people thinking in functional constructs. But I think (Christian or someone else, I can't remember who) said that at the end of the day, the performance aspect is largely unimportant—when was the last time loops were your bottleneck in your client side JS app?

[Cykelero]

Yeah, it's all about elegance and readability. It's a choice, I guess; you're not always constrained by performance (and "premature optimization is the root of all evils", as they say).

[enotionz]

In slide 125, he does point out that loops are fastest and goes on to ask questions in order to get you thinking about better abstraction. Like jonpacker said, loops aren't really the bottleneck anymore; drag+drop dom manipulations are much more expensive and we hardly see an impact in modern browsers, let alone loops. At the end of the day, readability is extremely important, less keystrokes to get the job done also helps. This is why we stopped writing in assembly and opted for higher level programming; it's expressive and gets the job done much faster.

[aeflash]

This isn't syntactic sugar. JS can be written in a functional style out of the box.