In a recent post of “Ajax Turkey’s for 2007″ Dietrich Kappe of Agile Ajax decided to group ThinWire together with other Ajax technologies he considers to be lame for 2007. Included on the list are Gmail 2.0, ECMAScript 4 (aka JavaScript 2.0), Vista, IE7 and of course… the all powerful ThinWire framework. Here’s what he has to say about ThinWire: “any framework that makes you specify position and calculate height and width of every widget is a productivity killer.” I don’t usually find myself at a loss for words, but all I can say here is “Bravo!” You, single handedly proved why its generally a good idea to RTM before opening YBM. Who is Dietrich Kappe anyhow? In any case, both Ted and I have made our best attempt to provide correction to his statements in the comments. Hopefully this will provide him with the information necessary to develop an informed opinion in the future.
{ 2007 11 23 }
jgbr | 23-Nov-07 at 9:10 am | Permalink
He should also learn some GUI programming as well. The TableLayout class we use throughout our project is simpler than the GridBagLayout from java.awt. Sun could include this type layout manager in the JDK.
I think Thinwire is an excellent framework. It requires some software design skills and knowledge of design patterns.
Ted C. Howard | 30-Nov-07 at 4:40 am | Permalink
Well, after several comments to his post defending ThinWire’s honor, Mr Kappe is taking it all back.
http://blogs.pathf.com/agileajax/2007/11/eating-some-cro.html
Thanks to the posters!
justinquring | 30-Nov-07 at 8:29 pm | Permalink
Hi,
I’ve just heard about the thinwire framework and was browsing this site. I use JSF. at first sight, the framework looks good enough to increase productivity. One thing where it falls short is the absence of a visual tool.(at least I didn’t see any link available to the public on this site).
this is a must if you want to compete, microsoft understands this very well, and that’s how back then Visual Basic overtook all the other languages, because of the huge productivity gain.
As for me and I suspect for a lot of other people, there is no compelling incentive to migrate to thinwire, if there’s no visual tool for this framework, whereas I am already using one with JSF.
just my 2 cents.
remember | 06-Feb-08 at 10:34 am | Permalink
having looked over the source of both ZK and Thinwire (the two top AJAX contenders featuring a java layer), I have to say it’s strategic suicide to sink a lot of functionality into any of these frameworks. Thinwire has the virtue of not binding everything together into one complex ball from data field out through UI (out through visually-oriented development process even, in JSF and .NET). However both of these java layers are complex and encode a lot of functionality in a java layer, which if you look under the hood, looks like CSS files are non-existent but styles are embedded in strings, and the javascript is there and looks just like an embedded javascript widget library (e.g. EXTjs). Can someone tell me why the Java layer is even here? In the age of SOA we need separation of concerns, not binding everything into one stovepipe. (I still have my own PHP-based stovepipe BTW…)
al0 | 19-Feb-08 at 6:11 pm | Permalink
remember,
It seems that your look on ThinWire code was very superficial. While it’s true (and IMHO pitiful) that TW does not support CSS it has its own external styling mechanism (XML-based). So while it is possible to embed styles, it is not required (or recommended).
JavaScript exists solely under the hood (how else would you reach fine-grained control control over browser behavior)?
And this JavaScript is fixed library the same for all applications, no Java-JavaScript generation occurs.
Concerning SOA - that is absolutely independent matter? ThinWire is about browser-based GUI, SOA are about services. There is no contradiction at all.
And Java layer is there to allow you use single base technology on each and ever level of your application. Thus save you a lot of time and integration efforts.
Regards,
Oleksandr