It does not matter in terms of programming style what type of environment the application is being developed in and will be deployed in. But it does matter to the libraries a lot.
The majority of JavaScript applications are designed to run on the client side, that is, in the client's browser. Browser-based environments are excellent for development because browsers are ubiquitous, you can work on the code right on your local machine, the interpreter is the browser's JavaScript engine, and all browsers have a developer console. Firefox's FireBug provides very useful error messages and allows for break-points and more, but it's often helpful to run the same code in Chrome and Safari to cross-reference the error output. Even Internet Explorer contains developer tools.
The problem with browsers is that they evaluate JavaScript differently! Though it's not common, it is possible to write code that returns very different results in different browsers. But usually the differences are in the way they treat the document object model and not how prototypes and functions work. Obviously, Math.sqrt(4) method returns 2 to all browsers and shells. But the scrollLeft method depends on the browser's layout policies.
Writing browser-specific code is a waste of time, and that's another reason why libraries should be used.
The Node.js library has become the standard platform for creating server-side and network-based applications. Can functional programming be used for server-side application programming? Yes! Ok, but do there exist any functional libraries that are designed for this performance-critical environment? The answer to that is also: yes.
All the functional libraries outlined in this chapter will work in the Node.js library, and many depend on the browserify.js module to work with browser elements.
In our brave new world of network systems, server-side application developers are often concerned with concurrency, and rightly so. The classic example is an application that allows multiple users to modify the same file. But if they try to modify it at the same time, you will get into an ugly mess. This is the maintenance of state problem that has plagued programmers for decades.
Assume the following scenario:
- One morning, Adam opens a report for editing but he doesn't save it before leaving for lunch.
- Billy opens the same report, adds his notes, and then saves it.
- Adam comes back from lunch, adds his notes to the report, and then saves it, unknowingly overwriting Billy's notes.
- The next day, Billy finds out that his notes are missing. His boss yells at him; everybody gets mad and they gang up on the misguided application developer who unfairly loses his job.
For a long time, the solution to this problem was to create a state about the file. Toggle a lock status to on when someone begins editing it, which prevents others from being able to edit it, and then toggle it to off once they save it. In our scenario, Billy would not be able to do his work until Adam gets back from lunch. And if it's never saved (if, say, Adam decided to quit his job in the middle of the lunch break), then no one will ever be able to edit it.
This is where functional programming's ideas about immutable data and state (or lack thereof) can really be put to work. Instead of having users modify the file directly, with a functional approach they would modify a copy of the file, which is a new revision. If they go to save the revision and a new revision already exists, then we know that someone else has already modified the old one. Crisis averted.
Now the scenario from before would unfold like this:
- One morning, Adam opens a report for editing. But he doesn't save it before going to lunch.
- Billy opens the same report, adds his notes, and saves it as a new revision.
- Adam returns from lunch to add his notes. When he attempts to save the new revision, the application tells him that a newer revision now exists.
- Adam opens the new revisions, adds his notes to it, and saves another new revision.
- By looking at the revision history, the boss sees that everything is working smoothly. Everyone is happy and the application developer gets a promotion and a raise.
This is known as event sourcing. There is no explicit state to be maintained, only events. The process is much cleaner and there is a clear history of events that can be reviewed.
This idea and many others are why functional programming in server-side environments is on the rise.
Although web and the node.js library are the two main JavaScript environments, some pragmatic and adventurous users are finding ways to use JavaScript in the command line.
Using JavaScript as a Command Line Interface (CLI) scripting language might be one of the best opportunities to apply function programming. Imagine being able to use lazy evaluation when searching for local files or to rewrite an entire bash script into a functional JavaScript one-liner.
Web applications are made up of all sorts of things: frameworks, libraries, APIs and more. They can work along side each other as dependents, plugins, or just as coexisting objects.
Backbone.js- An MVP (model-view-provider) framework with a RESTful JSON interface
- Requires the
underscore.jslibrary, Backbone's only hard dependency
- jQuery
- The
Bacon.jslibrary has bindings for mixing with jQuery - Underscore and jQuery complement each other very well
- The
- Prototype JavaScript Framework
- Provides JavaScript with collection functions in the manner closest to Ruby's Enumerable
Sugar.js- Modifies native objects and their methods
- Must be careful when mixing with other libraries, especially Prototype
Sometimes the thick veneer of C-like syntax over JavaScript's inner functionality can be enough to make you want to switch to another functional language. Well, you can!
- Clojure and ClojureScript
- Closure is a modern Lisp implementation and a full-featured functional language
- ClojureScript trans-compiles Clojure into JavaScript
- CoffeeScript
- CoffeeScript is the name of both a functional language and a compiler for trans-compiling the language into JavaScript
- 1-to-1 mapping between expressions in CoffeeScript and expression in JavaScript
There are many more out there, including Pyjs, Roy, TypeScript, UHC and more.