This is very good question and actually one of the biggest problem not only in this particular situation but also in general software development.
Imagine you decide to build something large like ERP or Banking Information system for an example (with hundreds even thousands of tables and forms) You didn’t even finish it because of its complexity and one day you find out that Swing or Angular1 or Flex or “something else” come to its end of living and you are not able to switch easily to anything else? I happened to me once long time ago with some other widget library, so I am talking from the personal experience :-( I will try to explain our strategy how to solve this problem: We are using GWT and we are really enjoying to use it but: We are not using WindowBuilder (it’s not supported anymore since version GWT 2.6 and it’s also useless when you are creating large application because it’s to slow), not using UIBinder because it generates to much boilerplate that we do not need at all, not using Request Factory that generates who knows what, not using MVP… nothing that is too specific or bound too much for the platform. The only thing that we use and is specific is Code Splitting but it’s totally hidden from developers and done automatically for each controller. We are not using any external library to do this. It’s simple to implement and it would be probably easy to replace it with something else tomorrow. Everything is done with a single annotation. GWT-RPC may also disappear? We are using JPA classes (with Hibernate) but we don’t use DTOs because there is simply no need to pack and unpack everything. We do not write code for every document we need to save (create, update, delete), there is only ONE class that is doing the job via GWT-RPC. Exceptions are rare (less than 10%) that you have to do something special while persisting the document and you are able to do that as a custom business logic that executes in the same transaction. Current implementation is GWT-RPC based, but when we decide to change this, it can be done in a single day (probably in couple of hours) because its’ ONE class and not hundreds/thousands of classes that we have to change. We are not afraid of changes when someone decide to stop supporting GWT-RPC or it’s suddenly surprisingly proven that it is prone to vulnerabilities. We have less than 10 services to change and note that we are dealing with >650 forms/JPA classes in this moment. All custom actions go via ONE custom action service, we do not create 100 services because it is used in 100 controllers. About UI: We are using something that I call “meta description approach” for UI. Describe you fields, views and forms on technology agnostic way including events. Your views should only describe the view, you should never see any TextBox or any other concrete widget in your code. Use interfaces in your controller and never use concrete GWT/GXT/GwtBootstrap widget. Current implementation is GXT 3 based but there is also ongoing GwtBootstrap 3 version that works equally well but it looks (much) better but that is personal opinion. You can even mix this libraries. In GwtBootstrap version you can create fields as widgets or you can use Bootstrap HTML and CSS, even jQuery JavaScript that sometimes comes with it, from any source and bind existing tag like this one: <input class="form-control" type="text" placeholder="User name" id="name"> to your meta field named “name”. The beauty of this is that you can do it even without any compile, it will simply work instantly. You do not need to add any annotations or even write any controller code if there is no need for it. We have a youtube movie that proves this: https://www.youtube.com/watch?v=ROZ5Oa6DoUg No widgets anymore? Ok, let’s rework engine not to use widgets and implement new version of your metafields that is using Elemental2, JsInetrop2 or whatever it is called today/tomorrow. You do this on engine level and nothing changes in your views, controllers or model. You like GXT, and they decide to do this? Great, make your new implementation in the meta platform engine to use GXT5(?) and you are ready to go. You like Vaadin webcomponent gwtpolymer ? GwtMaterial ? … Add this to the engine/platform. You do not need to change your controller, model, or view code because of this. Don’t want to use Bootstrap templates any more, and you want to use some other templates instead? When all mappings, field properties and events are in meta descriptions it would be much easier to replace it comparing to dealing with concrete widgets. When you think “meta way”, you are not bound to concrete technology and that is the way we decide to go. I am not concerned about the future, I am prepared for the changes this time. Hope this helps. -- 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/72e2237e-12b7-4e3f-8537-7536212089a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
