Aside from my opinion, there are several technical problems with this implementation:
1) Speed. I think that’s obvious, but parsing the DOM and all that stuff for every single page requested, even if it has no JavaScript on it, is a huge performance hit.
2) Flexibility. Or lack of flexibility. You can’t really control things like HTML formatting with the DOM. I mean, that’s not too important, but for someone like me who likes their HTML clean and indented when they click View Source, it’s a bit irritating to see it formatted the Mozilla way. You can’t even make a template engine (well technically you can, but it would be slow as hell compared to the same one written in another language).
3) Limitations. There are currently some technical limitations as to how it can be set up. For example, you have to set it to parse every document in a specific directory. You can’t associate certain file extensions with Jaxer (or at least not that I know of), like you can with PHP and all the others.

All in all, I don’t think Jaxer is ready for use. Of course, it’s a newborn baby, and I can see it growing up in the future, but I don’t believe it is ready for a production environment yet.

Anyway ItsNat doesn’t need to create new persistence APIs etc because is Java, you can use the persistence framework (or any JavaEE part) you like more.

When netscape server-side javascript was hyped, it proved to be slow as… [anything slower than a snail, or a statue]

10 years passed and what do we hear?

Javascript is good for the client, where it only has one instance (per application)… for the server… not surely.

It’s good tt o maintain only one language, but straight javascript isn’t necessarily the way… I prefer larger applications in javascript, with a JSON server backend (in anything)

You can already do anything you want with PHP, ASP.NET, Ruby, C++ etc on the server side. You have no limitations. You have ultimate control over the HTML on the server.

Plus, Anything dynamic on the client still has to be done on the client, otherwise you end up with a postback, hence the entire reason for javascript and AJAX.

?

The fact that it can run in conjunction with Apache makes me excited. If they figure out how to get this to run side-by-side with other languages (like PHP) to leverage existing frameworks then I think this project could add to my career right out of the hopper. I would have the missing link for writing killer Ajax components on top of current applications.

@Dion: Thank you for the screencast.

Depends how you define ‘innovation’, we have used it for several years over at widgetplus.

@thomas. never been able to code the app i want in only gwt, always end up in javascript land somewhere, same for rails and scriptaculous.
but you are right about the impedance caused by crossing the language boundary from server to client.

Yes and we called it classic ASP using JScript :-) Before that Netscape Livewire, etc.

Actually this is a good idea and is no different in some ways than pushing Java everywhere as GWT does but without the translation. Since browser languages are somewhat non-moveable it does spell some trouble for server languages that have a mismatch with JS, like strong typed -> weak typed.

@nathany and @peter svennson, the Linux version just needs a bit more testing before we set it free, look for it very soon. We chose to bundle Apache even though OS X has it because we’d have had to ship multiple versions of mod_jaxer for various OS X platforms, and explain how to configure. Our aim was to ship a simple, self contained package you can just start up and go. We’ll be making those platform-specific mod_jaxer modules available soon for people who want to use their own Apache.

@Liming, we very much want to have you an dthe rest of the IIS community on board! We’ve already started working on the IIS adapter, and we’re thinking of how it should fit within various IIS flows (like the .asmx web service flow you mentioned). What are your thoughts?

@jigs and @Liming: runat=”server” (and “server-proxy and server-nocache”) indeed will disappear from the page before it’s sent to the client. The client will NEVER see that code unless you explicitly send it there, e.g. by making a script block or an individual function runat=”both” (or “both-…”, you get the idea) or “client”. Code you ask to run on both client and server will indeed be made available to both ;-).

And as for SQL Server, Oracle, and so many other integrations we’ve been dreaming about and are now starting to look at: we’re very much demand driven. Please come join us on our community forums, and let’s get the conversations going!

Took a look, their server side has application, session, request, response, page and all that, got the full stack there. Too bad, SQL server 2000/2005 and Oracle is not yet there. Somebody fund this company and get them to release these adapters!

API documentation is well done too. I wish though, they can write an adapter for IIS server to forward all .html request to Jaxer, or are the microsoft lovers like me not invited to the party?

With SQLite support suggested in HTML 5, with planned support in Firefox 3, as well as the Google Gears and Adobe AIR solutions, it looks like a good offline/online database wrapper is needed. If everything is JavaScript/HTML/CSS, the move between offline/online web could potentially be a lot smoother. Yay. This is exciting!