[Tfug] Browser based UI's

[keith smith]

A browser based application only makes sense if you have to deploy the non browser based equivalent to many machines. 

If you are talking strictly local host I would write the application in something else and save yourself the headaches. 

------------------------
Keith Smith


--- On Thu, 7/16/09, Bexley Hall <bexley401 at yahoo.com> wrote:

> From: Bexley Hall <bexley401 at yahoo.com>
> Subject: Re: [Tfug] Browser based UI's
> To: "Tucson Free Unix Group" <tfug at tfug.org>
> Date: Thursday, July 16, 2009, 7:38 PM
> 
> 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?)
> 
> 
> 
>       
> 
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>