For all its warts and headaches, JavaScript has emerged as the lingua franca of the modern Web, arguably second in adoption only to HTML itself, which obviously is just a markup standard rather than a full-fledged programming language. It's effectively impossible to launch a sophisticated Web project without making extensive use of JavaScript and AJAX dynamic loading. That's precisely why recent projects that move JavaScript beyond its usual boring domain of defining in-browser interactivity are so interesting—because it's already dominant, and growing even more so. Consider MongoDB, for example, which relies on BSON, or "Binary JSON," which uses a faster encoding of JSON-like structured documents to store serialized data arrays and has emerged as the leader among NoSQL databases (which eschew complex query logic in favor of large documents, in which traversing and processing the tree is easy and efficient). As such, BSON is machine-friendly to the point that it becomes hard for humans to read—much harder than JSON, for sure—but the specific syntax is still derived from JavaScript's representation of arrays and objects. In a way, it's not unreasonable to think of this as a route by which JavaScript is moving into databases. There are already Mongo interface packages for more or less every sufficiently evolved programming environment, but the information retrieved by a database transaction already has a document structure compatible with native processing in JavaScript, even if character encoding is a little too obtuse for the time being. Ultimately, the specific methods used for compression and decompression of arrays into strings and back again is not terribly interesting to programmers working a few layers of abstraction away, since, in any well-designed platform, it will probably be available as a quick native function and accordingly transparent to the developers. This brings us to Node.js, the increasingly popular software package that enables server-side scripting but uses JavaScript as its language of choice. To put it another way, it arranges small API wrappers around popular C and C++ packages and then makes the wholly sensible decision to use JavaScript as the language for defining the interactions between them, rather than inventing something proprietary. Server logic is thus event-driven, asynchronous, and accordingly resource-efficient, which is one of the major reasons why it is being widely used by companies ranging from Microsoft and LinkedIn to Uber and Rdio, and at this point has more GitHub followers than Ruby On Rails. It also, for the first time, allows for the use of JavaScript at every stage of the development process. This is significant for a number of reasons, not the least of which is that JavaScript is effectively the only programming language that can be used in the Web browser, and is thus, for the foreseeable future, the only one that will be able to provide full-stack cohesion. Until all the major browser vendors agree to release compatible in-browser interpreters for Python or another client-side language, this territory is Node's for the taking. Server-side languages are often thought of as pathways to sophisticated HTML logic, but many seasoned developers have probably rendered JavaScript variables or even entire functions on the server side as a way of quickly passing mundane information from the server side to the client side, using the print statement to write a script tag or CSS instructions. Ultimately Node still leaves room for this sort of tricky thinking, because it doesn't actually provide a bridge between the two sides. But when server-side JavaScript is rendering client-side JavaScript, the language is at least coherent and this practice becomes a lot more cohesive, if still only arguably sensible depending on the sensitivity of the information and the scope of the project. This probably means fewer misplaced semicolons (this could even be automatically error-corrected using regular expressions) and certainly means you won't find yourself trying to run a built-in function from one language inside a script or module powered by another. But possibly the most fascinating part about this is that Node.js doesn't rely on common Web servers such as Apache or nginx (though it can be configured to work with them). Both those server packages, as sophisticated as they are, still fall short of being or supporting complete scripting languages, and even their biggest tricks can't hold a candle to the overall maturity of JavaScript. In a fully Node-driven project, though, the first step is often to boot a server through the use of the 'http' module. The function structure used to launch this allows for extremely complex logic extremely close to the server metal, and yet will be familiar to anybody who has worked in JavaScript, even via front-end user interfaces. In other words, Node dramatically reduces the distance between server admins and UX designers, two camps that often stay as far apart from one another as possible. This has dramatic implications for the development process on any given project. With a common language, developers at all stages of the project can share terminology, and in some cases even entire function sets—for example, a small JavaScript library for performing various kinds of string processing related to the different sections of a site would be useful to both jQuery and Node, and, depending on the specifics, might run unmodified in both contexts. Variable names and coding conventions can be normalized, making it easier for developers on opposite sides of the HTTP request to communicate and discuss features and bug reports. It's also a big deal for education. Developers are fragmented into incompatible disciplines, and you won't often see a skilled Ruby programmer working on advanced interaction design. But once the languages are unified, it's much easier to excel in both contexts; neither students nor educators have to fragment time and resources across separate platforms. Server-side use finally solves the primary security problem that has followed JavaScript for years. A language that's deployed on the client side can never effectively restrict user access to the code, which means that, in cases where a private API key is needed to access information, it's impossible to give users the content without also giving them the key. This simple fact has largely defined the shape of AJAX development, which depends on server-side preprocessing for anything secure, usually in another language. With Node, JavaScript developers have a widely supported path to security for the first time. And if you zoom out, language coherence across the stack could have a huge effect on the general pace of technology, since any further improvements can help in multiple arenas. For example, both Node and Chrome run on Google's V8 JavaScript engine, which compiles JavaScript into machine code. It's already shockingly efficient, and widely considered the impetus for the JavaScript optimization wars that kicked off with the initial release of Chrome way back in 2008. This means that if Google finds a way to make V8 even more efficient, speed of execution increases once on the server and then again in the browser. One can thus reasonably hope for a surge of interest in and support for JavaScript-focused projects which are useful in multiple senses. In most contexts, competition breeds efficiency, and its absence sometimes leads to stagnancy. But in the case of Web development, this sort of vertical integration is a strength to be celebrated. In a practical sense, there is no widely-supported competitor to JavaScript as far as designing front-end interactivity is concerned. If anything, Node competes only with other server-side scripting languages such as Python, Ruby, and PHP. With JavaScript now moving onto the server, competition among languages actually increases, even though developers on Node-based projects can count on full-stack languages. In the grand scheme, Node and Mongo are still quite new; for the most part, ace JavaScript developers who can write brilliant code on both sides of the request transaction have yet to emerge. But if and when they do, the things they build could be jaw-dropping. Image: Odua Images/Shutterstock.com Node.js and MongoDB Turn JavaScript into a Full-Stack Language
For all its warts and headaches, JavaScript has emerged as the lingua franca of the modern Web, arguably second in adoption only to HTML itself, which obviously is just a markup standard rather than a full-fledged programming language. It's effectively impossible to launch a sophisticated Web project without making extensive use of JavaScript and AJAX dynamic loading. That's precisely why recent projects that move JavaScript beyond its usual boring domain of defining in-browser interactivity are so interesting—because it's already dominant, and growing even more so. Consider MongoDB, for example, which relies on BSON, or "Binary JSON," which uses a faster encoding of JSON-like structured documents to store serialized data arrays and has emerged as the leader among NoSQL databases (which eschew complex query logic in favor of large documents, in which traversing and processing the tree is easy and efficient). As such, BSON is machine-friendly to the point that it becomes hard for humans to read—much harder than JSON, for sure—but the specific syntax is still derived from JavaScript's representation of arrays and objects. In a way, it's not unreasonable to think of this as a route by which JavaScript is moving into databases. There are already Mongo interface packages for more or less every sufficiently evolved programming environment, but the information retrieved by a database transaction already has a document structure compatible with native processing in JavaScript, even if character encoding is a little too obtuse for the time being. Ultimately, the specific methods used for compression and decompression of arrays into strings and back again is not terribly interesting to programmers working a few layers of abstraction away, since, in any well-designed platform, it will probably be available as a quick native function and accordingly transparent to the developers. This brings us to Node.js, the increasingly popular software package that enables server-side scripting but uses JavaScript as its language of choice. To put it another way, it arranges small API wrappers around popular C and C++ packages and then makes the wholly sensible decision to use JavaScript as the language for defining the interactions between them, rather than inventing something proprietary. Server logic is thus event-driven, asynchronous, and accordingly resource-efficient, which is one of the major reasons why it is being widely used by companies ranging from Microsoft and LinkedIn to Uber and Rdio, and at this point has more GitHub followers than Ruby On Rails. It also, for the first time, allows for the use of JavaScript at every stage of the development process. This is significant for a number of reasons, not the least of which is that JavaScript is effectively the only programming language that can be used in the Web browser, and is thus, for the foreseeable future, the only one that will be able to provide full-stack cohesion. Until all the major browser vendors agree to release compatible in-browser interpreters for Python or another client-side language, this territory is Node's for the taking. Server-side languages are often thought of as pathways to sophisticated HTML logic, but many seasoned developers have probably rendered JavaScript variables or even entire functions on the server side as a way of quickly passing mundane information from the server side to the client side, using the print statement to write a script tag or CSS instructions. Ultimately Node still leaves room for this sort of tricky thinking, because it doesn't actually provide a bridge between the two sides. But when server-side JavaScript is rendering client-side JavaScript, the language is at least coherent and this practice becomes a lot more cohesive, if still only arguably sensible depending on the sensitivity of the information and the scope of the project. This probably means fewer misplaced semicolons (this could even be automatically error-corrected using regular expressions) and certainly means you won't find yourself trying to run a built-in function from one language inside a script or module powered by another. But possibly the most fascinating part about this is that Node.js doesn't rely on common Web servers such as Apache or nginx (though it can be configured to work with them). Both those server packages, as sophisticated as they are, still fall short of being or supporting complete scripting languages, and even their biggest tricks can't hold a candle to the overall maturity of JavaScript. In a fully Node-driven project, though, the first step is often to boot a server through the use of the 'http' module. The function structure used to launch this allows for extremely complex logic extremely close to the server metal, and yet will be familiar to anybody who has worked in JavaScript, even via front-end user interfaces. In other words, Node dramatically reduces the distance between server admins and UX designers, two camps that often stay as far apart from one another as possible. This has dramatic implications for the development process on any given project. With a common language, developers at all stages of the project can share terminology, and in some cases even entire function sets—for example, a small JavaScript library for performing various kinds of string processing related to the different sections of a site would be useful to both jQuery and Node, and, depending on the specifics, might run unmodified in both contexts. Variable names and coding conventions can be normalized, making it easier for developers on opposite sides of the HTTP request to communicate and discuss features and bug reports. It's also a big deal for education. Developers are fragmented into incompatible disciplines, and you won't often see a skilled Ruby programmer working on advanced interaction design. But once the languages are unified, it's much easier to excel in both contexts; neither students nor educators have to fragment time and resources across separate platforms. Server-side use finally solves the primary security problem that has followed JavaScript for years. A language that's deployed on the client side can never effectively restrict user access to the code, which means that, in cases where a private API key is needed to access information, it's impossible to give users the content without also giving them the key. This simple fact has largely defined the shape of AJAX development, which depends on server-side preprocessing for anything secure, usually in another language. With Node, JavaScript developers have a widely supported path to security for the first time. And if you zoom out, language coherence across the stack could have a huge effect on the general pace of technology, since any further improvements can help in multiple arenas. For example, both Node and Chrome run on Google's V8 JavaScript engine, which compiles JavaScript into machine code. It's already shockingly efficient, and widely considered the impetus for the JavaScript optimization wars that kicked off with the initial release of Chrome way back in 2008. This means that if Google finds a way to make V8 even more efficient, speed of execution increases once on the server and then again in the browser. One can thus reasonably hope for a surge of interest in and support for JavaScript-focused projects which are useful in multiple senses. In most contexts, competition breeds efficiency, and its absence sometimes leads to stagnancy. But in the case of Web development, this sort of vertical integration is a strength to be celebrated. In a practical sense, there is no widely-supported competitor to JavaScript as far as designing front-end interactivity is concerned. If anything, Node competes only with other server-side scripting languages such as Python, Ruby, and PHP. With JavaScript now moving onto the server, competition among languages actually increases, even though developers on Node-based projects can count on full-stack languages. In the grand scheme, Node and Mongo are still quite new; for the most part, ace JavaScript developers who can write brilliant code on both sides of the request transaction have yet to emerge. But if and when they do, the things they build could be jaw-dropping. Image: Odua Images/Shutterstock.com 
