For many Ajax developers, who are already doing great things with JavaScript, HTML, and CSS on the browser, the prospects of doing everything that way, even on the server side, is very appealing.

But Java, PHP, Ruby, and other server-side platforms have tremendous established bases, strong developer communities, and powerful tools to make them compelling environments for back-end development. And indeed the vast majority of modern web applications use one of these platforms for their back-end layer.

The front-end of all these applications is almost invariably HTML, JavaScript, and CSS, because that's the common denominator of the browsers users use to access these applications. So Ajax technologies are almost inevitable — the only question is where is the boundary between Ajax technologies and the back-end platform. Usually, the answer is the internet: Ajax runs on the browser, the back-end runs on the server, and something serves as the presentation layer to bridge them. What is that something? We think it makes a lot of sense for that something to be Ajax itself: that way, the entire presentation layer can be in one paradigm, and it can interface cleanly to the back-end layer through established APIs architected for logical information flow across layers and not for public internet security or user-interface concerns.

Jaxer extends Ajax to the server to allow a single paradigm for the entire presentation layer, and furthermore makes client-to-server calling trivial, so the presentation layer can focus on the user interaction and not on low-level communications between browser and server. Jaxer already supports interfacing with back-end platforms via web service calls, and will soon offer native connectivity too.