• Post Reply Bookmark Topic Watch Topic
  • New Topic

Future of the Desktop App.

 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stemmed from a thread I started here I thought a good conversation piece would be:
What is the future of the Desktop App in the Business world? Seems everyone is running down the Web App trail and not looking back for obvious reasons.
1. Easy to maintain with updates, patches, etc.
2. No installation required on client PC
3. Better access via WWW
The list could go on. So what are your thoughts?
P.S. I realize that Applets and JWS solve some of these issues, but let's keep them out of the equation for the simple fact that if you are comparing the future all desktop apps, not just JAVA, MS doesn't really have a technology comparable to Applets and JWS.
 
Matt Wilcko
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think Desktop vs. Web Apps is going to be similiar to how people thought the web was(or is) going to replace printed magazines and newspapers. I think the answer is that the web is another option and works great for some apps but not for others. I wish Sun would make a native compiler for each of the os's they develop the VM for.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wish Sun would make a native compiler for each of the os's they develop the VM for.
Just out of curiosity, how do you find this relivent to my question? Even if a SWING app ran as an EXE, it would still run the same. There would be no performance gain. Therefor, it cannot determine the future of the desktop app. If you hadn't noticed, all the .NET languages are interrpreted now. Just like java.
 
Matt Wilcko
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Native Compiled apps run faster. Have you tried Excelsior JET?
I just stated this because in developing desktop apps, I believe deployment is much easier if you did not have to use the VM.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Matt Wilcko:
Native Compiled apps run faster. Have you tried Excelsior JET?
I just stated this because in developing desktop apps, I believe deployment is much easier if you did not have to use the VM.

I don't agree with any of the above.
Modern JIT Compilers execute Java Byte code just as fast, and in some cases faster, than native apps execute.
However, others that share your misinformation can attribute to the decline in Java on the Desktop. Because I know that many people share your views, specifically in my organization, therefor they don't like Java. Oddly enough they are all about .NET which as I said before is a VM. Strange.
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since we're talking about GUI applications, I don't think JET (or any other Java to native compiler) is going to make much difference. If you look on the JET Myths and Facts page they state that an ahead of time compile is not the best choice for all programs. They also state that ahead of time compilation will not significantly speed up a program where most time is taken up by native methods. A lot of processing in GUI applications is taken up by native methods to render the GUIs. They also state in the system requirements that if you use AWT or Swing the user must have a JVM matching the version you developed the program under (I'm guessing so it can find the appropriate system library) and if you use SWT you still have to package the appropriate SWT system library with your application.

I'm also betting that your application is going to be a bigger download as a pre-compiled to native Java application than as one JAR file. Every program is going to have to include a natively compiled version of whatever classes they use from other APIs and whatever native code provides the JVM-like functionality.

I also wonder at the actual difference in speed between an ahead of time compile and an on-the-fly compile from a JIT compiler. Both are actually producing native code... the ahead of time compile might speed up some of the initial loading and deciding to compile stuff, but once something is running, I don't think there would be much of a difference. This would also depend on the version/manufacturer of the JVM... some of them do better jobs of optimizing stuff, JIT compiling, etc. so simply doing an ahead of time compile isn't the only speed issue.

Anyway, since the original topic was the future of the desktop application vs. web applications, I'll try to get back on topic. I think that the web is where the future is... or whatever the "web" is going to be in the future. There are some cases where "stand alone" desktop apps are good enough. There are some cases where an application can provide enough functionality through generating an HTML interface. And then there are cases where both don't quite work out. Most business stuff is probably great for doing through generated HTML because most of it is just based on forms, calculations, etc. that were done through paper before the web was around. But once you add the web, there may be better ways of doing stuff than they were done when the forms, etc. were being used. Most businesses don't adapt to this point well and you end up with a digital version of a paper form with the workflow the same, just sped up because you don't have to mail the paper form. The real benefits come from places where companies realize the workflow can completely change because of what the computer or the network allows them to do.

Anyway, I think that if you mean "desktop" applications as "standalone" versus "networked" applications, then yes, they are mostly dead except for very special cases where all the data needed is on the users machine. (Which is getting less and less common now.) If you mean "desktop" applications as "GUI client" versus "web client" then they are smaller (because a lot of stuff that could be done with a web client used to be done with GUIs) but they are not dead because there are useful things you can provide through a GUI client that you can't get through simple HTML. Some examples are context sensitive help for users or cases where you want to see a wide variety of information on the screen at the same time.

The big question is how much work has to be done on the client for an application to be considered a "desktop" app, and how much work has to be done across the network for it to be considered a "web" app?

Where *do* technolgies like applets, JWS, Flash, ActiveX, etc. fit in? What if instead of launching as a plugin in the browser, you had a small custom launcher that provided the same sort of functionality... What about technologies like Mozilla's XUL or LUXOR that generate a GUI from XML... What if the source of the XML came from a remote source? What if the application consisted of several different user's "desktop" applications communicating through a P2P protocol?

Sorry for this post reaching monstrous proportions, but I think you need to narrow your question, Gregg... unless the point was to provoke discussion such as this.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!