ECMAScript for different environments (operating platform), very different design structure, ideas, use.
1, the browser: DOM BOM
2, NodeJS: FS, HTTP built-in module; third-party modules; built-in module
3, desktop applications and other platforms: Window Mac and other operating system platforms
A, CommonJS norms origin
JavaScript is a language born of a service in the browser.
JS API's performance depends on the ability of host environments
1, web1.0 era: W3C provides support for browsers
2, web2.0 era: With the development of HTML5, more standard API appears in the browser. However, the back end of the JS standards untouched
3, in January 2009, when, Kevin Dangoor wrote this article https://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/ , nominated for ServerJS specification. August 2009, changed its name to CommonJS.
API to display a wider utility
---- => article began ----
Server-side JavaScript needs what
At 14:00 on January 29 2009 * 816 * 4 minutes to read the word
Server-side JavaScript technology has been around for a very long time. Netscape provides early 1996 in their server software in a server-side JavaScript, and Helma there for many years. However, a great deal server-side development has occurred in the past few years.
Aptana's Jaxer provides an innovative view, explain how to use the JavaScript runtime environment at both ends of the line (client and server). Very convenient communication between the client and the ability to easily share code and the server is running great advantage of JavaScript on the server.
Jaxer and Helma is an interesting project, to be sure (and many other items!). But I saw on the server JavaScript is not lack of interesting projects, but a useful ecosystem . People who work in Python like to talk about debris and whatnot Web frameworks, but compared with JavaScript debris, this is nothing.
For example, JavaScript needs to cross interpreter of the standard library . Thankfully, there are some standard library (inherited from the browser section). So you get regular expressions and date. However, files and directories it? Why not use the same API in Rhino, Spidermonkey, V8 and JSCore in?
A small number of standard interfaces . Connect to the database and run the query is a well-understood and common problems. In Rhino, you can use JDBC. However, JavaScript really should have their own cross interpreter standards, such as Python's DBAPI . It may also be employed in the initial deployment of Apache running behind Spidermonkey module webapp, then through a standard Web server / Web application interface which is placed behind the Jetty .
JavaScript is needed is a standard way to include other modules, and these modules can exist cautious namespace. There are very simple ways to do namespace, but there is no standard way of programming to load modules ( once! ). This is important, because the server-side application can contain a lot of code, and can be mixed and matched in line with some of these standard interfaces.
We need a way to package and distribute the code for deployment, and further installation package . Linux people will rightly point out that they can only enter "apt get" (or yum, or other), their work is done. But there are a lot of people use both Mac and Windows, need a convenient way to set up their development environment, and packaged the code they use to deploy and others written.
Part of the problem is the distribution and installation package repository . I do not know JSAN if there is an answer, but I know the installation package and its dependencies simple method for the number of people may be summarized library in their applications are very different.
Moreover, in addition to all these advantages, we will get a template engine, object-relational mapper, middleware, packaged applications and so on. Indeed, many of which already exist. However, the problem is they do not have a common basis. This is the reason for blocking the development of the ecosystem.
If you search for the Python Package Index WSGI (standard Python for Web applications and Web server connection), you will find 180 packages ... servers, middleware, a complete application today. And these are just included in its list of package "WSGI" of. This is the way ecosystems. There is a Java, Ruby has a, JavaScript need one.
It is noteworthy that, due to the use of a common standard library, many WSGI components can remain unchanged in CPython, Jython and IronPython. JavaScript has achieved a series in C and Java and .Net implementation, only certain interfaces such as some agreements. Running in all these places libraries can attract more users, and hope that more submitters to help develop the library.
I describe here is not a technical problem. This is a people together and decided to go ahead and start building bigger, colder question things.
To this end, I created a new ServerJS team , to let interested parties to communicate, and even allows us to make some code together face to face and solve some interface issues. There has been a lot of JavaScript code collection, let's see if we can make all the code more valuable.
In Mozilla's Web developer tools group, we have a wide open charter, can help software developers take full advantage of the open Web. Make every effort to help the community grow and server-side JavaScript flourish course can be part of it.
(Before someone says, "Why not just use Ruby / Python / Java / C #?", I just want to say that this is a totally different issue, I will not address this issue in this article.)
Update: The group is now called CommonJS .
---- => Article ending ----