[Original translation Book] JS function Programming 3.2 development and production environment

?? Functional programming in Javascript main directory The third chapter establishes the function programming environment development and the production environment environment

The programming style has nothing to do with the environment that the application deploys or will deploy. But the library has a relationship.

Browser

The main JavaScript application is running on the client side, which is the browser. Browser-based environments are great for development because browsers are everywhere, you can write code on your local machine, the interpreter is the browser's JavaScript engine, and all browsers have developer terminals. Firefox's Firebug provides very useful error messages and supports breakpoints and so on, but the same code can be useful for running cross-referenced error outputs on Chrome and Safari. Even IE includes developer tools.

The problem with browsers is that they have different interpretations of JavaScript! Although it is not a common phenomenon, some code may get very different results on different browsers. The main difference, however, is how they handle the DOM, not how the prototypes and functions work. As an obvious example, MATH.SQRT (4) returns 2 on any browser and shell. However, the ScrollLeft method relies on the layout strategy of the browser.

Writing specific code for the browser is a waste of time, which is another reason why you should use the library.

Server-side JavaScript

node. JS has become a standard platform for creating server-side and Web-based applications. Can functional programming be used for server-side application programming? OK! OK, but are these functional libraries now designed for this performance-oriented environment? The answer is still yes.

All of the functional libraries mentioned in this chapter can work on node. JS, and some rely on the Browserify.js module to handle browser elements.

A functional use case for server-side environments

In this fearless new world of our network systems, server-side application developers are always worried about concurrency. The classic example is that an app allows multiple users to modify the same file, and if they're going to modify the file at the same time, you'll get into a sickening mess. This is the problem of state maintenance that has plagued programmers for decades.

Let's assume the following scenario:

1. One morning, Adam opened a report to start editing, but did not save it when he went out to lunch.
2. Billy opened the same report, added content, and saved the report.
3. Adam came back from lunch, added content to the report, and saved and unknowingly covered Billy's content.
4. The next day Billy found his content gone. His boss roared at him, and all the people were furious with the developers, and the developers lost their jobs.

For a long time, the solution to this problem is to establish a state for the file. When someone edits the file, it switches the status to lock, which prevents others from editing the file and then switches the state to unlocked after saving the file. In our situation, Billy should not be able to modify the report until Adam had finished his meal. And as long as the file is not saved, no one else can edit it.

This is precisely the idea of functional programming with regard to immutable data and state of practical significance. The implementation of the function is not to modify the file directly, but to modify a copy of the file, that is, a new version. If you want to save this version and a new version already exists, we know that someone else has modified the original file. Danger was circumvented.

Now this scenario can unfold:

1. One morning, Adam opened a report to start editing, but did not save it when he went out to lunch.
2. Billy opened the same report, added the content, and saved it for a new version.
3. Adam finished his meal and went back to adding content, and when he wanted to save it, the system told him there was a new version.
4. Adam opened the new version, added its own content, and saved it as another new version.
5. By looking at the version history, the boss sees everything running smoothly. Everyone was happy and the app developers were promoted and rewarded.

This is called the event source. There is no need to maintain a clear state, only events are required. The process is very clear and the history of the whole event can be recalled.

The idea, along with some other advantages, is the growing cause of functional programming on the server side.

Cli

Although the Web and node. JS are two main JavaScript environments, some pragmatic and enterprising users are looking for ways to use JavaScript for command lines.

Using JavaScript as a command-line interface (CLI) scripting language is a great opportunity to apply functional programming. Imagine using lazy evaluation when searching for local files, or writing the entire bash script in a line of functional JavaScript.

Working with functional libraries with other JavaScript modules

Web apps consist of many things: frameworks, libraries, APIs, and so on. They can rely on each other as a plug-in for each other, or only as objects that coexist.

• Backbone.js
  • An MVP (Model-view-provider) framework that uses restful JSON
  • Requires Underscore.js library, which is the only required dependency of backbone
• Jquery
  • Bacon.js by binding into jquery
  • Underscore and jquery complement each other well,
• Prototype
  • Provides a range of functions similar to Ruby's enumerable style
• Sugar.js
  • modifying native objects and their methods
  • Be careful when mixing with other libraries, especially prototype

A functional language compiled into JavaScript

Sometimes the heavy C-coat outside of the JavaScript functional core makes you want to change a functional language. Okay, can drip!

• Clojure and Clojurescript
  • Clojure is a modern Lisp implementation, a language with all functional features
  • Clojurescript compiling clojure into JavaScript
• Coffeescript
  • Coffeescript is the name of a functional language and its compiler, compiled into JavaScript
  • Coffeescript expressions and JavaScript expressions can correspond

There are many such languages, including PYJS, Roy, TypeScript, UHC, Purescript and so on.

Chapter III Summary

Which database you choose to use depends on what you need. Need function-responsive programming to handle events and dynamic values? Use Bacon.js. Need an infinite stream without needing anything else? With Stream.js. Want a functional helper to complement jquery? Try Underscore.js. Need a strictly specific polymorphic structured environment? Look at Bilby.js. Functional programming tools that need to be exhaustive? Use Lazy.js. With all this? You write one yourself.

Any library is only good at the way it is used. Although there are few shortcomings in the library mentioned in this chapter, most errors will occur inadvertently. It depends on whether the library you have chosen is correct and meets your needs.

If we introduce code libraries in JavaScript environments, we may also introduce ideas and principles. Perhaps we can express it through the Zen of Python. Tim Peter.

Beautiful is better than ugly
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren ' t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should is one-and preferably only one-obvious a-do it.
Although that is obvious at first unless you ' re Dutch.
Now is better than never.
Although never is often better than ' right ' now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it could be a good idea.
Namespaces is one honking great idea-let ' s do more for those!
The next chapter is the technique of implementing functional programming in JavaScript

[Original translation Book] JS function Programming 3.2 development and production environment