Competitive Reproduction

We’ve seen it serveral times in history. Company A launches a new, innovative product and company B takes it, copies it and wins the competition.

Not that we have come so far in just such a short time of AJAX apps but there are quite a few examples:

A nice conversation or rather a little fight on words has started between the listed writing apps: an article in TechCrunch reported about Zoho Writer. In the comments for this article Jason Fried of 37signals (author of Writeboard) and Sam Schillace (from Writely) seem very annoyed about “such blatant rips”.

But haven’t we seen this earlier? Competition keeps the market alive. You cannot rest on your laurels. You have to prove that you deserve the predominant position. So if such a competitior beats you with your own product you have done something wrong, or simply waited to long. See IBM vs. Microsoft 1980, Microsoft vs. Google 2005. If you’re better anyway you don’t have to fear a thing.

Some interesting thoughts about this can be found at Bokardo: Web-based Office Competition Heats Up.

Posted in Web

Office Web Apps are just Proof-of-Concepts

AJAX applications are far from replacing desktop office apps. So is Flash by the way.

Several projects are trying to prove the opposite. I still think that it will not happen.

The current development is only a rise of quite sophisticated JavaScript applications. We had such applications before but now it’s “in” or rather acceptable to use JavaScript extensively. No. It seems to be a must to use JavaScript in new applications now.

I’ve created JS based applications back in 1997 when I couldn’t afford web space with server side scripting. As soon as I started working with PHP I gave it up because servers were clearly faster at generating pages than browsers at interpreting JavaScript.

Rich interfaces were left to Flash at that time. As the Flash Player resides in the browser as a plug-in and operates as a natively compiled program for the platform it is run on, it provides more speed and is not only fairly dependent on browser restrictions. Additionally it is optimized for multimedia operation which made it first choice for complex navigation.

Browsers (or rather the PCs) are now fast enough to support JavaScript apps. And XmlHttpRequest of AJAX has provided the kick-off. We are now seeing rich interfaces done in JavaScript with the possibility of real time server communication for failure fallback.

There are a few points that keep AJAX apps from taking over. They mainly go together with arguments against Flash.

  • We are still caught in a browser. Ordinary web apps sit — by definition, of course — in a web browser. There are no means for accessing the local storage — which is initially a good thing. But when it comes to web apps you need to do all this up- and downloading to use these apps. Or you store everything at their server.
  • We are still caught in a browser. This is also a problem of user interface. “Normal” users have slowly adopted a different way of using interfaces when surfing inside a browser (single click vs. double click). With new interfaces we challenge them to start using web apps in another way once again. We should think about that thoroughly.
  • Web apps want your data. (see What is Web 2.0 by Tim O’Reilly) When using web applications you need to trust that app and give them all your data. Also for security reasons there is no chance to properly store the data on the client side. But even if there was, the web app would already have all your data anyway — as it needs it for processing it.
  • Running complex apps in JavaScript is a waste of CPU power. Our computers have become faster, that’s true. But I don’t think it’s a good idea to use the speed for having a browser execute an app in JavaScript when we have stronger equivalents on our desktop.
  • Flash is a plugin. On the one hand it’s a good thing. We have more CPU power. On the other hand it just does not feel right. I cannot use the browser’s find function. Brr.

For these reasons I stick to my opinion that most of the web based office apps we see now are just a proof of concept. In near future they will not replace real office apps.

We also need to find methods to be able to effectively share data with our desktop computer. The current solutions I know are far from usable and prevent any ordinary user from getting into such projects.

All in all I am far from being against AJAX apps. But we need to keep the focus on apps where the technique can be applied in a useful way. I see them in the fields of collaboration and communication.

office, apps, ajax, flash, web2.0

Posted in Web

Code downloading with AJAX

Earlier, I suggested to use Code Downloading in order to reduce the size of AJAX application. I left the term undescribed, but I will change this now:

As JavaScript is an interpreted language, it is quite easy to load additional code, even after the application has “started”. This means that only code absolutely necessary to display the app has to be loaded initially.

In the following example, we define a function test() in the context of an object App. Then via Ajax the original code is overwritten. Naturally also new functions can be loaded.



The downloaded code is eval’uated, i.e. it is executed. You cannot only execute statements but also define variables and functions.
Source of load.js:

App.test = function() {
alert("additional code loaded");
}

I have set up an example implementation of this.

This allows more flexibility for larger apps. My “negative” example, Kiko, could use this method to enormously reduce the amount of code to be loaded initially.

I alse see the possibility to only store encrypted Javascript source code on the server and decrypt it on-the-fly (of course also this would only prevent script kiddies from stealing, but it could challenge some hacker a bit more).

ajax, code downloading

Documenting prototype.js for AJAX

As the prototype.js library lacks documentation and I recommend to use the down cut version for AJAX, I thought it might be useful to document how to use the AJAX related functions.

A “normal” AJAX callback

When you just want to do a post-back to the server (for example to store some data the user has just changed) you’d use the following piece of code:




A simple corresponding PHP script (store.php) would look like this:

< ?php if (!isset($_POST["value"])) { die("no value given!"); } $db = mysql_connect(); mysql_select_db("test"); mysql_query("INSERT INTO table (value) VALUES ('" + addslashes($_POST["value"]) + "')"); mysql_close(); echo "successful"; ?>

The value the user entered in the prompting box will be stored to a MySQL database. The magic happens in line 2 of the function store(): new Ajax.Request will do an HTTP POST to the given script at the first parameter (store.php) with the parameters given in the second argument. The yet unusual notations within curly brackets denotes a hash (also called associative array) that stores key/value pairs. Here the pair parameters (key) and '&value=' + value (value) are stored. Other possible key/parameter functions can be found at the preliminary documentation of prototype.js by Sergio Pereira.

This brings up a problem common to AJAX applications: you explicitly need to inform the user about what happened, or if it failed. This can be done via an Event handler. The most useful one might be onComplete. It is inserted like this:


function store() {
value = prompt("Give me a value, please.");
new Ajax.Request("store.php", {
parameters: '&value=' + value,
onComplete: function (req) {
if (req.responseText == "successful") {
alert("Your value has been stored successfully");
} else {
alert("Something went wrong when storing your value");
}
}
});
}

This will display an appropriate alert box depending a successful status message by the script. In near future I will describe how to use the Ajax.Updater feature which allows to easily modify your existing page to instantly display results of a query.

ajax, introduction, tutorial, prototype.js

prototype.js just for AJAX

As I stated earlier, the prototype.js library is too large for just using AJAX. In its current version (1.4.0_pre10) it weighs 36KB and contains lots of other features that are most probably not needed when just dealing with AJAX.

I have therefore created a smaller version just for AJAX, based on 1.4.0_pre10: pt.ajax.js 8.9K

It now has only a quarter of size and still provides some nice features such as $ as a wrapper of document.getElementById.

Creating this was not too difficult: it is merely a combination of 4 files that make up prototype.js:

Just do copy and paste into a new files, i.e. copying each file to the bottom of your new javascript file.

As you can see, you can easily create your own customized (smaller!) version of prototype.js to fit your needs.

ajax, prototype.js, customized

Rise of slow AJAX applications

The current movement towards AJAX is a good thing. If it really were a movement towards AJAX. In my eyes it is rather a higher acceptance for Javascript applications. Of course, it is quite naturally in the early stages of a “hyped” technology to observe many misuses; they use AJAX just for the sake of using AJAX.

Pages get more voluminous because so much code has to be loaded to the browser (which makes the browser slow again) so you could just begin to use the application. This somehow reminds me of all the flash apps. Waiting for hours to load the page and you’ll stick to that page for half a minute. (I do have a broadband connection. Still a page with 30kb loads 10 times faster than a 300kb page).

A negative example for this is Kiko, a web calendar. It has a nice “Kiko loading” box which already hints that they are doing something wrong. All Javascript files are included via server side scripting instead of loading them via <script src=”xyz.js”> which would allow the browser to cache the file.

Kiko is just one example, there are others doing similar mistakes.

I think that the current usage of AJAX is a misuse of the browser. They are designed to render web pages (i.e. (X)HTML pages). Javascript is a bonus. Large data strucures can slow down browsers enourmously (they are still interpreting Javascript just in time).

As a conclusion I want to come up with some essential features for AJAX applications:

  • Keep it bookmarkable. Don’t load everything to one page, let users return to a certain section of your app via their bookmarks.
  • Don’t overuse AJAX. Often simple Javascript without server interaction will do. Try to reduce the server callbacks.
  • Minimize the code to be loaded. When you don’t have any other choice, consider code downloading.
  • Speed up your apps with AJAX. Use AJAX for what it was meant for: tune your existing application at points where postbacks need to reload the same page with only little change.

ajax, kiko, bookmark, code downloading, speed

Bloated Ajax Applications Due to Libraries

When Ajax began to rise, there was quite a movement towards the prototype javascript library. This was also pushed by the great Ruby on Rails. Then came the visual effects of script.aculo.us. They look great, they really do. But for what price? Lots of KB of code.

alex@www:~/scriptaculous/$ du *.js -ch --apparent-size
23K controls.js
18K dragdrop.js
21K effects.js
28K prototype.js
899 scriptaculous.js
12K unittest.js
8.7K util.js
109K total

This is unacceptable for just a library. Most of these KB’s have to be downloaded and do not provide any functionality per-se. Broadband is not an argument here. To load or not to load 100kb is relevant.

I therefor really like the Sack of Ajax. It takes only about 4K:

alex@www:~/sack/$ du *.js -ch --apparent-size
3.9K tw-sack.js
3.9K total

Now this does not give us all the script.aculo.us stuff. For that case I suggest to just reuse the relevant parts of it. Just let the user download what you really use. Maybe one day we will see a reduced script.aculo.us. Or an alternative using Sack.

UPDATE: I now recommend to use protoype.js again, in a reduced version just for AJAX.

ajax, sack of ajax, prototype, bloated