In the beginning of 2006, Alex Iskold - after spending the last 10 years of his career programming in Java - took off his Java hat and started a Web 2.0 company called adaptiveblue. In this Web 2.0 Journal exclusive, he shares his insights on transitioning from Java into the Web 2.0 development world.

I spent the last 10 years of my career programming in Java. When I first discovered it in 1996, I was instantly enlightened. My life in the C++ box of ambiguities and strange side effects came to an end, and boy, was I relieved! Since then, I lived, breathed and thought exclusively in Java.

There are a few a lessons that Java taught me all that I think are really important. The first lesson is that even complex software can be written in a simple and elegant way. The second lesson is that software development is not just about language, it is also about the libraries. The third lesson was that software engineering, like architecture, is about patterns.

In the beginning of 2006 I took of my Java hat off and started a web 2.0 company called adaptiveblue. In a few weeks I brushed up on my JavaScript, learned PHP and XUL. At first, I found the lack of debugger and everything else that should be part of normal development environment, rather frustrating. But after about one month, I started to like this new world order. I realized that I can get things done really quickly. It felt like... well... It felt like hacking. I knew that it was time to stop and take a deep breath.

Do not hack, engineer!

I do not believe in hacking, I believe in software engineering. While getting things done quickly is rewarding you can not build any serious piece of software by just hacking it together. First you need to understand the problem at hand, then you need to come up with the solution strategy, pick tools, decide on the architecture and plan the execution. In a nutshell, you need to engineer the solution.

More importantly, a 1000 little hacks do not deliver the same value to the consumers as a single integrated, well thought through system. Its cool to see many little web applications that combine X and Y to make Z. But cool and useful are not the same thing. Modern web software needs to leverage burgeoning web services and facilitates intelligent, holistic, consistent end-to-end user experience.

New game, old rules

As a Java engineer coming to the web 2.0 world, you naturally ask: What do I need to do differently? Clearly there is a set of new technologies that needs to be understood and learned. But there are no fundamental differences in how we should approach the software engineering itself. Change in a programming language, tools and environment does not mean the change in patterns and practices of software engineering. While the fans of Python, Perl and PHP, each believe that their language is the best, these languages are basically equally powerful.

To write good software in any language you need to be familiar with tools and standards and you need follow a software development methodology. Good tools make you more productive, while standards help your solution play nice with the other software. But in the end of the day, it is up to you to understand and follow the basic modeling principles, ensure modularity in your system, continuously cleanup and refactor your code and ensure the quality by doing testing.

The beauty of Web 2.0 platform is in its flexibility and the ability to bring together wide range of applications, data and technologies. This beauty and flexibility, however, come with important cost – fragility. Because we are dealing with scripting languages, evolving API and frequent changes, the software that we make is fragile. This is why applying basic software engineering principles is absolutely essential.

Lets take a look at the Web 2.0 development landscape and see what is there to help us get organized. The development practices combined with industry offerings make up our toolbox. Knowing what we have, what we do not have and what to ask for is important for dealing with Web 2.0 dynamic development environment.

No IntelliJavaScript yet...

To start with, we have a problem, because there is no smart IDEA for JavaScript yet. The overall IDE market right now looks sparse. I am not aware of any widely adopted JavaScript IDE at this point. (Please post the IDE that you use in the feedback section of this article). I've seen JSEclipse mentioned a few times and looked at the demo on their we site. It looks promising, but I have not tried it yet.

In the mean time, I still code in IntelliJ, because it supports JavaScript syntax highlighting and does string-based variable/method name completion. But IntelliJ's JavaScript support is not even close to the support this great IDE provides for Java. The lack of a smart IDE is a big blow to our productivity, because JavaScript files can quickly grow long and messy, buggy and unmaintainable.

Refactor, refactor and, if in doubt, refactor again

The solution is to combat the mess and complexity with refactoring. Even if it means doing refactoring via string replace and manually moving pieces of JavaScript around, it is still better than not doing it. Continuously refactoring JavaScript code, making it modular and splitting the responsibilities is your ticket to a healthy system.

It is also necessary to capture core abstractions, separate them into different source files and think about the interfaces that glue them together. This does not mean coding the way we coded in Java. In fact creating classes in JavaScript is not essential. But just like we wrote modular code in C, we need to do the same thing in JavaScript. Unfortunately, lack of refactoring support makes all of these activities much more difficult and error-prone, but they can not be skipped.

Complement/Replace debugging with unit testing

Lack of good IDE also means that there are no good cross-browser debugger. Most Firefox developers use Venkman and for IE there is Microsoft Script Debugger. But often people resort to printf-like debugging, which in JavaScript takes a form of alert popups. This style of debugging can lead to a big waste of your time, since you have to click 'Ok' to close every popup.

Instead, you will be much better off using Unit Testing. Ever since I first encountered JUnit four years ago I am more and more convinced that unit testing is an absolutely essential software development activity. Instead of old-fashioned 'If it ain't broken don't fix it', the modern motto should be 'If it ain't tested it ain't working'. Particularly because software quality is what is going to help you gain validation and customer acceptance in the Web 2.0 world.

There are a few JavaScript unit testing frameworks that are out there. Two of them are called JSUnit because they were developed simultaneously. One can be found here: http://www.edwardh.com/jsunit and another one here: http://jsunit.berlios.de/index.html. Both are similar to JUnit. Another unit testing framework is part of the scrip.aculo.us library.. All of these frameworks allow you to run the tests inside an HTML page. Of course, it would be nice to have the unit testing integrated into the JavaScript IDE.

Use existing libraries, but handle with care...

Now for the good news. There are tons of JavaScript libraries and most of them come with wrappers for AJAX, date functions, animation and DOM manipulation. Unfortunately none of them are standard, so you have to do research and pick the ones you find more appealing. Here are the libraries that receive a lot of attention: prototype, script.aculo.us, rico and dojo. For a good list of libraries, please see this blog.

At adaptiveblue we have been using the library called MochiKit, developed by Bob Ippolito. So far we have no complains and no bugs to report. We choose MochiKit because of its comprehensive documentation and complete set of tests. Reading Bob's comments made us convinced that he really knows and understands JavaScript and that we can trust him and his code.

Trust is no small issue in this case. With Java, we are all safe because Sun is a responsible company that has made a huge commitment to the language, libraries and development community. But with JavaScript the situation is different. Since there are no standard libraries, we have to use the code developed by individual enthusiasts. This begs questions like: How long will this library stick around? Will the bugs be fixed on time? Will the features that I need be added in the next version? These questions are not easy to answer right now. We need to have standard libraries. And it matters less which code we adopt, as long as it becomes the standard.

Patterns

No software engineering discussion would be complete without patterns. Since the famous GoF book, we have been discovering and applying patterns in all of our projects. Patterns form the back bone of any modern software, they ensure correctness and validate the architecture. Web 2.0 environment applications are no exception.

For an excellent, comprehensive overview of the Ajax patterns please visit Ajax Patterns web site. In our daily development work on blueorganizer Firefox extension, we have found the two patterns particularly useful: Singleton and Naming or Interface pattern. Lets take a look at them in turn.

The Singleton pattern, is probably the most well-known pattern. In JavaScript the singleton guarantees that only one object of a particular type is instantiated. However, we typically use singleton for a different reason. We use it to mimic namespaces. The lack of the namespaces in JavaScript can lead to strange side effects, like someone else defining a function with the same name as your function. To minimize the likelihood of this, we define our utility classes as singletons and prefix them with adaptiveblue, accomplishing Java-like namespace behavior. You can find additional information about singleton, as well as example code here.

Since JavaScript is not quite an object-oriented language, there is no concept of an interface built in. This does not mean, however, that you can't code to an interface. Quite the opposite. The interface in JavaScript are simply naming conventions. This is exactly the same as the bean property accessors and modifiers in java beans or naming conventions in EJBs. Using naming conventions to define the interfaces is simple, yet powerful way to introduce OOP style into your JavaScript. For example, imagine a general DOM traversal, which applies the node visitor to every node. The node visitors are simply objects that all have visit( node ) function. Simple naming conventions can get you pretty far.

Conclusion

JavaScript and Java have little in common except for the first four letters. If you are transitioning from Java into Web 2.0 development world it is worth while to familiarize yourself with the tools, standards and vendor API. It is also worth while to map each activity from your Java development process onto the Web 2.0 development world. But once you master the language, the libraries and the tools, it is back to old software development methods. Think interfaces, decoupling, refactoring and testing and
you will be able to build robust AJAX applications.

Don't miss Alex Iskold's blog: http://alexiskold.wordpress.com