JavaScript Comes of Age
Yesterday I introduced patterns in JavaScript. While looking further into JavaScript I came across node.js. Node.js is a “Platform built on Chrome’s JavaScript RunTime”.
The thing that caught my attention about Node.js is the ability to write code that may run on the server or in the client browser in the same language. Now there are some real advantages to that. Microsoft has tried to get to that point with SilverLight, requiring the end user to have the SilverLight plug-in added to their machine. In the case of Node.js, there is no need to have anything new added to a modern browser.
This ties in really nicely with David Ellis’ response to yesterdays editorial. David submits detailed comments frequently, and has agreed to have me attribute more information about him because I appreciate so much his well thought out responses. You can find out more about David at http://careers.stackoverflow.com/dfellis or send email to d.f.ellis@ieee.org.
David writes:
Javascript’s stopped playing on Geocities pages and has grown up in the past 10 years. 😉
And it seems many never noticed it.
First, as a language, Javascript is like a cross between Scheme and Smalltalk, and dressed up to look like Java, but since it was limited to only work on the page it was loaded into (no I/O, no graphics, nothing) it was seen as a toy language for making pointless animations on peoples’ Geocities pages.
Then, Microsoft gave Javascript the ability to contact web servers and go beyond the page playpen with XMLHttpRequest (AJAX), so web sites could start behaving more similarly to desktop productivity apps.
Mozilla had long experimented with embeddable Javascript engines for other applications (SpiderMonkey for C-based apps and Rhino for Java apps) to provide user scripting for "real work."
Google determined how to make Javascript *fast* by noting that no one really uses the abstract mutability of Prototypical Inheritance, and translates such "safe" code into C++ classes and then compiles it for near-native performance.
Douglas Crockford realized that Javascript’s object notation would be a better fit for what XML was generally used for (object serialization) and extracted a subset to produce JSON, which is entirely unambiguous (unlike XML) if somewhat restricted (Javascript’s looser-than-usual types).
Joyent and 10gen saw the power of Javascript for non-browser usage and created Node.js and MongoDB, a scripting environment a la Python and a document database, on top of it. Now Javascript is capable of doing just about anything you could do with any other language. Some personal examples: A command-line data processing utility https://github.com/dfellis/nuvpl-node , An experimental networking protocol and RPC layer https://github.com/dfellis/node-udp-rpc , client and server language localization https://github.com/AGROSICA/node-localize
The GNOME project decided a few years ago to use Javascript to power the GNOME 3 user interface, and shortly afterwards Microsoft added Javascript and HTML5 as a supported environment for Metro apps in Windows 8, both producing introspective APIs for Javascript to give the language deep access to the underlying operating system (like Node.js, but from a different angle more focused on Javascript’s GUI roots).
Is Javascript the "best" solution? That depends on what you think of as "best". Of course C/C++ are the best choices for truly high performance software: http://blog.j15r.com/2011/12/for-those-unfamiliar-with-it-box2d-is.html
But, in many cases, when you don’t create and destroy lots of objects (you don’t stress the garbage collector, that is), Javascript ranks up with C/C++ and Java in performance: https://github.com/andreyvit/naive-language-benchmarkhttp://raid6.com.au/~onlyjob/posts/arena/https://github.com/gflarity/peg-performance
From that perspective, and from the upswelling of support for Javascript as a server language, database language, desktop application language, as well as the language of the browser, and just how much **less** boilerplate code you have to write for Javascript versus Java, it may very well be that the "best" choice is to make Javascript and C++ the two "main" languages in your utility belt — C++ for performance-critical code and "final" versions of software, and Javascript for quick one-off applications, prototyping, and non-performance critical GUI code.
And remember, the WebGL push is putting significant pressure on the one area of Javascript that’s still outside of its domain — high performance code. And the solutions the ECMAScript Working Group are producing, a solid module system and a stricter type system, should feel much more comfortable for C++ devs.
Finally, Oracle declaring war on the entire world of software by claiming a copyright on any code that *uses* the Java APIs means that I truly do believe there is a perfect storm, from the corporate world with Microsoft Windows 8, from the open source community on the server with Node.js and MongoDB, from the web browser community from Google, Microsoft, Mozilla, and Apple, and from Oracle shooting itself in the foot to eradicate Java from all but legacy applications, and then Javascript, .NET, C++, and some smatterings to Python, Ruby, Go, and Rust will divide most of the Java marketshare amongst themselves (in roughly that order).
Thanks once again, David, for sharing your thoughts in this regard. If you would like to contribute to the conversation please send your response to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
SharePoint 2010 Enables the Enterprise
Written by KnowledgeLake
read more)
Featured Script
dba3_Add_Drop_IdentityColumnToTable_Demo
Demo: Adding / Dropping an Identity Column to an existing table by using the Alter Table Statement… (read more)