Monday, October 15, 2007

Ajax Needs Eclipse Like A Hole in the Head

Infoworld recently announced a new Ajax tool for Eclipse, called , RAP. While this is a logical step forward for the Eclipse community, it is an evolutionary dead-end from a Web 2.0 viewpoint.

The goal of enterprise Web 2.0 is to democratize the development of web applications by lowering the learning curve. Enhancing Eclipse does nothing to solve the fundamental skills gap between the Java "high priests" and the traditional application developers who are skilled in visual tools like Access and PowerBuilder.

Eclipse is the heavyweight champion of the heads-down Java server programming world. Ajax is the lightweight champion of the rich internet client world. These are clearly different tasks, so presumably would benefit from using different tools. Other than masochism, why would someone decide to saw logs with a hammer?

Given the cost and difficulty of hiring Java developers, putting them into the UI design role is a waste of resources. In addition, the skills that make a developer good at server programming do not necessarily translate into web page layout skills.

At ActiveGrid, our goal is to enable application developers to assemble web applications visually without needing deep technical skills in Java, Javascript, css, etc. This vision requires two components:
  1. Studio for lightweight page assembly: Web 2.0 application developers need a visual and lightweight tool for assembling web pages - they need a DreamWeaver for Ajax.

  2. Java server framework for seamless services integration: the web pages created by a Web 2.0 application developer should integrate seamlessly with a standard Java back end using something Json/Spring/Hibernate server.
While Ajax for Eclipse represents an incremental step forward, it is not at all clear that this is the best way to build Ajax clients. We are betting that the right tools for building Web 2.0 applications will unlock a wave of developer productivity within the enterprise equivalent to what simple blogging tools have done for web publishing.

6 comments:

ckeene said...

I ranted a bit more on this topic here at WebGuild and here at Ajaxian

ckeene said...

You take on a sacred cow, you're likely to get the attention of a few cowboys. My piece drew a rant from this Eclipse-bigot. The priceless quote from him was "Chris Keene doesn't understand get Eclipse, and therefore I don't think he gets Ajax either." Ajax is a good plug-in for Eclipse, but Ajax doesn't need a heavy-weight IDE to succeed, it needs a lightweight tool!

Peter said...

I'm curious, what's your definition of lightweight? DreamWeaver?

Eclipse cowboys there may be, but I don't get the aggressive anti-Eclipse take, either. In fact, to use the blog model, what I think people find appealing about Eclipse is its open, community-based, extensible nature, which is exactly what attracts some of us to platforms like WordPress. Don't get me wrong: Eclipse, WordPress, doesn't matter, all of these are imperfect tools and none is the right solution to everything. But to me, Eclipse is part of the puzzle as far as exactly what you describe. And "visual" and "lightweight" are two different things ... Eclipse might not satisfy those two principles, but neither do some of your examples.

ronan said...

I think their is a gap in the thin client space that will be filled by the likes of RAP, Java2JavaScript, or GWT that is being overlooked by the purest on the Web 2.0 side. Not all Java development is server sided development. A good portion is purely for desktop tools. I'm currently in a situation where my company has a mixture of mostly desktop (Java Swing, SWT, .NET) tools and a dabble of thin client tools (Isomorphic, Dojo) across numerous teams. We are looking to standardize on a platform and had presumed we would have to have a platform for thick tools and a different platform for thin tools. To me the ability to define a GUI tool that will have the potential of a substantial shared code base that has a deployment pattern for both thick and thin clients makes huge sense from the viewpoint of established OO build and test practices. I understand that it might not be true client side AJAX and that it may be slower than an app written by Web2.0 gurus. However my gut tells me that the potential development savings in time and resources of bringing GUI tools to market will win the day for us and other companies looking for thick and thin tools who's primary development is thick client.

I see a potential deployment pattern where an administrator installs a thin client app on a server and informs all their intranet users of the product. The users start using the thin client tool and some decide that they are using it so much that they click the web-installer of the desktop version because they are more accustomed to working this way. This satisfies both sets of users while reducing the admin headache.

ckeene said...

@Ronan, I think there is a very good use case for a Java-driven client like GWT, RAP or SWT.

My focus is on users coming from the visual tool world (Notes, PowerBuilder, Access, VB) for whom Java/Eclipse is too heavyweight.

Our hope at ActiveGrid is to provide a visual platform for building web apps, while making sure that the generated apps meet IT requirements (e.g., run in Java server, etc).

The exciting thing about Ajax is that it opens the door to rich visual tooling that will be both familiar and attractive to developers coming from the visual tool world.

Anonymous said...

For anyone who has invested much in the Java technology utiliies like RAP, GWT, Java2Script and similar technologies are enabling them to put their client-side work in the browser.

My opinion is: HTML + CSS + JavaScript + AJAX might be very nice user experience on the web BUT technologically worst of the worst (you can read opinion of the JavaScript creator about the language and you will see it was never ment to be used in such extent).

So: if we have such advanced technology like Java is, and because users and Microsoft don't want Java to be used on clients why not convert Java into JavaScript and both are happy: developers because of best technology and user because of user experience.

Slowly AJAX will enable everything what can be implemented on client. And then: AJAX and Client side apps will merge - AJAX will provide everything a standalone clint can provide today.

Of course: developers will be still free to choose pure HTML+JavaScript programming and put some simple apps on the web.

But for large scale app development I don't recommend pure HRML+CSS+JavaScript. I would call this a COMPLETE MESS. But I agree: there may be a talented programmer to write only in HTML+CSS+JavaScript and make a perfect structured, extensible app. But there are not so many of these developers... most of them are writing in Java...