The Thick-Client

Posted on November 30, 2008 by John Pencola

Recently I have been working on a project where 97% of the business logic resides on the “other side of the wall”. As a result, we do a lot of round-tripping as the user interacts with the interface and in the scenarios where we don’t, we’ve had to do a lot of pre-fetching before we can display anything to the user. All in all, this can appear to the user as a “click and wait” system. Some of the business logic that drove this approach was due to constantly updating and persisting user-state on the server. But looking back and thinking of how we could have refactored the approach brought to my attention the benefits of the thick-client and the different approaches that are available to developers.

One particular technology that has peaked my interest is the widespread adoption of Javascript. Most of this I believe can be attributed to the surge of Ajax implementations in the last few years. People are catching on, realizing the potential of Javascript and clinging to XHR as a silver-bullet. But more importantly to me is the benefits and alternatives that Javascript offers in the web stack to leverage a true thick-client approach, specifically when compared to Adobe Flash.

I’ve sporadically written Javascript over the years, using it where needed. In the last year and a half I’ve enjoyed working with the jQuery library, but I’ve spent most of my time focused on development in Flash (ActionScript) plug-in solutions.In Doing so, I have seen the benefits of implementing a good portion of business logic in the client and in some cases doing everything on the client. I’ve also noticed the downsides, but as I look at the rise of Javascript ( frameworks, libraries, server-side, etc. ) I was wondering what the current shortcomings of choosing either technology would be to implement a thick-client. On one hand you have a native scripting language that the browser can interpret and integrate with and on the other you have a plug-in that runs in the browser, but “seals” the user off from specifics of the browser ( read: rendering engine ). So what are the +/- for each approach?

Here are some of my thoughts, but as always I would appreciate any additional comments:

Downsides for Flash:

  • - Not tightly integrated with the browser ( DOM, etc. ). This comes at a cost, but it would be nice to work with the browser’s native features without having to use Javascript as a pass-through.
  • - Lives in a sandbox.
  • - Heavier – esp. when using the Flex framework. Adobe needs to open-source the VM!
  • - Version may be outdated on the client or the plug-in may be missing.
  • - Native support for full CSS and HTML rendering sucks.
  • - Needs to be compiled.

Downsides for Javascript:

  • - Implementation due to vendor differences is not consistent.
  • - Comparable visual effects ( ie: vector manipulation, animation, etc. ) need support of newer features (canvas) that only a very limited set of browsers support.
  • - It may be disabled on the client.
    (**Edit (2/27/2011): Duh, just realized that this is not unique when comparing to Flash)

I’m sure I have missed a lot, so please contribute to the list.

About John Pencola

Hello, my name is John Pencola. I can't get enough of exploring new technologies, discussing software principals, creating programs and having fun with interface design. I will share my experiences here and hope Liquid Language adds some useful information to the vast sea that is the web.
This entry was posted in ActionScript 3, Flex 3, JavaScript, Opinions and tagged , , , . Bookmark the permalink.
  • http://www.mindstorminteractive.com steve

    This list seems more like a comparison between Actionscript and Javascript. The areas where Flash still reigns are the integrated timeline and vector drawing API. Javascript is still relegated to basic tweening or sequence-based animations of images which have to be created in another program. When using flash as a thick client, the rendering capabilities of html and css are sort of moot. It provides its own presentation layer with an absolute positioning system. I would put this in the con column for flash though. Html scales much easier to various screens with its fluid positioning. Also we can’t forget rich Flash sites are bad for SEO, lose browser capabilities like the back button, bookmarks, etc.

    I would consider compilation a plus for Flash. Javascript runtime errors are a nuisance, especially considering the loose type and bizarre nesting functions which lends itself to make many more simple syntax errors.

    Depending on the project, both have big pros and cons. Flash will always be ahead of the class in terms of pushing the technological bounds. It already supports 3-d native now, and they continue to improve effects like blur. The Html 5 canvas shows promise for the future by taking a string ’2d’ in its constructor, but the drawing api is still very primitive in comparison to what you can accomplish in flash (try programming a shape tween).

    For game development, Flash will always win. For an enterprise app that needs to reach a broader and less tech savvy audience and doesn’t need the shiny glitz, the HTML/CSS/JS combo is usually your best solution.

  • http://www.johnpencola.com John Pencola

    @Steve:
    Thanks for chiming in on this!
    “This list seems more like a comparison between Actionscript and Javascript”
    It is. After re-reading this old post, I think somewhere about halfway through I lost my original train of thought :)

    “The areas where Flash still reigns are the integrated timeline and vector drawing API”.
    Agreed. Although obviously this will change as tooling and libraries for JavaScript solutions to these problems continue to mature. As for HTML Canvas, the 2d context is a far cry from ActionScript’s Vector and DisplayObject API. In terms of animation, 2d drawing and 3d, Flash ActionScript is much older in it’s implementations. I guess at this point JavaScript APIs for such things are probably comparable to AS1.0-ish abilities.

    “When using flash as a thick client, the rendering capabilities of html and css are sort of moot”.
    It depends. Sometimes you need to render HTML in Flash. The reason I included that was not to compare the native (Flash) rendering engine vs. the browser based renderers, but to jab at the Flash plugin’s HTML renderer. It’s horrible. As of the writing it supported such a tiny subset of HTML (with limitations) that it wasn’t even worth using.

    “I would consider compilation a plus for Flash”
    Really??… I find that when writing programs in interpreted languages it becomes easier to debug code. For example, you don’t need to kick-off a build process every time and in the case of JavaScript you can literally write the code directly in the browser using the console. “…which lends itself to make many more simple syntax errors” Gotta disagree here… First, if the IDE or editor you are using is worth it’s salt it can give feedback on simple syntax errors while you code. Second, it sounds like what you are describing is more a complaint about truly Dynamic Languages; which yes, when learning how they work in comparison to Strict Languages can feel a bit uncontrolled and error-prone, but you learn that you generally shouldn’t approach writing code the same way you would in a Strict language. Once you do, then your eyes are open to see the power and flexibility dynamic languages offer. ActionScript, as of version 3, has sort of always sat on the fence. But you can certainly get yourself in just as much trouble by declaring untyped objects, using closures, etc. in ActionScript, so it really has nothing to do with whether the language is compiled or interpreted.

    “(Flash)It already supports 3-d native now…”
    That’s true. But, I like where the “HTML5″ stack is headed with supporting WebGL by default to handle 3D.

    “For game development, Flash will always win”
    I’m assuming you mean browser-based games? It will be interesting to see how it pans out in the next 5 years.

    -JP