Re: [Gmod-ajax] AJAX GBrowse poster feedback from RECOMB

[Seth C. <sjc...@lb...>]

On Mon, 2007-04-23 at 13:28 -0700, Ian Holmes wrote:
> > learned if there's a good reason for it.  But why not Java applets?
> > The only two reasons we came up with are (1) long load time, and (2)
> > need to install Java, but that's not hard...
> 
> Interesting. I'd like to know what others think of this.

I can think of a few!

I've done stuff before with Java applets as web 2.0 type thingys, and my
recollection is that it was very nasty. One still vivid nasty part is
that there was no good way to have the Java applet and JavaScript
communicate with each other, thereby trapping what you're doing on one
side or the other. There were classes and objects to get around this,
but the implementations were buggy and platform dependent (LiveConnect,
etc.).

Another big ding against applets was presentation/layout issues. For
example, font resizing and layout won't work with the rest of the
browser, making styles very hard to use and control. Also, printing just
gave me some truncation and looked pretty bad when I tried it with an
applet from Sun's Java site (the spreadsheet applet) and cut-and-paste
didn't work at all. Scraping data would also be impossible.

It's hard to just stick with the tangibles: things were very...fiddly.
It may have all changed since I last did this years ago, but doing a
cursory google search right now it looks to be in more or less the same
state as I remember. 

It's hard to have the browser as a platform when it's actually Java.

-Seth


> My answer to this question would be "of course we will welcome your Java 
> code contributions", delivered with a polite grin.
> 
> In all seriousness, I think we already have an emerging dream of a 
> language-agnostic message bus, certainly on the the server side.
> 
> I've been asked about standalone clients before. Google Earth often 
> comes up in these discussions. Sticking with the analogy, I usually 
> point out that (A) Google Maps came first and (B) the two applications 
> are designed to be compatible, but they occupy distinct niches in the 
> ecosystem.
> 
> One can argue language merits endlessly. Java has clear advantages.
> 
> Still, there ARE good reasons for scripting the web browser, rather than 
> budding off an applet, mainly to do with the interface. "Long load time" 
> and "no plugin" are part of it, but there are a whole lot of subtle 
> issues that go along with this: look & feel, web-browser integration, 
> compatibility with other components.
> 
> When language discussions go negative it's all over, but having said 
> that, if you DO get backed up against a wall and need a good reason 
> AGAINST Java, go and take a look at some of the Java genome browsers out 
> there. They just don't feel as light on their feet. I'm sure their 
> codebase is more stable, but they're not as fun.
> 
> I definitely DON'T want to block Java-heads from hitching a ride on our 
> message bus, so we probably need to avoid using JSON or other 
> Javascript-only tricks, and keep casual eye on compatibility. But I 
> don't want to switch to Java ;)


> > Related to this, I got many questions/suggestions that we
> > should shift layout/rendering to the client side completely.  There
> > were quite a few people in favor of that idea and seem to think even
> > JavaScript can do what we need.
> 
> I am gradually being persuaded that this is practical. Mitch has been 
> trying to get me on board his boatload of divs for some time now. I 
> realize it makes mashups easier too.

I think this is part of the