Skip to main content

A short history of Web UI programming

Posted by evanx on June 26, 2008 at 7:18 AM PDT

Web 1.0, XUL, Ajax, Laszlo, Flex and Silverlight have a common approach - declare the UI view using markup (HTML or XML), and use JavaScript to handle the UI events and manipulate the UI. JavaFX/Swing is a notable exception - which is exciting and/or risky?! 'Cos Web developers know and love JavaScript and HTML, so XML plus JavaScript is right up their alley.

If you're a Java UI programmer, there's GWT, Wicket and Echo. And with a great new Java plugin in the works, maybe Swing applets will be considered again in some quarters? But all web developers know JavaScript, and not necessarily Java, Groovy, et al, so probably JavaScript/Swing is a better bet than Java/Swing? Imagine having an XML schema for a flashy JavaFX/Swing toolkit, call it JavaFXml, with great JavaScript bindings, so make that JavaScriptFXml ;)

1008232_network_spheres.jpg
Anyway, let's look at the short history of web programming...

HTML, CGI, Perl
The Web started with HTML. HTML forms could be submitted via a submit button. Apache's Common Gateway Interface (CGI) enabled server-side scripts to process the form data, and generate an HTML result page. Perl, being a popular scripting language at the time eg. with Linux system administrators, suddenly became the popular language for CGI scripts, and many "sysadmins" suddenly became "webmasters."

JavaScript, DHTML
Netscape invents JavaScript for client-side UI scripting in web browsers, "designed to be easier for non-programmers to work with." Microsoft adopts it too for IE, calling it JScript. So it becomes the de facto standard - the lingua franca of web designers everywhere. HTML plus CSS plus DOM plus JavaScript equals "Dynamic HTML" (DHTML). Web designers suddenly become "web developers."

Java Applets
While certainly suitable for experienced programmers, this was not so great for "web designers," despite promising books such as "Teach Yourself Programming, Java, AWT and Swing in 24 hours." Actually this stuff is not "for Dummies." Not to mention some technical issues with the plugin like startup time, browser crashes, download size, etcetera. So web developers stick with JavaScript, which they know and love, to do neat DHTML things on the client-side.

PHP
Web developers know HTML, some JavaScript for client-side scripting, and some Perl for server-side CGI scripts. PHP gives them embedded server-scripting in their HTML pages. Poifect! Web developers become hard-code PHP programmers.

Java JSPs, Servlets
Schools started teaching Java, and enterprises got Java programmers, and we started spreading our Java love across the internets and intranets. But the majority of the web developers are not gonna suddenly jump off the PHP bandwagon and onto the server-side Java supertanker, notwithstanding the availability of the above-mentioned books - because 21 days is quite a long time.

internetexplorer3.jpg
Flash
Woohoo, let's add animations, interactivity and multimedia to spice up web pages!

XUL
Fantastic technology - XML UI markup plus JavaScript logic - way ahead of its time! If IE hadn't taken over the world and crushed Netscape, then maybe XUL would have taken over the Web?!

Ajax
Let's load content asynchronously, without having to submit and reload the whole page, and script the UI using JavaScript as per usual. Poifect!

Laszlo
Great stuff, inspired by Flash and XUL. If it was opensourced earlier, and/or bought by Adobe and renamed to Flex, or bought by Sun and renamed to JavaScriptFX...

Flex
Inspired by Laszlo, and currently taking over the RIA world, athough the Web is still owned by DHTML/Ajax.

Silverlight
Ditto.

JavaFX
Too early to tell. How is it gonna be better than Flex and Silverlight? What JavaFX tools for web designers?

Summary

Everything from HTML, through to XUL, Ajax, Laszlo, Flex and Silverlight, have a common approach, namely let's declare the UI view using markup (HTML or XML), and use JavaScript to handle the UI events and manipulate the UI.

1008231_network_spheres.jpg
Given the predilection of web developers towards JavaScript and XML, one wonders if the JavaFX initiative shouldn't have embraced JavaScript with an XML thingymajig also, like Microsoft (XAML) and Adobe (MXML) chose to do, rather than introducing a new scripting language? 'Cos in any event, the visual aspects of an UI should be designed by designers, using a GUI builder tool, rather than programmed by a programmer?

With a great new Java plugin in the works, and other JavaFX-induced improvements for client-side Java, maybe Java/Swing applets will be the preferred option for many of the Java programmers out there, rather than moving to one of the available scripting languages on the JVM eg. JavaScript, Groovy, JRuby, JPython, JavaFX Script?

If we want JavaFX/Swing to succeed in the browser, surely we need a GUI tool to design those flashy UIs, generate XML,and be scriptable using JavaScript first, and otherwise Groovy, Java et al, for programmers that prefer those other JVM languages.

Related Topics >>

Comments

Too late for swing for the web.

The zk (http://www.zkoss.org) type approach is the best one at this time, in that you don't want to, you don't have to deal with javascript or even xml or html, and can do everything in Java. It is surprising that neither Yahoo's nor Google's open frameworks is that easy. Sun is inexplicably trying to invent yet another language rather than make a better ZK type framework.

I have no relationship with zk except that I have a good opinion of it.

So, as far as I'm aware as of version 4 OpenLaszlo can cross compile/generate either ajax or flex code. I guess the natural move would be for it to also be JavaFX compatible too before being declared the Lord of the Web UI languages (if only this was a post about network admin languages, it could've been called 'Lord of the Pings'.. anyway). One language to generate them all sounds pretty precious to me ! Incidentally, the OpenJX project sounds pretty interesting to this end too: https://openjx.dev.java.net/ Cheers

Cool - we've been testing Pivot in the FF3/j6u10 betas, and we are also looking forward to the final release!

greg, pivot looks like a tremendous effort, and i look forward to trying the demos again on firefox3 with the upcoming new j6u10 plugin! :)

> one wonders if the JavaFX initiative shouldn't have embraced Javascript with an XML thingymajig also, like Microsoft (XAML) and Adobe (MXML) saw fit to do, rather than introducing a new scripting language? That's exactly what we've tried to do with Pivot: https://pivot.dev.java.net/

that does sound interesting. JavaSwingBuilder uses YAML markup for construct Swing GUIs.

I believe that UI views should be created by UI designers using GUI builder tools, rather than hand-coded. In that case, it doesn't really matter what markup language/schema is used, but having a standardised schema for describing Swing GUIs might be helpful - call it JavaFXml ;) With animations, transitions et al.

But that'd only be useful if a graphical builder supported it eg. Netbeans, so that UI people could drag and drop, point and click, and not have to code it.

Then have nice UI bindings for javascript, and also java et al, to handle UI events and update the UI - where this would be coded of course, by programmers, in the language of their choice - and i imagine scripting languages like javascript et al might be more popular than java. Oh, and automatic beans binding to make programming the UI even simpler.

OpenLaszlo does offer some support for compiling to DHTML, though that is still in beta until the release of OpenLaszlo 4.1. Currently, production support is available for compiling OpenLaszlo to SWF7 or SWF8 with SWF9 on the way.

owatkins, yes, i agree with you and thank you for your discussion :) It is an interesting issue that is often overlooked and underdesigned, for XML/UI "companions" to Java classes (and other externalised resources, eg. .property files) to also inherit (from that of the superclass) and be overridable (from that of the superclass), so as not to break the capability of the class itself to be subclassable, or at least not make this any less trivial than it should be.

I agree with you Evan that most GUIs are fairly static, particularly coming from the web side of things, but I just think its a step backwards using declarative XML for building GUIs. A while back I used Matisse in Netbeans, and while I found it was fantastic from a visual perspective, what it generated was very rigid and brittle. The Java code generated seemed ok, but Netbeans would not allow me to edit it, and it also generated an XML file intrinsically linked to the GUI. There was a lot of fancy stuff that I just could not do after that... it's probably improved now. It would be nice to have some kind of GUI declarative XML that could phase in and out from XML to OO implementation. Say I have some hierarchical XML describing a frame with panels and buttons... but at a later point I think, I would really like to reuse a sub-panel (and possibly extend in other situations). Then at that point a chunk of the XML would surrender itself to OO implementation. However OO going the other way to XML is more difficult... and it would have to conform to naming/design conventions. I know this has been done a million times before... but some kind of adjustable floating barrier is needed to seperate the OO code from the XML declaration.

owatkins, i hear you, but the majority of majority of GUIs are fairly static. That doesn't preclude the controller from modifying the GUI, and adding/removing dynamic bits and pieces in event handlers - that's what the UI "controller" is for. Also components might be designed on the form but start off not visible.

But your point that this doesn't play nicely with OO is well made. Typically then only the UI controller can get OO/inheritance.

Still, GUI designers enable non-programmers, learners, etcetera to get up and running quickly and therefore are essential for adoption, rather competing platforms and languages. And as you say for rapid prototyping and kickstarting projects.

Also one should (ideally) be able to separate UI design concerns from programming - eg. a dedicated UI designer might build and tweak all the UIs in an application, independently of the controller/logic et al.

"'Cos in any event, the visual aspects of an UI should be designed by designers, using a GUI builder tool, rather than programmed by a programmer?" I don't agree with this. I also don't agree with having XML layouts to define the screen. Using a GUI builder is fine for protyping and kickstarting a GUI project... or very simple programs. Having a markup assumes that the screen is static. I have built dozens of Swing apps, where this is not so. That is, I press a button or something in a dialog, and that modifys an array of controls below it. You can't model this type of behaviour in an XML file.... well you could use two XML files, but then you break inheritence, and all the yummy good stuff you get in OO. When are all these AJAX clowns going to learn that a GUI is object oriented? Having designers build a complex desktop app is very naive thinking.

HTML is a disgrace of the modern computer era.. invented in the pre-historical age, it was designed only for rendering hyper-linked documents.. with time, the industry abandoned the research about better formats and nowadays all the universe is trying to emulate rich contents through html simple tags...

Our next chance will be the Digital TV programming, and I hope we don't see HTML printed in the TV screens ;)