Hawaiʻi's Technology Community

With the advent of xhr, more and more large code bases are finding their way onto the browser.  Now days, you can find applications with a million lines of code running in the browser.  And, as browsers get compliant to HTML5 this trend will only continue, the future looks bright.  

If you are planning on developing in the large for the browser, one of the first decisions you need to make is whether you should embrace javascript or avoid it.  There are many solutions that allow you to avoid javascript's quirks, take advantage of the better tooling available for statically-typed languages, and keep you comfortable server and client side.  In fact, there is probably one for every development group, Google Web Toolkit (GWT) for eclipsians, CoffeeScript for the RoR crowd, TypeScript for Visual Studio, and Dart for those who believe the Dart VM can really happen.  There is no right answer, each situation has its own characteristics and the best choice will depend on the requirements of your application, your current skill set, existing code base language and environment, etc.

I enjoyed developing GWT apps for several years with seamless client/server debugging, powerful refactoring, and easy impact analysis, however, in my current project the layers of abstraction presented by these supersets are cumbersome.  If you need to access tools and libraries in javascript or you want to make your library easily accessible to other libraries and environments, you probably should commit to javascript.

Javascript is the ultimate first-class citizen, the common denominator in the browser.  Browser developer tools are now fantastic and simple save and reload development is enjoyable.  But how can you stay in control of the ambiguities that grow from a large javascript code base?

If you are not aware of the Google Closure Compiler, it aggressively minimizes and optimizes your code rendering it indecipherable.  It is able to do so based on the JsDoc annotations and consequently, you benefit greatly because the compiler will warn you about type mismatches, interface non conformance, etc.  If you don't comment your code much this may seem like a drag but knowing that your comments are "in effect" will ease your mind as your program grows in javascript.  Just like unit testing, there is a little cost for staying in control of your code.

The Closure Library (not the compiler) makes it easier to use the Closure Compiler.  However, if you are not using the Closure Library there are a few things you need to set up to get your environment nice and productive.  For example, you'll want to be able to develop directly from the source files for save and reload development.  You also will need to be able to debug the compiled version via source maps.  If you are interested in trying this type of development I built a kickstart project on github.  It only requires Node and comes with a simple example project to get you started.

I find it convenient for its simplicity. Just point it to your source files and keep using your favorite text editor.

Even using Closure Compiler is a good example of why you might want to avoid supersets.  Any of the supersets can benefit from the Closure Compiler, but can they use it?  Probably not, or with limited functionality.  Usually, you will have to wait for someone or some third party to make it possible, and yet another dependency and less flexibility.

Mahalo for reading!

Views: 168


You need to be a member of TechHui to add comments!

Join TechHui


web design, web development, localization

© 2021   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service