/dev/null

Let me say a few words about Ape, an Ajax push server I came across this week:

http://www.ape-project.org/

Even though the authors say it’s a stable 1.0 release and “insanely great”, there are some issues you should be aware of. I write this in the hope that it helps others to evaluate the server and to give feedback to the developers. The general idea of combining fast C code with JavaScript is very good. It’s still a young Open Source project and has a lot of potential.

Incomplete documentation

It turned out to be a little bit challenging to develop code for Ape because of the quality of the documentation. There is an API documentation (which is not good for new users) and there is a Wiki with some links leading to missing pages. Most of the examples deal with how to implement a chat server. In fact Ape was previously named ACE (Ajax Chat Engine). It’s sometimes hard to understand how to use it for a general purpose application and what the limits are.

Maximum length of channel names

One of these limitations is the maximum length of 40 characters for channel names. In my library I use channel names like ‘foo.bar.baz’ that can be easily published with OpenAjax on the JavaScript side. Some of these events never arrived nor did the subscribe function throw an exception.

Nickname required to connect to server

At first it seemed like the server requires a nickname to connect, which makes sense for chat applications only. Not every Web site out there should ask the user to enter his nickname, right? After investigating the issue (I didn’t find a hint in the documentation), I found out that an example server-side script in /var/ape/examples was causing this behavior. You can comment out this line in main.ape.js to “fix” it:

include(“examples/nickname.js”);

Error when sending messages to empty channels

If you happen to send a message to a channel that is currently not subscribed (Ape calls it “joined”, like in a chat software), you’ll get an error. This behavior is strange, if you are used to other message servers that just accept the message, even if nobody will ever get it. If you know this can happen, it’s not so much of an issue anymore.

Complicated domain name setup

Ape uses sub domains in the form of [Number].ape. to communicate with the JavaScript client. Each connect increases the number (which is stored in a cookie) by one. They call the numbers “frequencies”. According to the documentation, this concept should provide sessions within a session, if you open multiple tabs in the same browser. I’ve never seen something like that before. I disabled the feature by modifying their code and tracking the different tabs on the server side. My code will be published later, so you can copy this, if you like. Another problem with the changing domain names is that you have a hard time to set this up locally in /etc/hosts – there is no support for wildcards.

Config directly inside the JavaScript library

I found it really strange to configure the Ape server URL directly in Build/uncompressed/apeClientJS.js. If you ever update this file, your config will be overwritten. Why not provide the config as a parameter to the load() or constructor function? Again, I modified the code.

Based on MooTools

There are two versions of the client library, one for MooTools and one for other JavaScript frameworks, which includes MooTools. I did not find out yet, why you need MooTools to write an Ajax push library for general usage. I also did not investigate how many files are loaded additionally when the Ape library is included. My feeling tells me, that this whole thing can be improved and that the library should be compressed and put in one single file.

No standard protocols

Even though it probably is possible to connect Ape to a general usage message server (like ActiveMQ or RabbitMQ) with some additional work, it does not offer a standard STOMP or AMQP interface by default. The Web site states that the Ape protocol is faster than everything else. So far, I was not able to confirm or reject that claim

JavaScript on the server side

It is convenient to be able to use JavaScript on the server side. Just let me note that this can lead to previously unexpected errors. JavaScript is a loosely typed language and if you happen to return a number instead of a string as nickname to the server, you will see this exception:

/var/ape/examples/nickname.js:6:TypeError: params.name.toLowerCase is not a function

A new stable release of the JavaScriptMVC framework was released yesterday Justin Meyer developed it, while working with us on a new Web application. Some features like the new custom events are direct results of this project. He did an excellent job!

New features include:

• Env.js/Shrinksafe based compression: A custom env to simulate the browser. As the browser encounters script tags, it adds them to a collection and then compresses them. This means instant file concat and compression from the command line with no extra work.
• Env.js Testing: Prior to 1.5, tests ran in the browser only. With Env, the same tests can be run from the command line. Great for projects where you need a quick way of checking if functionality works before check-in.
• Documentation:New JavaScript based documentation library split between JSDoc and NaturalDocs.
• Code Generators: Added code generators and made building custom ones easy too by using EJS.
• Scaffolding: Helps you develop iteratively by connecting to default Rest services and providing an easily expandable CRUD interface.
• Engines+Plugins: Added a command line plugin and dependency installer. So, if a developer wanted a jQuery plugin, he can install it from the command line, and it will also grab jQuery.
• Custom Event Delegation: Besides improving event delegation to cover all the cases that even live doesn’t do, they’ve expanded it to include custom events such as drag+drop, lasso, hoverenter, mousenter. Developers can have the benefits of event delegation with these complex events.
• Easy Update: JavaScriptMVC can update itself from the command line.

Shall I use JSON or XML as AJAX transport format?

There actually is no reason to use XML instead of JSON, if you don’t plan to use XSLT. JSON is part of JavaScript which has been around since the dark ages of the web. Also, there are very fast server-side JSON implementations and JSON is the more compact protocol, thus saving bandwidth.

Isn’t XSLT much faster than to use JSON and modify the DOM with JavaScript?

First, it is highly unlikely that there are more browsers that understand XSLT than {a: ‘b’}. In fact, with JSON you are on the safe side. For a client-side templating engine like EJS, the performance is not an issue.

Processed EJS templates simply add strings together.  They do not use eval() or have a processing step which is probably why typical templates run slow.

Also, XSLT is loaded from another file while EJS can be packaged with the JavaScript payload.  This necessitates an extra request by the client.

Is it better to render the HTML on the client or an the server side?

There is a general decision, you need to be aware of: Are you building a Rich Internet Application or do you want to beautify some HTML output with additional (JavaScript-)effects? Is the site required to be usable without JS? If you can rely on JS and if it’s a RIA, then I would suggest using a client-side MVC framework like JavaScriptMVC, which comes with client side controllers, template engine and model classes. Your server will mainly provide JSON-API functions and the basic page grid then, and not deliver complete HTML pages. Lots of logic (and therefore code) will move to the browser/JavaScript: In effect, you will need more JavaScript developers and less server-side developers for your projects. On the other hand, you will see a gain in consistency and also performance, as you have way less client/server communication, once the JS code is loaded (which can be pretty fast, thanks to compression). Many popular Web applications are using this approach.

Which JavaScript library shall I use (Dojo, jQuery,…)?

The choice of JavaScript DOM/Ajax library is IMO not so important, as long as it doesn’t leak memory, has a small code size and offers fast DOM queries. See

http://www.domassistant.com/slickspeed/

The real problem you will have, is that normal event binding causes problems because of memory leaks (circular references which can’t be handled by the garbage collection of most browsers) and also because you need to loop through all elements and refresh everything after doing changes to the DOM (for example after AJAX requests that modify the HTML). So, at the end of the day, you will want to use event delegation, which comes for free with the controllers of JavaScriptMVC.

I know there is JavaScript “integration” in my favorite Java/PHP/Python/Perl development framework. Am I ready for building a Rich Internet Application now?

Server-side generated JS, like what you will get when using any framework that offers JavaScript support (I’m not talking about JSON/REST here), can be a pain, because almost certainly, you will have a very limited feature set and maybe also problems with deployment and testing, because the common server-side frameworks can’t really test JavaScript code nor is there a smart way to optimize generated code or structure it. Most of the approaches I’ve seen just generate some inline JavaScript which is good for enhancing forms a bit with new input elements/validators or offer some nice visual effects – but that’s it. If something like this needs to be customized a lot and grows big, you might be in trouble. Again, the question is “JavaScript enhanced Web site” or “Rich Internet Application”? To generate JavaScript with a server-side language/framework  has it’s limits and is very often not consistent, if you use hand-written JavaScript code at the same time.

What features should a JavaScript framework for Rich Internet Applications offer?

I would argue that a good JavaScript framework allows an average developer to produce effective and structured code. jQuery and the like however are just browser abstraction layers (like Zend_Db is an abstraction layer for databases). Raw jQuery will almost certainly produce the same mess as raw PHP or any other server-side language that does not imply a clean application structure (MVC). You end up with reinventing the wheel and you will have different code to do similar things. Or it will just be plain slow, because without dispatching events (event delegation) you end up with looping over elements to attach events and effects, which simply gets slow for many elements. Also you will have no overview and especially inline JavaScript can’t be compressed, which means you will transfer the same source code with every request. That said, I vote for separating server-side code, JavaScript and HTML and have clearly defined interfaces. A sound architecture is a great help for all developers, as soon as there are more lines of code than fit on a screen. You don’t want to start guessing, if the code you look for is hidden in a JavaScript file, in a template, in a view helper or some other file.

Which browsers are commonly supported for Rich Internet Applications?

Compatibility is not a big issue anymore, if you are fine with supporting IE 6+, Safari 3+ (incl. iPhone), Firefox 2+ and Opera 9.5+. IE < 6 is very hard to support (I would simply refuse to do so). IE 6 is slow with JavaScript, but the real pain is it’s lack of good CSS support.

I want to use W3C standards only (W3C DOM, XML and semantic XHTML) for my Rich Internet Application. JSON, innerHTML and DIV elements are evil, right?

No. If you have a closer look, then you will notice that semantic HTML (for example, using the table element to render a table instead of DIVs) or not using innerHTML sometimes offers very bad performance for DOM manipulations, thus render the complete application useless. innerHTML very often delivers the best performance for inserting content to the DOM. So, don’t decide on certain implementation details upfront, especially if you plan to support IE6, which simply is an old browser and needs some special treatment. JavaScript forces you to be very pragmatic sometimes.

See http://www.quirksmode.org/dom/innerhtml.html

JSON is a standard because it is implied by EMCAScript. See JSON vs. XML.

Using parallel requests to get data from the server seems to be a good idea to speed up performance. Is there any downside?

Depends. A major issue with modern Web applications is that the initial loading causes many parallel requests, as you just deliver the page grid and the JavaScript client side code then renders all the other elements from client-side templates and loads the corresponding data (if needed) using the mentioned JSON-APIs. A constant overhead is produced when using comet. Parallel requests frequently cause problems, as some server-side session handler implementations lock the session (other requests have to wait then, until the session is accessible again). Also the many requests might require lots of memory and server processes.

I want to thank Justin Meyer (maintainer of JavaScriptMVC) for all the interesting discussions and his input on the JSON vs. XSLT debate.