Javascript revival

Last Friday, one week ago, the Software Development Day was at Xebia, the first one for me as I started at Xebia this year. As written by Iwein there was some discussion about the use of Javascript started by yours truly. Should we do all UI related functionality in Javascript? Do we do throw away our knowledge, tools and best practices we know when we start coding Javascript? Why should we code in Javascript using the browser as some sort of Virtual Machine, if in fact we want to create desktop application?

Well, to answer a few questions, there are quite some frameworks to allow one to do more mature Javascript coding. Frameworks like JQuery, Prototype and YUI allow you to create cross-platform user interfaces without lots of boiler plate. Using a templating framework Pure you can build up a user-interface by just transferring JSON-data. There are also lots of (unit-)testing frameworks for Javascript. So coding in Javascript doesn’t necessarily mean we have to go back to the coding stone-age.
An argument against using Javascript: there’s a lot of ugly code written in Javascript you’d might have to deal with. However, the possibility is there to write good code in Javascript: it’s a mature, dynamic programming language – although quite different from Java.
Finally, an argument in favor: we were going to develop a blogging site – not a desktop-application. Whether or not Javascript is best-suited for desktop application wasn’t relevant. Although I think that’s still an interesting open question for desktop-like applications.

There were quite a few developers and one project-manager who joined the website-team. Certainly we hadn’t any vacant project-manager role, but fortunately he mastered HTML and design as well :-). We formed three sub-teams, who each paired: one for the overview page (with all the blog items), one for the blog-item post (single entry) and one for the Javascript ‘backend’ (that backend-code also runs in the browser of course).
Arjan had the strongest arguments against my objections to javascript on the mailing list, so we joined as subteam to code the javascript ‘backend’. We decided not to use Pure as we didn’t like that you basically had to transfer you’re entire UI-structure in JSON. There wouldn’t be much difference on sending HTML and have the browser render the UI.
Our project manager, along with his pair created good looking design. The other team created a good overview of articles. Soon we had a good looking design, showing the message from the stubbed REST-service. All UI related logic ran inside the browser. Using url-rewriting rules, we managed to keep urls pretty – that way the javascript application can be indexed by search-engines.

By 17:00 REST-service started showing real message, rather then stubbed one. Not a moment to late, as we had to start the demo.

As already stated in a previous entry, the demo was a great success! The application displayed entries from our dedicated mailbox ran completely within a webbrowser, without any plugins (a modern, up-to-date browser is needed though), and accessed the Spring-based backend webapplication via JSON. Without a proper front-end, there wouldn’t be much to demo 😉 – of course every other team can say the same of their contribution.
Could we have done more? Well, we hadn’t created any unit-tests. If our application would become larger, that would certainly become a must-have. A challenge is that there doesn’t seem to be a good standard yet. Within Java the de-facto standard for unit tests is JUnit. For Javascript a ‘market-leader’ hasn’t emerged yet, so I’d have to pick one.
Arguably, something like a automatic build for the Javascript application (as was already in place for all the Java-code) would come handy as well, so all of those tests are run automatically. Test Swarm looks promising. And is there something like Maven for Javascript? To finally conclude, there’s more to investigate and try out.