Re: Why use GWT?
I do the same but i hold all my gwt modules in a single project. One of these gwt modules is the common module. Named Common . hehe I don't need to jar anything in order to be shared. And eclipse helps refactoring things from one module to the Common. All modules are compiled and errors are showed from all modules at the same time. sorry my english. On 26 nov, 00:56, rakesh wagh [EMAIL PROTECTED] wrote: my bad... that was a typo which i realized only after clicking the send button(and was too lazy to post the second response). just include the js = just include the jar. Following attributes in your gwt.xml while in development simplify compile some what: set-property name=user.agent value=ie6 / set-property name=gwt.suppressNonStaticFinalFieldWarnings value=true / On Nov 24, 2:23 pm, adam [EMAIL PROTECTED] wrote: 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,rakeshwagh[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%
Re: Why use GWT?
my bad... that was a typo which i realized only after clicking the send button(and was too lazy to post the second response). just include the js = just include the jar. Following attributes in your gwt.xml while in development simplify compile some what: set-property name=user.agent value=ie6 / set-property name=gwt.suppressNonStaticFinalFieldWarnings value=true / On Nov 24, 2:23 pm, adam [EMAIL PROTECTED] wrote: 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,rakeshwagh[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
Re: Why use GWT?
Adam, did you even try GWT? Because if you had developed a 3-4 screen application with server connectivity you would have already answered your question. I will not do gwt-jquery comparison here, but just few cents about gwt itself. That who is using list is incomplete. I can bet you that gwt's who 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's list you posted is not created by google or the gwt team. 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. GWT is 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 understand gwt much faster than some one who doesn't. Very fast, here are some basic advantages that make gwt a 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 make GWT even better. - Check smart gwt or ext gwt for really rich widgets. - Couple gwt with 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 with gwt most of the time. - Some really great features that are unique to gwt: 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 then gwt's rpc. 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 all gwt rocks!! 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). Else use one of the ready to go widget libraries, try smart gwt. Rakesh Wagh On Nov 22, 8:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythat lots of 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
For what it's worth, there's a Josh Bloch video where he talks about javascript vs gwt. Clearly he's a java hacker, but still interesting: Starts at 5:40 http://www.youtube.com/watch?v=RR1E5zO-eBo I really think the reluctance to pickup gwt (and use other toolkits) are strong anti-java, pro-dynamic language, anti-static-type language preferences. There are just so many reasons to use gwt, as long as you can tollerate java. On Nov 24, 10:05 am, rakesh wagh [EMAIL PROTECTED] wrote: Adam, did you even try GWT? Because if you had developed a 3-4 screen application with server connectivity you would have already answered your question. I will not do gwt-jquery comparison here, but just few cents about gwt itself. That who is using list is incomplete. I can bet you that gwt's who 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's list you posted is not created by google or the gwt team. 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. GWT is 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 understand gwt much faster than some one who doesn't. Very fast, here are some basic advantages that make gwt a 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 make GWT even better. - Check smart gwt or ext gwt for really rich widgets. - Couple gwt with 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 with gwt most of the time. - Some really great features that are unique to gwt: 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 then gwt's rpc. 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 all gwt rocks!! 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). Else use one of the ready to go widget libraries, try smart gwt. Rakesh Wagh On Nov 22, 8:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythatlots of 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
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
Re: Why use GWT?
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
Re: Why use GWT?
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
Re: Why use GWT?
First a couple of rhetorical questions to you: a) why do you think JQuery and GWT are equivalent? b) why do you think the sites of the JQuery list are probably led by some smart, deep-thinking, open-minded individuals (IBM's web site might not necessarily be built by IBM)? c) why do you think the GWT list you pointed to is definitive? (try this as at least one update: http://www.gwtsite.com/whos-using-gwt/) You use the tools appropriate to the job and for which is the least cost to you. To me, JQuery is a simple library best suited to evolving aspects to a web site using the JavaScript language; GWT is more suited to building applications and is more than just using Java - you get, amongst other things: a) One base code that drives code for all browsers with the well managed approach called deferred binding when you hit across a situation where one browser (we know the now) does things differently - driving down you costs of development. b) The same code for browsers can quickly become widgets and gadgets, using different linkers - again driving down cost of development. c) You use modern development practices and tools - IDE with autocomplete, refactoring, JUnit, Maven, Ant etc - there's a real reason why we've enhanced software development over the years to invent and use these tools; they will drive down costs for (complicated) developments. d) You get generators that allow you to combine / generate new stuff from source stuff - ok that's vague, but this is a real example of where GWT is more than just a Java to JavaScript compiler. You get ImageBundles, meaning in source you manage your images separately and you let GWT pull those together into one image at compile time that can be accessed as sprites in run-time - you save wire-space, cut down on server requests meaning increased user experience, and there are more like this is on the way. Yes you can do all this by hand, but that all costs time and money, with GWT it comes for free when hitting the compile button. e) Same language client and sever side, but with flexibility to use whatever server side you want. f) Aggressive reduction in code size from libraries, both your own and/ or 3rd party libraries - all decreasing load size and increasing user experience g) Ability (soon) seemlessly defer loading of functionality until it's needed - i.e. if you have a 4 tab application load only the code for tabs as they are needed - again decreasing initial application load and increasing user experience h) I would argue in Java it is easier to see how to defer creation of objects in order to decrease initialisation time of applications - maybe that is just me, but the ability to use IDE and refactoring to support this greatly helps. Look at the sites on your JQuery list, and most are really web sites/ pages that are using JQuery to add some fancy effects or some manipulation of DOM - it doesn't identify, for example, how much of the site uses JQuery - whereas your GWT list is pure GWT applications on mostly the whole site; the lists are not really comparable in terms of functionality; I do though, get your point on why aren't IBM, Dell, BBC using GWT - the answer I suggest is three-fold a) These are (mostly) web sites not web applications and have lots of legacy content. They are going to possibly struggle to justify the benefit of GWT in comparison to cost already sunk, and a large number of them don't need to - why move to mechanised looms if your comfortable with your current cloth being produced? b) Look at the basic purpose of most of those sites, especially the featured ones; they are effectively brand advertising, and as such need to be indexed by search engines otherwise their return on investment is zero. JQuery is good at keeping that, as you generally load HTML which is then manipulated by JavaScript - this way, the search engine can index the HTML and the user sees a slightly flashier version. Sure, you can do a similar thing with GWT but not in such an elegant manner - but the point of GWT is to build applications not web sites. c) The teams behind it would probably need investement in retooling and training to use GWT and certainly given the first point above, this cost could outweigh any benefit. If you're building a new web application, then GWT is certainly a top candidate that should be investigated, why would you not want something that is promising to cut down your overall through life costs (apart from the cost of retooling your team)? I would also argue that with GWT you can build more complicated web applications simpler than you could with JQuery. For example, look at Chronoscope (http://timepedia.org/chronoscope/) and it's associated blog to see how it was developed and available in many many different forms from single GWT base. What would be fascinating to see is the results of an actual study on the comaprison of the development of a web application using several of the competing and complimentary
Re: Why use GWT?
I think this is absolutely right: I do though, get your point on why aren't IBM, Dell, BBC using GWT - the answer I suggest is three-fold a) These are (mostly) web sites not web applications and have lots of legacy content. They are going to possibly struggle to justify the benefit of GWT in comparison to cost already sunk, and a large number of them don't need to - why move to mechanised looms if your comfortable with your current cloth being produced? b) Look at the basic purpose of most of those sites, especially the featured ones; they are effectively brand advertising, and as such need to be indexed by search engines otherwise their return on investment is zero. JQuery is good at keeping that, as you generally load HTML which is then manipulated by JavaScript - this way, the search engine can index the HTML and the user sees a slightly flashier version. Sure, you can do a similar thing with GWT but not in such an elegant manner - but the point of GWT is to build applications not web sites. Also big sites that are applications (the Amazons etc of this world) are not going to rewrite everything just like that. For building a new RIA, for building new business applications or for building replacement browser UI to existing back end business systems, GWT is a very strong candidate. regards gregor c) The teams behind it would probably need investement in retooling and training to use GWT and certainly given the first point above, this cost could outweigh any benefit. If you're building a new web application, then GWT is certainly a top candidate that should be investigated, why would you not want something that is promising to cut down your overall through life costs (apart from the cost of retooling your team)? I would also argue that with GWT you can build more complicated web applications simpler than you could with JQuery. For example, look at Chronoscope (http://timepedia.org/chronoscope/) and it's associated blog to see how it was developed and available in many many different forms from single GWT base. What would be fascinating to see is the results of an actual study on the comaprison of the development of a web application using several of the competing and complimentary libraries/toolkits/frameworks. So back to the first point, use the tool that is most appropriate for what has to be done, within the constraints you may have and the expectations users/client has. //Adam On 23 Nov, 07:42, adam [EMAIL PROTECTED] wrote: I'm not sure which people you're talking about, but I can't believe that the people who head large projects like the ones mentioned in the jQuery link don't update their knowledge of available tools and their development status on a regular basis. I think the answer must lie elsewhere. On Nov 22, 10:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From what I've seen is that a lot of people looked at GWT in it's really early stages and never really thought Hey, they're probably adding features and making everything work easier so they don't end up looking back at it. On Nov 22, 9:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythatlotsofbig 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? If so, why? If this has already been covered in another post, please point me to it; no need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
Thats one hell of a explanation from adam.. I think that content should be pointed at everybody who wants to know WHY GWT? Ajay --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
Thanks for writing a very balanced and clear-headed response. code is, how much easier would it be for you to have done it in JQuery? Well, I'm about to find out empirically. I'm not sure -- it might end up being a draw for my particular application -- but it will at least be a learning experience. I'll try to remember to keep track of my impressions and post them for others to benefit. Adam On Nov 23, 10:57 am, Adam T [EMAIL PROTECTED] wrote: I wouldn't say contradiction, I believe all aspects mentioned (inertia/retooling/SEO/experience/through life cost/future development cost/others) all combine to inform the decision of what technology to eventually use. In certain circumstances some aspects will weigh higher than others. Your example is a good case in point - did GWT naturally fit your design? How easy was it to do, how managed do you feel the resulting code is, how much easier would it be for you to have done it in JQuery? How much do you think your design was influenced by thinking of a GWT application as a multi-page app as opposed to a single page one? How much more complex is your application to some of those examples shown using JQuery? There are many questions that feed into stuff, which makes it hard to say why one is better than another. Though, if I'm going to build a complex application from scratch, then I would evaluate other technologies on a basis of why would I use it instead of GWT as I think GWT should be the starting point that others need to reach. Right now I would say the world is JavaScript focussed and there are many JavaScript coders out there, and hence the natural choice is JavaScript libraries. As we push the boundaries on complexity, so we need better and better tools/environments etc, and I believe GWT is well placed for when complexity catches up. Just for interest, there is a JQuery library for GWT:http://code.google.com/p/gwtquery/ //Adam On 23 Nov, 16:16, adam [EMAIL PROTECTED] wrote: Adam T, Thank you for your thorough and thoughtful explanation. There appears to be a contradiction running through the thread of your explanation and I'm wondering if you or anyone else would like to comment on it. You write: version. Sure, you can do a similar thing with GWT but not in such an elegant manner - but the point of GWT is to build applications not web sites. This seems to imply that the awkwardness of using GWT with traditional web sites -- ones whose separate pages are requested from a server -- may be a good reason to choose non-GWT tools for them. This would mean that the creators of the sites listed on the jQuery site are not refraining from using GWT on account of inertia or the cost/benefit ratio of training and retooling, as you suggest elsewhere in your reply. Rather they would be using the result of a decision-making process that, given the necessity of SEO as a premise, concludes it's necessary to create a web site rather than a web application and chooses a non-GWT javascript solution on account of its relative elegance. I've actually created web sites (again, separate html pages generated on server) using GWT. My strategy has been to include a javascript variable in a script block on each page, the string value of which corresponds to an Enum defined in GWT-generated code. As a given page loads, that variable is read by a JSNI call in my EntryPoint and, in a long switch based on the value of the Enum, a PageView subclass is instantiated. The PageView -- which is coded in GWT, of course -- in turn widgetizes parts of the html or generates widgets to insert into html placeholders. It also instantiates a PageController subclass, again coded in GWT. The way I see it, I am a creating a web app, albeit one whose execution environment (i.e. html content) is constructed differently by my server-side JSP code on each page load. It's been a few years since I've created a hand-coded Javascript app, but I think I'm going to give it a shot. Although this doesn't really amount to a study, I would be very happy to thoughtfully analyze the results and post them here. Thanks again for your very complete response, Adam On Nov 23, 3:37 am, Adam T [EMAIL PROTECTED] wrote: First a couple of rhetorical questions to you: a) why do you think JQuery and GWT are equivalent? b) why do you think the sites of the JQuery list are probably led by some smart, deep-thinking, open-minded individuals (IBM's web site might not necessarily be built by IBM)? c) why do you think the GWT list you pointed to is definitive? (try this as at least one update:http://www.gwtsite.com/whos-using-gwt/) You use the tools appropriate to the job and for which is the least cost to you. To me, JQuery is a simple library best suited to evolving aspects to a web site using the JavaScript language; GWT is more suited to building applications
Re: Why use GWT?
gwt's pretty amazing, but I think it takes a good six months to really understand it all. If the implementors of those sites hate typing and hate java, they'll never get to the point where they appreciate gwt. Seems to be there's a strong anti-Java sentiment these days. Big, static typed languages aren't that cool now, and people are able to make nice apps in dynamic languages (Ruby, Javascript). Churning java into javascript is kind of weird (or at least novel) and it takes a while to really get it. jQuery is tight -- you can do a lot in one line of code. That sort of stuff wins developers over. To me, gwt realy comes down to turning java into really tight cross- browser javascript with clean abstractions for ajax'y apps. If that's not a sale for you (ie, you hate java), then jQuery is probably the next stop in the evaluation path. On Nov 22, 9:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythat lots of 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? If so, why? If this has already been covered in another post, please point me to it; no need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
I found this list VERY IMPRESSIVE! http://instantiations.com/mktg/customers_gwtd.html Cheers, Scott On Nov 22, 8:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythat lots of 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? If so, why? If this has already been covered in another post, please point me to it; no need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
From what I've seen is that a lot of people looked at GWT in it's really early stages and never really thought Hey, they're probably adding features and making everything work easier so they don't end up looking back at it. On Nov 22, 9:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythat lots of 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? If so, why? If this has already been covered in another post, please point me to it; no need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why use GWT?
I'm not sure which people you're talking about, but I can't believe that the people who head large projects like the ones mentioned in the jQuery link don't update their knowledge of available tools and their development status on a regular basis. I think the answer must lie elsewhere. On Nov 22, 10:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From what I've seen is that a lot of people looked at GWT in it's really early stages and never really thought Hey, they're probably adding features and making everything work easier so they don't end up looking back at it. On Nov 22, 9:58 pm, adam [EMAIL PROTECTED] wrote: I see herehttp://docs.jquery.com/Sites_Using_jQuerythatlots of 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 using GWThttp://www.ociweb.com/mark/programming/GWT.html#WhoIsUsingItdoesn't look as impressive. Why are leaders on big projects deciding to use tools other than GWT? Do they have any good reasons to not use GWT? Should they use GWT? If so, why? If this has already been covered in another post, please point me to it; no need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
