I couldn't agree more. DEATH TO THE BROWSER!! Developing applications for the browser is a royal pain in the a*s. Then alongs comes ajax and all it's hype. The more I looked into ajax the more I was underwhelmed. from the hype you'd think it was going to revolutionalize the browser but all it has done is prolonged its death and forced developers to learn yet another object model. don't even get me started on control positioning. you might as well write a novel using a stone tablet and chisel.

I am a full-time developer and backup network admin for a medium-sized company, and there was a time in the not-so-distant-past where I spent almost as much time "fixing" computers with malware due to browser security holes as I did in application development. It has gotten a little better thanks to better security appliances (and NO thanks too browser improvements). I am moving away from web apps as my primary development tool and back to windows clients. deployment tools are getting much better as is pushing out updates.

I think one example of a balanced mix between web and windows clients is iTunes. I don't know anything about how it was developed, but I believe this model, or some form of it, is the future.

I agree. But, the correct solution was given long back. It is the applet-servlet communication. If only, people were not so adamant not to download JDK in their system, we can have the best of both worlds, so easily. I suggest that all browsers have automatic downloading and installation of a lightweight version of JDK in the calling machine.

Luke,

All these comments have been made in the context of the article "Death to the Browser". Going back to the thrust of that article, what is being suggested is that the browser in holding back the development of applications that suit the needs of users. There is no argument about that, as an architect the major problem still faced by all enterprise class applications is to structure a simple, efficient and engaging interface for the users (particularly enterpise users).

And let's be clear, I did not say that MXML and XAML are superior to (xforms and AJAX), I said that they where superior to xforms and XUL. There is a way to say that, because all 4 technologies are designed to do the same thing: Define an application user interface. And as such XAML and MXML are simply more extensive, being able to define a broader set of applications than XUL or XFORMS can.

I am in no way "dis-sing" AJAX, it has its role to play and I have been using the core technology element (XMLHTTPRequest) for about 6 years (2 years after it was invented by Microsoft for OWA)

The other technologies are working at a level up from what goes on inside a browser (it's an outside-the-box kind of thing).

Gary,

I don't think any posts suggest AJAX is the panacea for UI. It's Really Damn Good for making better UI's on web applications, but no-one is suggesting CAD could be done in a web app with typical AJAX.

AJAX very much addresses the interface issue because of the way it improves the transport issue. The UI is about the user's experience, and AJAX really improves that experience.

There's already a pretty slick AJAX word processor built into Gmail for composing messages. And my Google personalized home page has toolbars and tabs that are "aware of each other." Not to mention I can add plugable content by throwing in my own RSS feeds, or search results.

But that's all just tit-for-tat. The point is that UI highly situational. There is no way to say MXML and XAML are "superior" to XFORMS and AJAX. It's all dependent on what one is doing.

Yes, there are applications where a web approach would butcher the user experience. But that number of applications got smaller when good AJAX design became prevelant. Ignore it at your own risk.

About four or five years back I came to the same conclusion, and began experimenting with an application I called SNAP which on paper would have ticked pretty much all the boxes in your article. It linked and configured Java components (either built in or dynamically fetched on-line) together via an XML document, which also contained scripts (I used Rhino, the Java JavaScript implementation, to begin with) to glue everything together. All the components could interact via a 'DOM', which also stretched across networks to reach components physically located on other computers (ala RPC/RMI).

The ultimate idea was that you didn't 'save' your work, you 'bookmarked' it. So you could shut the client down, go somewhere else, access your bookmarks and select the project, and the necessary IU and data would be loaded on your new client so you could resume your work. Not only did the data follow you around from place to place, but the application itself did too.

Obviously the scale of the work (the above is only a brief outline of my idea) kind of got to me - I knew from the start that I'd bitten off more than one person could chew. And nobody else seemed to appreciate the idea - so inevitably this 'spare time' project ran out of steam and was mothballed after a few weeks. Ever so, it was rather interesting 'messing about' just seeing what worked and what didn't. :-)

I think the author of this article has no experience with applets nor has he heard about java webstart technology.

A good example of what you can't do with HTML is the browser itself. Thats why Mozilla had to develop a new language (XUL) to build "real" applications like FireFox or Thunderbird. Dockable Toolbars, MenuBars, Tabs, Tab Pages, Pluggable extensions. all of those elements live within an implict "Window" heirarchy, so they are aware of each other. You can do some really nice stuff with (xHTML + CSS + Javascript) but you can't build a browser with it (or a word processor, or a CAD system or paint program ....

Imagine if you could!! you could "construct" or assemble applications on-the-fly completely platform independent capable of anything and tailored to the needs of the user at the specific time.

All UI based applications have some sort of UI definition language. Whatever is missing from HTML is minor (given the success of the existing Web) and can be added as the need arises.

In fact, the evolution of HTML as a UI definition language is evolving, but as a widely adopted standard, that evolution is slow. Take a look at the WHAT-WG for an example of the kinds of things that will happen to HTML over the next 1-2 years: http://www.whatwg.org/

What specific part of a GUI were you unable to build within a browser when you tried?

All the posts suggesting "AJAX" as the panacea miss the point. AJAX still relies on HTML, and HTML (or XHTML) is weak at defining an application user interface for all but the most simple applications.

AJAX addresses the transport issue not the interface one.

I think sean the author of this editorial, should turn off his computer and leave the IT field. Want a more client-server action? Try AJAX!

Wow, talk about 2 steps backward. I don't think I've seen any good Java applet online. And I haven't seen one at all in a couple years.

AJAX is not another sail. It's a set of existing technologies that, when integrated throughout the design, create a different kind of technology altogether. It is the steam power.

XAML and MXML may be the never-ending nuclear-engine substitute, but some ships don't need all that.

And some apps just need a single auto-complete drop-down in a form. You could do it with lots of things, except maybe not an applet, and XAML might be overkill.

It's all pretty situational, so throwing at a perfectly viable and proven approach like AJAX is just plain ignorant.

Halleluja!
html is for TEXT and LINKS. not for GUIs!
posting of forms is the maximum.
AJAX is just an attempt to put an additional sail on a boat. lets move on to steam power!
the big problem is, how do we get the masses to use a new standard? everybody has a browser, nobody wants to change. perhaps the browser should only be used as a java-applet delivery mechanism?

In my first comment below I put both XUL and XFORMS behind MXML(Flex) and XAML. Both XUL and XFORMS are better than HTML, but both are very "last century" in concept. They both focus on forms and represent an application as a static collection of Interface elements.

XAML by contrast creates a framework for forms, but also includes 2d & 3d graphics rendering, animation, document flow control in a highly compact xml based syntax. XAML has been criticised for lack of CSS support, but the style model within XAML is far more powerful than CSS, again based on an XML syntax, the style element in XAML not only controls visual presentation it can also be applied to behaviours.

MXML like XAML has a richer application construct than XUL and XFORMS, but MXML uses CSS for style, and ActionScript for event handling.

All of these technologies depend on a client side rendering engine;
MXML use the Flash Player
XAML uses the new WPF
XUL uses the gecko engine
XFORMS requires an XFORMS processor

I gave the thumbs up to MXML because the Flash player is light and already widely distributed.
XAML is probably the most powerful but will need the distribution of a new engine.

XUL and XFORMS are quite "retro" and could use an architectural and conceptual overhaul.

The possibility of rich user interfaces delivered thru the current browser exists, and it's actually the stagnation in HTTP and HTML that has enabled it.

Everyone knows how HTTP and HTML works and will always work (since they're not innovating). So working with that un-changing base means you can be creative with the rest - things like AJAX, XUL, etc. to achieve usability.

It's already happened. Have you ever heard of Firefox ( http://www.mozilla.org ) and XUL ( http://www.xulplanet.com/ )?