Frank Sommers discusses his journey through four user interfaces HTML, Swing, Ajax, and Flex.

http://www.artima.com/articles/journey_through_four_interfaces.html

What has your user interface journey been?

At our company we are currently doing a rewrite of our configuration programs. They used to be MFC programs and now become a webinterface. We use GWT for that and it is a lot of fun to be able to use a modern GUI library for the web. We have also written user interfaces in HTML and that HTML would be produced by C++ code.

I think it is great that with GWT we do not have to generate HTML ourselves. I think the whole HTML, CSS and JavaScript stack of languages is basically just a mess because the web evolved far faster then the languages and the languages had trouble keeping up. And now the W3C is trying to sell this pile of lack-of-design as if it were a sound idea to begin with.

The idea of having separate languages for document structure, layout and automation seems totally backwards. In decent languages one uses a GUI library for all of that and one uses the possibilities that a well-designed language has to separate concerns. So, one can have a class that represents a particular way of organizing a form and then create various child classes of it that represent concrete forms with particular texts and controls. By creating some sensible methods and doing a bit of method chaining the building of concrete forms is just as readable in e.g. Java code as it would have been if it were written in HTML (or more readable, actually). And one can organize it in such a way that adding an input element also makes sure automatically that it communicates with the server in the right way.

> I think the whole HTML, CSS and
> JavaScript stack of languages is basically just a mess
> because the web evolved far faster then the languages and
> the languages had trouble keeping up.
Not quite. HTML was constrained from the beginning. It's explicit design imperative was to display text, and nothing more. It was designed to allow academics to trade their papers, often with embedded tabular data. It *isn't* a language, much less a programming language; just some syntax rules. Same goes for xml, only less. JS was a bandaid, and still is. HTML isn't a basis for an interactive POS input screen; that it is used so isn't evolution of the web, but cost avoidance by the developers; they hacked at what was available to make it contort itself into a Klein Bottle (or Frankenstein Monster) rather than create a bespoke language on the assumption that it would be cheaper in the short run. One can argue that Applets were that attempt, and their failure was due not to technical reasons, but Sun's inability or unwillingness to make the infrastructure robust enough.


> And now the W3C is
> trying to sell this pile of lack-of-design as if it were a
> sound idea to begin with.
Amen.

> What has your user interface journey been?

I've dabbled in just about every user interface technology available to the mainstream over the past 15 years. Even the most obscure stuff like the Curl VM, I've dabbled with.

I think Frank should never have wrote this piece. He basically took an eon to say a few simple things.

Personally, my biggest "wow" moments in my UI learning journey were (1) high-level shading languages (2) physics-based layout (3) true 3D perspective user interfaces (4) data grids that allow you to compose the independent pieces and give the developer control over telling the data grid how to read the data source, such as the Smalltalk Skeleton system and ext Js data grid (5) resolution-independent toolkits like WPF and what a phenomenal time saver that is for freeing you up to focus on just building cool stuff.

There.

One paragraph. Or 5 bullet points. However you want to count it.

Actually, I'll add two more:

1) Using actors to manage the overall orchestration of a front-end GUI to a distributed application
2) converting the UI description into a dataflow diagram, thus fixing the input-output relation of the system to the history relation of the system, making inplace update of the UI an atomic, cheap, reliable, intercessant operation.

> I think it is great that with GWT we do not have to
> generate HTML ourselves.

After reading this, I thought that I'd take a look at GWT, since it sounds like it might be just the thing for my next project. So, I went to the GWT home page and from there to the 'examples' page and from there to the 'GWT Gallery' where the 'Featured Project' is Google Wave! And it says this about Google Wave: "Google Wave is a new tool for communication and collaboration on the web, coming later this year.".

A bit worrying.

I wouldn't worry about the Google Wave thing, per se.

GWT is used by lots of people and has lots of commercial vendor support.

I think there are indeed some architectural flaws in GWT, but most people don't care or understand why I consider them flaws. For most people, GWT is good enough. Unless you've got safety critical interaction design requirements, GWT probably works fine for you (assuming you know Java).

If you don't know Java, then the only real alternative you might consider that is a direct competitor (in an indirect way) would be F# and WebSharper. WebSharper is IMHO better, but still not nirvana. It shares a lot of the same architectural defects. WebSharper is a little bit nicer in that its form construction is based on Phil Wadler's programming language work on Links, and so all form construction follows rigid matematical rules for abstraction; this means you can't do stupid shit and the compiler will statically prevent you from writing dumb code (more or less true).

I don't think most people understand distributed programming, and even fewer believe/understand that GUIs are distributed programming endpoints. Believing/understanding that requires understanding that partial failure is a primary technical requirement.

I actually debated the design of a feature of GWT on the programming web log Lambda the Ultimate, and the designers of GWT weighed in. I was not impressed by their feedback to me, and gave a very strong rebuttal as to why I think they missed the point.

Bottom line: GWT is "good enough" software, but I don't think it will be how we are writing web apps in 10 years. At least it is better than ABC's Tea Servlets.

> One can argue that Applets were that attempt, and their
> failure was due not to technical reasons, but Sun's
> inability or unwillingness to make the infrastructure
> robust enough.

Somebody on the FONC mailing list (Alan Kay's project) recently linked me to some fascinating discussion on the history of Java's AWT and Swing products. Basically, I don't think it was unwillingness. Rather, it was a bureaucratic shame carried through to political perfection.

In short, the AWT team at Sun ended up getting control over Swing due to mergers and acquisitions and deadline pressure. The AWT team were by and large horrible GUI programmers.

And AWT itself was built in 1 month.

So as Gerry Weinberg says, "Things are the way they are because they got that way ... one logical step at a time".

It's a shame that Applets failed to gel.

One Java/AJAX technology similar to GWT, but slightly different, is ZK. (www.zkoss.org) Vincent might want to look into it as well. One uses the client more, the other the server more. I can't remember which is which and don't really care. :-)

> I think there are indeed some architectural flaws in GWT,
> but most people don't care or understand why I consider
> them flaws.

So, what are these flaws?

> If you don't know Java, ....

Seems like a rather silly problem to have. I did not know much about java before I started programming in GWT. The solution is to just learn it. I am now reading "Thinking in Java" alongside just starting to program in it. Best way to learn any language, I think.

> I actually debated the design of a feature of GWT on the
> programming web log Lambda the Ultimate, and the designers
> of GWT weighed in. I was not impressed by their feedback
> to me, and gave a very strong rebuttal as to why I think
> they missed the point.

A link to this?

> Bottom line: GWT is "good enough" software, but I don't
> think it will be how we are writing web apps in 10 years.
> At least it is better than ABC's Tea Servlets.

GWT so much looks like a standard GUI library that I would be tempted to conclude that you think that standard GUI libraries are not going to last 10 years. Is this what you think? Or are you referring to possible problems that come with having part of the code running on the browser and part of the code on the server?

Chris,

I didn't link it originally because it is a very long thread and I don't expect most people here have the free time to read it, but here you go: http://lambda-the-ultimate.org/node/3707

If you want to read just the exchange between me and the GWT architect, go here: http://lambda-the-ultimate.org/node/3707#comment-53190

In a nutshell, GWT hardwires sequences of collaborations between its loader interface, the browsers request engine, and the application's communication protocol with servers. This ends up subverting a lot of your module design and actually inhibits modularity.

Some have come up with slight solutions to manage GWT 2.0's poor code splitting API design: http://jcheng.wordpress.com/2010/02/16/elegant-code-splitting-with-gwt/ Not perfect, but a neat hack.

Cheers,
Z-Bo

> GWT so much looks like a standard GUI library that I would
> be tempted to conclude that you think that standard GUI
> libraries are not going to last 10 years. Is this what you
> think? Or are you referring to possible problems that come
> with having part of the code running on the browser and
> part of the code on the server?

Both.

The former is too big of an issue for me to care to delve into here.

Speaking to the latter, as far as I'm aware, batching code for remote execution is still an open problem (but with a number of solutions); we don't really have a framework for analyzing the trade-offs in designing such a language feature. Related: William Cook wrote a great paper that won a best paper award, analyzing "Web Services versus Distributed Objects: A Case Study of Performance and Interface Design" http://www.cs.utexas.edu/~wcook/Drafts/2006/WSvsDO.pdf -- highly recommended reading.

> In a nutshell, GWT hardwires sequences of collaborations
> between its loader interface, the browsers request engine,
> and the application's communication protocol with servers.
> This ends up subverting a lot of your module design and
> d actually inhibits modularity.

Okay, but I would not call these "architectural flaws". It seems more like a problem that could theoretically be solved in between GWT versions 2.3.6 and 2.3.7 by just reimplementing the code import mechanism, exposing a lower level interface in a sensible way and keeping the same higher level interface as a default way of dealing with the lower level one. Or is there a fundamental browser problem that would make this impossible? But if it is a fundamental browser problem, it is not an architectural flaw of GWT but of browsers...

My journey has been that all four solutions suck a lot, each one for different reasons.

1) HTML is a mess.

2) Applets have the problem that need a Java installation.

3) I haven't used Ruby On Rails, but from what I've been reading about Ruby, it's super slow.

4) Flex is proprietary and closed source and does not run in all platforms.

I am still waiting for the 'Internet O/S'. The first one to create such a product will get all the money ;-).

> Okay, but I would not call these "architectural flaws". It
> seems more like a problem that could theoretically be
> solved in between GWT versions 2.3.6 and 2.3.7 by just
> reimplementing the code import mechanism, exposing a lower
> level interface in a sensible way and keeping the same
> higher level interface as a default way of dealing with
> the lower level one. Or is there a fundamental browser
> problem that would make this impossible? But if it is a
> fundamental browser problem, it is not an architectural
> flaw of GWT but of browsers...

RE: whether these are "architectural flaws"

Have to disagree with your definition, in that you refer to the current callback mechanism as high-level. To me, I think I correctly abstracted the problem domain by thinking in terms of a distributed system and the problem of linking and loading code in a distributed system, tied to actual user stories. But everyone's POV will be different.

To me, callbacks are a fine *implementation* detail, but do not make sense to expose the programmer to. If the GWT compiler has to compile them to javascript callbacks, then so be it - Javascript is well-suited to use event-loop concurrency and that should probably be how it's done, anyway.