We are excited to announce that Kevin Hakman has joined Aptana to head up marketing and developer community programs. Kevin is a recognized leader in the Ajax community. Long before the term “Ajax” was coined, Kevin was pioneering single page web application concepts via the company he co-founded, General Interface Corp., one of the first enterprise Ajax libraries and visual development tools companies. General Interface Corp. went on to be acquired by TIBCO Software in 2004 as a compliment the company’s service-oriented architecture (SOA) products. Today TIBCO General Interface is used by many Fortune-scale companies for rapid Web application development and deployment atop their XML and SOAP data sources.

In addition to his historic role on the steering committee of the OpenAjax Alliance, Kevin currently chairs the organization’s integrated development environment working group. The OpenAjax Alliance IDE Working Group which includes Adobe, Aptana, the Eclipse Foundation, IBM, Microsoft, Sun, TIBCO and others is now close to delivering a draft specification for a uniform way to describe Ajax libraries and controls and thus streamline the ability to use Ajax libraries within your development tools of choice. Kevin is a frequent speaker at Ajax industry events and is an author to many published articles on Ajax in the enterprise.

I asked Kevin a couple of questions about his move, comparisons between the companies, and the industry in general.

What similarities / differences do you see between pioneering heavy JavaScript on the client w/ GI and JavaScript on the server with Aptana

GI and Aptana’s primary application models are different to serve different purposes similar to the way that Java has multiple presentation tier architectures for differents kinds of apps: Swing, SWT, AWT for application GUIs and JSP, JSF for generating web pages. With GI, the concept in 2001 when we deployed some of the first “Ajax” apps pretty much evolved from a need to migrate software-style GUIs to the Web and a technical approach summarized as “we like Java Swing, but not the JRE dependency, so let’s do something Swing-like in JavaScript with a JavaScript VM of sorts and get data as XML / SOAP via the XML HTTP Request Object — an oh yeah, make it Visual Basic-like easy to visually develop too”. That led to what I call a “Client-Services” architecture where you have a full fledged JavaScript application running in a web page talking to back-end data services plus the WYSIWYG rapid development tools for which GI has been recognized as best in class in enterprise IT journals. With GI, you never really interact with the HTML page or its DOM. Instead there’s a higher abstraction of application concepts and a model of the GUI, called “dual DOM” by some. The result is that the JavaScript applications are deployed into a webpage more like an applet, (except it’s all in the same JavaScript memory space and there’s no JRE dependency of course). This “Client-Services” architecture has been a great fit for many enterprises pursuing service-oriented architecture strategies.

Aptana Studio is clearly among the best-in class for the predominant model of Ajax development called “single DOM” where you work directly in the HTML DOM to describe elements within a page, then apply Ajax and CSS concepts to bring that page to life with interactive features. Aptana Studio meets the needs of Ajax developers working in this model extremely well. Whereas tools for web page development have historically focused on layout, image placement, styling, and JavaScript for roll-over and simple navigational assists, Aptana saw that with Ajax and the popularity of all the single-DOM model Ajax libraries like dojo, Ext, prototype, MooTools, and jQuery, the page was becoming increasingly programmatic in the client and needed tooling optimized for the programmatic page.

What excites you about Aptana

Aptana Jaxer is a very cool concept for all the JavaScript developers out there because they can now go boldly where no JavaScript developer has gone before–to the server-side. Sure Netscape had LiveWire back in the day, but remember there was no real DOM, no real CSS and certainly no XHR object at that time. Aptana Jaxer’s genius is that is takes the same Mozilla engine we know and love in the browser, and puts it inside a server along with a bunch of handy Jaxer methods and properties to do server-side things like interact with databases, web services, session concepts, sockets and more. I personally love the ability to write a script that runs on the server, but call it from the client as if it were running on the client. In this case Jaxer handles all the sync or async communications for you transparently, and soon will provide end-to-end debug capabilities as well. We’re also now working with Joe Walker of the DWR project to extend this kind of capability to remote Java objects as well through Jaxer. We’re also investigating how to best interoperate with Microsoftâ€™s .NET platform.

To some, JavaScript is not a preferred language and that’s where things like GWT and DWR come in real handy. At the same time there’s millions of developers who like the ease and mutability of JavaScript. Aptana Studio, with its JavaScript debug and type inference capabilities, and Aptana Jaxer with its server-side power enable all JavaScript developers to do much more, more quickly in the language we love to work with — JavaScript! Thinking beyond the solid JavaScript programming tools in Aptana Studio today, things like visual WYSIWYG GUI composition and data-binding are clearly natural extensions. Not many people know that the Aptana team contributed to much of the Eclipse Monkey code which enables JavaScript to run within and communicate with Eclipse’s APIs. This means that Aptana is extraordinarily well positioned to execute a first-class solution for WYSIWYG editing — and further streamline the creation of Ajax web pages and full-featured Ajax applications.

Now you have been around JavaScript for awhile, what are you likes and dislikes, and do you have any thoughts on JavaScript 2?

Having been part of Ajax projects where we had single HTML pages running for 9 hours sessions with over 180 separate application modules you could load/unload during that time (and that was in 2001), the GI core team (Luke Birdeau, Michel Peachey, Jessee Costello Good, and myself) has had loads of experience in what it means to make highly scalable, full featured apps in JavaScript. Much of what we had to invent and implement in JS1.5 for the TIBCO GI Framework, things like object orientation for example and better memory management, is on the horizon for future releases of JavaScript. The primary pain of JS though, until recently, has been lack of great debugging, type inference, and code assist capabilities. What few people realize about Aptana Studio is that it not only code assists on the Ajax libraries you’ve loaded, it assist with the Ajax objects, classes, packages, functions and properties that you create too — again a concept borrowed from the Java community, but with less programmatic overhead since its JavaScript.

I posted that comment – I knew something was up.
Kevin Hackman is one of the pioneers of Ajax, and I look forward to what he will do with Aptana. However, I worry what will happen to Tibco’s GI now that the orignal author has left the company.
I also have been watching Paul Colton for a while – he was behind Xamlon when he was investigating XAML – I guess the work has now transformed to Aptana.
Aptana is now the company to watch!

I’m really excited about Aptana’s vision. The great products are a direct result of the great team Paul and Uri have built. And there’s lots more innovation to come. (And without the Sarbanes-Oxley restrictions hanging over me, we can actually talk about our roadmap! So be sure to stay tuned!)

Also–speaking of great teams, (and to clarify) GI was created by a team — not me as the “original author”. There have been many contributors, but the core most have really been Luke Birdeau and Michael Peachey who were there on day one in 2001 when we sat down at the whiteboard and in the more recent years Jesse Costello Good who added lots of great stuff to Luke’s insightful foundations and helped refine and optimize the concepts further (and did the bulk of the work to get GI running in Safari too). The source says it all @ http://gi.tibco.com.

I’ve recently enlisted Aptana Studio to help me kick my Dreamweaver habit. Glad to see more people helping out.

Comment by igaenssley — February 27, 2008

…i downloaded the Aptana IDE awhile ago on my Windows machine at work (i like TextMate on my Mac)…. haven’t delved deeply into it, but seems to be where i’m leaning when it comes to Windows… now that I hear this exciting news, I am leaning further that way. Thanks for the info Kevin, Dion, et al

This post has really got me interested in Jaxer. A ‘single DOM’ on both client and server without framework code abstraction or language translation? Awesome.
.
Before I put my heart into it, can you guys please let us know:
a) how it degrades on clients with limited or no JS functionality? and…
b) how does it (or how do you expect it to) scale?
…and then put those in the FAQ, please.
.
Doing some web development and working with Opera Mini, which runs a full-fledged Opera 9.85 on the server (so I’m told) has been impressive. It’s amazing how it captures click & mouseover events and translates them into selectable links, among other things. So, I think Jaxer should scale and degrade well, if Opera Mini is any example… or am I way off base? Please say I’m not!

a) Since Jaxer is primarily a server-side technology, it actually can solve many problems for developers that want to target browsers with *no* JavaScript support at all — how is that for degradation? For example, if you detect there’s no client-side JS you could do whatever is needed in server-side JS and send the results to the client. Of course you then have no client-side event handling, and really no callbacks, as you might expect. If JavaScript is available on the client, the client-side part of the Jaxer framework is very small, and is really only used/needed for callbacks.

b) This one deserves at least an FAQ entry but really more of a detailed study and use-cases. We’re working on that now. The scaling story is a lot better than having to mirror all of the browser-user interactions on the server, as in your Opera Mini analogy. Jaxer simply processes the page before it’s served to the browser, then leaves the browser to do its thing without mirroring anything, and only needs to worry about function callbacks. There is no need for, and no resources invested in, maintaining a synchronization between the client and server DOMs, user events, etc.

@Uri: I’ve been really busy, and just noticed your response. I really appreciate you addressing these issues for me — that was just what I wanted to hear, and in detail. Hopefully I will have the time away from sales soon to set up my LAMP box with Jaxer and slice my dev time in half!