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
--
You received this message because you are subscribed to the Google Groups "Google
Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
