Thursday, November 19, 2009

Web Technologies on a Desktop Application - Portability Do Matter

What's the desktop application most commonly used? For a great majority of persons the answer is simple: the browser. The omnipresent browser has begun not to be perceived as an application anymore: instead, it's the container where web applications run.




Although there's still plenty of space for desktop applications,
they can't be thought as stand-alone any longer. Users continuously
rely on Internet as a source of information and desktop applications had to learn to use Internet as if it were a database.




Browsers and web developers probably learnt that before: Web
Services and the AJAX paradigm being just the last trends in the
industry. Vendors have been implementing similar technologies in their
SDKs and the boundary between web-technologies and general purpose
framework gets thinner day by day.



I just remember when JAX-* specifications were being integrated into
Java2 Enterprise Edition: nowadays you can hardly think of a Java
desktop application not leveraging JAX-WS or JAX-RS.




Many vendors have being trying to port web technologies on the desktop and the major players in this are are:


  • Adobe, with Adobe AIR
  • Sun Microsystems with JavaFX framework
  • Google, with Google Gears




I've being intensively using Gears-powered applications just because
I'm a faithful Google applications user. I must say that I'm pretty
happy with it and that in this sense Google is probably making one step
more in this direction with its Google Chrome OS. Nowadays, although
Google Chrome still is a browser, it really acts as an environment for Google Gears applications.




As far as it concerns JavaFX, I've played a little with it with my
NetBeans and I must say that I'm impressed. Java SE and Java EE already
have all of the pieces you need to build rich internet applications and
JavaFX goes one step further: it's a platform that aims to support a
variety of devices (browsers, mobile phones, gaming consoles and so
forth).



Adobe AIR is impressive: although I never wrote any line of of code, I've seen some applications and, just as anything-Adobe, great hype is given to integration with Flex/Flash applications.




Which one should I go with?



Although every framework has got its own peculiar advantages, such a
decision depends on many factors, such as your needs and your
requirements.



One of the fundamental advantages of web applications is their
platform-independence (usually). Yes, there are many glitches depending
on the browser you're using but nowadays the situation is pretty
satisfactory, at least as far as it concerns an application
functionality. Such an independence is achieved by means of the
browser, which is the container in which such an application is
executed. Taking an application out of the browser is complex and in
that process you run the risk of reducing an application's portability.
That's the original sin of many frameworks, such as Adobe AIR.




I strongly believe in portability and that's something I'm
never going to sacrifice easily and when I do the requirement must be
compelling. That's why I always go with Java.



Let alone enterprise-level technologies supported by Java Enterprise Edition, Java gives you the basic tools you need such as:


  • A powerful programming language.
  • Support for Web Services (JAX-RPC and JAX-WS).
  • Support for RESTful Web Services (JAX-RS)
  • Support for AJAX.
  • Integration with databases (JDBC, JPA)




The Java language itself has been recently enhanced by annotations
which are commonly used by specifications and frameworks (such as
Spring) to greatly reduce boilerplate code. EJB 3.0, JPA, JAX-RS,
JavaBeans Validation (JSR-303) are just examples of the
annotation-centric APIs you can use in a Java program just by applying
metadata to your class and letting the framework (or the container) do
the job. POJO-based and annotation based frameworks and APIs greatly
contributed to simplify the programming models previously used: whether
you're developing a web service, a web service client, an interaction
with a DB, an EJB, you're probably producing just POJOs. Reusing such
objects is straightforward: the boundary that existed between the
various kind of Java applications have blurred and nowadays is almost
null.



Moreover, in the incredibly vast ecosystem of Java libraries and
frameworks you're probably going to find everything you need to get the
job done.




Conclusion



When deciding the tools you're going to use to develop your next
application, always consider that there's someone out there who might
not be using your browser or your OS. If you haven't got compelling
reasons, don't shut the door in their face. Users do not understand, sometimes not even with reasons. And they'd just turn to another provider.


No comments: