> > > Google didn't have any incentive to release GWT 10 years ago, or to > continue maintaining it in the open source. They've always been the main > drivers and main contributors so they could have stopped sync'ing their > internal repository to the outside work long ago; but they did just the > opposite 4 years ago, with the opensource repository being the source of > truth and them sync'ing it into their internal repository (they have a few > internal patches, such as completely removing the legacy devmode). > You're just being pessimistic here. >
I did't expect GWT 10 from Google. I understand that. But if you decide to expose something to the market at least clearly communicate the intent once you want to stop it. We haven't had that. > RedHat publishes the Errai framework, and has several tools built using > GWT (including their JBoss/Wildfly admin console if I'm not mistaken) > RedCurrent is actively using GWT (no idea how and where), and employs (at > least) 2 of the most productive contributors. > ArcBees (which you didn't cite) maintains the GWT-P framework. > There once was representatives from Sencha (Colin, then Justin), but > they're apparently putting an halt to GXT (no new development at least), > and the representatives have left the company. > RedHat/Errai seems to use GWT internally only, not expose it directly, but I may be wrong. RedCurrent - I have no idea. ArcBees GWT-P is only about the client-side. There are many alternatives to that. Sencha - I actually saw that as we are using GXT too. They also communicate vague but different picture. If GXT is truly out (and indications are that it probably is) that only means *worse*, whether GXT is of interest to someone or not - it means that they could not influence GWT on behalf of its customers. Who is there using GWT fully, exposing it downstream and not limiting it to own codebase? > The Closure Compiler is doing a better job at optimizing JavaScript. Even > if it were doing a slightly worse job, using it means freeing development > resources to work on something else. > Closure is only a part of the whole (future) toolchain though. > I don't have a problem with Closure. That is fine. It may even be a great idea to leverage it do Java to JavaScript (or other target) conversion. But that too was vague and, it seems, will be a one-shot deal - to get off the Java code. It will address the client only and not nearly as efficiently as we know is possible. > Why would it necessarily require a ton of boilerplate code? > Also, "handing all the magic in between" makes it way too easy to produce > inefficient code in terms of network usage. > > For every class that was made GWT-serializable by someone else we have to write code to wrap it in our own/new serialization frameworks. That may not be possible because we may not have sufficient access to their code and data and because we may not even be aware of their code. We'd have to introduce additional requirements to them and standard that they would have to follow and our compatibility with what they have written already goes down the drain. Joint customers don't have a path forward. We may not be able to communicate our and their objects together, in single request/responses roundtrips and may need to split them. That split introduces inefficiency. So instead of using optimized, *efficient* code created by everyone for this purpose, we are forced to eliminate that efficiency and break encapsulation and write more boilerplate code that runs slower. This is making it easier to translate code to JavaScript *but has nothing GOOD to do with efficiency.* If something is needed, it is needed. You can't just write it off and say that it is more efficient without it. Without it it does not work and would need to be replaced with something else. You think that something else will be more efficient? Think again. You think that developer time is cheaper than tool time? I know you don't. But this perspective may have been missed in GWT future planning. I wonder if there is a way to identify other heavy GWT users that actually have a vested interest in its future... The approach can be better than anything else on the market, but the ball is being dropped. I realize it may be too late to pick it up. Just thinking. -- 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/ef0b6c62-c717-40e9-949f-261584ae926e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
