The Artima Developer Community
Sponsored Link

Weblogs Forum
The Real Lesson of Flex

25 replies on 2 pages. Most recent reply: Oct 24, 2008 6:03 AM by Rob Reynolds

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 25 replies on 2 pages [ 1 2 | » ]
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

The Real Lesson of Flex (View in Weblogs)
Posted: Mar 16, 2007 8:23 PM
Reply to this message Reply
Summary
In addition to being a rich-client development toolkit that targets the Flash virtual machine, an interesting aspect of Flex is that it relies on code-generation to reduce the amount of code a developer has to write by hand.
Advertisement

Inspired by some of the recent buzz about filthy rich clients, I decided to take a more thorough look at one of the more interesting rich-client technologies, Flex. Flex is a client development library, and while not open-source, the Flex SDK is available as a free download from Adobe. Flex applications are compiled into a bytecode format that runs inside a virtual machine that's part of Adobe's (formerly Macromedia's) Flash player. Thus, Flex applications come closest to the original vision of Java applets.

As a long-time Swing fan, I always thought that the applet model's promise was never fulfilled. Thus, I looked with envy at the VM-based Flash runtime, a feeling further exacerbated by some of the more snazzy Flex applications that incorporate multimedia in a way I had seldom seen in Java applets or applications.

Recent articles pointed out installation difficulty of the Java runtime as the main reason applets never took off as a popular rich-client medium. While a valid point, installation complexity alone doesn't explain the relative obscurity of applets. JRE installation became much easier since at last JDK 1.4, and while installing the JRE is certainly more involved than installing the latest Flash runtime, Sun has made great inroads into having the top PC vendors pre-install recent versions of the JRE. Although I was not able to obtain any market share numbers from Sun or from other sources, there are plenty of desktops well-equipped to run Java 5-compatible applets.

A more plausible reason for why few developers think of Java applets as an attractive rich-client technology has, I think, more to do with the fact that developing applets, and developing with Swing in particular, is very labor intensive: A lot of code needs to be written to affect basic tasks required of even modest Swing applications or applets. Those tasks go beyond drawing a user interface—most applications must access back-end data, for instance, manipulate data in some way, and provide the user with visual cues or capture input in ways that make sense in the context of an application's data.

To be sure, the Swing APIs to accomplish all that are there. And, indeed, stunning Swing applications have been built. But the price of benefiting from the latest Java client APIs is the need to write a lot of code by hand. I contend that a developer wanting to develop a non-trivial applet or Swing application has to write more code than a server-side UI framework would require for an application with similar features.

In comparison with Swing, Flex feels much like Ruby on Rails feels in comparison to J2EE (especially pre-J2EE 5). While recent server-side Java frameworks have been making great strides towards increased developer productivity, client-side frameworks, and Swing in particular, have been slow to follow suite.

Some months ago, Bill Venners noted in his blog post, Code Generation: The Real Lesson of Rails, that Rails' real lesson is that it makes extensive use of code generation in order to minimize the amount of code a developer has to write by hand. In some respects, Rails can be viewed as a domain-specific language for building Web applications. In a similar vein, Flex can be viewed as a domain-specific language for rich-client user interfaces.

While one can argue with the decisions Flex's designers followed in implementing a declarative user interface markup language in XML, and especially with the decision to rely on a mix of XML and ActionScript code as a way to customize user interfaces, at its core, Flex defines a language targeted at building client applications with minimal code. Once a user interface is defined in that DSL, the Flex compiler generates ActionScript code from the DSL markup, and then compiles that generated code into Flash bytecode in a second compilation phase.

To paraphrase Bill Venners' earlier blog post, the real lesson of Flex is just how potent code generation is as a tool to increase programmer productivity. A common client-side programming task, for instance, is binding user interface components to object properties (so that when a user types a string into a text box, an underlying data model's appropriate property changes to that newly entered text). While various Java frameworks exist to help with that task, and even a new JSR is in the works to address data binding, none of the proposed Java solutions are as simple for the developer as Flex's data binding. The reason is that Flex uses code generation from a DSL to implement data binding. A developer can simply mark a class, or properties of a class, as Bindable, and the Flex compiler's first pass will generate the voluminous boilerplate code needed to observe changes in that object or property.

Flex introduces code generation into higher-level user interface features as well, such as, for instance, the definition of various view states, data validation, and even network communication. The effect of those is that a feature-rich user interface can be constructed with minimal hand-written code.

To be sure, every DSL-based framework has its limitations and rough edges, and Flex is perhaps no exception. But if Swing can learn one thing from Flex, it is that domain-specific-languages can work well for user interfaces. And Flex is not the only user interface framework to prove that point: Chris Oliver's Form Follows Function (F3) is a promising attempt at an even higher-level UI DSL.

As I learn more about Flex, I will post more tidbits about its code-generation features. For now, though, what do you think of the role DSLs can play in user interfaces? If you had a concise way to define Swing UIs, would you be more likely to develop rich-client Java applications?


M Adair

Posts: 1
Nickname: madair
Registered: Mar, 2007

Re: The Real Lesson of Flex Posted: Mar 16, 2007 10:49 PM
Reply to this message Reply
I struggle to understand how this is a lesson from Flex or rails. C++ users have had code generation forever. All sorts of environments, particularly for GUI apps, use boilerplate blocked off code blocks. You could argue that Visual Basic was hiding a boat load of generated code. At one point it sounds like you may be referring to syntax sugar. But every language has that. Even with clarification, I doubt highly that there is anything interestingly new in how Flex does this, but please enlighten me. Even the rails model just made popular what plenty of coders were doing for a very long time, both through dynamic code, code generation, syntax sugar, and so forth. I wish this current spate of "everything old is new again" would abate. Blogs blogs blogs...*sigh*.

adrian milliner

Posts: 13
Nickname: goron
Registered: Feb, 2007

Re: The Real Lesson of Flex Posted: Mar 17, 2007 12:14 AM
Reply to this message Reply
I wish people would stop complaining of the current spate of "everything old is new again." People have been doing that for centuries.

:-)



Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: The Real Lesson of Flex Posted: Mar 17, 2007 6:44 AM
Reply to this message Reply
I find it so easy to lay out a web gui in html. Javascript event handlers are easy. There's hardly any thinking involved. I can do it in my sleep.

There's no reason why Java app(let)s shouldn't be just as simple. I don't understand the problems with XML as a layout language, which would make writing desktop apps as simple as web pages.

Why aren't they? Is there a fundamentally different mindset between web programmers and Java programmers?

Being able to layout my applets in XML, writing event handlers in Java, and accessing data on the server/local machine via datasource type interfaces sounds like my idea of heaven. Java is *so* powerful.. it beats Flex hands down on raw capability.. it's just sooooo complex to use when it comes to guis.

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 17, 2007 3:10 PM
Reply to this message Reply
What we need are tools to create our own XML DSLs. What would be better than a DSL for this? You write code in an XML DSL that transforms other XML into Java (or directly to Java byte codes for efficiency).

<define tag="button">
  <argument name="name" />
  <argument name="height" />
  <argument name="width" />
  <transform>
    Button ${name}Button = new Button();
    ${name}Button.setHeight(${height});
    ${name}Button.setWidth(${width});
  </tranform>
</define>


This defines a DSL that turns this:

<button name="save" height="20" width="100" />


into this:

Button saveButton = new Button();
saveButton.setHeight(20);
saveButton.setWidth(100);


This is a trivial example, but I think you can get the point.

Another thing that would be cool is building DSLs on top of other DSLs. For example:

<define tag="standardButton">
  <argument name="name" />
  <transform>
    <button name="${name}" height="20" width="200" />
  </transform>
</define>


We could define basic things like method calls in the DSL to keep things structured:

<define tag="call">
  <argument name="object" />
  <argument name="arguments" />
  <transform>
    ${object}.${method}(${arguments});
  </transform>
</define>


Imagine the possibilities: the code is structured, so the IDE can really "understand" it.

And this DSL will include looping constructs and if-elseif-else of course. We don't need Java at the bottom at all, because we can compile the code that results from this DSL directly to bytecodes. Zero code duplication because you can write a tag transform for all code that is duplicated.

The last thing we need is a better syntax for this DSL. XML is just too verbose for these things. Something like this would do:

<defineTransform button <name width height>
  ~<begin
     <var $name <new Button>>
     <$name setHeight $height>
     <$name setWidth $width>>>


Usage like this:

<button saveButton 100 20>


All these <'s and >'s may be a little scary, but remember: we only need one < and one > here, whereas we need two <'s and two >'s in to use a tag (+ closing tag) XML. XML may look less < and >'y because there is more other verbosity.

Also, an IDE for this can make editing this much easier because it understands the structure.

;)

Werner Schuster

Posts: 8
Nickname: murphee
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 17, 2007 7:35 PM
Reply to this message Reply
>
<button saveButton 100 20>

> All these <'s and >'s may be a little scary, but remember:
> we only need one < and one > here, whereas we need two <'s
> and two >'s in to use a tag (+ closing tag) XML. XML may
> look less < and >'y because there is more other
> verbosity.

Wow.... we really always come back to what LISP has been doing all along, haven't we...
Greenspun ( http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule ) has been right all along...

(For those who don't get it: replace the point brackets with parens and you have LISP code, which could be handled by a macro to generate the boiler plate; then consider that you'd use the same tools to write the LISP code, the LISP macro the GUI definition code,...).

PS: before anyone accuses me of being a smug LISP weenie (http://c2.com/cgi/wiki?SmugLispWeenie), I should mention that I have written less than 100 lines of code in LISP.
Another data==code language does it for me:
Mathematica http://www.wolfram.com/
And as it happens, Mathematica has the only sensible, Java based GUI definition DSL that exists:
http://www.wolfram.com/solutions/guikit/

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 18, 2007 2:22 AM
Reply to this message Reply
Shht

Faui Gerzigerk

Posts: 9
Nickname: fauig
Registered: May, 2006

Re: The Real Lesson of Flex Posted: Mar 18, 2007 3:17 AM
Reply to this message Reply
Alright, so here we go again. I agree with everyone here that Flex is nothing so new and that Lisp is great for DSLs and all. But I think the real lesson from all of this is that good ideas and principles are simply not enough. The real lesson from Flex is that you need to f******* execute on those ideas and you need to execute superbly! You cannot just throw a good idea into the market, like Sun did with applets, and then take 10 years to make it barely work.

And let's not talk so much about things being new. Everyone who was around in 1995 knows that there has not been any real progress in the UI space when it comes to interactive business apps. What the tools around Flex or JSF or Swing or Ajax frameworks do today is not so much different from what VB did almost 15 years ago. For business application UIs, the whole web thing was a giant detour and we're basically back to square one today. Let's not pat ourselves on the back for that.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: The Real Lesson of Flex Posted: Mar 18, 2007 2:14 PM
Reply to this message Reply
> Alright, so here we go again. I agree with everyone here
> that Flex is nothing so new and that Lisp is great for
> DSLs and all. But I think the real lesson from all of this
> is that good ideas and principles are simply not enough.
> The real lesson from Flex is that you need to f*******
> execute on those ideas and you need to execute superbly!
> You cannot just throw a good idea into the market, like
> Sun did with applets, and then take 10 years to make it
> barely work.

Yes, I agree that execution (or poor execution, rather) caused applets to wither, or at least to not really take off en masse. Maybe the Java browser edition will solve some of the VM installation-related problems, but I do think we need a programming model for rich-client Java that makes writing rich-client apps a more effective solution than what it is today in a business setting.

Now if I just worked on such a solution instead of whining about it...

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: The Real Lesson of Flex Posted: Mar 18, 2007 2:46 PM
Reply to this message Reply
> I struggle to understand how this is a lesson from Flex or
> rails. C++ users have had code generation forever. All
> sorts of environments, particularly for GUI apps, use
> boilerplate blocked off code blocks. You could argue that
> Visual Basic was hiding a boat load of generated code. At
> one point it sounds like you may be referring to syntax
> sugar. But every language has that. Even with
> clarification, I doubt highly that there is anything
> interestingly new in how Flex does this, but please
> enlighten me.

It is true that code generation is nothing new, and that GUI-generators create blocks of code. To me, at least, the lesson from Flex is that building feature-rich UIs should not have to take a lot of effort. Of course, that should not be surprising, since UI development is full of boiler-plate code, so it's possible to define a DSL that simplifies development.

The other lesson is that XML can work as a layout language - hardly a "lesson", since we've all been using HTML, and increasingly now XHTML, to lay out UIs. But this is perhaps the few occasions where I can see XML being the right solution.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Real Lesson of Flex Posted: Mar 19, 2007 3:30 AM
Reply to this message Reply
All that is needed is Java to adopt an S-expression approach using tuples. For example, expressing a GUI becomes very easy with the following syntax:

Dialog ui = new Dialog {
    text = "this is a dialog",
    new Button {
        text = "Hello world",
        click = () {ui.close();}
    }
};
ui.run();


The syntax <class name> { <tuple members> } where <tuple member> is <member name> = <expression> could be used for building lots of things, including web pages, UIs and database schemas. It can also be used as a generalized way to invoke a method with named parameters.

The syntax <class> <tuple> should create an instance of <class>, passing <tuple> to the class constructor.



Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: The Real Lesson of Flex Posted: Mar 19, 2007 3:42 AM
Reply to this message Reply
> Now if I just worked on such a solution instead of whining
> about it...

Yeah, all of us whiners think that from time to time. I think the point is that as individuals we're not really in a strong position to implement this kind of stuff, but we are in a position to state common sense from a user's perspective. That's pretty constructive in my eyes. There have been many efforts from other dedicated individuals to produce XML GUI generation for Java indicating the desire for it (Luxor, SwiXml, XAMJ,.. see http://java-source.net/open-source/xml-user-interface-toolkits), but at the end of the day it takes a player like Sun to put proper resources behind it to bring it to its full potential and give users the confidence to make it mainstream.

Dianne Marsh

Posts: 9
Nickname: dianne
Registered: Mar, 2007

Re: The Real Lesson of Flex Posted: Mar 19, 2007 7:19 AM
Reply to this message Reply
I was at the Java Posse Roundup in Crested Butte, CO March 5-9, and we had a session on "Does Java need an answer to Flex?". The group was very interested in the future of Java (and Java on the desktop), and the conversation was very interesting and full of energy. Earlier in the week, we had seen some really great Flex demos (James Ward, from Adobe was there and he brought some great stuff with him).

Josh Marinacci did a good job of describing some of the ideas people came up with for fixing applets on his blog at http://weblogs.java.net/blog/joshy/archive/2007/03/back_from_the_j.html.

Others felt like it made sense to partner with Adobe and lean heavily upon Flex for an engaging user interface, at least for now. But most everyone agreed that if we have to wait til Java 7 is released, THAT is a problem.

My strong opinion is that the Java community should put significant effort into Flex. Take advantage of what it can provide. The battle for the desktop is now. It's not going to wait til Java 7 or until problems with applets can be resolved. Use the tools that we have on hand or we will lose the desktop. If we want to fix Java at the same time, fine. But don't lose the desktop because of a mistaken assumption that the battle is with Adobe while WPF is breathing down our necks.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: The Real Lesson of Flex Posted: Mar 19, 2007 7:25 AM
Reply to this message Reply
> > Now if I just worked on such a solution instead of
> whining
> > about it...
>
> Yeah, all of us whiners think that from time to time. I
> think the point is that as individuals we're not really in
> a strong position to implement this kind of stuff, but we
> are in a position to state common sense from a user's
> perspective. That's pretty constructive in my eyes. There
> have been many efforts from other dedicated individuals to
> produce XML GUI generation for Java indicating the desire
> for it (Luxor, SwiXml, XAMJ,.. see
> http://java-source.net/open-source/xml-user-interface-toolk
> its), but at the end of the day it takes a player like Sun
> to put proper resources behind it to bring it to its full
> potential and give users the confidence to make it
> mainstream.

It's a good thing that projects like linux never went mainstream. Or perl. Or python. Or tcl. Or....

You get the idea.

Maybe Java is a special case, but if somebody came up with a decent mechanism for doing this that the community embrace, I don't see how you could stop it from getting Sun's blessing in the end, as long as it didn't screw with the language spec or implementation at all.

To me one of the great things about doing this for a living is that one or two people in a garage CAN implement this kind of stuff. There are so many examples of this sort of thing it is mind boggling to think that so many people have defeatist "the big corporation must back it" mentality.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Real Lesson of Flex Posted: Mar 19, 2007 8:39 PM
Reply to this message Reply
I I've learned anything over the 17 years or so I've been throwing code it is

1) Code generation is nearly always a bad idea
http://www.blackbagops.net/?p=68

2) Magic is dangerous.

So I see nothing in Flex that I find appealing.

Flat View: This topic has 25 replies on 2 pages [ 1  2 | » ]
Topic: Goodbye Artima Previous Topic   Next Topic Topic: My experience with the EeePC 901 so far

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use