Also, you should never preselect a tool to match the requirements. One major requirement often over looked is the ongoing MX costs, therefore you should only change tools if there is a major driver to select something which will lower your long term costs. Never select a technology for just the sake of a technology, have a reason.
In my opinion, the "problems" Thoughtworks has with GWT are exactly its strengths. It is a large complex framework which encourages specific patterns and types of development needed by larger and more complex projects. The quick, dirty and small applications which Thoughtworks advocates in the article are a MX nightmare of one of custom code jobs, especially in a large organization with complex requirements.
Lastly, in terms of Spring and Angular, they meet specific goals. Decide what you are trying to do and then determine if you want/need to use the tools. How do they help you? Never just use a tool because.
Tim
On Aug 8, 2014, at 1:36 PM, Axel Regnoult <regnou.a@gmail.com> wrote:
Hi,I am asking about the future of GWT.... (here, in France, it does not seem that is have a so good reputation, but this is just my feeling)I have read this article : http://www.thoughtworks.com/radar/platforms/gwt (the citation is at the end of this mail)Martin Fowler, a worldwide reconized expert is working at Thoughtworks, so I think their opinions are well thinked...and I would like to know the opinion of some gwt gurus about it...I have used GWT 3 years and I personally liked it; but my lack of experience in other frameworks doesn t allow me to give an opinion. And I am asking if I should use, and learn, for exemple Spring, or Angular.js to develop my next application...Thanks you,AxelGWT is a reasonable implementation of a poor architectural choice. GWT attempts to hide many of the details of the web as a platform by creating desktop metaphors in Java and generating JavaScript code to implement them. First, in many ways, JavaScript is more powerful and expressive than Java, so we suspect that the generation is going in the wrong direction. 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. 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.....Google Web Toolkit (GWT) offers an interesting premise: write Swing-like Java code and generate unit testable JavaScript widgets and user interfaces. From a practical standpoint this doesn't work well. First, using code-gen to produce the artifacts is time consuming, artificially extending build times and requiring manual changes to obtain optimal package layout. Second, if the JavaScript doesn't behave exactly as you want you will have to hack the generated code. Third, using Java to generate JavaScript means that you can't take direct advantage of the powerful features of JavaScript or numerous libraries such as JQuery. Finally, the JUnit support is quite limited, for example code using reflection cannot be tested.--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment