Live Ajax chat is one of those Comet 101 kind of examples (as RSS readers were to Ajax back in the day!).

We saw a couple of items from this meme recently.

First, jChat, a showcase chat application using Jaxer:

Jaxer ships with a number of basic samples, but I’ve seen quite a few people online in search of more complex examples and specifically ones that make use of the new ActiveRecord.js library. The extended example I developed is called jChat. jChat is fully functional chatroom application that demonstrates integration of the following web related technologies; HTML, CSS, JavaScript, MySQL, YUI, Jaxer, and Activerecord.js.

jChat’s DOM access/manipulation, event handling, and animation code makes heavy use of YUI. The YUI Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX.

Then we get to Red tag crazy (or w00t! for girls) who told us about their live chat implementation in the wild:

We wanted this to be really fun for our shoppers, and chicks like to chat. Then came the idea, “what if we have a chat system right on our home page?”. The pre-requisites were: it has to be super easy to use, not require any sign-up, no plugins, and it has to support thousands of users at once. Solution = jQuery Ajax.

Our server crashed on day 2 from the memory used by PHP to refresh hundreds of ajax clients at once. Our solution was to cache a single JavaScript file that is loaded via ajax by each client every 15 seconds. This file contains all the necessary data to update a page with a bunch of chat bubbles and slide in new comments as if it were some sort of crazy java plugin. PHP runs via cron-job to update this cached JS/jQuery powered file every 2 seconds on our server, which turns out to be a lot less memory intensive than at every ajax request.

Once you load the file you simple configure the main object (change the file rather than calling .config(...) which would make more sense):

ActiveRecord.js is an open source object relational mapper (ORM) that supports multiple JavaScript environments, including:

• Google Gears (client-side persistence)
• In Memory (if no SQL server is available on the client)
• Adobe AIR (client-side persistence)
• SQLite and MySQL (via Aptana Jaxer, the open source Ajax server)
• additional environments (like HTML5) expected to come through working with the community on the project

ActiveRecord.js abstracts away underlying SQL commands so that JavaScript developers can have a unified API for storing, finding, selecting and retrieving objects and their data using the ActiveRecord pattern popularized by the Ruby on Rails community.

Here is some example code using the ActiveRecord.js framework; note that they've made some interesting changes away from how Ruby on Rail's does the ActiveRecord pattern:

See the Aptana blog post for more details.

The mobile Web is getting increasingly interesting. Nokia has put another hat in the ring with their new Nokia Web Runtime that embeds WebKit into S60 phones:

Widgets — you're familiar with them from the desktop. Small, focused web applications that are easy to install and use. Perfect for the small screen. Nokia has extended the S60 browser engine to behave as a runtime platform in its own right.

Web Runtime (WRT) is available in devices based on S60 3rd Edition, Feature Pack 2 and later. It's also available as a software update for selected S60 3rd Edition, Feature Pack 1 devices. WRT is a simple mobile web technology that can really work for you.

Kevin Hakman announced an Aptana plugin for this work:

Aptana is expanding its support for mobile web applications with today’s beta release of the Nokia WRT (Web Runtime) plug-in for Aptana Studio. The Aptana iPhone Web development plug-in has been one of the most popular for Aptana Studio – and now there’s support for Nokia phones too. What’s cool (other than all the great development tools in Aptana Studio now available) is that Nokia has embedded WebKit for NATIVE phone apps. That’s right -- You use your Ajax, JavaScript, HTML and CSS skills to create NATIVE apps – and in so doing get better and more optimized performance along with more capabilities that come from running natively.

The Nokia WRT is based on WebKit. So there's lots of sound, open web technology there as a foundation upon which to build. Despite the "duh factor" of this, it's kind of revolutionary since mobile devices historically have required specialized runtimes, libraries and tools resulting in a highly fractious eco-system for mobile app development. WebKit's adoption by many leading mobile device manufacturers, including Apple for its iPhone, lays a great foundation at last for a mobile standard: JavaScript, HTML, and CSS -- Duh!

For the folks that like to write AIR apps that at least have some JavaScript, you will be happy to see that WebKit has been updated:

The version of WebKit included in AIR has been updated to a newer version. The updated version includes Squirrelfish, a new bytecode interpreter that improves the execution speed of JavaScript for common actions. Our internal tests show that HTML-based AIR applications run as much as 35% faster for many types of operations. We have also added support for interactive debuggin fo Ajax-based AIR applications.

There is also a nice sample app that uses jQuery called BlackbookSafe.

Aptana is also helping you out with their new Studio plugin for AIR debugging:

Today's release of the Adobe AIR Development Plug-in for Aptana Studio (beta) features, you guessed it — JavaScript debugging for Adobe AIR apps along with support for Adobe AIR 1.5 which Adobe announced earlier this week.

First, Jaxer 1.0:

If you've already been using Jaxer you're likely familiar with its database, file system and socket APIs and its ability to not only run JavaScript and process the HTML DOM at the server, but also to expose server-side functions to the Web such that a HTML page can call back to those functions directly from the Web page. Thus Ajax communications could not be any easier with Jaxer: You just write a server-side function, "proxy it" with one line of code, then call it from the Web browser as if that function were part of the web page. Jaxer handles the client/server communications, data transformations, and provides the client-side function with its return value (either synchronously or asynchronously).

Recently we've added even more capabilities based on community feedback. These including support for RESTful APIs as well as native support for JSON to supplement the E4X (XML for JavaScript) support that's been there all along (thank you Mozilla!). The combination of these means you can easily create RESTful services that can be consumed by a wide array of Ajax applications, Web gadgets, Facebook or OpenSocial apps, and even Adobe Flash or Microsoft Silverlight based apps since those support JavaScript too. Plus mobile devices like the Apple iPhone and phones from other manufacturers are nearly all supporting JavaScript and Ajax. As you can imagine we're excited to see JavaScript become more and more the lingua franca of Web applications. It's already ubiquitous on the client side and now you can use it confidently on the server side.

We sat down with Paul, Uri Sarid (CTO), and Kevin Hakman (Director of Evangelism) to talk about this release in particular as well as the other recent news and the grand plan.

We have the audio directly available, or you can subscribe to the podcast.

There are a series of nice new screencasts to give you a quick feel for it all. Learn more about Jaxer, Cloud, and Studio.

The Jaxer team has released a release candidate for Jaxer 1.0.

Here a synopsis of all the new features and improvements that have gone into this latest release candidate:

• Jaxer.Sandbox: HTTP-level control; support readyState, toHTML, waitForCompletion
• Built-in, extensible dispatching for RESTful and RPC service requests
• Fast, native JSON support
• Improved APIs for HTTP Request and Response
• More flexible handling of application configuration
• Many bug fixes, smaller improvements, and cleanups

They are moving pretty fast, so are looking for feedback before they wrap up a final 1.0 release.

We wanted to answer a simple question: how does Jaxer, with its server-side DOM and JavaScript, perform relative to these other popular alternatives?

This was not designed to be an all-encompassing shoot-out, or a detailed study of everything you might want to do in a web app. Instead, we took a few common tasks — making database requests, using JSON, etc. — and implemented them as you might expect in the three platforms. We made enough DB requests and JSON calls and so on to give us a reasonable number of milliseconds to measure. But we also wanted to make the repetitions representative of what you might find on somewhat intensive real-world page, so we're not making a million DB requests, just a hundred, for instance. And we included one benchmark of serving an almost-static page: the "almost" was to make sure we were measuring the time the platform took to really read through the page, in case it had dynamic content in it. (Otherwise, if the page were truly static, you could always arrange for the web server to serve it without involving the platform.)

The tests include page scraping tests (e.g. mashup work), database performance, file I/O, JSON, and programatical loops.

Tom Kirkpatrick has written about writing one form, and using access control to map it to various roles using jQuery and Jaxer.

This is a simple pattern. You never want to use client code to manage access, for obvious reasons. The approach is to use the server to spew out HTML that makes sense, and then parse in the input and check access control.

Using Jaxer, this is all taken care of in JavaScript, and you can use libraries such as jQuery to do work there.

One solution to the roles issue is to manipulate the DOM on the server before it heads to the client. The magic lies in the 'server-nocache' directive which tells Jaxer than "the code should only run on the server, and that the code or should not be cached and will therefore not be available during callbacks."

Of course, to be safe, you need to always test access control incoming, and not rely on the HTML that you send down.

Tom Kirkpatrick has written about a new API in Jaxer, Jaxer.Process, that allows you to call out to the host operating system. His example has a call out to get the uptime on the machine:

You can see the application running live.

Kevin Hakman told us about the release:

We've had server-side JS database APIs all along, but now handing result sets is even easier. There's also now full fine grain control and access to the entire communication cycle with APIs for message headers, redirects, content and types. Speaking of types… for the first time with Jaxer, you can return content types other than HTML including JSON, XML, GIF, etc… Yes, even GIFs. Jaxer has a fresh new Image API that among other things can convert Canvas to static images and serve them up. Like, Greg, I too really like the idea of using Jaxer for easily creating JSON data services which is a rapidly growing trend as developers discover the powerful capabilities of JSON more and more. In Jaxer, it's very cool since it's all native JavaScript on the client, on the wire, and on the server. There's even enhanced JSON serialization to make it even easier than before on both client and server. JSON services also open Jaxer to be useful in combination with rich internet clients other than Ajax UIs such as Flash, Flex or even Silverlight since all those support JavaScript on the client and can consume JSON data. For Ajax and RIA developers this is a boon since you can now write your client-side and server-side code in the same language. And if you prefer XML data services Jaxer's native E4X (ECMAScript for XML) support means you can handle XML docs natively in JS on Jaxer as well.

This release also includes a totally new concept: a secure sandbox which as Greg explains, "lets you load, on the server, pages from other domains and allow their JavaScript to execute without giving them access to the Jaxer API or your own server-side code, but still gives your code access to their window objects and anything inside them". For anyone who has ever done screenscaping for mashups or other applications, this really helps a lot since Ajax pages have historically thwarted scraping operations. With this feature in Jaxer you can securely get a remote page, execute its functions, and scrape the resulting DOM nodes (yes, you need not do tedious manipulations with strings) and voila!

Here are the features:

• Application context settings that allowing for easier app configuration, app properties, database settings, etc...
• Database API enhancements with richer APIs for working with result sets.
• Server-side image manipulation including server-side canvas support and ability to convert to other image types.
• Native command execution API so that you can run system commands and handle the output from those.
• Asynchronous server-side JavaScript processing lets you implement callbacks in your server-side code too.
• Ability to return custom content types (e.g. json, xml, gif, html, etc...)
• Full control of the request/response lifecycle including setting redirects, headers, content, etc...
• Secure sandbox supporting cross domain calls, sandboxed JavaScript execution, META refreshes, ...
• Serialization support for JavaScript objects to and from XML, E4X and JSON.

Uri Sarid has a great post that shows how you can do DOM Scraping with Jaxer, and updates it for this latest release:

There's a lot of other new goodness in Jaxer 1.0, as well as the official released version of the Mozilla engine found in Firefox 3. So for example getElementsByClassName is natively implemented (see John Resig's speed comparison), in addition to the other Mozilla features such as built-in XPath functionality and a very robust DOM feature set — just what you need for some serious 'screen scraping', mashups, and content repurposing.

Let's see it in action!

It includes code that shows the Sandbox in action, as well as the DOM work:

Greg Murray was the Ajax guy at Sun, created jMaki, and did a lot of work in organizations such as the Open Ajax Alliance. Ryan Johnson is the creator of the livepipe and object.event Ajax libraries. What are they doing?

Greg's primary role will be creating increasingly robust application frameworks for Jaxer, Aptana's open source Ajax server product. Ryan has already been working on MVC concepts for Jaxer and will be collaborating with Greg and the rest of the Jaxer team to drive that and other great concepts for Jaxer forward.

The timing could not be better. Greg and Ryan have joined up just before we get the Jaxer 1.0 release candidate out the door to the whole community (it's just a matter of days now). This puts us in a great position to start working on some of the next things that'll be in store for Jaxer in the coming months -- and there are some great ideas brewing. For example, Greg and Ryan have already been collaborating with the Jaxer team to create an ActiveRecord-like JavaScript ORM for Jaxer that promises to make working with JavaScript data a pleasure -- since it'll all be native JavaScript!

This is possible as the JavaScript is running on the server, and this server is running on Windows. You can download the source code to check it all out.

I asked Rich why would developers do this versus doing a simple Ajax call to a template sitting on a server:

The template bit lets you generate the html before the page is served up so that no extra client side calls are necessary. I think the Ext template system is really slick and easier than even a lot of other existing server side templating systems. More or less it was also just an example to get people thinking about what could be done now that Ext can be run server-side.

The code snippet allows you to make the calls to Jaxer very easily:

which would then populate a grid control and render it accordingly.

The source code to this new functionality can be downloaded here.

Dougal Matthews has been playing with Aptana Cloud in a beta form. He wrote up this piece that walks you through the functionality with screenshots:

After creating a project it then is automatically available in the cloud options.

When you click on the project under the cloud menu you are taken through a (very easy to use) wizard for configuration. This runs your through a few steps, setting up a site name, picking a payment plan (the beta is free), payment details and so on. Most of these screens are fairly standard, however the service selection is quite interesting. I imagine these prices are not final, so just take them with a pinch of salt.

The payment scheme seems to be quite flexible and we can see a large number of services that are included, PHP being the main server side language at the moment, with Aptana Jaxer still being a beta… (Ruby of Rails is on the ‘coming soon’ list). The prices range from the cheapest being 256 MB ram and 5 GB hard disc for $0.99 a day, up to 2 GB of ram and 25 GB hard disc for $8.22 a day. Seems fairly reasonably priced.

After set-up is finished, it phones home and does some magic.

This is an important step for Aptana, as it not only gives us a good general cloud service, but it also gives you the perfect place to play with Jaxer. I am looking forward to seeing more.

Aptana have announced their cloud platform initiative, Aptana Cloud.

Aptana Cloud plugs right into your IDE to provide instant deployment, smart synchronization, and seamless migration as you scale. Aptana Cloud is ideal for developers who use scripting languages to create Ajax, Facebook, mySpace and all other sorts of Web applications.

The key is that this isn't a infrastructure play, which they clearly point out:

Aptana Cloud is architected to complement Cloud infrastructure providers like Amazon, Google, Joyent and others. To get started we've selected Joyent who serves up some of the largest of all Facebook apps.

This shows that their platform is designed to go meta, allowing you to deploy to various clouds in the future.

I think that the number one meme from Web 2.0 Expo last week was the "cloud", coming off of the excitement of Google App Engine. With Aptana Cloud we will see sophisticated tools to make us productive in the cloud. I am very excited to see that it won't be too long until developers will be able to build an application, hit DEPLOY, and be done. This is a huge win.

For developers:

• IDE plug-in integrates Cloud development, deployment and management life-cycles right into Aptana Studio in either its standalone or Eclipse based editions
• Instant deployment of projects to Cloud
• One click sync your project to the Cloud, or provide fine grained sync control too
• Integrated service management consoles
• Configure desired memory size and disk size
• Develop and instantly preview remote files right inside your Studio desktop environment
• Subversion source control.

As Ajax developers, the vision of Jaxer in the cloud is very interesting too. The entire application using JavaScript, and deployed up into the cloud, all through the nice IDE.

I was also pleased to read that not only Ruby on Rails, but Python is on the docket. After developing Django applications and playing with Google App Engine, I would love to be able to use Studio for Python code too. Not that Emacs (X or GNU) isn't great, Steve!

Darryl Taft wrote:

Aptana adds extra value via IDE integration, deployment automation and active monitoring and notification services, Hakman said. “It's like the ease and simplicity between iTunes on your desktop and its connectivity to services on the Web,” he said.

For developers, the IDE plug-in integrates cloud development, deployment and management lifecycles right into Aptana Studio in either its standalone or Eclipse-based editions, Hakman said. "The ability to deploy stuff to the cloud from Eclipse is part of this as well."

Other developer features include instant deployment of projects to the cloud; one click can sync your project to the cloud or provide fine-grained sync control; the technology features integrated cloud services management, enables users to provision their cloud right from Aptana Studio, configure desired memory size and disk size, develop and instantly preview remote files right inside the Studio desktop environment, and includes Subversion Source Control.

Can't wait go get an invite. If you want one too, request an account.

Also, Aptana Studio just passed 1,5 million downloads. Impressive.

The article describes a polling application that features:

• Using jQuery server-side to manipulate a DOM before it's sent to the client
• Doing some database / SQL interactions, server-side in javascript of course
• User sessions in javascript (Jaxer.session.set('status', status);)
• Using E4X on the server-side.

There are fun little features such as nuking portions of the page if the permissions call for it:

Since the application delivers no JavaScript itself, this would all work even if the user has JavaScript turned off, on a simple mobile phone, etc.

The Jaxer folks have posted on Easy File Uploading using Aptana Jaxer which shows how you can tinker in JavaScript to get everything you need in a very simple way:

To receive the data from the form when submitted we put some Jaxer code into the page the form will be submitted to. The code below should be in script block with a runat = 'server' attribute, which makes the code run serverside and doesn't present it to the client so you don't expose any serverside filenames or folder structures.

RadRails 1.0 runs as a plug-in to Aptana Studio. So in addition to all the Ruby on Rails IDE goodies and the integrated Rails shell command-line console, developers get the great HTML, CSS, DOM, JavaScript and Ajax features in Aptana Studio, which can run stand alone or within Eclipse to that all your other Eclipse tools can be right there as well.

The new version has a slew of new and enhanced functionality such as:

• Rails 2.0 support
• JRuby support
• Bundled auto-installing gems for rails development
• A Ruby profiler for Pro users
• An RDoc preview view
• Extended RHTML/ERb color preferences
• Code completion for ActiveRecord model fields and finders
• Code completion suggesting method call arguments
• Significant expansion of code warnings and analysis, including syntax changes from Ruby 1.8 to 1.9
• An improved look and feel

You can watch a screencast of the product at work or a full feature list.

Aptana continues to add new functionality to its products as it tries to hit the "best tools for Web development with scripting languages" vision.

Today we have Kriz Zyp talking about their Jaxer support and how you can use the Django template language, that Dojo recently added, to once again do its thing on the server side.

Kris tells us more:

Once this is done, Dojo should load in Jaxer, and you can utilize the library capabilities of the Dojo Toolkit on the server side. In particular, you can now use the DTL renderer as you would on the browser. The DTL renderer can take templates written using Django template language and render the templates based upon JSON data. If you are running Jaxer, you can view a demonstration of DTL rendering on the server by loading /dojox/dtl/demos/demo_Templated_Jaxer.html (make sure the Dojo Toolkit base URL is correct).

By using Jaxer’s capability to allow scripts to execute on both the client and server, we can utilize our Dojo Toolkit in both environments. On the server we can utilize many of the Dojo Toolkit’s features such as functional language features, math libraries, cryptography, dates, encoding, and more to improve development speed and code quality. We can use the same powerful features and idioms in both the browser and the server. An example of a practical way to use the Dojo Toolkit in both environments is to utilize the DTL renderer as described above to generate HTML on the server, and then use the Dojo Toolkit’s Ajax capabilities to dynamically update the page once it’s on the browser. For example: we could use the DTL renderer to display the comments in a blog, dynamically add any new comment the user makes at the end of the list of comments, and then send the comment to the server using Ajax.

It is important to note that Jaxer is not capable of transferring the programatically set event handlers for widgets—it can only send the static HTML to the browser. This means you can use DTL as a templating engine to create HTML on the server, but the Dojo Toolkit client side widgets are still necessary if you want to use interactive widgets on the browser.