I will agree on the final thing about listeners and feel that it is more of personal preference. In my experience we had good luck and happy results using listeners to decouple our widgets and hence screens. Basically like any other java based application you need a lead in your team who will always take care of the over all design and make sure that listeners are not abused; that parents do not pass themselves as references to the child for purpose of method invocation; and many other best practice that come by little practice. With gwt, client side programming deserves equal or more respect(hence design and lead resources) compared to its server side counter part.
About the size of generated javascript code. As I said I am not going to go in comparison with any other lib, because that would be apple vs bananas(I love both fruits btw). If your app is compiled as 160kb js, I think it is not huge. It is probably just okay. The best thing I like about gwt is that it does not include a static gwt.js of its own (like most other toolkits does, take dojo for instance). Gwt maps your java code as effeciently as possible to corresponding javascript(again without including its own static js lib). I agree with you that lazy loading would be a good idea. Moreover I also agree with you that hosted mode refresh time sucks as your app size increaseas(and that happens pretty soon!). We all face this issue, and I think that gwt team will put a solution in coming months. See my comments in this thread: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/604aec6b7460c133/950c73ed1d98ae3a?hl=en#950c73ed1d98ae3a Here are some suggestions: 1. Use modules right from the beginning if possible. If you could divide your project into distinct modules that do not rely on each other, do it! A good example is managing administration activities could be a separate module. This way you take away the load from main application. 2. Create a "separate project" for common gwt widgets. If you are relying on vanilla gwt for widgets(not using gwt-ext etc), you would most probably end up writing lot of common widgets that you would like to re use in your project. We created a separate project just for this purpose. So whenever we write a reusable(1+ times) widget, we go to this common project, do our development, test it in hosted mode(with a demo app) and just include the js. This way we shift at least 30% of our development to this very small project that is easy on hosted mode refresh, debugging, and over all development. I hope you get my point here. 3. use lazy initialization of variable where ever possible. This reduces lot of start up time. 4. At time of development compile only for IE(through a property in gwt ex More over we created a entirely different project that would contain the common widgets that we develop and can be reused. I think Finally: - I reiterate, it is futile to compare gwt with any other js libraries. For us, gwt eliminates the use of many server side layers and xml configurations etc that we would traditionally do in a struts like app framework. - If I am allowed to be philosophical: "GWT is a change in paradigm for web app developments" - It also makes our server side code simple to a level where we have to just provide the implementation to a bunch of interface methods. Our server and client teams can work totally independent of each other. - Moreover when we float requirement, all we need is a person who is good in java, and nothing else.(yes there is a learning curve for this person, but that is true with any thing else). - Before gwt, javascript was my personal favorite for the flexibility and ease of that language. However it didn't take me to long to realize how nasty it would get to debug others code and how difficult does it get to add new features to a already written js based application. Frankly it is a nightmare and ppl tend to stay away from touching pre written js based applications. - Last year we developed a gwt based application and shipped it offshore for maintenance and the response from our offshore team was really good(compared to our earlier experiences). All were new to gwt but they could go in and do bug fixes and add new features without much hand holding(and without hating or messing the existing code). Rakesh Wagh On Nov 24, 11:20 am, adam <[EMAIL PROTECTED]> wrote: > Hi Rakesh, Thanks for your response. > > > Adam, did you even tryGWT? > > As I said earlier in this thread, I've developed applications in GWT. > My most recent one (still in development) is matchomat.com. This > application has some rollover buttons, dialogs, form checking, gwt > rpc, history, and it even uses gwt-coded jsonp to communicate with an > erlang server. All of the js is written in GWT. I described the client- > side architecture in the reply to Adam T earlier in this thread. I've > also made a large pure-GWT-history app before. > > > created by jquery itself.gwt'slist you posted is not created by > > google or thegwtteam. > > They should really post a list! > > > - Generated js is super-super fast and tiny(relatively)! You end up > > writing fast and small apps. compare it with flex and or any other > > toolkit of your choice. (btw, comparing it with lo level libs like > > prototype.js is wrong) > > The javascript for matchomat, which is compiled in obfuscated mode, is > around 160kb. I don't like having to wait at my browser for all this > javascript to load. Take a look at Netflix or Facebook; very ajax-y > and yet they seem to load instantaneously. I believe I could have hand- > coded essentially identical functionality for matchomat with a smaller > javascript file had I been using a js toolkit like jquery. > Furthermore, Flex allows you to dynamically load modules -- I do this > in langolab.com. Although GWT.runAsync is in the trunk, it hasn't been > released yet. I have a friend who is on a team creating a b2b gwt app > where the monolithic javascript file weighs in at over a megabyte. > This is untenable for a public-facing app. > > > - Every thing is so modular and object oriented. you can write long > > lasting apps and manage huge application easily. > > I respectfully disagree with you. First of all, to run my project in > hosted mode I have to wait about 30 seconds for java->js compilation. > This may not sound like a lot but I feel like it really interrupts my > design->debug->design cycle. With hand-coded javascript, there is no > need for this extra compilation step. In order to test my app on other > browsers with GWT, I need to compile in web mode, which takes about > 1-3 minutes on my very very fast machine. > > > - Creating reusable widgets is a snap. And that is what you do withgwtmost > > of the time. > > Although creating them is a snap, as we noted earlier in this thread > actually using them in an app where html is generated on the server > (like, for SEO) can be a PITA, at least with all techniques that I > think of. It must especially be a PITA with very large apps that > consist of dozens or even hundreds of distinct pages, like the one I'm > currently starting. I wonder if anyone else has some thoughts about > how to ease the pain of using GWT with apps like these. > > > - Some really great features that are unique togwt: locale mgmt, > > history token management, image bundle, exception handling and rpc > > mechanism > > Thank you for reminding me of local mgmt, history, and the image > bundle. You are right, these are really useful features. I think I > might continue with GWT on account of these. > > > - Strongly typed java is always better compared to js. You end up > > making less mistakes as 80% errors are resolved by eclipse as you type > > your code. > > Thank you for reminding me of this also. This is a huge advantage. > > > - Never seen a better way of debugging my code. > > Firebug is pretty useful for debugging js. > > > - Listeners architecture(if you understand and implement correctly) is > > a great tool to decouple your app widgets/classes and make them more > > reusable. Great way of event handling! > > Well, actually I find it more natural to use anonymous functions in > AS3 and Javascript. I find Java's anonymous classes to be a little bit > clunky. > > Thanks again for your great reply. > > Adam > > On Nov 24, 9:05 am, rakesh wagh <[EMAIL PROTECTED]> wrote: > > > Adam, did you even tryGWT? > > Because if you had developed a 3-4 screen application with server > > connectivity you would have already answered your question. I will not > > dogwt-jquery comparison here, but just few cents aboutgwtitself. > > > That "who is using" list is incomplete. > > I can bet you thatgwt'swho is using list(if honestly made) will be > > bigger than any other ajax tech adaption. Jquery's adaption list is > > created by jquery itself.gwt'slist you posted is not created by > > google or thegwtteam. FYI, we have done more than 3(big) projects > > successfully overt the past 2 years and we do not care to be part of > > any such lists.GWTis more than a UI library, it is a paradigm shift in > > developing > > web applications. People who have spend there life in struts and other > > similar web based framework will typically take a while to understand > > this paradigm change. If you liked and respected swing and javascript > > for what ever they are, you will probably like and understandgwtmuch > > faster than some one who doesn't. Very fast, here are some basic > > advantages that makegwta toolkit of choice: > > - Google's beta releases are production quality! > > - You get answers to your question within 24 hours from a great user > > community. Like you just did for this thread! > > - Apache, A great license, without any fine prints. > > - Dozens of supporting projects, which makeGWTeven better. > > - Check smartgwtor extgwtfor really rich widgets. > > - Couplegwtwith spring and hibernate and with little plumbing you > > are dealing with only java objects from client browser to the data > > layer. > > - A very small technology and tool stack required for the entire > > project. > > - Generated js is super-super fast and tiny(relatively)! You end up > > writing fast and small apps. compare it with flex and or any other > > toolkit of your choice. (btw, comparing it with lo level libs like > > prototype.js is wrong) > > - Every thing is so modular and object oriented. you can write long > > lasting apps and manage huge application easily. > > - Creating reusable widgets is a snap. And that is what you do withgwtmost > > of the time. > > - Some really great features that are unique togwt: locale mgmt, > > history token management, image bundle, exception handling and rpc > > mechanism > > - I am yet to see a more elegant and easier way to communicate data > > back and forth the server thengwt'srpc. You send a generic arraylist > > to your client code. You cannot beat this! > > - Strongly typed java is always better compared to js. You end up > > making less mistakes as 80% errors are resolved by eclipse as you type > > your code. > > - Never seen a better way of debugging my code. > > - Listeners architecture(if you understand and implement correctly) is > > a great tool to decouple your app widgets/classes and make them more > > reusable. Great way of event handling! > > - Can keep going ... > > all in allgwtrocks!! > > Fine prints: There is a learning curve if you really want to build > > long lasting production ready code(depends on your java experience and > > understanding of swing, layouts, event handling etc). Elseuseone of > > the ready to go widget libraries, try smartgwt. > > > Rakesh Wagh > > > On Nov 22, 8:58 pm, adam <[EMAIL PROTECTED]> wrote: > > > > I see herehttp://docs.jquery.com/Sites_Using_jQuerythatlotsof big > > > projects, most of which are probably led by some smart, deep-thinking, > > > open-minded individuals, are using jQuery and hand-written javascript. > > > I notice that this list of projects > > > usingGWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't > > > look as impressive. > > > > Why are leaders on big projects deciding tousetools other thanGWT? > > > Do they have any good reasons to notuseGWT? Should theyuseGWT? If > > > so, why? > > > > If this has already been covered in another post, please point me to > > > it; no need to reinvent the --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
