Web GUI tools – Not as different as they seem

What else indeed do these competing options offer? Let’s first understand why we’re using JACXX at all, instead of just coding our HTML pages directly.

There is the matter of cross-browser compatibility which has been the thorn in the side of web developers since "the second" browser appeared (whatever it was) back around 1993. If you code directly to the browser you will find that someone using a different browser, or just a different version of the same browser, will not get the same experience. In the past (and today to a great extent, but waning) people coded their pages with script that said "if the browser is this, render that". But this sort of code is error prone, tedious, and bulks up the browser.

So as development platforms evolved, more code was put on the server, checking the HTTP headers to see what kind of browser was making a request, and on the server side generating the right code for the user making the query. Why push Netscape-specific code into Internet Explorer when you don’t need to? There are of course other benefits to server-side code vs client-side. On the server you have a wider choice of languages. You get more freedoms on the server than in the secured client sandbox. But the focus here is on using server-side code to generate browser-specific code.

Developers got tired of writing the same code, even on the server, to check the browser and render different variants of the same UI components. So, in the spirit of making computers do the grunt work, middle-tier technologies were created, to allow developers to code in a more generic, platform-independent manner, and the middle-tier would translate that generic code at runtime for the specific browser. To make this easier, more "declarative" coding practices were developed. The idea is that you describe what you want a UI component to look like, but you don’t write code that does the actual UI component generation. XML is an excellent tool for writing this sort of declarative definition.

But lots of developers going through this evolution have created their own dialect/schema for XML declarations of UI components. I call my listbox a <vlist>, someone else calls it a <dropdown> someone else calls it a <combo> (requiring a flag to differentiate between a dropdown and a full combo… So which one do you choose? Well, the choice shouldn’t be narrowed to your preference for the term vlist or dropdown. There is a lot more to the decision.

Let’s look at Adobe Flex MXML as an example. As mentioned in prior blogs, Flex is the less "flashy" RIA tool that makes use of the Shockwave/Flash browser plugin, but it’s used for more serious data-oriented applications. In true JACXX form, you write XML code to describe something like a button, then you write JavaScript to take action when someone clicks the button, and you write CSS to make the button look nice.

However, as with most/all of the other tools, the use of XML is optional. You can write your entire UI in nothing but JavaScript (well, ActionScript which is JS plus extensions, just like all of the others). So your code can look like this:

<mx:Button id="myButton" label="I’m a button!"/>

or you can do it like this:

myButton = new Button();
myButton.label ="I’m a button!";

The result is exactly the same! Why? Because there is middleware that takes the MXML and converts it to script code first, and then at run time the script is converted to something the user can see. This isn’t unique to Flex, all of the JACXX tools do the same thing. So if you don’t like XML you can generate your entire UI with nothing but code. But ideally you aren’t writing HTML tags, you’re writing code that will be interpreted at run-time so that the end-user sees the right HTML for their browser – and you rarely or never need to see that code.

Just for reference, the JavaScript code to create a button using ExtJS looks like this:

In this case, the "middle-tier" isn’t server-side code, it’s the Ext library that processes the above request on the client and renders a button. The point here is that you’re using one language (JavaScript) to generate code in another language (XHTML/CSS).

Where’s the beef? Errr, I mean the middle-tier?

Some people get way bent out of shape over browser plugins. What they don’t "get" is that a plugin is just an extension of the browser. Flex and Silverlight use a plugin, others don’t. Your middle-tier is an abstraction layer between your code and the browser. It can attempt to generate browser-independent code at run-time, or it can try to generate browser-specific code, and you need to hope that it’s always going to generate code that will work with each new browser release. That’s a lot to ask.

To get around this problem of trying to get the details right for all possible browsers on all operating systems, Adobe and Microsoft (and Sun with the Java Virtual Machine for applets, and many others) have chosen to put the middle-tier on the client rather than on the server. Their middle-tier will always render output in a consistent manner because they control the code that paints the pixels on the screen. These companies have decided that it’s sometimes easier to just make the container work within the browser application, rather than to try to generate JACXX that’s conformant with any client environment. Note I say "sometimes easier". Adobe produces Dreamweaver and other products if you want to write code on your own, but they have Flex too. Microsoft has ASP.NET for server-side rendering, but they have Silverlight too. And with Java you can use Tomcat and maybe Beans on the server, just like ASP.NET makes use of Server Controls.

I don’t want to get into a battle here over the evils of plugins, but I think many people don’t like plugins for the wrong reasons. Plugins have long been recognized as an attack surface for hackers. These guys write some code that exploits the fact that the plugin has access to the browser application, outside of the page, and thus to your system. I fully understand the preference that some people have for reducing the number of attack vectors into their PC. That said, the specific plugins being discussed are no more prone to vulnerability than any other software that people invite into their network on a frequent basis. I’m amazed that people are shy about browser plugins but the same people will rave about all of the various helpful utilities they’ve put on their system … if you watch the security reports, you’ll find there isn’t a direct correlation between "Open Source" and "secure".

My sub-point here is two-fold: First, get bent out of shape about the right things and for the right reasons – Flash and Silverlight are the least of your worries. Second, these plugins exist because of other issues, like browser incompatibilities which significantly increase development costs. If you’re looking to create a RIA for commercial use, you should think less of your personal aversion to plugins (whether technically justified or simply philosophical) and think more about your business goals as a developer. You can avoid almost all cross-browser issues by deploying through a plugin – and that also means you automatically get a wider audience like Mac and Linux clients who can use your RIA. The ultimate goal of creating most RIAs (for my audience anyway) is to improve the marketability of your software and increase revenue. The goal is to create a product that other people will use. Even if you don’t personally like plugins, the fact is that most other people will use whatever they need to see the content that you offer. So regardless of your personal feelings, consider plugins as valid options among many others.

In the big picture, I’m not talking about plugins here anyway, I’m talking about JACXX, and just noting that your coding to XHTML-based browsers is relatively the same as when you’re targeting a plugin. I want to emphasize this: when you’re targeting a plugin you’re often using the same tools you use to target a browser without extensions. So if you say you have an aversion to plugin development, that should be (right or wrong) because you simply don’t like plugins, and not because you’re thinking you need to use some new language to target the plugins. We can argue about whether plugins are safe but they’re just like any other JACXX tool for development.