InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Bruce Eckel: Use Flex as the UI for Java Applications

Posted by Rob Thornton on Jan 31, 2007

Sections
Development
Topics
Java ,
Rich Client / Desktop ,
Rich Internet Apps
Tags
Flex ,
Flash ,
Adobe

Bruce Eckel has written about the future of user interfaces in Java. He reviews the state of Rich Internet Applications (RIAs) and states that while Ajax helps, a language designed for user interfaces and rich media is what we need. He proposes that we stop trying to use one language (Java) to solve all of our problems , and instead use Flex and Apollo as a front-end for systems written in Java (or JRuby, Groovy, Scala, etc).

Eckel writes that programming for the web is not working, because current RIAs do not "work well". Developing with the combination of HTML, CSS, and Javascript is expensive and hard to make cross-platform. He points out that one of the biggest gains from the Ajax trend is that the toolkits that have surfaced abstract away the cross-platform problems. However, Ajax is not enough. Eckel states that Ajax is reaching its limit:

We do see relatively amazing Ajax-based tools like GMail and the other Google tools which are slowly seducing me (but I repeat: it took Google to create those, not Joe garage-programmer). Very nice, but is this the best you ever want to see on the web? You're seeing, if not the limit, then very close to it in those applications, and even then they don't work consistently.

Eckel says that one of the reasons Ajax has become popular is that it solves the installation problem. Java started on the internet with Applets but failed, among other reasons, because installing the JRE was so difficult. While Javascript has its own problems, it is already installed. Further complicating GUI development in Java is the lack of good media support. In the end, Eckel says GUI applications in Java is too hard.

It's not impossible to build GUI applications with Java, but it's been 10 years and there are still installation hiccups with applets, Java WebStart, and regular applications. After 10 years, people don't trust it anymore. If it's not there after 10 years, then I'm going to go out on a limb and say that someone doesn't consider this problem important enough to fix.

Eckel proposes Flash, and Flex in particular, as a UI library for Java, both for RIAs and for desktop applications. Installation is trivial, high quality UIs are easier to develop than in Java, Flex is no longer expensive, and Flex was created as a DSL for user interfaces. In the end, Eckel says marrying Flex with Java might be the best way to deliver cross-platform applications with high quality UIs:

You don't insist on using a Java database for an application; you use a specialized system like MySQL or Oracle. Sun is directly supporting the development of JRuby for hybrid Java/JRuby programming. We are seeing other special-purpose languages arise to solve specialized problems. Why insist on using a Java library for UI if a specialized system solves the problem better?

Paul Brown responds that he thinks Flex might be a step in the right direction but the problem to focus on is graceful degradation to HTML. With the growth rate of new mobile devices and platforms to view the web, the ability to get back to the common denominator is necessary.

Eokyere agrees with Eckel and hopes that the open source community will get involved with Flex, perhaps in working on an open source alternative to Flex Data Services.

16 comments

Watch Thread Reply

Pricing by Corby Page Posted
Re: Pricing by Stefan Tilkov Posted
Re: HTML UI + Javascript/Ajax is an excellent solution for 80% use-case by Cyril Gambis Posted
Re: Pricing by James Ward Posted
Re: Pricing by Raghu Madabusi Posted
Re: Pricing by Stewart Robertson Posted
Re: Pricing by James Ward Posted
Re: Pricing by Stewart Robertson Posted
Why would I want to lock into a proprietary solution? by Marc Stock Posted
Re: Why would I want to lock into a proprietary solution? by Corba The Geek Posted
consultant in search of a subject by Joost de Vries Posted
Re: consultant in search of a subject by James Ward Posted
Why not... by david m Posted
Flex for UI as an option to AJAX UI library by claude hussenet Posted
Thick clients can do more than the GUI ... by Ashley Aitken Posted
OpenLaszlo is the way to go! by Sébastien Arbogast Posted
  1. Back to top

    Pricing

    by Corby Page

    Flex is no longer expensive


    I'd like to verify that we are no longer looking at $10,000 per server deployments, but it's pretty hard to.

    Asking a Flex advocate about pricing always degrades into a bunch of hemming and hawing and 'free for development' and 'cheap for most uses'.

    I look at the Licensing and Pricing section of Adobe's Flex FAQ. There are no numbers, except for the phone number to talk to sales.

    Even if the dollars are now reasonable, I now know that I have a new third party Licensing/Sales Consulting bureacracy that has to be managed for deployments in any reasonable-sized enterprise.

    I've been consulting for too long to go down this road. I'll be sticking to something a bit more open for core UI infrastructure.

  2. Back to top

    Re: Pricing

    by Stefan Tilkov

    IMHO, the necessity for "rich" UIs is vastly overrated. A well-designed HTML UI that uses Javascript/Ajax only as an additional option (i.e., degrades gracefully) is an excellent solution for the 80% use-case.

  3. Back to top

    Re: Pricing

    by James Ward

    Hi Corby,

    Here are the exact pricing details for the whole Flex product line:
    www.adobe.com/products/flex/productinfo/buy/

    Many companies have been very successful with Flex using only the free Flex SDK, which is free and doesn't have any hidden runtime fees. Free as in free. :)

    Hope that helps.

    -James

  4. Back to top

    Why would I want to lock into a proprietary solution?

    by Marc Stock

    Seriously, did everyone get the memo but Eckel that locking yourself into proprietary solutions when FOSS/open standards solutions exist is a bad plan? I am no open source bigot -- I buy more software tools than anyone I know but I just don't get the point of using Flex. I think Eckel has become obsessed with the "ease" of everything to the point of exclusion.

    Just because something is easier to do does not instantly make it better.

  5. Back to top

    consultant in search of a subject

    by Joost de Vries

    Ha, so Eckel has worn out Python as a subject so a new programming model is needed?

  6. Back to top

    Re: consultant in search of a subject

    by James Ward

    Haha. Actually Bruce and I recently recorded a screencast about using Python & Flex together:
    www.jamesward.org/wordpress/2007/01/10/bruce-ec...

  7. Back to top

    Why not...

    by david m

    MS Sparkle? I hear it will be better than Flash.

    Or VRML. It's had time to mature, and I hear there's a netscape plugin.

    Please, keep me away from web sites this person develops. HTML is a great thing, no matter how bad it gets.

  8. Back to top

    Re: Pricing

    by Raghu Madabusi

    How about Laszlo(www.openlaszlo.org), an open source platform for RIA. I have developed an application with Laszlo and it was quite impressive.

    Raghu

  9. Back to top

    Re: Why would I want to lock into a proprietary solution?

    by Corba The Geek

    There are open source alternatives to Flex that also use the "free, if proprietary" Flash plugin... Like OpenLaszlo. The main plus of "Flex" is the use of a commonly available, easily installed VM; i.e., Flash. If you're not willing to use proprietary development environments like Flex, you might be more interested in OS solutions like Laszlo (which have been around about as long as Flex). Check out www.openlaszlo.org.

  10. Back to top

    Flex for UI as an option to AJAX UI library

    by claude hussenet

    I have personally evaluated Flex 2 SDK, Flex 2 Builder(Flex eclipse pluggin) and Flex chart
    for an internal project.

    I was very impressed by the quality of the UI libraries,the extensive documentation (API, Reference manual,examples),a very active mailing list (too active :-) )
    an openness to AJAX/Javascript through a AJAX/FLEX-FLASH Bridge that for example Google is using
    for their finance chart

    After starting using Flex SDK is quite tough to go back to PROTOTYPE, SCRIPTACULOUS ,DWR, GWT, DOJO world.(Great js libraries or toolkits by the way)

    I believe that people should download the SDK with the trial version of the eclipse pluggin and test by themself that web development can be painless using tools such as a powerful debugger

    Regards

    Claude Hussenet

  11. Back to top

    Thick clients can do more than the GUI ...

    by Ashley Aitken

    One of the things that I believe this discussion misses (at least for some apps) is that a thick client can do more than just the GUI. For example, it can do client-side business processing (saving the results to the server at a later point) and off-line processing (in some circumstances).

    A big benefit from using the same programming langauge on the client as one uses on the server is that you can share various business libraries (or parts thereof) across the server and the client. This way we don't have the duplicate business logic like we have had in the past or with Flex on the client and Java on the server.

    Of course, some apps don't need this sort of client-side processing but some could benefit a lot from it.

    Cheers,
    Ashley.

    --
    Ashley Aitken
    Perth, Western Australia
    mrhatken at mac dot com

  12. Back to top

    OpenLaszlo is the way to go!

    by Sébastien Arbogast

    I definitely encourage you all to have a look at OpenLaszlo, especially the next version soon to be released, OL4, which has what no other RIA platform offers: multi-runtime support. In other words, you create all your UI with one common language (LZX) and it can be deployed with Flash (Flash 9 support is on its way) OR AJAX... or anything you want.
    And their documentation is great, honnestly they lack a few small things compared to Flex, but hey, it's Open!

  13. Back to top

    Re: Pricing

    by Stewart Robertson

    However from my understanding from looking at the flex site if you are ISV then you have to pay licensing fees for using flex even if it is just the SDK without Data Services. So hypothetically if I am Application Service Provider (ASP) making available a Basecamp (37 Signals) type application that uses flex then I need to pay licensing fees. Is that correct? Below is the quote from the flex page...

    For ISVs that develop software applications for sale that are built on or embed Flex, an Adobe ISV support plan and/or OEM license and redistribution agreement is required. Flexible licensing and value pricing options are available for Flex OEMs and ISVs.

  14. Back to top

    Re: Pricing

    by James Ward

    There are very few instances where someone needs to redistribute the Flex SDK. Anything you build with the SDK is not under any license restrictions. Just like the stuff you create with the JDK.

  15. Back to top

    Re: Pricing

    by Stewart Robertson

    Well that's good news. Thanks for the info.

  16. Back to top

    Re: HTML UI + Javascript/Ajax is an excellent solution for 80% use-case

    by Cyril Gambis

    IMHO, the necessity for "rich" UIs is vastly overrated. A well-designed HTML UI that uses Javascript/Ajax only as an additional option (i.e., degrades gracefully) is an excellent solution for the 80% use-case.


    We are speaking about the future of UI (Web or not).

    A monochromatic screen is an excellent solution for the 80% use-case too, but the additional possibilities of a color screen are very welcome for 100% of the applications.

    HTML+AJAX/Javascript is okay for current applications, but we are seeing the limits of these technologies. I totally agree with Bruce Eckel on that point.

    Another idea would be GWT direct support for Flash rendering; it would be possible since GWT compiles Java to HTML+Ajax/JS.
    And as the next version of OpenLaszlo, it would offer different rendering for different devices/platforms.

    But I totally agree with Bruce when he writes that Java as a technology to design GUI is not a very good solution.

    Cyril

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.