About GWT opinion in thoughtworks technology radar july 2011

[Emilio Bravo]

http://www.thoughtworks.com/articles/technology-radar-july-2011#Platforms

thoughtworks technology radar july 2011, talk negatively about gwt,
these are the 3 reasons:

"First, in many ways, JavaScript is more powerful and expressive than
Java, so we suspect that the generation is going in the wrong
direction."
more powerfull for that?

"Secondly, it is impossible to hide a complex abstraction difference
like that from event-driven desktop to stateless-web without leaky
abstraction headaches eventually popping up"
I can't comment, I do not know the compilation process.

"Third, it suffers from the same shortcomings of many elaborate
frameworks, where building simple, aligned applications is quick and
easy, building more sophisticated but not supported functionality is
possible but difficult, and building the level of sophistication
required by any non-trivial application becomes either impossible or
so difficult it isn’t reasonable."
What is meant by functionality not supported?. Program non-trivial
applications with GWT is easier than directly in javascript

What do you think?

[Michael Allan]

Emilio Bravo wrote:
> http://www.thoughtworks.com/articles/technology-radar-july-2011#Platforms

> > First, in many ways, JavaScript is more powerful and expressive than
> > Java, so we suspect that the generation is going in the wrong
> > direction.
>
> more powerfull for that?

This critique makes no sense, as the two languages are comparable in
expressivity. Admittedly something is lost in translating from one to
the other, and maybe that's what they want to say.

> > Secondly, it is impossible to hide a complex abstraction
> > difference like that from event-driven desktop to stateless-web
> > without leaky abstraction headaches eventually popping up
>
> I can't comment, I do not know the compilation process.

The JavaScript engines that GWT targets are not stateless. There is
no such gross incompatibility between the source and target platforms.
I wonder what they were thinking?

> > Third, it suffers from the same shortcomings of many elaborate
> > frameworks, where building simple, aligned applications is quick
> > and easy, building more sophisticated but not supported
> > functionality is possible but difficult, and building the level of
> > sophistication required by any non-trivial application becomes
> > either impossible or so difficult it isn’t reasonable.
>
> What is meant by functionality not supported?. Program non-trivial
> applications with GWT is easier than directly in javascript

I have the opposite problem. I often want to do something that would
be trivial in JavaScript or HTML, but I have to struggle a little to
accomplish the same thing in GWT. Something as simple as wrapping a
Widget in a div - just for a quick layout test - requires reading the
API docs. I'm no a GWT expert yet, and I guess that's part of the
problem. I'm more familiar with CSS, HTML and even JavaScript than I
am with GWT.

--
Michael Allan

Toronto, +1 416-699-9528
http://zelea.com/

[Paul Robinson]

On 02/08/11 18:02, Michael Allan wrote:
> Emilio Bravo wrote:
>> http://www.thoughtworks.com/articles/technology-radar-july-2011#Platforms

They really like Javascript, and that gives a strong bias to their report. I suspect generating Javascript from something else probably feels morally wrong to them. Personally, I'm *much* happier writing in Java and very pleased that GWT allows me to create Javascript without having to write Javascript.

For enterprise use, they made no mention of any of the benefits of GWT. Like the tool set, being able to share code between client and server, code splitting, optimised Javascript, deferred binding and more.

This report presents their view, and doesn't try to be balanced or unbiased.

>>> First, in many ways, JavaScript is more powerful and expressive than
>>> Java, so we suspect that the generation is going in the wrong
>>> direction.
>> more powerfull for that?
> This critique makes no sense, as the two languages are comparable in
> expressivity. Admittedly something is lost in translating from one to
> the other, and maybe that's what they want to say.

The tool support for Java is really very good. That counts for an awful lot in terms of helping to save developer time and be able to produce good results. Besides, what on earth does "generation is going in the wrong direction" mean? Browsers run javascript, so it's the end product of the compilation. Reversing the direction makes no sense. As long as you can express everything reasonably in Java, and you can convert that to javascript well (which GWT can), I don't see the problem. But then, I'm not in love with javascript.

>>> Secondly, it is impossible to hide a complex abstraction
>>> difference like that from event-driven desktop to stateless-web
>>> without leaky abstraction headaches eventually popping up
>> I can't comment, I do not know the compilation process.
> The JavaScript engines that GWT targets are not stateless. There is
> no such gross incompatibility between the source and target platforms.
> I wonder what they were thinking?

If there are abstraction headaches within GWT, Google are doing pretty well at hiding them. It's not perfect (eg key mappings used in the keyUp, keyPressed events etc), but we're stuck with the web browser as the deployment engine and that limits what can be done while achieving very high browser compatibility. They may have a point, but is it really significant?

However, just like Michael, I'm not really sure what they were trying to say. Their comments here leave me feeling like they're complaining about some kind of perceived potential problem rather than a concrete issue.

>
>>> Third, it suffers from the same shortcomings of many elaborate
>>> frameworks, where building simple, aligned applications is quick
>>> and easy, building more sophisticated but not supported
>>> functionality is possible but difficult, and building the level of
>>> sophistication required by any non-trivial application becomes

>>> either impossible or so difficult it isn�t reasonable.

>> What is meant by functionality not supported?. Program non-trivial
>> applications with GWT is easier than directly in javascript

GWT isn't actually a framework, it's a toolkit. But, putting that aside, I've built a complex application with GWT and I don't think their characterisation of the feasibility of doing this is at all accurate. However, things did take me longer when I was new to GWT (and not particularly familiar with css either at the time). Whether that's just the normal learning curve or something else, I can no longer tell.

Paul

[Grzegorz Kossakowski]

On Tuesday, August 2, 2011 5:18:51 PM UTC+2, Emilio Bravo wrote:

http://www.thoughtworks.com/articles/technology-radar-july-2011#Platforms

thoughtworks technology radar july 2011, talk negatively about gwt,
these are the 3 reasons:

"First, in many ways, JavaScript is more powerful and expressive than
Java, so we suspect that the generation is going in the wrong
direction."
more powerfull for that?

Scala+GWT project should address this problem bringing more expressive language (Scala) into GWT environment.

To give you a specific example, take a look at:

http://scalagwt.github.com/samples/Showcase.html#CwDatePicker

and check Source code tab. Notice how event handler is expressed:

    datePicker onValueChange { event =>
      val date = event.getValue()
      val dateString = DateTimeFormat.getMediumDateFormat().format(date)
      text.setText(dateString)
    }

A few more examples can be found in these slides:

http://goo.gl/WXCGq (check slides 23-25)

-- 

Grzegorz

[kellizer]

I agree fully with Paul's comments and I do have great respect for a number of the authors and have indeed heard them speak on a number of occasions however I do get the sense that there is an element of bias towards native javascript and, in my personal view, a lack of exposure to GWT.. 

I've been using GWT for a over 6 months now and have written a quite complex application that works very well and a great deal of that is to do with the GWT technologies- I'm not suggesting that it could not have been achieved with native javascript but that (for me) would have been much greater of a challenge than starting with GWT and I personally have not run into the negative points that the authors have raised.. 

Giving what I know now (after being exposed to GWT "in anger") - I would still continue to utilise the GWT technology on future projects as I don't believe by using javascript would give me any advantages but I do believe that it would give me a number of disadvantages (across the complete development lifecycle).    

Regards,

Ian.

  

[Grzegorz Kossakowski]

On Tuesday, August 2, 2011 5:18:51 PM UTC+2, Emilio Bravo wrote:

http://www.thoughtworks.com/articles/technology-radar-july-2011#Platforms

thoughtworks technology radar july 2011, talk negatively about gwt,
these are the 3 reasons:

"First, in many ways, JavaScript is more powerful and expressive than
Java, so we suspect that the generation is going in the wrong
direction."

Scala+GWT should help to mitigate this problem by bringing support for Scala into GWT.

Some promising examples how Scala helps can be found for example here:

http://scalagwt.github.com/samples/Showcase.html#CwDatePicker

If you take a look at source tab you'll see:

    datePicker onValueChange { event =>

      val date = event.getValue()

      val dateString = DateTimeFormat.getMediumDateFormat().format(date)

      text.setText(dateString)

    }

More examples can be found those slides:

http://goo.gl/WXCGq (slides 23-25)

-- 

Grzegorz