Why Functional Javascript Works Better For Me ( sometimes, and maybe for others)

I’ve been writing javascript code since 2006.

Right from the very first lines of code in javascript, I felt that the simplicity of javascript was exactly what i was looking for in a language.

In this post, i’m sharing my thoughts on why i think javascript was and still is awesome and how functional javascript sometimes works better for me.

Coming with knowledge of strong typing languages (actionscript 3.0) and from weak typing languages (php), javascript had the feeling of being in the middle.

The syntax is readable, simple, familiar (as in actionscript), however – the need to be strict about every declaration didn’t exist – THAT’s the point.

Being a dynamic language with which, one can do everything on the fly – made it to be the favourite tool for web apps and a rising force for ligth rich internet applications (remember RIA?).

After discovering how prototype works in javascript (it’s a function…) – I really getting used to this idea minimalism – using “function” – you can define a reusable class, singleton, method and quite everything else that is needed.

So, with jquery around, teaching everyone the concept of “chaining” functions – without knowing, myself and probably everyone that used jquery, was actually writing functional javascript code.

Another common use case of functional programming in javascript is closure: in some of the examples of closures, there is a function that returns a function (again, minimalism at its best, imho):

Douglas Crockford explained quite well how javascript with ES6 is becoming a truly functional language.

With latest rise of javascript, I see functional programming becoming a part of todays development  – perhaps, along side with oop. Here are few of my own reasons for adopting some of the functional programming style to my development in javascript:

Zen of Syntax – no weird syntax

In javascript, there’s really no need to introduce the unusual syntax of loops, such as:

There’s a function for every loop you’ll ever need, starting with: forEach, map, etc.

I started adopting Douglas’ approach for iterating json objects using:

Readable and Declarative

Javascript can be written as a story, if one might want to:

Safer Context

The following (famous problem) code will assign the same value of “i” to every function:

That’s because the “for” loop run all assignments of the “onPlay” function in the same execution context. To solve that, prior to modern es5/6 solutions, you could use private context for each (using a closure):

With functional javascript, you would use a simple “forEach”:

Documented by Nature

This pro perhaps should go with the “readable and declarative” title, however, I think it should deserve a title of its own – since sometimes, writing functions and naming them appropriately (name is why a function exists), saved those lines of comments:

Conclusion

To conclude, I feel like functional programming and its implementation with javascript, has its positive impact for a solid readable and secured code maintenance. I’m aware that for some, functional programming might not feel the same nor better, however, I sure hope you’ll be able to see that we’re using it and it may make sense in some cases.

 

  • azder

    if
    > forEach executes the callback function once for each array element;
    > unlike everyand some, it always returns the value undefined.
    from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach

    then how come:

    musicTracks
    .forEach(addThumbs)
    .forEach(addToPlaylist)
    .map(createPlaylistTrack)

    ?

  • vsync

    any function is always slower than the basic code, and in many cases, where performance matters, you should use loops. it’s even less characters to type. here is some benchmark: http://jsperf.com/fast-js-benchmarks

  • @azder you’re right.
    i fixed that.

  • hi @vsync:disqus.
    you’re correct.
    my article takes the perspective of functional coding.
    performance wise operations should be considered when the time comes (not premature) – only then – a solution of for loop might be applied.

  • Wayne

    Benchmarks change over time.