Issues of state

[Jay Loden]

Steve Holden wrote:
> greg wrote:
>> Jay Loden wrote:
>>> Like most things involving dynamic client side-javascript code and AJAX
>>> technology, it's a lot harder than you'd like it to be to solve the problem, but
>>> in cases where the Back button is really an issue, it's worth the effort.
>> So if you're willing to put in a huge amount of time,
>> effort and ingenuity, it's possible to overcome a
>> problem that only existed in the first place because
>> you chose an inappropriate technique for implementing
>> a user interface...
>>
> Exactly my point. Once you start to involve a complex framework to 
> handle state and interactions you see less and less advantage to 
> "desktop web" applications, since it's hard to match the directness and 
> simplicity of a native GUI.

This is true, you certainly won't get an argument from me! I've spent a lot of
time explaining to people why a real-time GUI and the HTTP protocol don't get
along. Event-driven programming using a request/response framework == square
peg, round hole. But, it seems like the benefits of a web-based GUI make for a
big hammer, so people keep pounding away at that square peg ;)

On the negative side, developing any sort of non-trivial web application is
fraught with problems:

  * language limitations of javascript/(X)HTML
  * highly varied implementations of CSS, HTML, js
  * browser-specific bugs (and features)
  * no real IDE to speak of
  * no way to receive events without some very ugly hacks or polling

However, there are also major benefits, which is why you see so many companies
and individuals jumping on the Web 2.0 train:

  * lower barrier of entry to creating a GUI (compare how quickly
    most people can turn out a form in HTML versus creating a GUI
    with the same entry fields)
  * cross-platform (yes, you have to support multiple browsers,
    but once you do, it works on the majority of platforms. For
    instance, support Firefox means OS X, Linux, Windows, etc all
    supported at once
  * Convenience for the end user - no need to install anything to
    use your software, which entices a lot more people to use it.
    This is less of a valid concern in an enterprise environment, but
    it still attracts people to feel they don't need to install
    something locally
  * available from multiple machines without extra effort for the user
  * Familiar interface (in most cases at least) to the user; more
    comfortable for them, less they need to learn.
  * Potentially available on many new platforms such as the iPhone,
    with some presentation tweaks. Good luck writing a cross-platform
    GUI app that runs on all the major OSes and mobile devices using a
    standard GUI toolkit etc. (or shipping the Python interpreter with
    an app intended for a Windows Mobile device, for instance)

Your point is absolutely valid, though. I think the web 2.0 craze has people
doing some things that just don't really make sense (like implementing Photoshop
in a browser - what's next, AutoCAD?). The bottom line is that there are many
many things that a native GUI is much better at and more than likely always will
be. If you're developing an application, it's important to stop and ask yourself
why it needs to be a web-based application, and unless you've got compelling
reasons, the native GUI should win out.

-Jay