Rakesh, This was a totally great response and I'm really thankful that you took the time to write it.
> 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. I see what you mean, but it's often pretty tough to come up with modules whose dependency graph is disconnected from the rest of the project. They do appear from time to time, I suppose. > 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. Please let me know if I understand the "just include the js" part correctly. You are saying that you keep your UI widget lib in a separate project, compile it to javascript, and then include that javascript in the html for your main project? If this is correct, how do you expose the methods? Do you just add functions to $wnd in JSNI or are you using Cromwell's GWT Exporter? I use the "passive view" pattern, which means it's usually pretty easy for me to try out my widgets in a harness; I usually keep a second module in my main Eclipse project for this purpose. > 4. At time of development compile only for IE(through a property ingwtex I'm sorry, but I didn't catch you here. I think your original message may have become a bit garbled here. Thanks again. Adam On Nov 24, 12:47 pm, rakesh wagh <[EMAIL PROTECTED]> wrote: > 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. > Withgwt, 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 aboutgwtis that it does not include a staticgwt.js of its own > (like most other toolkits does, take dojo for instance).Gwtmaps 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 thatgwt > team will put a solution in coming months. See my comments in this > thread:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa... > > Here are some suggestions: > 1.Usemodules 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 commongwtwidgets. If you are > relying on vanillagwtfor widgets(not usinggwt-ext etc), you would > most probably end up writing lot of common widgets that you would like > to reusein 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.uselazy 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 ingwtex > 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 comparegwtwith any other js > libraries. For us,gwteliminates theuseof 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: "GWTis 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). > - Beforegwt, 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 agwtbased 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 togwt > 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 inGWT. > > 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 usesgwt-coded jsonp to communicate with an > > erlang server. All of the js is written inGWT. 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. AlthoughGWT.runAsync is in the trunk, it hasn't been > > released yet. I have a friend who is on a team creating a b2bgwtapp > > 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 withGWT, 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 usingGWTwith 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 withGWTon 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 touseanonymous 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
