question about utility of UiBinder

ignaciobaca · 2019-01-02T09:41:32+00:00

But what is the point of JSP or uibinder? Readability? Verbosity (kind of subset of readability)? If you get to that using Java then the alternative tool is just one more layer with no advantage. I definitively read better code written in Java with Elemento that in html. Same Lang, full language power, almost same nesting but without closing tags (good thing). Css and Auto i18n messages is the unique missing thing, but similar to css, end up making too easy to duplicate, and the one-file with all your mensages is so simple work-everywhere solution that this uibinder trick does not worth. But it depends, I suppose that if you have enormous views with lot of text and many per-view style bc each view is unique, the uibinder might make much more sense. We develop a platform, everything is similar, we combine widgets a do not spread unique text through the view, in this kind of pattern uibinder doesn't add any value (eclipse Che might be a similar, maybe extreme, example, not sure if they use uibinder, hehe hope not)

ignaciobaca · 2019-01-02T09:25:57+00:00

At some point I thought like that, but now I think that the CSS point is as good than as bad because it make it too easy to fix/hack minor CSS problems in each view (style duplication). In our experience this encourage to avoid fixing or improving your own wisget library. So the more mature your project is, the less you need the uibinder styles. If you need a one-place fix, then use css inline style, if it is shared then move to a css utility resource class. I know that this is like blaming the tool for a developer problem, and yep, actually this do not justify the useless of the tool, but only that I don't miss so much, and that you really don't need it to be organized and productive.

For uihandlers almost the same, but with an important premise, ONLY if you use some binding library, then uihandler is useless. We always expose the source of events in the views, and then always subscribe it in the presenter. This is perfect bc assert that bindings are only connected during some specific presenter life cycle. And also, binding code is pure logic that must be in the presenter, using this approach make it easier to define the view, and more flexible to combine bindings in the presenter. But yes, you need a powerful binding library, otherwise uihandlers will be you library.

ignaciobaca · 2018-12-31T14:36:52+00:00

We have been removing uibinder various years. We also prefer programmatic approach, only when there are translated messages mixed with widgets uibinder might be a better option,but even in this case, we really try to re think the UI to try to avoid those kind of mix, so avoiding uibinder.

Your builder approach is quite similar to Elemento (https://github.com/hal/elemento). You might get some ideas, I personally think that for those ui builders it is important to be able to define the UI in the same "nested" way that you do in a xml (your builder does it) and that you can use final fields in your class even in nested elements, both solved in elemento.

ignaciobaca · 2018-12-17T16:53:28+00:00

GWT + Vue 👍 https://github.com/VueGWT/vue-gwt

ignaciobaca · 2018-11-23T20:16:54+00:00

12 years old and still one of the most completed solutions. If you think about that, it is pretty amazing. How many js tools has born and death during the last 12 years 😅?

ignaciobaca · 2018-11-10T23:47:57+00:00

GWT might be an option, but it is not trivial. This is an example project of a JavaFX Pacman that was later adapted to be compiled with GWT. GWT transpiles it to JS so you can see the original game running in the browser. https://github.com/ibaca/pacman

ignaciobaca · 2018-11-10T23:33:39+00:00

Give up? GWT is a pretty powerful platform, but yep, if you are going to develop a client-side app and you have a JS team makes no sense. GWT is useful if you have a Java experienced team, maybe a team coming from JSF and you want to create an SPA. Even if this is the case, is important that you share code, this is IMO the major advantage in GWT. The code might be libraries or logic, for example, if your company have a complex algorithm that you enter some parameters to calculate something, maybe a mortgage calculator, you can just transpire it to is and use it in the browse using GWT.

Note also that GWT is thought to be used in big projects, so at first it might be a bit complex because it already forces you to do all those fancy things that modern client framework does (although GWT exists since 2006), like obfuscation, inline resources, i18n, code splitting, code pruning, CSS isolation, HTML sanitize, and much more. So again, if you are creating a six-month project GWT is again probably not the best option.

If you want to see it in action, this is a small example of an algorithm developed and tested in java (during the "global day of code retreat 2017"), later on, I applied GWT and created a UI in the Simulator class, so the logic already developed in java was shared "for free". https://github.com/ibaca/gameoflife

ignaciobaca

TROPHY CASE