问题
I just tried to play with Vaadin Framework and it seems to me very easy to use. Plus what I like about his framework is that it is built on top of Google Web Toolkit (GWT).
What do you think, should I continue using this framework or it's better to stick with GWT?
回答1:
Hey. As a disclaimer, I work for the company developing Vaadin.
Vaadin uses GWT in a way that it has a set of components precompiled in GWT. You can, of course, additionally make your own components if you so want to. However, the set of components is quite complete, and can often be customized for your own need. This means that you don't have to recompile your code from Java to JavaScript every time you change your application. You just combine the already available components together.
The framework is server driven, so all logic is handled on the server side. The components has two parts, client and server file. The client side is just a dummy "view" for the component. Once you interact with it, it sends a message to the server that this or that was pressed/written/etc. The server then decides what should be done. This is for increased security, because you can't "hack" the logic as only a small API meant for sending requests is available in the javascript. This may be in some cases a little trade-off with speed of the application, but I don't think it is a so bad. Worst speed bumps are usually db query round-trips and such, which doesn't have anything to do with the choice of the UI framework. Sluggishness of the demos as suggested can be because you're far from the server or there is a high user hit at the moment. Try it in an own environment, close the the final application of your application, to see how well it performs. There are some ready application that you can just deploy to test it out.
I guess the choice boils down to what you are trying to do. Vaadin is good for web applications, as you can build a normal Java application and do the dynamic web UI for it easily. If your doing something more of a traditional web site, where users only views the page - more than actively interacts with it, then Vaadin is not the best way to go. Go with some other free frameworks like rails or a php framework etc. I think that you're more doing an application as you're suggesting that you are using GWT now, so Vaadin should be good.
Ask more questions, here, on the Vaadin forums or at the irc channel #vaadin @freenode and maybe someone can give you more reason to why or why not use Vaadin.
回答2:
After almost 1.5 year developing a not so huge GWT application, using all the best-practices I learned from the last Google I/O like MVP, EventBus, CommandPattern, etc. I say this from the bottom of my heart: after spending days trying to get things work out the way my team and client wanted both technically and visually, even after the release of UiBinder, Vaadin came to me like a light in the end of the tunnel.
After writing almost a thousand boilerplate actions for command pattern, another thousand presenters and views and another thousand event handlers, etc.. Not having to deal with almost 75% of these classes and still maintaining a good pattern approach (appfoundation add-on), a little network overhead is acceptable. With Vaadin, out-of-the-box, you get good widgets, paging, data binding, flawless layouting. All of this for what? Some more memory consumption in the server-side.
I think I can say this is acceptable because I'm not building the next Facebook or something. I still can handle thousands of simultaneous users per medium server and yet maintaining low-latency round-trips.
With Vaadin, I can build a nice app with almost a half of lines of code and still the application seems more complete. :-)
!! UPDATE February 23, 2011: I can't stress out how one should be aware of each framework's limitations. Vaadin is no different. One should be aware that Vaadin abstracts away any form of HTML or JavaScript. Also, the resulting HTML is very heavy and you should take care of history state changes yourself. So, be aware of those overheads when you build your project.
回答3:
Disclaimer: I'm affiliated with none of the libraries mentioned hereafter but happen to know my way around them quite well.
Like you, I stumbled upon this post when pondering which stack/framework to use for a new project. I had some solid experience with Play! (ok, in Scala, but that's not relevant here) but the compelling widgets and their seamless integration with the server side + the Swing like development did pique my interest. That was in late 2010, and as the answers convinced me to give Vaadin a try, I decided to come back and write the answer that I would have liked to read here, esp. as the question is still relevant today. Meanwhile, Vaadin went from version 6 to 7 with a few notable improvements that were needed, Play! went from version 1 to 2 and I (+ a small team) completed a small number of successful projects with both frameworks.
I think that the comparison is interesting because both frameworks
- run on the JVM and can leverage its abundant ecosystem
- couldn't be more at odds in their approach to web applications and what you, as a developer should care about, and
- to a lesser extent, how they relate to Java EE.
Praise
In one sentence, if you find the idea of porting a desktop application to a browser while being completely abstracted from the underlying HTTP request/response mechanism compelling, then Vaadin is probably your candidate for making web application. Its Swing like approach to programming can be a breeze for those who are happiest away from the low-levelness of HTML and JavaScript. A new request to your app is indeed starting a new instance and the rest of the flow is up to you and your logic. Links revert to the good old buttons for navigation and you're free to compose your layouts using the many built-in templates without ever being required to tweak the HTML or the CSS. The API is generally quite consistent and admittedly well documented (the Book of Vaadin is a compulsory read. Do it thoroughly as many things are readily available, eg. binding your beans to components and validators, ...). The widgets have a good overall cross-browser compatibility, thus ensuring a consistent behavior of your application over a wide range of clients.
Reality check
We had a nice time developing and testing our Vaadin apps. Things became clearer and more nuanced when we released the first version and started collecting feedback. We realized that we had actually been biased in quite some fundamental ways, namely:
In 201x, most users have had a long history of using the web, and few of them actually hardly use desktop apps any more. The key point here is that browsers standardized the UX interaction with hypertext links, a back, a forward and a reload button, ubiquitous tabs and sometimes windows, and the basic idea that most actions trigger an HTTP request and will await a response. This is the implicit contract that websites abide to and around which they are built. Therefore, we shouldn't have been surprised when users complained that they couldn't use the back/forward buttons as they were used to, or that tabs didn't work the expected way. And we agreed. We broke the invisible contract binding users and browsers. Actually, we ourselves were implicitly not using our browser with the Vaadin app the way we used it with any other website. Of course, you may go back to the aforementioned book and read up carefully on replicating a web navigation experience with URL fragments and you'll see that it is actually more involved than anticipated because Vaadin apps are stateful. Moreover, the MVC or MVP paradigms are only loosely imposed on the developer, in contrast to Play! where there is virtually no other option. Don't take this lightly but your brain is used to the bright white screen shown for a fraction of a second following a page change. When users click and expect to be taken a new page, the browser acknowledges by showing the hourglass (or variations thereof). With AJAX, requests are placed behind the scenes. There are today places where small, almost surgical AJAX strikes have become the norm, but not for major UI updates yet.
Stateful apps bring their share of challenges... and trouble. Load balancing (if you're concerned) for one is more complicated. The concept of transaction is wholly different as Vaadin sessions span many requests and are therefore long in contrast to REST based approached, but relatively short lived in terms of UX. Indeed, it is not uncommon for users to go back to a form they started hours ago to finish their task. This could, in theory, work with Vaadin too, but you'd have to keep sessions alive for a long, long time with memory blocked all the while and think carefully about well this would scale w.r.t. concurrent users.
Stateful pages are also harder for users to share, let alone bookmark (that's assuming that you dealt with URL fragments).
Finally, we share the impression that the UI is generally more sluggish with the logic being on the server. Of course you may always create a widget loaded with client-side JavaScript to trim down the number of round-trips but you will inevitably have to make some UI updates on the server. The JS is already quite heavy to interpret in my experience and makes for a lesser experience on mobile devices (I'm aware of TouchKit, but still: HTML5 apps on mobile devices just don't cut it for me). Also, bear in mind that the UI thread is active after a request is posted (ie. user action on the client side, similar to pulling UI updates) and will be accessible to you through various listeners. However, updating the UI from background threads is more complicated (eg. pushing updates). Vaadin 7 improved the situation in this respect though, especially with relatively lighter HTML generated. Significant improvements to UI reactivity were noticeable by simply turning on HTTP compression.
Conclusion
So we paused and wondered what we found so attractive in the Vaadin approach to begin with. The initial development had been a relatively smooth ride yielding fast results but reworking some concepts to accommodate web UX expectations gave us a strong impression of swimming against the tide. We concluded that the seducing idea of being abstracted (obscured?) from the HTTP request/response mechanism proved a double-edged sword that unveiled the real impedance mismatch between web apps and desktop apps.
Instead of pretending that the web is yet another layer, we strongly felt that one should embrace the way it works and this starts with having a URL-centric application (as imposed by Rails/Django/Play). You probably heard someone say that data outlives application. Nowadays data is referred to by URL resources so one could safely say that URLs outlive data. After all, they are what people bookmark, aren't they? So basic separation of concerns should also apply at this level. This is probably why the web became so popular in the first place. So we revisited our app to structure it more around a central controller responding to actions à la Play made on distinct resource paths.
For now we're maintaining our Vaadin apps but due to some of these constraints and the fundamental paradigm shift we won't be starting new projects with it. However hat off to the team who built a technically coherent, cohesive and well documented 360° Java web framework requiring very little knowledge of the web inner workings. On the upside they even back their framework with a company selling consulting services. I'm grateful for the experience and for how it made me reassess my views on web applications. I'll closely monitor its evolution but we definitely need more control and granularity.
Hopefully one day Vaadin will free itself from the whole Servlet architecture upon which it relies to have its own HTTP server. Better still would be a MVC design more deeply rooted in the framework. But that's somewhat unlikely in the foreseeable future as it seems to have found a lucrative niche among seasoned corporate Java gorillas who only swear by EE. Shine on.
TL;DR: I think that Vaadin misses the point of what webapps are and more importantly, how they should behave. It's about time programmers embraced the web and how users interact with it (ie. back button, reload button, tabs and bookmarks). The closer a web app sticks to HTTP requests and semantics (verbs), the more likely it is to match user expectations. And that's key.
EDIT: If you have any Python experience, I'd highly recommend trying out Flask too to get a flavor of url-centric, REST-based web application programming.
EDIT 2: If for any reason you feel you must use a full-stack Vaadin-like framework, then give Meteor a try. It's a JavaScript-based (both frond and back end) framework that runs on Node.js with asynchronous communication occurring through WebSocket (thus smaller latency than request/response) and it's reactive by default. A number of things that I dislike in Vaadin have been addressed in Meteor. For instance, the logic for UI updates run on the client which makes it so much more responsive than in Vaadin. Folks in the JavaScript and Java communities don't intersect much but when I first heard of it, the parallel with Vaadin struck me immediately. It currently enjoys quite a bit of momentum in the community for reasons akin to those that made Vaadin popular, ie. the ability to make desktop-like web apps. Do give it a try if you also came to realize that Java doesn't belong much in the picture of future web apps or if you are tired of those long deploy cycles when hitting refresh is all it should take. But think twice before tying an entire app to just one library.
回答4:
The usual talk about Vaadin concerns the widget set and worries about round trip communication between client and server.
But in my opinion this overlooks the most significant (perhaps revolutionary) aspect of Vaadin: it completely eliminates the task of designing and implementing the client-server communication that is usually required for AJAX applications (the "A" and "X" in AJAX).
With Vaadin, you can completely forget DTO's (data transfer objects), protocol-based security problems, Hibernate lazy loading exceptions, etc.
You are in some sense just writing a regular old Java Swing desktop application, only you are using a different UI toolkit from Swing.
回答5:
From my experience GWT requires to much boilerplate code and slow when building complecated and rich UI. Usually we deal with quite complex application models that holds many persistable domain objects. To bring all this data to client you'll need to introduce separate client model and provide data conversion mechanism. We've used Dozer for this purpose and it takes much time to map each filed, create custom converters and test all this stuff.
On the other hand if don't fall into overengineering and if application is not very complicated you may take a benefit of utilizing client resources and have less load on server. In this way you may dramatically minimize communication with the server and get much more responsive software.
Vadin looks very developer frinedly :) But I a little bit afraid of "massive AJAX attack" to the server. I have experience in ZK and to often we faced the performance problems when a trivial operation on UI works slow because it requires communication with server.
Wicket is another good framework but it is more suitable for websites. It can work with and without AJAX, can be indexed by search engines. And the most attractive thing it deals with clean HTML code - no custom tags, no control structures, strict separation of concerns and only specific wicketid namigs for components.
It mostly depends on your needs:
- If you need super fast and simple application - use GWT and utilize client resources
- If your application is quite complex than Vaadin looks to be the better option
- If your application is public and you need an ability to index it for SEO than chose Wicket.
回答6:
The thing is, for serious development, you can't forget about anything, let alone dtos.. i am ditching seam, and server side ui concept just because i wish finer control over what is going on the wire.. vaadin's problem to me is precisely that, having state on the server side..
回答7:
There were "concerns" about Wicket using sessions to manage component states and scalability similar to the arguments about Vaadin and server side processing. I have learned over the last 10 years that the Java community is usually wrong about how to measure a web framework's potential (among other things). From JSF to Grails, it usually takes a couple hundred GB of memory and at least a dozen open source jar files with overlapping and inefficient functionality to get a production application running. Look around and you will see most web hosting companies don't offer a practical java option because of the erratic path java technologies have taken for web frameworks. GWT 2.1 is still a pain to use because of compilation speed and it is just getting serious with MVP and data tables which should have been there from the start. I like Wicket but Vaadin looks promising... but knowing how Java frameworks go, I'm sure they will shoot themselves in the foot at some point but I doubt it will be because of heavy server side processing.
回答8:
For building good looking UI's, I would say this would be the way to go. Plus it's very well documented.
回答9:
I've been using it for a couple of weeks and I really like it so far. Code is solid, docs a re good, very logical construction, end results are excellent.
I'm loving it in combination with Hibernate to sort out all the database tedium.
Plus - easy to deploy (with Tomcat you can just upload a single .WAR file via the web interface, couldn't be easier)
回答10:
It's also worth considering Apache Wicket as strong alternative for Component-oriented Java Web UI frameworks. Vaadin sounds great and I don't want to detract from this discussion, but choice is a good thing. There's a few examples with source linked off the home page, and even more at the WicketStuff site, and the excellent book from Manning forms great third-party documentation.
回答11:
take a look at the Vaadin demo build with Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html
回答12:
I thought Wicket was the way forward, until I tried to make it work efficiently and started a depression (joke). Then, I switched to GWT, which looked great, but there is soooo much boiler plate code to write and the documentation is not that great... -> The light came from Vaadin: simple, operational, no bugs so far... !!!
回答13:
In our company which is predominantly a large Java SW house (among other things) there came upon us a chance to create a new web based product.It was a set of products and there were many teams in three countries developing this. When it came to our team I had the choice of using Vaadin for the benefit of leveraging our java development experience.I searched Google to help me in my decision. I also read this post; However I chose against using Vaadin though many other teams chose Vadin. Below are the reasons from a mail I send at that time before starting on the product (To Vaadin or Not). This is from my personal view and distrust of frameworks in general is always in me in varying degrees. So just wanted to give another take on this question to the reader.
Well we went on a learning spree learning HTML, CSS, CSS Selectors, a wonderful language JavaScript and JS libs, JQuery and YUI and created the web product in time with full GUI and performance compliance; and I personally I am happy and the team is as well as well as the users.
Other teams who went the Vaadin way also created their products in time and I guess are equally happy.(Only they don't know the joy of JavAScript they are missing :)) .
As someone said, all abstractions are leaky abstractions and when they had to migrate from Vaadin 6 to Vaadin 7 they had to do quite some re-work and it took more time than anyone thought; though of course they managed to grind and finsh it; Still there was a little bit of delay due to this.Also I guess there was some problem with InvientCharts addon which was not supporting Vaadin 7 causing the teams to buy ($$) the related Vaadin Charts addon and change for that....
To Vaadin or Not
With Vaadin it seems that the underlying JavaScript ,HTML and CSS are dynamically generated from a Java Swing type application. From a biased and probably silly purist point of view, such a "I will generate code for you" tagline does not give a good design smell. Unless you need an abstraction why tie up with yet another framework. As with any code generating framework, it should work best for the the abstraction Vaadin had in mind, but not very flexible; I feel that if we do web technology it is best to do in the tools and languages out of which the technology has aroused – namely , HTML , CSS and JavaScript/JavaScript libraries rather than relying on another level of abstraction – the Vaadin framework. This may feel naïve to an expert GWT or Vaadin developer as I guess the Google compliers generate the most optimized JavaScript than your hand coded ones, , helps manage code better between multiple teams etc (but mostly when developing pretty biggish web applications), better developer productivity, easier debugging etc. However writing components in Java for Vaadin and then auto converting to JS is I feel not right in that many of our developers will never learn a very important programming language – JavaScript for web development (and gaining traction fast in the server side – Node.js). When relying on frameworks to get your JavaScript right as then you will never excel in that language . I guess for a product based company it is important to learn firsthand the language of the web instead . As someone commented Java has become like the COBOL of yester year and it is imperative for competence build up to learn other important languages like JavaScript. However having worked in JS for the small time that I have, I have noticed that if we code with some discipline (Module pattern) , test all logic – JavaScript unit – JSTestDriver, and run JSHint , it is a rather powerful language to work with, and productivity gets better than Java once it is learned. Also most of the important components example – OpenLayers are written in JS and if you need to extend these or work with optimally you need to know JavaScript , or for that matter powerful libraries like D3.js So in short though there is a lot of advantage in using Vaadin and frameworks, in the long run maybe using JavaScript is important ?
回答14:
I'm using Vaadin as well. Although the application is not large, what I really liked about the experience was that the API was consistent, generally well documented and given I was developing with a new tool, I was able to crank out stuff for a very demanding client in the same, or in some cases, better timeframes than the tools I used before.
Very few issues. The only one right now is the client insists on using IE 7 (don't ask) and some of the fancier eye candy doesn't work totally 100% in an addon component (charting).
BTW I don't work for Vaadin either :-)
回答15:
I have tried Wicket and Vaadin both and if you really try both for some time, with in a month you will know that Vaadin is the way to go and not Wicket, period. - Dheeraj G
回答16:
We have looked at Wicket where I work but we found instead of 9,000 files, we could have over 30,000. We have nearly 1,000 screens with our core financial services application and although Wicket looks great it is extremely difficult to convert our Struts 1.3 code to Wicket. Our architect did a POC project and just 3 screens added several hundred classes (many are for re-use). It's also difficult to protoype a screen with Wicket since your html must match the Java code and vice-versa.
Vaadin looks promising but it will be a hard sell to the team.
P.S. No matter how great a framework is, no one will learn it if it isn't used in the industry. Wicket has been around for awhile yet very few companies use it. Most developers I talk with are concerned with learning a new framework that is useless on a resume.
The key thing is Vaadin uses Swing-like design and it helps that I started in Java using Swing.
回答17:
I have used Vaadin to develop a giftadvisor at the company I work for(not Vaadin ;).
Vaadin allows you to build real componentized Swinglike web applications.
If you are concerned about client-server roundtrip for every click I have this to say: I created a mouseover button which changes the look of the button on yes, mouseover. For this the framework has to go to the server and back. And it works fast enough imo. See http://www.cadeau.nl/sophie to check out what I mean.
I like Vaadin, it suites my needs and makes webdevelopment a breeze.
Regards, Rob.
回答18:
I started with Vaadin only two days ago and was able to build a small CRUD application on OSGi complete with modularity, data binding, OSGi services for persistence. One really nice thing is that my complete UI is only 118 lines of code and supports complete CRUD operations for a simple java bean structure.
It is also nice that Vaadin works perfectly in OSGi. It is already a bundle and I found a little bridge from Neil Bartlet that makes vaadin extremely easy to use in OSGi.
See Tasklist Vaadin Example
回答19:
I dont mind using states on the server side. It serve its purpose. With Cloud computing now-a-days storage and bandwidth are becoming cheap. But yeah I can see your point from a good design perspective especially if you want to RESTify your application. But I believe that there are more pros than cons regarding Vaadin and the like. One major thing, you dont have to tweak a great deal about your web-apps for a specific browser lets call it IE, for Javascript/CSS intricacies - especially if you are oriented towards the back-end like me. All your webapps becomes compatible across browser without having to worry anything. Remember developer time is pricier than that of storage and bandwidth. Thats my opinion. =)
来源：https://stackoverflow.com/questions/1183801/should-i-use-vaadin-framework