Archive Page 2

10
Jan
07

Flex vs. Ajax Revisited

This is a topic I’ve been delving into for some time (Flex or AJAX :: A Quick Litmus Test), as I’ve had the pleasure to implement production solutions with both Flex and Ajax; while I’m a diehard proponent of Flex, I gotta give Ajax some respect for bringing RIAs to the masses — that simple little acronym unknowingly brought me more RIA (again, both Flex / Flash and Ajax) work than my team can even handle!
…and so it seems it’s time for another round of the Flex vs. Ajax debate, with Forrester taking a stab this time: Ajax Or Flex?: How To Select RIA Technologies. Or, you can read Ryan Stewart’s and / or Yakov Fain’s quick summary of it…and if you’re too lazy to click to those, you can take away this extremely short version of it all: Flex is one, robust library / framework backed by Adobe, whereas Ajax usually includes choosing a framework (usually a tedious, iin-depth process within itself…trust me…dojo still does it for me though, as it proves to offer the most extensive library at least backed by some of the major players) and a development toolset backed by many or no one of consequence — I nabbed from Ryan’s summary of the report because it also hit home with me:

Choosing a commercial Ajax solution means adopting a proprietary framework and development tools. In this light, commercial Ajax vendors look more like Adobe than like open source Ajax tool kits.”

I’m also still a fan of pushing the Flash Platform over Ajax with it’s Unified Cross Browser / Platform User Experience:
  • One virtual machine means one rendering engine means one code base and one set of coding standards.
  • Ajax / DHTML applications are subject to each browser’s implementation of the DOM and often require developers to provide workarounds for each variation thereof; this inherently creates additional, unnecessary code and ultimately adds to the development timeline. Large Ajax applications with rich user experience = large development effort.
  • While many Ajax / DHTML toolkits exist to facilitate this shortcoming by abstracting browser inconsistencies, they’re often extremely large in file size, immature, lack standards and documentation and ultimately fall short of a complete solution.
Followed by, What’s Your Application Platform?
  • The Flash Platform provides a true application platform as a virtual machine that’s browser / platform independent, including a JIT compiler and strong typing.
  • The very intention for the Flash Player was to provide a container to perform operations like rendering complex animations and filter thousands of data sets at the same time, thus providing a desktop-like experience with comparable performance on the internet.
  • AJAX applications leverage the browser as the application platform something it was never intended to be used for. The browser is nothing more than a text-based rendering engine, and was never conceived as a container for client-side applications.
  • The performance implications of running a complex Ajax application are subject to the browser’s ability to interpret JavaScript and determine the type at runtime is it a string, a number, an object? whereas ActionScript 3 (AS3) eliminates type look-up because its strongly typed and compiled into bytecode rendered by the Flash Player VM this facilitates better responsiveness in your application.
And the Development Models
  • The Flex workflow and programming model follow a more traditional approach familiar to application developers. Flex applications are implemented using a combination of declarative tags (MXML) for the user interface / presentation and a scripting language (ActionScript) for complex business / application logic.
    • MXML is an XML based, declarative language that’s similar to HTML and is used for layout.
    • ActionScript is a strongly typed, classed based OO language analogous to Java, but with the flexibility of a scripting language.
  • While the MXML and AS aren’t native to most traditional app developers, the development paradigm is a similar model to that of JSP and Java development, making it an easy transition for seasoned developers.
  • Flex Builder offers a professional IDE based on Eclipse, with the usual myriad of tools an application developer expects.
    • Debugging is built on top of the Eclipse Debugging Framework and provides common tools like setting breakpoints and watching variables
  • While Ajax is the mesh of several, common client-side technologies, overcoming the browser compatibility issues often requires expert knowledge of each browsers interpretation of the DOM, and usually leads to hack-like workarounds. Even if you’re using an Ajax / DHTML toolkit, you’re still subject to the pains of cross browser issues.
  • Ajax often entangles both HTML and JavaScript to create rich user interfaces where the end result is a tightly coupled client application that’s often difficult to maintain and extend.
So then there’s the final question of openness…Ajax (and it’s encompassing technologies are all open)..what about Flex? This was a question that stumped me for some time…I used to just say, open, what are going to do with it even if the Flash Player is open? …and then I saw read this: How truly open is Flash? Do we need “Open Flash”?
At the end of the day, I’m still going to arm myself with Flex as the weapon of choice in the RIA war. Perhaps the release of Apollo and other desktop-like browser apps will be the tell-tale.
12
Sep
06

Dear AJAX…with love, Flex

So I continue to be asked Flex or AJAX…AJAX or Flex…here’s a list of why Flex is a better solution for enterprise level applications…not brochure-ware sites or small RIA widgets added to a site, but a full-blown RIA…feel free to agree, disagree, or fill in what’s missing.
  • The Flash Platform provides a true application platform as a virtual machine that’s browser / platform independent, including a JIT compiler and strong typing. AJAX applications are subject to browser inconsistencies and leverage the browser as the application platform, something it was never intended to be used for. The performance implications of running a complex AJAX application are subject to the browsers ability to interpret JS and determine the type at runtime — is it a string, a number, an object? — whereas ActionScript 3 (AS) eliminates type look-up because it’s strongly typed and compiled into bytecode rendered by the Flash Player VM — this facilitates better responsiveness in your application.In addition to the performance benefits is the Flash Platform’s browser / platform independence — you want your application to look and act a certain way and code it once, then go with Flex (or even Flash for that matter) — if you’re into writing several different versions JS / CSS in order to achieve this, then you want AJAX. Until browser’s start to follow standards, the closed, Flash Platform is the only answer for consistent UIs and actions on multiple platforms and browsers.
  • FDS (Flex Data Services) provides the ability to perform data push from the server in the form of pub / sub messaging; there’s a Java adapter that allows Flex clients to subscribe to JMS topics and additional adapters can be written to subscribe to legacy / other messaging systems. In addition, FDS provides data synchronization, an API that abstracts the action of capturing all the data deltas on the client and persisting them to the server, thus enabling developers to focus more on the application and business logic. FDS allows provides data paging for large data sets and handles temporary disconnects transparently to the developer.A direct implementation of push simply isn’t possible in an AJAX application, but can be simulated by forcing the client application to poll the server every <n> seconds — however, this increases network traffic and puts additional strain on the application server. While I forgot to mention that a form of push is possible for ajax with Comet, Alessandro Alinone pointed me to another server-side component called Lightstreamer:

    …Lightstreamer Server is a general push server (designed for maximum scalability), that can be used to deliver real-time data *both* to Ajax/Comet clients and Flash/Flex clients. For example, there are some banks that have chosen to rely on a single push server (Lightstreamer) to stream data at the same time to: AJAX clients, Flex clients and .NET clients. Currently the integration between Lightstreamer and Flash/Flex is performed through a JavaScript gateway. You can see a demo here. But soon a native Flash/Flex integration library will be released too.

  • AJAX typically requires some type of data transformation in the middle layer and client side, adding an unnecessary performance overhead on both sides of the wire, eg:
    1. Client makes an asynchronous HTTP request for data
    2. Request is mapped to a servlet / JSP that uses JDBC to query your database
    3. Data is transformed into an XML doc (or JSON) and sent as an HTTP response (transformation 1)
    4. Client receives the XML and must parse it into useable data (transformation 2)
    Flex can make calls directly to the back-end by invoking methods on Java objects, like POJOs or EJBs. These objects are transparently serialized and deserialized by the FDS application, mapping your client-side ActionScript objects to your back-end Java VOs, DTOs, or whatever other pattern(s) your architecture enlists; the developer is just left to expose the java objects to the flex client via a couple thin lines of xml in remoting-config.xml. For example:
    <destination id="myBizDelegate">
        <properties>
            <source>myWebApp.myBizDelegate</source>
            <scope>application</scope>
        </properties>
    </destination>
    where myWebApp is the package for the Java object myBizDelegate.java. In addition, you can tell FDS you specifically want to map an AS object to a Java object in your ActionScript object with the following meta data in myVO.as:
    [RemoteClass(alias="myWebApp.myVO")]
    In this case, my Flex client is directly invoking methods on my Java biz delegate myBizDelegate and returns a Java value object myVO, which is now deserialized into the ActionScript object, myVO.
  • Flex provides an elegant and familiar programming model with MXML as the declarative presentation layer and ActionScript as the application / business logic in a true class-based, strongly typed programming language with a similar feel to Java — this makes Flex development an easy transition for traditional enterprise developers who are familiar with (for example) JSP / Java development. AJAX is a mesh of several client side technologies: CSS, DHTML, and manipulation of the DOM with JavaScript, and requires extensive, expert knowledge of each. There are some DHTML / AJAX toolkits that attempt at abstracting the details of AJAX development, but most are still in their infancy and haven’t been proven in production environments or follow standards, and often lack documentation.
  • The Flex Framework provides a rich, robust, and extensible set of UI components that facilitate rapid UI development with MXML, the declarative presentation layer. Furthermore, MXML is simply an abstraction to ActionScript (MXML is compiled to it’s complimentary AS objects under the covers — it’s analogous to what JSTL is for Java), enabling developers to create complex, custom components with a blend of MXML and AS. The following illustrates how the same end result can be accomplished with MXML or AS:MXML:
    <mx:TabNavigator width="200" height="200">
        <mx:Vbox title="Tab 0" />
        <mx:Vbox title="Tab 1" />
    </mx:TabNavigator>

    ActionScript:

    // create a tab widget and set properties on it
    var tabNavigator:TabNavigator = new TabNavigator();
    tabNavigator.width = 200;
    tabNavigator.height = 200;
    
    // create first child container
    var a:Vbox = new VBox();
    a.label = "Tab 0";
    
    // create second child container
    var b:Vbox = new VBox();
    b.label = "Tab 1";
    
    // add containers to tab widget
    tabNavigator.addChild(a);
    tabNavigator.addChild(b);

    This flexibility not only provides a certain degree of elegance, but also offers the unique ability to write complex components entirely in AS and then actually implement them through a simple MXML tag. It’s extremely powerful.

  • Flex Builder 2 provides a powerful and extensible IDE built on top of Eclipse. Developers can can expect the same debugging tools as the Java flavor of Eclipse, as Flex Builder’s debugging suite leverages the Eclipse debugging framework — inspect variables, watches and breakpoints — you can even configure the IDE to enable full end to end debugging of your Flex to Java to Flex application, etc. AJAX IDEs are starting to pop up as Eclipse plugins as well, but are in their infancy and still don’t offer the same level of debugging and standard tools a typical application developer expects.
  • Standards and best practices for Flex exist in the form of client-side microarchitectures, a unit testing framework, core AS3 libraries, and a documentation generator similar to JavaDoc:
    1. Cairngorm
    2. ARP
    3. FlexUnit
    4. AS3 Libraries
    5. ASDoc
    6. FAB (Flex AJAX Bridge)

    At current, best practices, standards, and additional developer tools are a major drawback to using AJAX as an enterprise level solution, as again, it’s still in it’s infancy.

  • One final point — with Flex and FDS, you’re not pigeon holed into a solution — if needed, Flex and FDS integrate nicely with AJAX via a the FAB. This is typically used when creating mashups with existing applications but also allows developers to create components from either solution and still make them communicate.
Like I said when I started this post, feel free to add, subtract, rip, agree, etc…
After writing this, I found two additional posts with similar thoughts:
22
Aug
06

Flex or AJAX :: A Quick Litmus Test

NOTE: This post in no way attempts to provide an exact science for selecting Flex or Ajax as your presentation layer and is by no means the end all — it simply provides a couple quick points I often use as a litmus test. For a more detailed discussion, read my earlier post “Dear AJAX…with love, Flex
So without further adieu, let me start with this blanket statement — I’ve come to think that each RIA technology really does have a niche.
If you’re looking to spruce up a relatively static (HTML based) site with a small bit of “richness” without introducing another layer, plugin, etc, then AJAX is a good way to go; eg, you wanna add the ability to rollOver a shopping cart in the header of an app and show it’s contents — this doesn’t sound like a job for Flex — not that you couldn’t, but is it really necessary to require users to download 180k just for a small piece of functionality; AJAX’s relatively unobtrusive nature makes it a good choice for small upgrades or small new features in the UX.
On the other hand, you wanna build a large, complex enterprise level app with multiple business processes over several states, requiring data entry that leverages a myriad of business logic on the back-end, like an entire shopping experience, then hell yes Flex is the way to go!
Finally, if your application needs to support a long laundry list of nonfunctional requirements (ie, you need to support Firefox, IE, Netscape, Opera, Mozilla, Safari, etc on Win, Mac, and Linux), then wisely choose the independent Flash Platform as your runtime — employing the non-standards compliant browser as your application’s runtime / vm just doesn’t cut it.
My bottom line — use each technology for the right problem domain:

Ajax

  • An unobtrusive solution for adding minor rich features and functions and / or updating small bits of text-based data in a static, HTML site.
  • Examples:
    • Adding a roll over effect to a shopping cart and showing the user’s current items in a floating DIV tag by making an Ajax call.
    • Updating the description for a photo in an online album without forcing a page refresh.

Flex

  • Ideal for large, complex enterprise level applications that include multiple states and performs data manipulation on non-trivial / complex data objects on the client side via a rich and robust user interface.
  • Examples:
    • Taking a multi-page / step shopping experience and redesigning it into an accordion interface with a CSR collaboration component that offers audio and video chat all contained within one seamless application without page refreshes.
    • Creating an online email application with all the functionality of it’s desktop brother.
…and for everything that falls in between, use your functional and non-functional requirements to lead you to the right solution.
Again, this is just a couple quick points. If you’re looking for some additional bullets, check out my aforementioned post “Dear AJAX…with love, Flex
07
Jun
06

AJAX Development Is Painful

AJAX, AJAX, AJAX…that’s all I hear these days…I’m pretty sure even my mother could provide some semblance of a definition by spouting off XML, JavaScript, and some asynchro-ish like word…so my question is this…with all the hype, has anyone really tried to develop a large AJAX app? I have, and I think I’d rather stick pencils in my eyes…ok, that’s pretty harsh, so please allow me to go off on a somewhat related tangent to better explain my frustrations…they are twofold.
AJAX is really about leveraging XML over HTTP to transport small bits of data from the server to the client without invoking a page refresh; this facilitates better user experiences as the web is transformed from an information platform to an application platform. This is a good thing and I fully support it. My first beef with AJAX (or what most people are confusing to be AJAX) is DHTML.
AJAX by itself gets us the Application part of the acronym RIA, and only half way there…in order to truly be an RIA, we need a Rich UI that delivers more desktop-like applications with drag and drop, data filtering and visualization, etc, and we’re forced to revert back to DHTML. I say revert, because I feel it is a bit backwards. The problem with DHTML is the cross browser, cross platform inconsistencies — sure, there’s some AJAX frameworks (I like to call them DHTML frameworks b/c only about 10% of the framework actually handles the XML over HTTP stuff, while the other 90% is comprised of DHTML widgets) that abstract some of the browser issues to the developer, but not all…have you ever tried to create a seamless DHTML user experience across multiple browsers on multiple OSs??? It’s straight up not fun…

So as we start to use the web as an application platform and deliver more desktop-like applications with drag and drop, data filtering and visualization, we revert back to DHTML. I say revert, because it’s almost backwards.

Even with the aid of dojo, ATK for Eclipse, and my previous knowledge base / experiences in RIA development from Flex and Flash, I still think it sucks. While ATK does provide a couple tools to like debugging and code hinting, it’s analogous to developing in something like Fischer Price’s “My First AJAX IDE.” I love Eclipse, but the whole development paradigm for AJAX needs vast improvements.

My words may seem harsh (and perhaps there’s a bit too much emotion oozing out), but I guess that’s because I’ve had the luxury of developing in Flex and the pains of trying to create a seamless cross-browser experience with Ajax.