1. We’ve all listened to the experts tell us the orthodox way, only to see to see the wind shift another direction. So we’re skeptical. If it ain’t broke, don’t fix it.

2. We favor the tool we know over the tool we don’t. I can get this page done in an hour using tables, or I can spend a day and maybe get it done with CSS.

3. Tables have a scaling problem. A single table is usually simple enough. But then you put another inside it, and.. eventually you have tables in tables in tables. I’ve never seen tables go 4 deep because 3 deep is already insane.

4. Tables, especially tables in tables, are a maintenance problem. Pay attention to how much time you spend on changes.

5. Tables go away, except for true tabular data, for designers that go with CSS. It’s hard to explain to those who haven’t made the journey. They haven’t had enough table pain yet. They haven’t felt enough CSS relief yet. Until then, the CSSers appear as fanatics adhering to the standard du jour.

6. Watch the trend. Every year, some tablers go on to CSS, no CSSers go back to tables.

Yeah, I totally agree tables died a long time ago when it comes to layout. However, when it comes to GWT there are various layout containers you can use that use div’s under the hood and that rely on good old css positioning.

Gwt Flex table is great at what it’s designed for. Showing tabular data. I think its a case of use for what it’s intended for.

GWT makes it easy to prototype, but there are other frameworks (JQuery MooTools) that are much better for prototyping. GWT excels at creating large maintainable applications.

What you are really talking about is GWT inability to totally abstract you from HTML. You’re right. GWT doesn’t totally abstract you from GWT. Nothing does. I’ve never seen a programming language that totally abstracts you from the underlying architecture.

The DTO pattern is one that you can follow more or less, but the basic idea is realizing that HTTP requests are expensive and combining them makes a lot of sense. We normally have many widgets and a helper class for saving the data.

The DTO pattern just does not always work for me. The problem is a bit less obvious, it’s more an effort in finding the right balance. Consolidating all your ajax calls into two calls to get/set the data seems ok but you are also fixating the data structure that a particular page can use which reduces flexibility. How does this work when you’ve got widgets that you’d like to reuse everywhere?

Thank you for commenting. I’ve heard them called many things, but encapsulating your data is always a good idea.

I suppose the suggested UITO is what Fowler called a Data Transfer Object (DTO).

In general terms, what you say is correct. However, the above article as well as my comments were referring to layout within the confines of GWT.

With GWT, making a self-contained widget using the table-based layout primitives is a lot more easy and manageable than using CSS. With CSS, you can’t simply move a widget to a completely different position in the DOM-hieararchy without having to rewrite a lot of the CSS. Especially if you want to have a proper design that adopts itself to the width (and height) of the browser window.

Also, of course, there is no need to mess with table, tr and td tags when using GWT.

So, to summarise: I agree with you on the advantages of CSS when designing a page using hand-written HTML. I absolutely do not agree when it comes to GWT layouts, which is what the article was about.

At the end of the day I suppose it comes down to what one’s approach to GWT design is: Are you trying to build a web page using Java code, or are you trying to write a Java application that runs on a web page? I tend to gravitate towards the latter camp.

My biggest reason for using CSS instead of tables is that it is easier. CSS does take a little more effort to learn, but once you do each page is easier to create and make it look good. CSS is also much easier with dynamic layouts. Take a look at my Dynamic Grid Layout In JavaScript article. Writing the code to generate a few CSS properties is much more manageable than handling all of the TABLE, TR, and TD tags.

…but that is just my opinion.