Javascript, Javascript, Everywhere

Abhishek Jain

Aug. 09, 12 · Interview

Like (2)

Save

11.04K Views

Javascript has been available in the web world for a while. It has become one of the most popular, known and understood (and also hated) languages available. We can find many reasons as to why some people hate JavaScript, and many literatures about its turning to a vamp. Others, however, see its goodness.

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 http://code.google.com/p/js-test-driver/	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 http://qunitjs.com/	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 http://busterjs.org	Buster.JS is a JavaScript test framework for nodes and browsers.
TestSwarm https://github.com/jquery/testswarm/wiki	TestSwarm provides distributed and continuous integration testing for JavaScript.
JSUnit
RhinoUnit
FuncUnit http://funcunit.com/	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.

With adaption to best practices and patterns in client-side frameworks, managing code is no longer a nightmare. Javascript dependencies can be easily managed and optimally loaded more efficiently and quickly in the browser. The data-interchange format, of course, is none other than JSON, which fits into this architecture.

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

JavaScript framework unit test mobile app Web Service Database Google Apps Script

Published at DZone with permission of Abhishek Jain, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Comments