Tuesday, May 22nd, 2007
Ask Ajaxian: Are there clean techniques for writing JavaScript on the server?
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?
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”.
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 :)
https://phobos.dev.java.net/
It’s also so simple to install it’s silly!
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.)
I second the Spring + DWR recommendation.
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
Here some other projects to check out for server side javascript.
http://dev.helma.org/
http://www.bluishcoder.co.nz/2006/07/javascript-continuation-based.html
http://www.wxjavascript.net/mod_wxjs/index.html
Because we could foresee how producing JS on the server-side would be a pain, the KSS team has designed a client-side engine that can process a restricted set of commands coming from the server. Currently those commands are serialized in XML.
Further, to keep all logic on the server, the set of commands is very generic and kept small (almost DOM manipulations only). The idea being that AJAX page manipulations could be done declaratively, about the same way than rendering HTML plus CSS.
KSS is the infrastructure that gets integrated into Plone 3, the next version of the famous Zope-based CMS.
Oops, wrong link in previous comment : should have been KSS.
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.
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 ;-)
This is insane.. the XIN project is about exactly that.. and has been for a year at least..
http://www.fameos.com/basic/basic.htm
http://www.widgetplus.com
http://www.xindesk.com
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? :-)
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.
Eh.. Mikael, how come that whenever I see you post, You always put it up as advertisement for your project ?
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.
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.
“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
“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?
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)
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):
http://tapestry.apache.org/tapestry4.1/usersguide/script.html
And an example of using it:
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/dojo/html/InlineEditBox.script?view=markup
might this helpful?
http://projects.nikhilk.net/Projects/ScriptSharp.aspx
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.
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.
Checklist:
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.
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.
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.
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).
The samples of Gaia (http://ajaxwidgets.com/AllControlsSamples/) are all built without ONE single line of custom JavaScript…
.t
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?
Well…
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 :)
There’s your problem. You need MVC or a templating system. System.out.println(’hi’); is nasty. Don’t do that.
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.
Regards,
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.
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.
Hi,
For a full stack javascript development environment check out Zimki.
http://www.zimki.com
Si