I haven't looked at the Eclipse offering that much, since right now it strikes
me as a less mature GWT clone with fewer features and more baggage. I can see
why they went that way - javascript, especially if you want it to run cross
browser, can be a nasty, hateful thing. And I would assume that like everyone
else, they have light experience going in so they avoid things that can hurt
them right off the bat. So it appears as though in some cases they have moved
the processing to the server side to avoid having to deal with the performance
implications of client side operations. Which do exist. If you check out the
mature frameworks such as Ext or YUI (can't speak for Dojo on this one, but I
believe it would hold true), you get the option to do it as either client OR
server. Your call depending on the quantity/complexity of the data. I'm not
much on state replication server side( also known as 'the portal way' or 'the
jsf protocol') - it kind of negates some of the attraction of the RIA model,
IMO.
I really like RIA's. A lot. Flat HTML interfaces always seemed to be a step
backwards from the client server apps of the 90's. Just prettier versions of
the old green screens. Tried applets for a while, doing pretty much what is
getting done now - using http to send data back and forth. But there were
always a lot of issues with updates to the client base, jdk versions and the
like. So when this whole RIA/Ajax thing hit, I kind of went, "Wow, at last!"
But there was some trouble in paradise. You've still got a lot of browser
based inconsistencies both in display or the language implementations. These
things focus heavily on styles and dynamic object creation, so the differences
can cause some issues. I've been getting bitten by that stuff for the last 6
weeks or so. Toolkits make it a little easier, so you don't have to learn so
much javascript, but all toolkits aren't created equal. A lot of people like
prototype/scriptaculous, but that combo extends Array and Object, and so you
see a lot of issues with conflicts when you mix and match. Mochi doesn't do
that, but they do muck with the global namespace. Dojo, YUI, Ext, and JQuery
are better in this regard and all have their points, but with each you give up
something to get the things they offer. So there isn't really a silver bullet,
unfortunately.
And none of the documentation for them keeps up with the features -Dojo's the
worst offender here, but there's always a lag.
I kind of like Flex. I evaluated it starting out the project I was on. But it
was kind of in between versions 2 and 3, and there was some uncertainty as to
the IDE features and pricing for release(and that's a big deal where I am,
can't code without some sort of wysiwyg ui, right?). But FlexBuilder is a nice
tool, and the fact that the runtime is so ubiquitous means you can kind of get
the benefits of the JRE without a lot of the Sun baggage. The main
reservations I have are that when you get a drag and drop tool like that, a lot
of places tend to go out and build things that aren't terribly well thought
out, since you can just throw things together quickly and get them running. So
you get a badly performing and/or hard to maintain mess that no one will want
to take the time to go back and fix.
GWT? Well, it makes sense to some degree. They hire the javascript experts
and you just stay in java. But they kind of have the same issue as the Eclipse
toolkit in that it can be tough to integrate with widgets you have already
(although Ext is pretty proactive in this regard if you are OK with the
licensing) and they haven't seemed to have kept up real well in this regard.
New release should be out soon, so I guess we'll see. I haven't had a chance
to check out the trunk and see what's currently up.
But this stuff is like the glut of client server apps written in VB and
PowerBuilder circa '92. Ya gotta go in with eyes open, 'cause you know that no
matter how careful you are there's gonna be some hurt down the line when people
actually start using the stuff you built. And a new browser release breaks
everything you just spent 6 months developing. Or somebody adds a feature or
set of users and everything slows down the proverbial crawl. And you have
absolutely no clue why. And it's a certainty have half the stuff that's around
now will be gone, purchased, or morph into something else in another year or
two. Probably not for the faint of heart. And don't even get me started on
the issues when you combine it with my own personal pet peeve, portals.
I think I would still stick with one of the better toolkits (Dojo, JQuery, Ext,
or YUI). Be careful on licensing with Ext if you are building a toolkit
yourself. Maybe GWT. I think it's going to be a while before the Eclipse guys
have something industrial strength. If you are serious about building a Web
2.0 poster child I think I would suck it up, figure on the need to learn some
serious javascript, and settle down for the long haul.
gn
---- "Kulkarni wrote:
> Hi All,
>
>
>
> Does anyone have any experience using or investigating the new Eclipse
> Rich Ajax Platform - RAP (http://www.eclipse.org/rap/)? This seems to be
> a new offering from the Eclipse community that extends the Eclipse
> component/plugin architecture & the Rich Client Platform [RCP] client
> development model to "web" applications. It is a server centric
> application - the J2EE web container holds UI & context state for every
> user by instantiating & maintaining the Eclipse plugins and
> user-specific objects as long as the user's web session is active. Does
> anyone have experience exploring this?
>
>
>
> At first it seems an exciting development model with code-reuse &
> skill-reuse opportunities (especially, if you want to port an existing
> RCP application to the web), but there could be scalability &
> performance issues because of runtime model and the dependency on
> server-side processing. For example, table sorting will need to happen
> on the server as the client is a pure visual element tree with almost no
> processing/logic, except what is required for immediate UI display - so
> every user gesture would most likely need server trip for getting
> updates and/or syncing the client-server state. Seems to go in the
> opposite direction of RIAs/GWT etc., that want to bring more and more
> power on the client side.
>
>
>
> What do you guys think? Is it a viable model, even for "enterprise"
> applications?
>
>
>
> Thanks,
>
> Sarang Kulkarni
>
>
>
|