Tuesday, May 22nd, 2007

Ask Ajaxian: Are there clean techniques for writing JavaScript on the server?

Category: Ajax, Editorial

Jim McCabe had a question for the community, so we thought it would be good to hear your thoughts:

Over the past year or so I’ve gradually integrated AJAX into a web
application. While this is great for our customers, I’m increasingly
disturbed by the ugliness of the code on the server side. We have nice
Java objects representing various components, but the code for those
components is getting uglier by the month. Java that writes HTML was
bad enough. Java that writes JavaScript is even less readable.

I’ve been looking around for information that would help me approach
this problem better but can’t find anything that really discusses this
specific problem. Are there design patterns that help? Are there
libraries that help Java build JavaScript, or even just any good
suggestions on how to keep things readable and clean?

There are many directions that you can take this, and there are many takes on it:

  • “I hate JavaScript”: These frameworks abstract away from the JS itself so you don’t care about it. GWT and RJS are two very different examples here
  • Finally. web services matter: You can code the server side to speak web services, and then the client is responsible for doing the right thing, and both are very separate layers.
  • JavaScript everywhere: Imagine if you just coded in JavaScript throughout the tiers. The client/server piece could blur, and you could share the object model. This could make offline simpler. A framework could be smart enough to grok annotations of methods to know when to go back or not. Of course, we don’t want to make the same mistakes as distributed object systems.

Do you have any advice for Jim?

Posted by Dion Almaer at 6:11 am

4 rating from 51 votes


Comments feed TrackBack URI

I believe the problem comes down to design patterns, more than Java/not Java. (I don’t believe Java was intended as a server-side web development in the first place, but that’s another topic).

After years of Ajax development I’ve found it much better to have a pile of handy functions that are delivered to the client with the initial page load and the only javascript you need to deliver inside your Ajax responses are calls to these functions and maybe some JSON data. Make the client smarter and the server “dumber”.

Comment by James MacFarlane — May 22, 2007

Please check out the phobos project, which lets you run javascript (or ruby) in a portable J2EE container. You can extend enterprise Java classes, including database, security, et.c. and use it right off the bat, just like groovy – expect you already know the language :)


It’s also so simple to install it’s silly!

Comment by Peter Svensson — May 22, 2007

I agree with James that this really isn’t a Java/not Java or a Javascript everywhere (shudder) kind of issue. This is about refactoring your application to properly use AJAX in the client tier, not to “integrate” AJAX on top of an existing front end. If you designed right, separating concerns and adhering to MVC or Model2 then creating an AJAX front end on top of your already existing server app.

Now for libraries, I personally do not use GWT or anything like that. Code your UI in your favourite JS Framework (Ext, mootools, scriptaculous, prototype etc), create your back end in Java as you would and “integrate” them at the communications level only – don’t have Java generate Javascript UI componenets, merely have it deliver the information so ANY framework can use it. I highly recommend Spring + DWR. You can then use just about any framework for the UI and JSON for the communications, all without even touching your server code.

FWIW, remember that generated code is supposed to work, not be readable. Sometimes that’s all you need, since you can always (and usually do) regenerate.

**(Note to James: “I don’t believe Java was intended as a server-side web development in the first place, but that’s another topic” – I agree, but it certainly excels at it.)

Comment by Mike — May 22, 2007

I second the Spring + DWR recommendation.

Comment by Ryan Breen — May 22, 2007

Rather than have the server-side spit out html and/or javascript would it not make more sense to have it produce JSON like a web-service? Then the Javascript could deal with transforming this into DOM elements.

I know there is a JSON class for PHP to easily convert arrays into a JSON string (it might even be built into the latest PHP release) and am sure there is something similar for Java

Comment by Aaron Bassett — May 22, 2007

Here some other projects to check out for server side javascript.

Comment by Felix — May 22, 2007

The question seems to be about generating dynamic JS code. As much as possible I’d try and avoid that. It seems like an approach fraught with difficulties, although I gather that is sort of what GWT and openlaszlo do.

In terms of JS on the server, I’ve used it as a sort of business control system. It worked well, but I wouldn’t want to do database stuff with it. There are any number of similar scripting languages that would be a lot better are are not that different to JS. PHP, Ruby, even Perl.

Prototype has tried to extend JS to include Ruby like language structures. That is another way to sort of merge client and server side code.

I think most people have the right idea. If you want clean client side code you need common libraries that include everything you need. If you are inclined you can write these yourself. Otherwise there is Prototype, JQuery, Moo, Dojo, YUI. etc etc etc…

Server side, frameworks like Spring, RoR etc are the way to go.

Comment by Colin — May 22, 2007

I don’t like the idea of server-side code writing javascript. It feels like scriptsoup and I don’t see why you’d want to do it that way. Most of the time your Ajax/Javascript layer adds functionalities to the UI, and the impact server-side boils down to “do I need to serve this within the whole template (page load), or just as is (ajax request)?”. So make sure your code can handle this two types of requests, then build your app without any javascript. Then add the fancy behaviors in separate js files, loaded in the appropriate pages… and don’t be lazy, write the javascript by hand ;-)

Comment by cedric — May 22, 2007

This is insane.. the XIN project is about exactly that.. and has been for a year at least..


Comment by mikael bergkvist — May 22, 2007

I use JSP+JSTL to render the javascript, just as it used to be done to avoid mangling HTML with java in servlets. For a not-too-complex app. I’m I commiting heresy here? :-)

Comment by Little talker — May 22, 2007

Hi, I am still adapting my applications to “Ajax”, but I like the approach I’ve taken. I have my own Ruby Web framework which has been adapted to support Ajax as well, and the premises of trying to not repeat myself and Ruby easiness/clean code helps to keep things straightforward. Here’s a listing of the public Web files of my Blog tool:

$ ls
add_post.js edit_post.js index.rb post.js posts.rbh template.rbh x_public.rb
add_post.rbh edit_post.rbh index.rbh post.rb rss_feed.rb x_comment.rb
authenticate.rbh gen_pdf.rb manage post.rbh t9n x_post.rb

The files starting with the “x_” prefix are what I call “Ajax services”, and the x_public is where I try to keep the code that is publicly accessible, while the other “x_…” ones need authentication.

I try to streamline things, for instance, some of the data validation routines on the server are automatically downloaded by the client when the client needs them, which makes me keep things on the server and reuse on the client when needed. The validation works in a declarative way, and both server and client have similar implementations of it.

For example, when a new record is to be inserted, the client first sends a prepare_insert commad like this snippet of code:

case t

when ‘prepare_insert_comment’
a = {‘fields’ => comment_fields}

when ‘insert_comment’

Where the fields validation data is sent in the “comment_fields” above for pre-checking, but it’s rechecked in the insert_comment of course.

I find Ruby provides are very “no fuss” experience, better than JavaScript would on the server. With Rails you probably can make things work in a streamlined way as well.

BTW, I use the Ext JavaScript library widgets/code as well, which helps to keep things “componentized”, even though I’ve created a wrapper for it to keep the redundancies low.

The bottom-line is that Ruby is core to my server-side code, and I always try to reduce redundancy, while keeping things secure at the same time.

Comment by Joao — May 22, 2007

Eh.. Mikael, how come that whenever I see you post, You always put it up as advertisement for your project ?

Comment by Andy — May 22, 2007

Leaving aside the possibility of actually running JS in the server (which is very tantalising http://softwareas.com/phobos-server-side-js-redux), how does your server output JS?

Personally, I don’t much buy into frameworks that magically produce JS for you. JS is a first class language and if you cleanly separate tiers, outputting JS should be no more than writing some JS into a file and placing that file on your server for static consumption. No auto-generating JS on the fly.

This does imply all programmers know JS, but if you have a *web* developer cutting Ajax apps, I think that’s fair game for typical mainstream development. With appropriate use of libraries, any competent developer can produce portable, robust, JS without being a Javascripting guru.

Comment by Michael Mahemoff — May 22, 2007

It makes sense not to generate any application Javascript on the server side. Instead, Javascript files that form the client application should be delivered statically (with good caching) and exchange with the server should only include data requests. A resource requested can then be represented using XML or JSON (this is an exception where generating Javascript on server makes sense, but there are also very good frameworks for this purpose)

What language is used at server side is not relevant, as long as the web application framework is able to create multiple views of a resource, e.g. the HTML view, the RSS view and the JSON view.

Comment by Lars Trieloff — May 22, 2007

“Finally. web services matter: You can code the server side to speak web services, and then the client is responsible for doing the right thing, and both are very separate layers.”

’nuff said

Comment by Wade Harrell — May 22, 2007

“Eh.. Mikael, how come that whenever I see you post, You always put it up as advertisement for your project ? ”

– Only when it’s relevant to do so, I dont think I’m spamming..
I rarely post anything here or anywhere else, but in this case it’s a slam-dunk.
It’s spot on what we do, so why shouldn’t I?

Comment by mikael bergkvist — May 22, 2007

I’ll “third” Mike and Ryan’s suggestion about DWR, if you work with Java.

A couple of days ago, i released IBDOM to dramatically ease the process of injecting JavaScript objects (retrieved asynchronously thru DWR or any other framework), into your document.

DWR also goes to great lengths to bulletproof developers against security issues surrounding services that output javascript.

Here are some URLs:

DWR: http://getahead.org/dwr
IBDOM: http://ibdom.sourceforge.net/ (i just put out today some more documentation, an interactive demo, and fixes to ibdom.js to put in the next release, but which you can just download straight from the SVN HEAD)

Comment by chris holland — May 22, 2007

I don’t like being too direct about advertising but since I didn’t implement it anyways ….

Tapestry has supported a javascript templating ability for as long as I’ve used it. It doesn’t try to auto-generate javascript for you but it sure does make it a ~lot~ easier to write complimentary javascript code for whatever you are doing on the server.

The script template language (very velocity-like):

And an example of using it:

Comment by Jesse Kuhnert — May 22, 2007

might this helpful?

Comment by norman — May 22, 2007

There are in many instances where JavaScript on server-side comes to play, but they either mix with Java, have their own variant, or whatnot. There’s almost no pure server-side JavaScript, unlike PHP. wx_js is a good example of what server-side JavaScript should be, and, like all server-side scripting languages, JavaScript needs to be deployed and wide-spread enough to gain advantages. Most hosting companies provide PHP, Perl, Python, and sometimes Ruby, but no JavaScript, because no single server-side JavaScript implementation has been shown to be mature enough.

Comment by kourge — May 22, 2007

This is alarming. With all of the awesome Java web frameworks you somehow have Java writing Javascript and returning it directly?Consider a remedial lesson in jsp templating. I’d suggest looking at something like Spring MVC to give you a sense of how you should be seperating your code.

1. Your Java should return Java DATA
2. Rendered HTML should be passed through a template which for beginners I would recommend .jsp.
3. Javascript (do you mean JSON?) can be returned via a transformer like XStream.

If you feel you’re learning or implementing rocket science to tie Javascript to Java, you’re doing something very wrong.
I wish I had more time to lay it out, but its bedtime.

Comment by Ivan — May 23, 2007

As others already pointed out, I don’t think it’s a good idea to generate javascript with Java (or any other language).

For me, what works best is to write all the code for the view and controls in javascript, and the code fo the model in Java, JSP, or both (using JSPs only to format data in JSON format).

One problem caused by this approach is the initial delay caused by tons of javascript being loaded. A workaround that I use is to load at first only the declarations of the public functions and methods (as a C++ header) with small bodies. These bodies force the loading of a chunk of javascript that contains the real implementation of the method.

I don’t know if any framework or lib have sometinhg implemented to help with it, but it’s easy to do somenthing simple by hand. I guess that dojo does something similar, but I’m not sure.

Comment by Roberto Giordando Barra — May 23, 2007

It depends where your expertese lies.

If you’ve got a building full of Java programmers then GWT or similar might be for you.

If you’ve got one or two developers who understand browser-side development on more than a superficial level then you should really build a nice tiered web service system.

Comment by Richard Marr — May 23, 2007

If you know how to code JavaScript, do it manually. Otherwise, I’ve always heard good things about GWT but I’ve never used it (I tend to avoid Java like the plague).

Comment by Andy Kant — May 23, 2007

The samples of Gaia (http://ajaxwidgets.com/AllControlsSamples/) are all built without ONE single line of custom JavaScript…


Comment by Thomas Hansen — May 23, 2007

The original post was about running javascript ON the server, and not about outputting javascript to the client FROM the server. It seems this got lost somehow.. :-)

Further more, to run javascript on the server seem to call for a dhtml model, use of the DOM, on the server as well, and this is also getting lost.

So, what if one could mirror the DHTML/DOM model on the server and have persistent variables, just like in the browser on the client, only with serverside objects?


Comment by mikael bergkvist — May 23, 2007

mikael: while you do pose interesting questions that merit their own discussion, i’m not sure i agree with your interpretation of the original post :)

Comment by chris holland — May 24, 2007

Java that writes HTML was
bad enough. Java that writes JavaScript is even less readable.

There’s your problem. You need MVC or a templating system. System.out.println(‘hi’); is nasty. Don’t do that.

Comment by jason moore — May 24, 2007

As I understood the initial question was something like “I didn´t like JAVA to create HTML, now it also creates JS to it, and my code becomes more and more unreadable”…
JAVA has its pro.s and contras – but it definitely is the one language most commonly used in big business citical systems, and I regard it as the most common gateway to any kind of Oracle DBs.
In this, I share the authors sorrows about JAVA creating HTML and JS. This way the code becomes server heavy and complex beyond servicability.
In my eyes the solution lies in one of Dions initial comment: let JAVA do what it is designed for – business processes – but the interface to the client should be strictly JSON objects, or if you prefer: XML.
For everything else the server should simply deliver files, that is JS, HTML and CSS files.
I have been working with this approach for a long time now, and I have no fear about the readability of my application code, no matter how complex the project.
My system utilizes PHP on the server side. To completely convert it to JAVA you have to migrate 60 lines of trivial PHP code. On the client side, it is pure JS / HTML / CSS coding and webdesign. It is all 100% separated.
@Jim: if you want to see it at work, try the link below.

Comment by Frank Thuerigen — May 26, 2007

One thing about spamming (in response to Andys comment on Mikaels post):
We are all sitting in one big boat here, some row, some sail and some fire their steam engines. I really like to hear about other ways of doing things, and try to learn from it. But I cannot try all these approaches, at a certain point I had to decide what my way is. Also I´m a bit proud of it, it took me some time to get there starting from scratch. My try was simply a balancing and simplifying approach.
So I can clearly understand everybody that presents his system of doing things. In fact we all bring our systems on the table to open discussions on them – no feedback no gain.

Comment by Frank Thuerigen — May 26, 2007

In 1998 I was writing server side of web application in JavaScript on IIS.
But at that time JavaScript support from Microsoft was much inferior to support for VBScript:
– there was not yet exceptions in JScript, so clean error handling of errors in ActiveX components was impossible
– the Microsoft documentation has only VBScript samples for ASP. I finally found how to initialize Application and Session with JScript, but it was awkful.
– there was too many limits in available ActiveX components used to interact with the system. The only solution was to create new components in another language, which destroyed the aim to use only one language for both server-side and client-side. There was scripting engine, but not an useful enough API/framework.

All those points also apply to Microsoft Windows Sripting Host.
The last point is the main reason why I consider ASP and WSH to be missed opportunities from Microsoft. They have powerful scripting engines but they did not invest enough in interfaces/testing/documentation to make every part of the system available to them. They choose instead to try to ease the creation of ActiveX components with C# and .Net.

Comment by Olivier Mengué — May 28, 2007


For a full stack javascript development environment check out Zimki.



Comment by Simon — June 29, 2007

Leave a comment

You must be logged in to post a comment.