Summary: The people who are developing XUI claim a 60% reduction in code when using XUI... however they fail to provide adequate proof. (Note the date above and keep that in mind if you visit XUI's website and the claims have changed.)
If you're going to add an abstraction layer over a subsystem, it better be quite thin and worth the effort to learn. XUI claims a 60% reduction in code size when used vs using AWT natively and claim similar savings with Swing.
I doubt this would be a 60% reduction on the whole code base of a real-world application. It would have to be a 60% reduction of the GUI-related code which itself is only one relatively small portion of a normal application. I did a quick analysis on Exert grepping for files that use javax.swing or java.awt and considering all files that do have that string to be 100% GUI-related and files that don't have that string to be 0% GUI-related: with this method, Exert contains about 17% GUI-related code and that's an overestimate since you can be certain that files that don't use either javax.swing or java.awt are not GUI-related but files that do use javax.swing or java.awt are certainly not doing 100% GUI work. So at best, in the case of Exert, using XUI and assuming the 60% claim is true, that would be a 10% improvement and this is an overestimate. (I'm guessing the actual GUI-related code in Exert, if the analysis was done on a line-by-line basis would be at most 8% so the benefit would be around 5%.)
Then, the problem is that the 60% claim is not backed up by any data from a real-world application. I realize that's no small task but toy projects are just not good enough to substantiate productivity claims. It's just too easy to tailor small projects to make the methodology being sold look good. What is needed is some real project where corners are not going to be cut.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recently stumbled across this criticism of a 60% reduction in code when using XUI.
First of all thanks to Laurent for taking the time to comment on XUI, almost all comments are welcome be they good or bad.
In response, we are not trying to pull the wool over anyone's eyes, if you will excuse the expression. The XUI project is open source, so just like the reviewer did, anyone else can review the code and decide for themselves. In any case I would like to point out that our statement claims a saving of **up to** 60% of code.
Even so, the main point has some validity in that it is very hard to determine what saving can be achieved by the likes of XUI. The saving depends on the extent of the code affected and the level of interactivity between that code and the rest of the application.
The analysis described in the review is itself a little inaccurate as the simple search for AWT or Swing references will be inadequate. XUI is more than just a means of constructing GUI widgets. XUI provides an MVC architecture that simplifies data access and it is here that much of the savings of code are achieved.
The figure quoted is a very rough metric, but we have in fact seen much larger savings than this in real world, commercial applications. We are not developing XUI as some sort of pet project, we make daily use of the tools it provides so I am confident that XUI is a beneficial tool for a wide range of application development scenarios. I can happily say that a number or third party products have also been built with XUI.
The point about null layout is also valid, but it should be noted that layout managers can be used with XUI and we have plans to greatly enhance such support. The original development targeted some limited platforms where layout support was limited. Furthermore, the documentation is set out in several steps, introducing a feature at a time so I don't think we could reasonable describe all the features of XUI in one small example.
If one compares the type of code generated by tools such as Jbuilder it is clear how much layout and setup code is saved by the likes of XUI. However the greatest benefit we find is in making the code clearer and easier to read. In fact this was our original motivation (we worked on a business banking platform for a major bank where the saving enabled by XUI would have been more like 90%, but some of that extra saving is probably as much down to the quality of the original code).
If anyone has the time and would like to comment further we'd be happy to see such comments on this forum. Who knows, maybe others have similar criticisms. In any case once we know of a problem we can work to fix it!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found this critique of XUI recently at http://www.lddubeau.com//ramblings/xui, here's an extract.
Summary: The people who are developing XUI claim a 60% reduction in code when using XUI... however they fail to provide adequate proof. (Note the date above and keep that in mind if you visit XUI's website and the claims have changed.)
If you're going to add an abstraction layer over a subsystem, it better be quite thin and worth the effort to learn. XUI claims a 60% reduction in code size when used vs using AWT natively and claim similar savings with Swing.
I doubt this would be a 60% reduction on the whole code base of a real-world application. It would have to be a 60% reduction of the GUI-related code which itself is only one relatively small portion of a normal application. I did a quick analysis on Exert grepping for files that use javax.swing or java.awt and considering all files that do have that string to be 100% GUI-related and files that don't have that string to be 0% GUI-related: with this method, Exert contains about 17% GUI-related code and that's an overestimate since you can be certain that files that don't use either javax.swing or java.awt are not GUI-related but files that do use javax.swing or java.awt are certainly not doing 100% GUI work. So at best, in the case of Exert, using XUI and assuming the 60% claim is true, that would be a 10% improvement and this is an overestimate. (I'm guessing the actual GUI-related code in Exert, if the analysis was done on a line-by-line basis would be at most 8% so the benefit would be around 5%.)
Then, the problem is that the 60% claim is not backed up by any data from a real-world application. I realize that's no small task but toy projects are just not good enough to substantiate productivity claims. It's just too easy to tailor small projects to make the methodology being sold look good. What is needed is some real project where corners are not going to be cut.
I recently stumbled across this criticism of a 60% reduction in code when using XUI.
First of all thanks to Laurent for taking the time to comment on XUI, almost all comments are welcome be they good or bad.
In response, we are not trying to pull the wool over anyone's eyes, if you will excuse the expression. The XUI project is open source, so just like the reviewer did, anyone else can review the code and decide for themselves. In any case I would like to point out that our statement claims a saving of **up to** 60% of code.
Even so, the main point has some validity in that it is very hard to determine what saving can be achieved by the likes of XUI. The saving depends on the extent of the code affected and the level of interactivity between that code and the rest of the application.
The analysis described in the review is itself a little inaccurate as the simple search for AWT or Swing references will be inadequate. XUI is more than just a means of constructing GUI widgets. XUI provides an MVC architecture that simplifies data access and it is here that much of the savings of code are achieved.
The figure quoted is a very rough metric, but we have in fact seen much larger savings than this in real world, commercial applications. We are not developing XUI as some sort of pet project, we make daily use of the tools it provides so I am confident that XUI is a beneficial tool for a wide range of application development scenarios. I can happily say that a number or third party products have also been built with XUI.
The point about null layout is also valid, but it should be noted that layout managers can be used with XUI and we have plans to greatly enhance such support. The original development targeted some limited platforms where layout support was limited. Furthermore, the documentation is set out in several steps, introducing a feature at a time so I don't think we could reasonable describe all the features of XUI in one small example.
If one compares the type of code generated by tools such as Jbuilder it is clear how much layout and setup code is saved by the likes of XUI. However the greatest benefit we find is in making the code clearer and easier to read. In fact this was our original motivation (we worked on a business banking platform for a major bank where the saving enabled by XUI would have been more like 90%, but some of that extra saving is probably as much down to the quality of the original code).
If anyone has the time and would like to comment further we'd be happy to see such comments on this forum. Who knows, maybe others have similar criticisms. In any case once we know of a problem we can work to fix it!