Architecture Question: GWT or Vaadin to create Des

问题:

We're planning on creating a feedreader as a windows desktop- and iPad application. As we want to be able to show Websites AND to run (our own) JavaScript in this application, we thought about delivering the application as HTML/CSS/JavaScript, just wrapped by some .NET control or a Cocoa Touch webbrowser component. So the task at hand is to find out which framework to use to create the HTML/CSS/JS files to embed in the application.

For the development of the HTML/CSS/JavaScript we would be happy to use Vaadin, GWT, or some other framework, as we're a lot better with Java than with JS. We favor Vaadin after a short brainstorming, as the UI components are very nice, but I fear that most of the heavy lifting will be on the server and not in the client (and that wouldn't be too nice). We would also like GWT, but the Java-to-JS compiling takes a lot of time and an extra step, and slowed down development time in the past when using it.

The question is: which development framework would you choose (given you wanted to implement this project and you mostly did Java so far) and why? If there are better framework options (List of Rich Client Frameworks), please let me know.

Edit: The application will need to talk to our server from time to time (sync what has been read for example), but mainly should get the xml feeds itself. Therefore I hope that most of the generated code can be embedded in the application and there doesn't need to be heavy activity with our server.

Edit2: We (realistically even if you doubt) expect at least 10000 users.

回答1:

Based on my experience with Vaadin, I'd go for that, but your requirements are somewhat favoring pure-GWT instead.

• Vaadin needs the server and server connection. If building mostly offline desktop application, this can be solved with an embedded Jetty for example. (synchronize with an online service only when needed), but for iPad you would need to connect online right away to start the Vaadin application.
• GWT runs completely at the client-side and you can build a JavaScript browser application that only connects when needed.

Because Vaadin is much quicker to develop, you could build a small Vaadin version first and see if that is actually problem on the iPad.

On the other hand, if you can assume going online right away, you can skip the local server installation altogether. Just run the application online and implement the desktop version using operating systems default browser control (i.e. the .NET control you suggested). Then Vaadin is easier.

回答2:

Vaadin is just framework base on GWT but have two very important features:

• don't need to run GWT compiler. It is pure java. Of course if not add addons because then gwt compiler must run.
• you don't need to write communication code. So you don't need to solve DTO problems, non-serializable object mappings and dont need to write servlets.

I use Vaadin in my work for one year and we haven't performance problems yet (desktop like application with ~500 users). IMO very good solution is to use Vaadin just for UI, logic move to independent beans and connect this two elements using Spring or Guice.

In this case you should use MVP pattern and Domain Driven Development.

• Bussines beans is domain objects and logic that use view interfaces to send responses.
• Custom Vaadin components (could extends standard components) implements view interfaces.

That way is good when you decide to change UI engine if Vaadin is not for you. Just rewrite guice/spring mappings and write new implementations of view interfaces.

回答3:

My 3 cents:

If you decide to use vaadin, You will benefit from already GOOD LOOKING components. Since you dont want to write (alot of) CSS , vaadin is already good looking out of the box. How ever, Vaadin is a SERVERSIDE framework. User interface interactions will hit the back end even if they dont involve getting any data (e.g moving from one tab to the other) .

If you decide to use GWT, you will have to atleast style the application (this is not hard) . There is also the problem of long compilation time (but you can test and debug on hosted mode which allows you to run the application without compiling , then you compile only when deploying). The main advantage of gwt is that you control what gets sent to the wire, For UI interactions that dont require getting data from the backend, it will work purely on the client side. You the developer will determine when to send a request to the back end. (Doing RPC requests in GWT is very easy)

Hope this will help you make the decision.