Javascript revival

28 Sep, 2010

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.
Xebia Blogr
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.

Newest Most Voted
Inline Feedbacks
View all comments
Iwein Fuld
11 years ago

Just because it is javascript it doesn’t mean it has to be ugly.
I think as a skeptic, you’ve given some weight to that phrase. Nice summary!

11 years ago

Hi Gerbrand,
Thanks for the link on PURE.
I’m surprised by your phrase about your conclusion to have to send the UI in JSON.
PURE was especially built to separate the UI(HTML), the data(JSON) and the logic(Javascript).
Have a look at our app. All the HTML rendering is done client side, the browser and server communicate exclusively with JSON messages.


[…] This post was mentioned on Twitter by N Daniel-Richards and rmat0n, Alltop Agile. Alltop Agile said: Xebia Blog: Javascript revival […]

11 years ago

There are 2 ways, to use PURE:
1) using the class, and it maps automatically with JSON properties. This way links the JSON to the HTML in a way. I guess this is the way you describe.
2) using a set of JS commands we call directive to tell PURE what to transform. This way separate strictly the data and the markup. This is what I use in our web app.
Good luck in the client side of the web!

Arjan Molenaar
11 years ago

Nice blog. One other thing we noticed was that is was not possible to test JSON using static files. We had to test it through a web server :(.
@Mic: From the tutorial we basically noticed the first method and time did not permit to look into it more extensively. The second method sounds much more interesting (although the amount of data was not that striking and we managed that with a nice jQuery one-liner).

Explore related posts