The Maturing of JavaScript

Last week was the third Texas JavaScript conference, and, by good fortune, the third year I have attended it. Although nominally a Texas conference, it actually attracts attendees and speakers from around the country, and even from around the word.

The topics at the conference have tracked closely with the evolution of JavaScript as a first-class programming language. The past two years had several talks around server-side JavaScript, in the form of NodeJS. This year, there wasn’t a single talk about NodeJS. This isn’t because server-side JavaScript is dying, it is because server-side JavaScript is accepted as a given in the JavaScript community and is being used with great success as an alternative to heavier stacks.

The selection of topics reflected the maturing state of JavaScript. In any modern web application, there is no longer a question of “if” you should use JavaScript. The question is now “how much” you are going to use it. Even in the simplest projects, JQuery is frequently used for simple Ajax calls or client-side data validation. On the other end of the spectrum are complicated single-page interface applications, like the Twitter and Facebook home pages, built with rich client-side MVC framework like Backbone or ExtJS.

The growing pains the JavaScript community is dealing with are very similar to what other technologies experienced at similar points in their evolution. The efforts now are around how to structure and test large JavaScript codebases, as well as improving productivity through improved tooling.

As the size of the JavaScript used in a project increases, it becomes extremely easy to end up with a disorganized mess of individual JavaScript files, each polluting the global namespace with variables and making it difficult to track down bugs. The two dominate JavaScript paradigms for designing modular code are CommonJS, as implemented by NodeJS, and Asynchronous Module Definition (AMD) as implemented by the RequireJS library.

Both provide consistent APIs on how JavaScript code can be turned in to modules, and how those modules are to be loaded as dependencies by other modules. CommonJS and AMD can even be used on the same project. CommonJS would be used to handle the server-side code in a NodeJS application, while AMD/RequireJS is used on the client-side to load modules in the browser.

On the developer productivity side, the development stack for a JavaScript developer has become much more sophisticated than simply pounding out text files in Vim. Rebecca Murphey’s excellent blog post (A Baseline for Front-End Developers) shows the extent of sophistication now being applied to JavaScript-centric software development.

JavaScript is rapidly maturing, and is finding itself at a similar stage as Ruby on Rails a few years back. As the lingua franca of the web, there is significant developer expertise, but the emphasis of the community is on putting in to place the practices and tools to not only build sophisticated solutions, but to also make them maintainable. This conference was a great showing of the steps being taken in those areas.

• Javascript
• Txjs