[Tfug] Browser based UI's

[Bexley Hall]

Hi Tom,

--- On Tue, 7/14/09, Tom Rini <trini at kernel.crashing.org> wrote:

> > >   have you tried GWT?
> >  
> > But that's part of the issue.  What's the point of a browser
> > based interface if you have to rewrite all your applications in 
> > Java?  I.e., to me, the beauty of a browser interface would
> > be that it could represent a "dumb client" and leave all the
> > smarts server side.  If you're going to deliver the application
> > to the client (instead of just the *interface*), then why not just
> > build a VM that runs on bare iron and code directly in that
> > (and skip talking to http://localhost).
> 
> Well, there are some nice things about having something
> inbetween the application and the bare iron.

Yeah, it's called an operating system!  :>

> But part of the answer as to how a
> mostly browser machine would work is that with some
> commodity parts (x86) Java or C# or whatever is fast
> enough, and with other parts (some
> ARM cores) there is HW assist for VMs, along with some
> tricks to speed things up (Android for example spawns apps 
> by forking a mostly
> initialized VM, to save some cycles).  Oh, and of
> course you can have
> the interpreter be tuned for the CPU and if things are
> design well, it'll end up pretty fast.  And the porting 
> effort isn't put on the application developer, but the
> system developers.

This last point is the most germane (IMO).

As to the others, how does "standardizing" on Java under
a browser differ from <anyspecificlanguage> under
<anyspecificAPI>?  IMO, its only real appeal is that you 
can deploy (distribute) applications at run time in a
hardware/OS neutral environment.

Note the wildly successful (ha) Krups/MrCoffee.  I.e., Java
by itself is a flop.  Take the web away and it offers
very little to the developer or the user.  (E.g., an
application written in C on a Krups vintage SPARC will
outperform a Java application on Krups...)
 
> But from the other point of view, the beauty of Java is
> that it's going
> to work for everyone.  And having a browser that meets
> some set of
> standards might fix the J2ME issue of a consistent but not
> elegant UI.

I try to be really "light handed" in how I phrase my questions
soas not to lead answers in any particular direction.  I think
the web analogy taints this discussion.  I had hoped my
http://localhost/kde example would be the model folks would
expound upon.  (i.e., cut the internet cord.  Now, does a
browser based application make ANY sense?)