At the risk of starting another flame attractor, what would use suggest to
use for the desktop?

I have the need to build an application for doing some ecommerce work. Lots
of network interaction, but it needs database and reports.

I could build everything on a server where I have full control over the
database and access to the network data I need. I can create jobs for
updating information and so forth. For the face of the application I could
create an HTML5 app using all the html, javascript, ajax goodies and have a
nice application.

Or I could build an application that has to have a database included, some
kind of gui such as swing, and it runs without a server. It would be a
completely standalone application which the customers would like more.

I keep going both ways.

HTML5/Server - I can update the application and all users get the benefits
right away. No need to worry about database issues because I have full
access to the server 24/7. Changes to web-api's means I change things and
everything is working again. Installation is a breeze, and I can update the
user interface all the time as needed. Yes it is interpreted, but I'm not
creating a first-person-shooter game. I want reports, graphs, etc and all of
those are pretty straight forward in HTML5.

GUI/Embedded - The application would be standalone so no need to call home.
I don't have to run a server. The customer's data is their own. It would
have to be running all the time so that information can be downloaded from
the Internet on a schedule. The UI would be responsive, reports would look
fantastic, and there would be far fewer security issues because users are
not sharing a machine. The program is on their machine and I would have far
fewer issues in that respect.

Why way do I lean? Well, typically I would rather spend more effort on
building than on maintaining an application. It is easier to fix a problem
that I cause than one that a customer causes. If I have access to the
application, then I can get fixes out quickly. If there are problems with
data, I can clean it up. Hard to do that if the application is on some
machine somewhere and I don't have any visibility into the environment or
can see what is going on.

So I keep going back to the HTML5/Server option since it is easier to
develop, but more important, I can deal with customer issues much more
easily. I think developers sometimes worry too much about a technology and
forget that users are the reason for the existence of the software. You have
to keep them happy and be able to deal with problems quickly without
spending all your time and resources doing so.

I am very interested in what others may have to say about this. Perhaps I'm
missing some technology that would give me the best of both worlds? If so,
I'll have found my next research project.


On Thu, Oct 28, 2010 at 4:31 PM, ADRA <[email protected]> wrote:

> >  Sounds to me like a FAR nicer environment for
> > programming a GUI than swing, though not quite as nice as JavaFX.
>
> Really? I mean web UI's are fine and dandy for what they are, but what
> they aren't are easy to develop rich desktop applications. You can
> create a stupidly beautiful HTML5 UI that looks amazing, but how many
> people can write at that level, and how many of them are there? If you
> just want forms and images, fine, but when you want real desktop
> integration and feel a web page is not the way.
>
> Lets not even talk about the painful performance penalty of using
> interpreted Chrome/HTML/JavaScript/Java vs. Swing/Java
>
> I see this is clearly a technique for the Java UI ignorant who have no
> idea or interest in learning Swing. If you're lazy to learn something
> new or you want to write HTML/CSS/JavaScript/bindings without learning
> a better way of doing it, by all means write this blasphemy. The sad
> thing is that Swing really isn't that bad when you get used to it. Yes
> its verbose, and you always need to learn grid bag and its 600
> properties, but once you're off the training wheels, programming for
> it becomes very straight-forward.
>
> This just reminds me of the bug tracking 'web' app that one of my
> companies used. It was a giant set of ActiveX components that filled
> an IE window completely, and you couldn't use any of the browsers
> buttons, because what they were really doing was just wrapping their
> paradigm of development (Rich windows client development) and shoe-
> horned it into a 'web application'. If that wasn't bazaar enough for
> you, there was an installation for a rich application who's sole
> purpose was to display a window with the web page (hosting the ActiveX
> apps) within an MSHTML container... very depressing.
>
> > Close though. If you are assured you can use all the latest and
> > greatest HTML features because of a guaranteed updated webkit running
> > your webapp, programming in vanilla HTML+CSS+JavaScript is great. For
> > macs it could include a JVM :0
> Macs still couldn't release through the app store since they aren't
> allowed to self-update outside of the store itself (both in Webkit &
> in JVM unless you're using dynamic library linking maybe).
>
> you will also run into the problem of major/minor releases breaking
> some stupid little thing in your code that makes your application a
> steaming pile of useless. JNLP (love it or hate it) gives you the
> ability (as a dev) of choosing the specific JVM you want to use.
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>


-- 
Robert Casto
www.robertcasto.com

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to