Dependency Management & JavaScript Loading

While writing enterprise grade web applications, we land up writing complex code and with time, as application size expands our problem gets worse. With complexity it becomes harder to assemble the code and thereby developer tends to write modular code for understandability and ease of maintenance. And hence the code is broken down into modules which reside under discrete JS files. This may lead to deployment challenges, wherein we wish to minimize HTTP calls for latency optimization.
Today JavaScript community is aware and active for the solution of above problem. There are frameworks which are built to get the above problems solved. Objectives of these tools are to provide dynamic loading of JavaScripts using sort of include/import/requires syntax which are common in today programming language. Also these tools targets resolving nested dependencies between scripts. Of course all these features shall not sacrifice deployment and hence are backed by optimization tools which help in deployment.
Below matrix compares capabilities of such available frameworks:

JavaScript Testing

An evolutionary approach to development is TDD, Test-driven development which combines test-first development where one write a test before one writes production code to fulfill that test and refactoring. With more and more features coming in javascript plate, it becomes a must to evolve javascript unit testing tools. Cristian Johanson has documented it all on whys and hows around this topic in his book.
Another challenges faced by web applications is the support of web browsers with different versions. This challenge is inherited from the lack of testing the javascript code living in the presentation tier. Without unit testing this code, organizations may pay for repeated testing of web applications after upgrading or supporting new browsers.
Community has also designed specifications for standardizing the javascript unit testing tools.
Below are the different javascript test frameworks available:

Client-side Templating

Template engines is always been a server-side technology and migration of this to client side is relative new. There is definitely a shift going on where logic is moved away from the server to the client side, more and more frameworks are gaining traction as this trend goes on, helping us in crafting maintainable code. The basic idea behind client side templating is to offload the server from rendering the template.
Below is a comparison matrix produced by Veena Basavaraj which compares different templating javascript framework.

“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 what can be achieved with any other language. With SSJS one can run JavaScript code in the backend, outside a browser, and thus can support HTTP processing and hence can act as server side language as well.
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 doing networking correctly. This can be viewed as javascript bundled in console with set of APIs on top of it. These APIs provided are not just limited to normal programming but extend to assist programming web servers.
Serverside javascript typically designed to take care of event driven model. In a typical webserver, every client request spawns off a new thread. So server spawns large number of threads for requests, even if some threads are just sitting idle waiting for some task to complete. 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 shall not be considered as an alternative to asynchronous programming, which has its own advantages.
Below is the list of different server side javascript frameworks.

Conclusion

With adaption of best practices and patterns in client side frameworks, managing code is now no more a nightmare. Javascript dependencies can be easily managed and optimally loaded in the browser more efficiently and quickly. Data interchange format of course is none other than JSON which fits in this architecture.
Today, NoSQL databases are a game-changer on the back-end and it brings a new paradigm to web development. When we put them with the new architecture, we have a well-integrated engine all the way down. All of a sudden, 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