Team Eiffel

I'm a big fan of the approach of using progressive enhancement to build websites. In short this approach builds websites that begin with content/markup (HTML), use CSS to change the style and presentation, and use JavaScript to add behaviour. If you have to support IE with its limited support for CSS you might have to twist your content a bit, but with a decent browser this approach works very well. It will lead to websites that work everywhere and even work when JavaScript is disabled. It will give you quite a bit of guidenance in building robust websites, believe me.

This is also the approach that one should take with HTML controls and capabilities like auto complete support that are possible with AJAX techniques. Make sure the control works when JavaScript is disabled. Use CSS to make it look nice. Use JavaScript to make it work better.

The question is how to add these additional capabilities to HTML. Because in the end, the browser reads and interprets HTML. It uses CSS for the styling and JavaScript for the behaviour. That's how this environment works. And programmers should not be shielded from that. That is how the web really works. Having some magic to make it appear that this isn't the case is very detrimental to any programmer's internal model of how web applications work.

I've occassion these days to do a lot of work with Visual Studio 2005, C#, ASP.NET and Atlas. And the result is horrible. Microsoft's behaviour can be best explained if you believe that they want lock-in. It explains why they will try to shield you from HTML, CSS and JavaScript. They allow absolute positioning of controls. A favorite technique in examples. Because drag/drop of controls works better that way. Woo the programmer who tries such a website on anything else than a pair of perfect eyes, perfect color perception, IE and the screen size of the original programmer. The web isn't a Win32 Visual Basic app. Making it appear so, will only lead people to build an internal model of web programming that is fundamentally untrue.

The same is true for Microsoft's postback approach. How many websites work somewhat fine on intranet and then fundamentally fail on the internet? Again, Microsoft Visual Studio's approach is to give the programmer the idea he is building a Win32 form. He isn't.

And then the controls. You have all those Microsoft controls like asp:Button. What's that? Is it an HTML button? Something else? You set its properties using background color and such. And that doesn't end up in some CSS style sheet let me tell you that. Programmer doesn't need to know CSS because this is just a win32 form.

And then the Atlas toolkit. Exactly how one shouldn't design a toolkit unless you want to shield programmers even more. For example you can extend an existing control with auto complete support. It's supposedly declarative (another rant, I promise). The good thing is that you can extend a normal HTML input. The bad thing is that you have to write that support in some declarative JavaScript, called XMLScript (good luck finding any documentation on that) or with using an atlas:AutoCompleteExtender element in your source. Copy and paste some sample code and things work. That's cool. But how does it all work? The last thing Microsoft wants you to learn is HTML and JavaScript. You have to be shielded from that you know. Instead of JavaScript you write XMLScript. And when ignorance is bliss I suppose this will do.

But sometimes you get paid to take the red pill. And you will need to dynamically, at the client, create an input control and it should get AutoComplete behaviour. And while the mirror starts dissolving you have to take the plunge into how stuff really works.

No need for pills and ignorance does get you nowhere. That summarises EJAX's fundamental approach to HTML controls. It is an explicit design goal to not shield the programmer from the underlying mechanisms. Controls should work such that they guide the programmer into building the proper internal model. This to allow the programmer to easily use the control outside the presented toy example. Create some dynamic HTML? Even if the toy example presented static HTML it should be intuitively clear how to apply that knowledge for that scenario as well. And for returning HTML by some AJAX call, etc. So the control is HTML. The behaviour is applied with a JavaScript call.