This post originated from an RSS feed registered with Java Buzz
by Marc Logemann.
Original Post: Changed my mind: no Vaadin but Spring-MVC+YUI
Feed Title: Logemann Blog
Feed URL: http://feeds.feedburner.com/LogemannBlog
Feed Description: Marc Logemann's thoughts on java and other stuff
We have done some prototyping lately. Mid November we started developing our products admin console with Vaadin. Of course we defined the first weeks as prototyping because thats what it was and we didnt want to settle that fast on a "new" (to us) technology. Let me summarize our feelings with Vaadin:
Its a great framework where things can be solved VERY easy and fast. As long as you dont have really complex forms. I said it elsewhere. When you provide a framework which abstracts you from about everything you normally have to worry about (html, css,js,...) its quite important that you really abstract all the things you need in a modern RIA app. Including two column forms with graphical sections and stuff. But Vaadins form features are quite basic. This results in heavy workarounds from developer site. Then you start learning how you can do the things the "old" fashioned way which is more work as doing it directly in html/js.
We reached a certain point where we wondered if this is really a time saver at the end. This combined with the natural "lag" when using terminal-server-approach frameworks we come to the conclusion that we dont want to go with it. But besides the Form issue, we were pretty happy with Vaadin. The other thing we noticed is that the other part of our application runs on PDAs (with Browsers) with very limited GUIs and there we simply cant use Vaadin at all. This results in another framework inside our Application. So we had to use Spring-MVC, Struts2 or the likes anyway for this part of the app.
So we decided that we want to go with one framework for both worlds, AdminConsole and the GUI part where the real work is done. After we decided that Vaadin will not be the player, we again spent some time to re-evaluate all the options inclusing barebone GWT 2.1.x and component frameworks like Wicket.
GWT is interessting because i checked it several times. As of 2.1.x, they get stronger and stronger with rich components like data tables and stuff. But again, since we also use very basic PDA based browser apps, we would need a different framework anyway because browsers based on Windows Mobile will definitely dont work with the JS hell GWT creates. So while i still think that its a nice framework it just doesnt fit in our environment.
To make the story short: We decided on Spring MVC (its quite comparable to Struts2 but since we use a lot of Spring stuff, we feel better to use Spring for MVC too). Spring 3 really made some big (good) changes to MVC in its recent version. But Spring doesnt solve that much on the frontend part and i also checked all possible alternatives there. Lets name the darlings in the JS world again: JQuery, MooTools, Rico, YUI, Dojo and 2-3 other whose name i forgot. I decided on YUI on a project 2 years ago and the decission is still valid. JQuery, while everyone seems to like it, is quite weak when it comes to CORE components. Of course you can plug in thousands of plugins like datatables and stuff but after all you have a cluttered, hard to skinnable JQuery frontend. Dojo is the same but even worse w/o that much plugins. And the rest is not RIA enough.
YUI2 has nearly all components in its core and also provide a lot of other nice stuff like css framework and layouts. Its syntax is not that elegant compared to JQuery, admitted. Of course i checked YUI3 because newer version is always better but its somehow unfinished and the YUI3 components are much weaker and nearly undocumented (did you every try to get paging running with Datatable...?).
That leaves us to our current choice: Spring-MVC (a lot of other Spring modules), JSP, YUI2 and most likely Sitemesh for decoration. Of course we wont get a Single Page Application with that but instead rely on JSP rendering with AJAX baked into the JSP but i think this is not a major drawback. Also nice that we can reuse a lot of existing code like our DAO Layer. We can even migrate quite easily our old Struts1 (yikes!) actions to Spring Controllers. Its not the complete re-engineering as envisioned before but perhaps its a good choice because the risk is under control ;-)
I can really say that i checked nearly everything which is in the java market today when it comes to frameworks. I used a lot in the past and tried a lot which i have not used so far. I just wanna be sure that my choice is fine. But i also realized that there is simply not the perfect framework. I still like Vaadin but i still think that some things are way to complicated to accomplish. But at the same time i think that it could be one of the best frameworks, if they would focus on RIA issues. The latest roadmap doesnt look too promising that they will improve form handling and creation anytime soon. Apart from that, abstraction is always some kind of magic bullet which can turn into a whole mess when you cant use it because of missing features. Thats why i would never Spring Roo. Its promising first but i am quite sure that it will turn into the direct opposite if you wanna do things that are not thought out by the core developer beforehand.
Previous Topic
