Comments on: Ext GWT 1.1 Released

By: simongil

simongil — Mon, 22 Sep 2008 11:56:08 +0000

And, isn’t it argument enough that even with this latest release, the api still lags behind what ext-js 2.2 offers?

By: simongil

simongil — Mon, 22 Sep 2008 11:32:01 +0000

I think mare pretty much summed it up with “The thing I hate about GWT is that it takes 40sec of building just to see weather your your element looks better with an icon on it or not…”. UI design is extremely iterative. You might do 200 iterations a day as you build and tweak a layout. At 40 seconds, these GWT iterations add up to a lot of wasted time.
.
My take is abstracting away from the very platform (html/javascript) that we deploy to just doesn’t make sense. It’s like wanting to drive a race car, but sitting in the back and telling a driver what to do. Might sound good in theory, but you’ll never get the best out of the vehicle. So learn JavaScript, and reap the benefits from being in the drivers seat.
.
As for GWT-Ext, the power is in Ext. Leverage that with it’s native JavaScript API. Don’t step back and get bogged down with a Java bridge to that API. And the API is one thing, but the UI mechanics are another. Consider a maintenance UI with a dozen different field types (radio sets/combo boxes/text fields), multiple widgets within (grids/trees/whatever) and with inter-dependencies between all of them. Add read/write/delete functionality where you’ve got to enable/disable certain fields&widgets as part of it. Now JavaScript as dynamically typed makes it a breeze to hook all these components together and create some slick routines that step through all UI objects and apply enable/disable/RO/RW automatically. Try and do that with Java, and watch the lines of code pile up. Worse still, you’ll probably end up writing a dozen different state routines with 20 enable commands handling each UI component individually.
.
There is real power in JavaScript. Why avoid it?

By: ExtAnimal

ExtAnimal — Sat, 20 Sep 2008 08:54:09 +0000

How would GWT work in a single page app? AFAIK, you can code up a “page” in Java (I can’t see why not to use Javascript directly – just GET THE SKILLS), but then do you have to reload a new page each time with the associated reload of the javascript?

By: DiSiLLUSiON

DiSiLLUSiON — Fri, 19 Sep 2008 23:39:02 +0000

Yes, but that’s not what I mean. Those buttons simply implement accesskey. What I mean is, for example, your Tab control. In graphic OS environments (Windows, and I believe Linux as well), the Tab control can also be directed with the keyboard, when it has focus. Try it on a native Tab control on your OS. Use the arrow keys to move forward/backward. Use pgup/pgdown/home/end keys to move to the start or the end of the list. In your example, it doesn’t work. It doesn’t have to be much work, but it’s (imo) very important for any heavy duty user of whatever software uses your widgets. Of course, there are widgets out there which use keys differently in the same context on different OS’es, but a combination or even part of an implementation is better then no implementation at all.

By: ThomasHansen

ThomasHansen — Fri, 19 Sep 2008 17:55:11 +0000

@DiSiLLUSiO
I don’t know about all the other frameworks, but Ra-Ajax (ours) is stuffed with support for Keyboard Shortcuts (if that’s what you mean)
Check out e.g.; http://ra-ajax.org/samples/Effects.aspx
and try the Keyboard Shortcuts there which is attached with the buttons the…
(Though it’s pure .Net/Mono so probably not that interesting for Java people)
(And also quite IMmature (0.4 release, 0.5 coming up within a week))

By: DiSiLLUSiON

DiSiLLUSiON — Fri, 19 Sep 2008 13:10:28 +0000

I see, so they have it… but hardly use it in their own widgets? That’s a shame.

It does illustrate my point: Even the tree in the documentation browser isn’t easy to navigate using the keyboard; typing a word to scroll to a certain topic, using arrow keys to expand/contract a branch or using page up/down to quickly browse through the list simply doesn’t work.

After paying such amount of attention to their top-notch widgets (everything is pixel-perfect and, as far as I can determine, cross-browser), it does seem strange such basic functionality isn’t included by default.

I do hope the next release will take care of that, the widgets aren’t really usable in a productive online application as-is.

By: danh2000

danh2000 — Fri, 19 Sep 2008 12:08:37 +0000

@DiSiLLUSiON – mostly keyboard events just aren’t demonstrated that much. Ext does provide good support though:

http://extjs.com/deploy/dev/docs/?class=Ext.KeyMap
and
http://extjs.com/deploy/dev/docs/?class=Ext.KeyNav

By: DiSiLLUSiON

DiSiLLUSiON — Fri, 19 Sep 2008 11:15:43 +0000

One thing I don’t understand: why is there still no proper keyboard support in Ext? Or is it simply unused in the demos? The demos I’ve seen show a glaring lack of support within seconds of using, especially the ‘desktop’ demo.

And Ext-JS isn’t the only widget library with this (seemingly, correct me if I’m wrong) fault, most out there don’t capture keypresses properly (as the native OS version of those controls do). It makes for a frustrating experience whenever such widgets are used.

By: ThomasHansen

ThomasHansen — Fri, 19 Sep 2008 04:56:13 +0000

@Jonny
Learn BOTH, you need JS knowledge for another 30 years just like you needed ASM knowledge the first 30 years of computer development, but rely as much as possible on Java ;)

By: mare

mare — Thu, 18 Sep 2008 20:38:37 +0000

The thing I hate about GWT is that it takes 40sec of building just to see weather your your element looks better with an icon on it or not… Otherwise, GWT doesn’t suck much.

By: Jonny

Jonny — Thu, 18 Sep 2008 20:12:23 +0000

Wow…those two comments sure don’t help a person pick which direction to go when learning this stuff. :)

I’m learning Ext JS right now…but am wondering if I should be learning Java and going the GWT direction instead.

By: Tommy Maintz

Tommy Maintz — Thu, 18 Sep 2008 19:43:57 +0000

@ThomasHansen
“Practically JS development is like assembly programming 40 years ago, necessary but decreasingly important the more Ajax matures…
The future belongs to abstracting away JS and anyone who bets different are in for a though ride.”

I think you are completely wrong here. Javascript is getting more features, a lot faster, broader adoption. Jaxer even takes it to the server, which is probably not yet mature enough, but definitely something I’m sure will be improved. I think Javascript will be a language which you will see more often in desktop applications because of things like gears and AIR. There are more and more developers learning the language, more books written about it.

Summary: I think it will be the complete opposite of what you said. Not abstracting away JS, but more and more usage of JS.

By: ThomasHansen

ThomasHansen — Thu, 18 Sep 2008 16:34:31 +0000

@simongil
There’s a “gazillion” reasons to doing just that. Though I am a “believer” in server-side Ajax as you can see by following my link…
But I’ll toss in a few reasons;
* Many developers *don’t* know JavaScript, many developers *do* know Java
* You get (most of) your code to run in a protected environment behind the firewall in your server which increases the level of security
* You get to use the compiler which will trap most of the bugs you’d normally have to have JS Unit Tests for (which BTW is a nightmare to build)
* You get far less browser portability problems since the ExtJS team (or we) do this for you
* Probably your app will be more responsive (though with GWT I am not 100% sure) since the amount of JavaScript often gets orders of magnitudes smaller
* You can incorporate all the optimalizations (like GZipping of JS files, minification, adding script tags to the bottom of the page and so on) in the LIBRARY meaning this is no longer a “choice” but the *default* behavior which again increases the level of responsiveness of your apps
* No more Cross Site XHR problems since you fetch the data from other services/servers from your own server instead of within the client (yes I know you can build a proxy, but with ExtGWT and other “sibling projects” this is *implicit*)
* You can get to use a “gazillion” other libraries like (j/n)Unit, (n)Hibernate, log4(Net/Java) and so on without having to create JS abstractions on top of them
* You get the Java/.Net IDEs with intellisense, refactoring and all the other goodies
.
Practically JS development is like assembly programming 40 years ago, necessary but decreasingly important the more Ajax matures…
The future belongs to abstracting away JS and anyone who bets different are in for a though ride. I thinks the Ext team’s focus on GWT is VERY mature and foresighted… ;)
.
But these are MY thoughts and I might be wrong ;)

By: abickford

abickford — Thu, 18 Sep 2008 15:20:31 +0000

At the very least you get the GWT compiler optimizations.
.
You also get access to other GWT libraries, such as Gears, Search, Maps and so on.
.
You also get the java development environment and IDE support. This means that while it may take 2-3 times more statically typed *code*, it doesn’t require 2-3x as much *coding*. Much of it is generated/auto-completed by an IDE.

By: simongil

simongil — Thu, 18 Sep 2008 13:36:05 +0000

I don’t really understand the value of recreating the Ext JavaScript API in Java? Statically typed Java ends up creating 2-3 times the volume of coding required to do what is done via Javascript. Is it because J2EE developers don’t want to learn JavaScript??