This article is not about cursing this multifaceted language. We will simply explore some of the possibilities concerning it. These days, the developer community has expanded JavaScript's reach. Once solely a client-side language, JavaScript is now welcomed on the server-side, too. Its frameworks are available today in various flavors to meet different use cases. JavaScript is all set to rock in the arena of next-generation enterprise applications.
Under the “javascript everywhere” banner, the JavaScript-based enterprise application development framework needs lots of maturity to withstand community demand. In this article, we will further discuss the ongoing standardization of JavaScript frameworks backed with architectural pattern implementation. Also, we will look in depth on dependency management and JavaScript loading solutions. Today's community is seriously looking at test-driven development & design. Let's begin.
Pattern Oriented JavaScript Framework
Rebecca Murphy’s article on ‘jQquery & Large Application’ is an excellent write up that discusses problems associated with jQuery when adapted for enterprise-level applications. By the way, it is not just limited to jQuery, but it is a common problem with most of the JavaScript frameworks available today. JavaScript frameworks which were meant for an older web now no longer can with stand with the requirements of next generation web application. With more powerful browsers, today’s web applications rely intensively on client side and thereby a big piece of code is now migrated to javascript. Today’s applications are now responsible for managing user interaction, state management, data management, web flow and templating all at client side. With such complexities and no framework support, managing piles of javascript would have been a nightmare for a developer.
Today’s javascript frameworks are now backed by architectural patterns which were only known for server side components. Community is striving to build frameworks with which the enterprise application code is more organized and manageable. Frameworks are now developed on top of MV* (MVC, MVP, MVVM) architecture patterns. We today have literature which details on implementing core[1] & enterprise level patterns[2] for javascripts.
Below is comparison matrix which details different pattern available with MV* based JavaScript frameworks.
|
Framework
|
UI Bindings
|
Composed Views
|
Web Presentation Layer
|
Integration with others
|
|
Backbone.js
|
No
|
No
|
Yes
|
Yes
|
|
SproutCore 1.x
|
Yes
|
Yes
|
No
|
No
|
|
Sammy.js
|
No
|
No
|
Yes
|
Yes
|
|
Spine.js
|
No
|
No
|
Yes
|
Yes
|
|
Cappuccino
|
Yes
|
Yes
|
No
|
No
|
|
Knockout.js
|
Yes
|
No
|
Yes
|
Yes
|
|
Javascript MVC
|
No
|
Yes
|
Yes
|
Yes
|
|
GWT
|
No
|
Yes
|
No
|
No
|
|
Google Closure
|
No
|
Yes
|
Yes
|
No
|
|
Ember.js
|
Yes
|
Yes
|
Yes
|
Yes
|
|
Angular.js
|
Yes
|
No
|
Yes
|
Yes
|
|
Batman.js
|
Yes
|
No
|
Yes
|
Yes
|
Note: Credits to Gordon L. Hempton
for his research.
Dependency Management & JavaScript Loading
While writing enterprise-grade web applications, we end up writing complex code. With time, as application size expands, our problem gets worse. With complexity,assembling the code becomes more difficult and thereby developers start writing modular code for understandability and ease of maintenance. The code is broken down into modules that reside under discrete JS files. This may lead to deployment challenges, wherein we wish to minimize HTTP calls for latency optimization.
Today, the JavaScript community is aware of the solution of the above problem. Certain frameworks are meant to solve the above problems. Objectives of these tools provide dynamic loading of JavaScript, using a type of include/import/requires syntax common in today's programming languages. Also, these tools aim to resolve nested dependencies between scripts. Of course all these features shall not sacrifice deployment, and hence are backed by optimization tools that help in deployment.
The below table compares capabilities of such available frameworks:
|
Framework
|
Priority based loading
|
Callback support on loading events
|
Restrict duplicate JS execution
|
Dependency management
|
Web worker support
|
Cross domain scripts
|
|
LabJS
|
No
|
Yes
|
Yes
|
Yes
|
-
|
Yes
|
|
HeadJS
|
No
|
Yes
|
Yes
|
Yes
|
-
|
Yes
|
|
RequireJS
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
|
YepNope
|
No
|
Yes
|
Yes
|
Yes
|
-
|
Yes
|
|
BootStrap
|
No
|
Yes
|
-
|
Yes
|
-
|
Yes
|
JavaScript Testing
An evolutionary approach to development is TDD, Test-driven development. TDD uses test-first development to write a test before producing code to fulfill that test and refactoring. With more and more features coming on javascript's plate, it becomes a must to evolve javascript unit testing tools. Christian Johanson has documented the whys and hows in his book.
Another challenge web applications face is supporting web browsers with different versions. This challenge is inherited from a lack of testing the javascript code living in the presentation tier. Failing to unit test this code causes organizations to pay for repeated tests of web applications after upgrading or supporting new browsers.
The community has also designed specifications for standardizing the javascript unit testing tools.
Below are the different javascript test frameworks available:
|
Test Framework
|
Description
|
|
JSTestDriver
|
JsTestDriver aims to help javascript developers use ‘test-driven design’ practices and aims to make writing unit tests as easy as what exists today for Java with JUnit.
|
|
QUnit
|
QUnit is a powerful, easy-to-use JavaScript unit test suite. It’s used by the jQuery, jQuery UI, and the jQuery Mobile projects. It is is capable of testing any generic JavaScript code.
|
|
BusterJS
|
Buster.JS is a JavaScript test framework for nodes and browsers.
|
|
TestSwarm
|
TestSwarm provides distributed and continuous integration testing for JavaScript.
|
|
JSUnit
|
|
|
RhinoUnit
|
|
|
FuncUnit
|
For automated and functional testing.
|
Client-side Templating
Template engines have always been server-side technologies. Migration to the client side is relatively new. A shift is definitely occurring. Logic is moving away from the server side and going to the client side. And more and more frameworks are gaining traction as this trend continues, helping us craft more maintainable code. The basic idea behind client-side templating is this: Offload the server by rendering the template.
Below is a comparison matrix produced by Veena Basavaraj, which compares different templating javascript frameworks.
“The UTurn” – Server side JavaScript (SSJS)
An established pattern of web development is to use a programming language for interactivity in the browser (via JavaScript) and another for server-side request processing (via PHP, JSP, ASP, Java, Python, Ruby). However, we're now seeing the rise of JavaScript as a sort of universal web language encompassing the server side too. JavaScript is a “complete” language—one can use it in many contexts and achieve everything that any other language can. With SSJS, one can run JavaScript code in the backend, outside a browser, thus being able to support HTTP processing while also acting as a server-side language as well.
The idea behind the SSJS is using high-performance javascript engines designed for different web browsers. E.g., NodeJS sits on top of V8, Google’s VM for javascript processing. SSJS has been evolving as a general purpose programming platform, but its core strength and expertise lies in networking correctly. This can be viewed as javascript bundled in a console with a set of APIs on top of it. These APIs are not just limited to normal programming but extend to assist programming web servers.
Server-side javascript is oftentimes designed to take care of an event-driven model. In a typical web server, every client request spawns off a new thread. So the server spawns large numbers of threads for requests, even if some threads are just sitting at idle waiting to complete a task. With event-driven programming, one can register events. And once the results return from the database, event calls are made. So idle time is less, and thread footprint is minimal. By the way, this isn't an alternative to asynchronous programming, which has its own advantages.
Below is the list of different server-side javascript frameworks.
|
Framework
|
JavaScript Engine
|
Server Type
|
Description
|
|
CouchDB
|
SpiderMonkey
|
HTTP
|
JavaScript in CouchDB is used to write map/reduce queries. It's also used for document validation & update handling.
|
|
Google Apps Script
|
Rhino
|
Cloud (PAAS)
GAE
|
Google Apps Script is a JavaScript cloud-scripting language that provides easy ways to automate tasks across Google products and third-party services.
|
|
NodeJS
|
Chrome V8
|
Standalone
|
A platform built on Chrome's JavaScript runtime environment for fast, easy building of scalable network applications. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient—perfect for data-intensive real-time applications running across distributed devices.
|
|
Wakanda
|
SquirrelFish
|
HTTP
|
Wakanda Server’s ease of use and high performance are all tied to its implementation of JavaScript (based on WebKit’s Squirrelfish Extreme just-in-time compiler) and the datastore class paradigm. In addition to accessing data from HTML5 widgets on the front end, all of the server's data and logic are available directly to you via JavaScript, using standards-based APIs.
|
Conclusion
‘JavaScript Everywhere’ has put on a new thinking cap; applications are now designed to keep its principle in mind. With SSJS platforms built over JavaScript's runtime environment, easily built, scalable, network-based applications are possible. It uses an event-driven, non-blocking I/O model that makes the server lightweight and efficient, and perfect for data-intensive, real-time applications running across distributed devices. Today many enterprises like LinkedIn, Ebay, and Yahoo rely on such frameworks.
Today, NoSQL databases are a game-changer on the back-end, bringing a new paradigm to web development. When we put them with the new architecture, we have a well-integrated engine all the way down. Suddenly, Javascript becomes a mainstream language and can be used for both front- and back-end. The entire stack speaks one language and integrates like a charm.
References
http://bitovi.com/blog/2010/08/why-jquery-needs-javascriptmvc.html
http://rmurphey.com/blog/2010/08/09/on-jquery-large-applications/
http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/
http://addyosmani.com/resources/essentialjsdesignpatterns/book/
http://addyosmani.com/largescalejavascript/
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
http://stackoverflow.com/questions/300855/looking-for-a-better-javascript-unit-test-tool
http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more
http://www.nodebeginner.org/#javascript-and-nodejs
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}