Hi there! I am faced with having to re-think what we are doing in the company I work for with respect to GWT, existing and new projects and I am struggling, to say the least. We've been very much a GWT shop for years now and have used it to expedite the development of very large solutions and improve the end user experience. We did this and this was possible because:
1. There is (was?) a *visible* big name behind the technology - Google. There were regular updates and a lively community. 2. It allowed us to share a lot of code between the client and the server properly and use a programming language suitable for very large software - strong typing, encapsulation/visibility control and all the works. JavaScript just isn't an option - it isn;t even a thought with all the enhancements they are making. 3. It allowed us to cleanly and efficiently segregate and encapsulate functional responsibilities of both business and representation code. We were able to create a foundation with clean APIs that other teams build their modules on top - and we bring those modules together. We can evolve that foundation and dramatically change it looks beyond just CSS because we encapsulated units of UI into widgets and we came up with the means to aggregate client-server communication from all modules into single requests/responses via serialization (we otherwise used GWT RPC very little - there is a single service with a single method in there). 4. It offered integrated code optimization and debugging tools with what seemed to be a promising future vision and dedication. We've been following what is going on with GWT 3.0 and, admittedly, didn't like it. However, we were hoping that our problems are common and that it will become apparent that GWT 3.0 vision needs some adjustments. We've observed other people communicating similar perspectives to ours. Unfortunately, we've also seen little acceptance of these comments, little action and, essentially, no direction with respect to those beyond "waiting to see what happens with GWT 3.0". We believe that this effective limbo is, at least, a big part of the reason for frequent statements like "GWT is dead, past its time" and abandoning the technology simple because they have to move forward but are left behind. I/we perfectly *understand *the reasons why one would want to do things planned for GWT 3.0. Removals of GWT RPC and widgets can simplify some code and increase the performance of the tools, among other things. At the same time, I believe that the perspective taken to decide what to do is wrong. Instead of finding ways to simplify GWT at the expense of making GWT-based products more complex and loosing any chance of being compatible with pre-3.0 code, efforts should have been focused on solving the problems. I know that these problems are hard, but they are also *possible* to solve. I know because I made solutions to similar problems. Yes, new GWT may produce code faster and it may produce faster code and it may interoperate better with the browser and JavaScript. But consider the following: 1. For perfect interoperability with JavaScript one can use JavaScript or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM. 2. For sharing code with the server, some people use node.js (I do not subscribe to this) but there are other options - JSweet, TeaVM, possibly Dragome and others. 3. For runtime performance of the code written in Java (via optimizations and otherwise), TeaVM seems to yield better performance than GWT with JavaScript output and also has experimental support for WebAssembly, which yields about double the performance on some tests I've seen. One could offer both options, to support browsers that can't do WebAssembly. 4. If one is forced to use external frameworks for serialization they don't get any benefits from GWT that other alternatives don't also get. 5. In terms of tooling - GWT seems to, now, be the worst. Super Dev Mode proved to be essentially a failure because one does not really see the data that matches the code. Runtime performance still suffers and debugger often freezes for long periods of time doing who-knows-what if/when breakpoints are set or we're stepping through code. Coding in JavaScript directly means what-you-see-is-what you get and no wait times. Other solutions offer their custom tooling which seem to be possibly better, at least on paper (did not check, so cannot verify yet). JSweet and TeaVM translation is much faster than GWT is, even without GWT RPC. TeaVM does not require source code, which is better for companies who need to deliver a module but keep the source closed. GWT needs *both* source and binaries... 6. If we're to work directly with the metal, similar to how JavaScript frameworks do things, then again - JSweet may be a better fit, possibly TeaVM. Neither has widgets in a sense GWT does/did. Put it simply, GWT 3.0 does not seem offer a path for existing users, does not have much novel for brand new users that isn't already available othewise *and better*, takes more time to do whatever it does and slows down the development and is losing trustworthiness - what guarantees that, if I start with GWT 3, I won't be left stranded when GWT 4 comes out... if it ever will? So, who is GWT 3.0 for? Who will use it? Does this mean that there really is no vision about how GWT can truly evolve and grow? If so, let me offer some of my challenges that would be best solved or need to be solved in GWT, in no particular order. 1. Simulate synchronicity even for what would be, under the hood, asynchronous calls. See TeaVM for how multithreading is supported in it, Thread.yield() and related. We know why things must be asynchronous in JavaScript, but that does not mean that this has to be exposed as such in the Java world - a Java method could "block" at a call only to continue when a relevant event is triggered. This would go a long way to simplifying the code and increasing how much code can be shared between the client and the server without exposing the server to unnecessary asynchronicity or the client with synchronous methods that may/will not work. 2. Doing the above will let you improve code splitting as you will be able to load code at any point, not just at GWT.runAsync() points. It will open up other possibilities of driving how the code is split - e.g. perhaps per module, project or package. 3. Separate widgets into an optional module but definitely keep them going. They are important. They are used, both directly and via 3rd party libraries. 4. If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization. This is possible in TeaVM with its "Metaprogramming API". Arguments that "it is hard" are not helpful and "I don't need it" may apply to a class of users who really don't need GWT at all or are not creating very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but allowing matching OWN client and server code to communicate. Do include the means to store discovered relationships so that they don't have to be discovered again. Allow polymorphic serialization one way or another via specific annotations. Whether done internally or externally, rethink RPC with respect to (1) - synchronicity emulation and what plumbing code needs to be written. There is a discussion about these things in https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ 5. Bring back (something like) *.gwtar files. Even better, replace them with something that will be self-sufficient and *not* have the original source code in it. This would be very useful for both increasing the compilation performance and for delivering closed-source modules. 6. Deferred binding and code generators are something we do not use *directly *as we tried to be as "clean" as possible. As I am propagating compatibility, you should not remove this but do provide means to not depend on it. That may have a significant performance impact too. 7. JSNI methods in comments were nice but are the *only thing* that truly *requires* the source code. Find other ways of doing this, such as via annotations or separate files, e.g. for each Foo.java there may be Foo.jsni 8. Think about how would one support post-development (e.g. install-time or run-time) linking of multiple modules. For example, we build our foundation product, but our partners build plugins for it. Customer chooses and installs plugins they want. Right now this forces us to do a GWT compilation step at that time and it is painfully long. (from the customer perspective). We are trying to hide this cost in various ways (store results, reuse them across nodes, etc.) but I am sure you can figure out the challenges. Since these modules only communicate via dedicated APIs, obfuscation can be limited to the implementation only and/or there can be an overlay of "exported" symbol maps for cross-module calls. This is a very similar "problem" to Java class file obfuscation so nothing new. 9. Clean up the tooling. Stop embedding everything in a single monolithic jar, update code coverage tool support. Rethink debugging - perhaps leverage existing work done outside GWT for this? Separate the classpath of the compiler from what it is supposed to compile. These are not the same thing and cause grief. Without the above, what seems to be a closer alternative to existing GWT 2.x users is a separate fork of GWT (that may not be coming any time soon) or a TeaVM enriched with a fork of GWT widgets and a module doing GWT RPC (possible!). It does not have code splitting support (yet) and, likely, no desire (or need) for "permutations" and related concepts. That would require widget libraries to be rewritten with that in mind, but that would be *possible* and would, it seems, yield a better dev environment with a better performing end result. I don't want to see GWT fail. We have our future depending on it and, if we can't use it, I presently don't know what we can do. But we cannot use GWT 3.0. Remember - "I don't need it" is not the same as "Nobody needs it" and "shouldn't need it" is a matter of perspective typically uttered by those who don't create projects as complex as many of us others do. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/59e72304-d23c-4d60-9d9f-2586c7096edf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
