If you just want to run java apps in the browser there are solutions out thtere Free: http://www.webswing.org Paying: http://www.creamtec.com/products/ajaxswing/overview.html
Now if you want to run create webapps then it is another matter. For me the web stack is a crazy platform. But still since it is backed by all these people (us, developers) is the __platform__ and if you want to write for the __platform__ then you have to speak the platform language natively. That is HTML, CSS, JS. All the new cool things, the new UI paradigms the new libraries the new API are happening in browser-land in JS. I think that the GWT did the right thing with the super dev mode. I develop in chromium and firefox. I occasionally test in IE and in Safari to deal with the weird platform idiosyncrasies (bugs?). I also test less often in mobile devices to get the touch events more or less right. How I am about to test all these things in classic dev mode with Firefox 24? Why do I need a java debugger when my main problem is not on the logical end of my program but on the assumptions my program makes for the platform it runs on? (Why the event didn't fire? Why it did fire multiple times? What does preventDefault() does in this case? Why there are extra padding? Where the hell is my padding? Who painted my pixels?) About the fork you mentioned. I think the GWT is on the right track also on this one. I am slowly phasing out the use of gwt widgets not because I want to, not because they are not working good enough. They are perfectly fine for me but my users want more shiny toys i.e. rotary dials instead of menus and drawers instead of pull down menus or menubars. And you have to admit the GWT widgets are somewhat rusty - most of them are designed with tables and they are impossible to change without breaking compatibility. So I believe a division of GWT to GWT-compiler and GWT-widgets as a separate compatible library is not a bad move especially if it accompanied with a better ([semi] automatic) way to interface new and cool JS libraries like JSInterop claims to be. It makes perfect sense to me. On Mon, Oct 19, 2015 at 9:39 AM, salk31 <sal...@gmail.com> wrote: > Maybe there is effectively going to be a fork? So if the interest was > there could be GWT 2.9 - GWT 2.123 > > I think that might represent the truth that there is one user base that > wants to build Java apps that happen to run in a browser vs users who are > working on products that need to squeeze everything out of the browser. > > The discussion about classic dev mode didn't seem very healthy > https://groups.google.com/forum/#!topic/google-web-toolkit/QSEjbhhHB4g > maybe because of this split? > > > > On Sunday, October 18, 2015 at 5:13:12 PM UTC+1, steve Zara wrote: >> >> I'm eager for GWT 2.8 because of Lambda support, but I can't see that my >> company will ever use GWT 3.0 if what you write is true. We have products >> that make substantial use of GWT Widgets, and there is no prospect of >> re-writing to some other system. GWT without the Widgets just isn't GWT - >> it's just a Java -> JavaScript transpiler. We also use UIBinder heavily. >> >> Of course, this may not be what happens. It's a symptom of what seems to >> be a common problem with GWT - lack of clear information about what is >> happening with the project (still no sign of GWT 2.8, and no indication of >> when there might be a sign). >> >> GWT really is wonderful and has been a source of great productivity for >> my company for many years. I really hope the heart of it isn't slashed out >> to produce some incompatible new version. >> >> On Saturday, 17 October 2015 11:36:45 UTC+1, salk31 wrote: >>> >>> Thanks Thomas, >>> >>> For my own use I'm going to keep a list of what I think I know >>> http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections >>> welcome. >>> >>> I can see why they want to reduce the scope of GWT and integrate (not >>> build) but is such a high quality complete package in 2.7 it is a bit >>> scary. I've had to use BroadVision, Vignette, Struts 1, Cocoon, Wicket... >>> in the past and GWT felt like finally web development had grown up. >>> o >>> On Friday, October 16, 2015 at 5:44:25 PM UTC+1, Thomas Broyer wrote: >>>> >>>> I think nobody has such information yet; not even Google who are >>>> pushing for the change. They do have many apps that use widgets and RPC >>>> today (example: Google Groups, the exact app I'm typing this message into) >>>> and will need to come up with a migration path for those apps too. >>>> >>>> On Friday, October 16, 2015 at 2:19:02 PM UTC+2, salk31 wrote: >>>>> >>>>> Is there a guide somewhere of migration path to 3.0 per feature? >>>>> >>>>> I've been trying to follow these threads but I'm still not sure on the >>>>> future of things like RequestFactory and Editor. They heavily depend on >>>>> GWT.create and the latter depends on Widgets, are they really going away? >>>>> >>>>> We have a large-ish app so want to start worrying about migration even >>>>> if we are long way off. >>>>> >>>>> Cheers >>>>> >>>>> Sam >>>>> >>>>> On Tuesday, July 28, 2015 at 10:01:21 AM UTC+1, Jens wrote: >>>>>> >>>>>> >>>>>> Where can I read that GWT RPC and widget system will be dropped with >>>>>>> GWT 3.0? Is there a presentation / doc online? >>>>>>> >>>>>>> And what does it mean that GWT.create will be dropped? >>>>>>> >>>>>>> And: really dropped or set as deprecated? >>>>>>> >>>>>> >>>>>> GWT 3.0 drops support for JSNI and GWT.create(). JSNI will be >>>>>> replaced with JsInterop and GWT.create() will be replaced with either >>>>>> annotation processors (generate-with case) or dependency >>>>>> injection/System.getProperty (replace-with case). So all library code of >>>>>> GWT which depends on those two features need to be ported to the new GWT >>>>>> compiler. >>>>>> >>>>>> Widget is probably doable but GWT-RPC might be really difficult (if >>>>>> not impossible) because the current GWT-RPC generator asks questions like >>>>>> "give me all types that implement XYZ" which an annotation processor can >>>>>> only hardly answer (if at all). GWT-RPC might be portable if some >>>>>> refactoring in the app using GWT-RPC is acceptable (e.g. slapping >>>>>> annotations on DTOs instead of marking them with Serializable). >>>>>> >>>>>> You can see videos about that topic from the GWT 2015 meet up at >>>>>> https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE >>>>>> >>>>>> Slides are linked in the playlist description. >>>>>> >>>>>> -- J. >>>>>> >>>>> -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@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. > -- Vassilis Virvilis -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@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.
