Well..
> We looked at this and it seems reasonably simple to get the Widgets > working under a pure jsinterop+System.getProperty world. Simple but > labour intensive. You could do it now if you wanted to prepare for > GWT3. > > Everything is possible if we do not. Fork GWT or any part of it and make it our own. The problem is that then it has no common direction of evolution and it becomes proprietary. Even if we open-source that we're still disconnected from the main development and may stop working at any time. > We use UIBinder extensively and that is probably easy enough to get > 95% converted to APT. However I do recall there being a bunch of > scenarios where it becomes harder - although what they were slips my > mind atm. In that case we are likely to just implement the subset and > generate errors if there is any of those scenarios in our code. > > Good for you. May not be good for someone else (we do not use UiBinder). The problem we have is that we are not the last in line of dependencies. While, with some large effort, it is possible to migrate any code you own entirely to anything else, this isn't the case if you have downstream dependents in form of external customers and partners. We do. > I have no idea what shape the client bundles would end up in but I > suspect we would move to using wrappers for whatever tool bundled the > javascript be it webpack or closure (does it have a bundling tool?) or > whatever. I love some of the css-in-js stuff happening in javascript > land - (See > https://markdalgleish.github.io/presentation-a-unified-styling-language > for an overview). I certainly see some significant advantages about > changing the way we do stuff here. > > Going forward this may be good for some. My previous comment applies here too. Even if we could "move", we cannot force others to. > > How to reasonably accomplish GWT RPC serialization (all of it)? > > It is unfortunate that you have used this feature but I can't see it > ever being implemented by google or the community at large. Why is it unfortunate? It works. It is efficient (code). It requires the least effort to use. It is NOT for the API but for internal communication. > Most frameworks based on language/framework specific serialization > strategies tend to fail, often due to the difficulty of interacting > from other platforms or difficult evolving code on the same platform. > Java RMI is largely unused these days. Maybe now is the time to move > to something different*. > Who says there is a need to interact with other platforms or languages? We do have other solutions for that. But we have/had a better approach for our internal Java-to-Java communication. We don't use Java RMI for the same reason we don't want the outer part of GWT RPC. That is, for us, replaceable. It is the serialization that is important. And, arguably, Java serialization is NO different than any other except: - It encapsulates control of serialization in a common way for all classes and in the language syntax - Its wire format is (somewhat) flexible by using an appropriate (sub)type of object stream - It works without having to code special access to default/private/protected fields or resorting to hacks that work around it - It completely and safely matches the language semantics w.r.t. primitive and complex types and null (or undefined), etc. - It works whatever frameworks different libraries you use use themselves Sure, it does not put field names into the stream but that would be an inefficiency and not desirable in many cases. It is important for public APIs, but not for internal communication. Do NOT confuse GWT RPC with public API exposure framework. We all agree that it isn't for that, never meant for that. > > -- 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/827e32db-2838-46fa-8c8c-2940511b1359%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
