Developing JavaScript client using, well, JavaScript

So, we are using JavaScript to develop a JavaScript client. What do you think about that? We are not using GWT, RichFaces or any other tech that could free us from writing JavaScript. We decided to get our hands dirty and to write JavaScript ourselves.

It is well known fact that number of people who don’t like working with JavaScript is not small. It looks like there is an aura of fear around that language and it scares a lot of people. It shouldn’t be like that. People shouldn’t be afraid. JavaScript was a pain in the neck in tha past, that’s true, but browsers of today are much better in dealing with it. And they are doing it in more uniformly than before. JavaScript community produced a number of libraries and frameworks that can help a lot: jQuery, Dojo, prototypejs, just to name a few…

But, nevertheless, people still tend to avoid JavaScript as much as they can and go completely other way around by using, for example, Java frameworks to produce JavaScript as final product. My personal opinion is that if you think the tool is just the thing your project needs and want to take advantage of it, you should use it. It sounds somehow strange not to use it, but to use a tool that uses a tool that compiles your code into code that you wanted to write in the first place.

Of course, you can say you don’t agree with me and that you still want to use your “workaround” tool. It’s ok, but you should think about getting deeper knowledge of JavaScript anyway. A developer will be able to create great JavaScript client app only if he/she really understands what is going on beneath the surface. I’ve seen situations when people got carried away and start thinking they are in Java environment while writing GWT client code. It happened to me, too.

Our development team has chosen Google Closure library as underlying framework of our JavaScript client. Guys at Google use it for number of their products: Gmail, Maps, Docs, Calendar, Photos…

Besides it is proven to be capable of doing great things (Google Apps) it was great help to us too. It provided us with large number of widgets, cross browser support (including mobile devices) and dedicated tools such as Closure Compiler and templating engine.

But, it’s not the framework who writes great JavaScript apps. It’s the people. People who know where the traps are and care about doing it properly.

JavaScript is hard to maintain. That’s the biggest problem with it. Fortunately, there are some things you can do to increase maintainability of any JavaScipt application.

• Write object-oriented JavaScript

Take advantage of OO design and pair it with the power of this scripting language. Application shouldn’t be just a set of scripts that run as they are loaded into browser.

• Adopt Java style

There is no need to prove your skills by writting a bunch of hacks and nonunderstandable code. Use good library as help in overcomming cross browser and other issues and write JavaScript to look like Java – at the end it will end up shrinked and obfuscated anyway.

Library such as jQuery could be a good example – it is very, very powerful but looking at code that uses it feels like looking in some other language, not JavaScript.

• Design in detail

Design your client app with clean separation of concerns between modules and classes. Design it to be multi tier application. It is more complicated to do, but it will help maintainability and boost understandability.

• Use packages and namespaces as source organization

Having classes organized in packages (directories) makes it is much easier to find what you need than to have one big file or a number of files representing parts of JavaScript logic. Also, while using package structure, it would be even better to add namespace organization to your code. For example, if you have a class named UberCustomer placed in de/codecentric/greatjsapp/view/model/, its full name should be de.codecentric.greatjsapp.view.model.UberCustomer. Closure library comes really handy here providing full namespace support with its goog.provide and goog.require functions.

• Use “One class, one file” rule

This is the easiest way to organize your code. You will have a bunch of files, that’s true, but you will know exactly what every file contains and what every class does (with assumption you were giving classes logical names). Adding to the UberCustomer example from the above, file containing the class should be called UberCustomer.js. I bet this sounds familiar.

• Separate component communication by using event bus

Don’t let you code become tangled cause every class can directly call any other class’s functions. Make different parts of the app communicate with each other using messages, i.e. events. Ones should fire those messages, others should listen. Just like in real communication – if everybody talk at the same time, nothing can be heard.

• Don’t use too many JavaScript frameworks

Some of the libraries are using same qualifiers for different things. Having in mind global scope of JavaScript, one can have an idea how many things can go wrong. Furthermore, every JavaScript library has its own philosophy and those can be quite different comparing to each other. Parts of the code (using library A) could look and feel completely different from part of code using library B. By using one library, development team has more chances to stay uniform across the whole app which is extremely important. So, choose your framework wisely.

• Document, document, document

Write JavaScript documentation for every variable, function and class. You are already documenting you Java code with JavaDoc, why not doing so with JavaScript? And it will help you a lot.

If infrastructure exists, create project wiki pages – this will help your team in discussing problems and solutions. When solution is implemented, write an article about how it’s done – great help when tring to remember what was done or when new team member is getting introduces to the project.

• Automate build process

The usability of this advice will vary depending on which JavaScript framework you choose. Somewhere it makes sense, somewhere it doesn’t. Using Google Closere it does, so our team integrated Closure Compiler into build process using Maven. It is hooked up to the compile phase of the build so it compiles templates, compiles all the the JavaScript and copies the result into proper place.

If we take a minute and think a bit about what is said, we could agree that it is nothing revolutionary. Every application, written in no matter which language, should be developed having in mind good organization, easy maintenance and steep learning curve.

If you want or need to implement JavaScript client, JavaScript feels natural tool to do it. Of course, supposing that some good JavaScript framework will be used as help.

The biggest issue with this approach is its maintanability and the only way to work it out is paying constant attention to it. I listed some of the things I think might help that endeavour. Developing JavaScript client using nothing but JavaScript is not so hard as people might think. It’s just more dangerous. But, hey! This is why we do what we do. We love when it’s exciting and challenging. 😎