Skip to main content

Vaadin vs GWT

From Chapter 1 of book of Vaadin I quote the following.

Vaadin Framework is a Java web application development framework that is designed to make creation and maintenance of high quality web-based user interfaces easy. Vaadin supports two different programming models: server-side and client-side. The server-driven programming model is the more powerful one. It lets you forget the web and program user interfaces much like you would program a desktop application with conventional Java toolkits such as AWT, Swing, or SWT. But easier.

While traditional web programming is a fun way to spend your time learning new web technologies, you probably want to be productive and concentrate on the application logic. The server-side Vaadin framework takes care of managing the user interface in the browser and the AJAX communications between the browser and the server. With the Vaadin approach, you do not need to learn and deal directly with browser technologies, such as HTML or JavaScript.

As the client-side engine is executed as JavaScript in the browser, no browser plugins are needed for using applications made with Vaadin. This gives it an edge over frameworks based on Flash, Java Applets, or other plugins. Vaadin relies on the support of Google Web Toolkit for a wide range of browsers, so that the developer does not need to worry about browser support.

Behind the server-driven development model, Vaadin makes the best use of AJAX techniques that make it possible to create Rich Internet Applications (RIA) that are as responsive and interactive as desktop applications.

In addition to the server-side Java application development, you can develop on the client-side by making new widgets in Java, and even pure client-side applications that run solely in the browser. The Vaadin client-side framework includes Google Web Toolkit (GWT), which provides a compiler from Java to the JavaScript that runs in the browser, as well a full-featured user interface framework. With this approach, Vaadin is pure Java on both sides.

Vaadin uses a client-side engine for rendering the user interface of a server-side application in the browser. All the client-server communications are hidden well under the hood. Vaadin is designed to be extensible, and you can indeed use any 3rd-party widgets easily, in addition to the component repertoire offered in Vaadin.

Like GWT styling can be done by CSS and SAAS sheets.

Why is Vaadin different?


 In a typical web application you need to do everything by yourself. (The description below corresponds to the JS layer - one in orange of the diagram above).
1. Browser javascript to generate fancy widgets and styles
2. Establish communication with the server via some means; let it be RPCs, a custom protocol implemented on top of HTTP or even a custom protocol implemented using network sockets .
3. Web sever programming using servlets, cgi perl scripts, php, asp or what not.
4. Finally you'd have to have access to some data source in a backend server, and your web server has to be communicating with this backend server to fetch you some data which needs to processed and sent to the client to serve its request.

All this seems too hard, doesn't it?
Smart people have built different frameworks to do everything much more easily and provide developers with frameworks that can be used instead of going through the full stack.
Wicket, JSF and Google Web Toolkit and of course Vaadin are some examples.

GWT is a very powerful framework developed by Google to make the lives of the developers easy. It provides a range of widgets and UI components library that developers can just use off the shelf. It's a strong API that you can use to customize the appearance of your web UI components so that you don't have to worry too much abut the size of your tables, the roundness of your button edges and the shadows created by your panels. (Have a look at my earlier blog post for a GWT introduction and its perks). This eliminated the JS development associated at client-side (Look at the figure above for the middle layer).

What Vaadin has essentially done is to swallows the GWT in whole and provide internal mechanisms for server-side architecture by taking advantage of all GWT widgets. Does that make any sense?
OK. Let me explain.

Vaadin guys were smart, they didn't want to just do the same thing as Google :-)
But they knew that the GWT Java to JS compiler was very powerful, so they took the advantage of it so that the developers can still use many customizable widgets like GWT.
However, what's different was that now the developers didn't have to be stuck with client side rendering of all widget interactions being taken care at the browser itself. Huh? OK, this means that GWT Java to jS compiler was capable of handling all events within the browser. Yes, there was javascript code dispatched to the client browser for every event by the GWT remote servlet at the load of the application, and yes this made starting slow for GWT applications.

What the Vaadin framework does is that they built something called the "Vaading Client Side Engine".  When the users connect to a Vaadin Servlet the servlet would first send a javascript built "client engine" as an HTTP response to the client browser. Now this client engine has built in mechanisms to communicate with the Vaadin Servlet. This meant that the event listners could easily communicate with the Vaadin servlet to update the client side appearance according to user actions. Yes this means that there are AJAX calls to most user action events in Vaadin, unlike GWT.

However the important thing is you can still build pure client side applications using Vaadin. Why? remember Vaadin swallowed GWT, so that Java to javascript compiler is still inside Vaadin.

OK, a quick comparison from what we know so far.

GWT and Vaadin client-side application advantage:
App logic (replies to user interaction) is faster as it is run locally in the browser. It's also relatively insensitive to bad network conditions. Network is used only when needed (to read/save new data), which saves net traffic (important for high traffic sites).

In this regard Vaadin server-side applications are slower and introduces a lag in UI interaction which is annoying to user. If network is bad this will show in UI responsiveness.

Vaadin server-side application advantage:
Faster development cycles because you have no distinction between client and server side separate development. App logic is run on the server so it can not be inspected by the user. Arguably (Vaadin claims) that makes it more secure.

Take a look at the address book widget construction using GWT on the left and Vaadin on the right. It's obvious that the Vaadin client engine has taken over all the communication burden so that the developers face a much simpler task at hand.


A quick look at architecture comparison between a server-side web application and a client-side web application is given below. It should be clear that the missing Vaadin client side engine calls for a vaadin client side API and it also avoids the necessity to run Vaadin Servlet, all and all a JVM on the server side.

Server side application architecture
Client side application architecture
So what are the other differences between Vaadin and GWT. I extract this information from the answer here.

A) Vaadin includes a server-side development model that:
  • Cuts number of code lines to half by reducing layers one has to implement for user interface.
  • Allows you to use any JVM based language for user interface - Scala, Groovy
  • Increases security by keeping user interface logic in the server
  • Allows synchronous calls to any backend API from the web server
  •  Allows use of any standard Java libraries and tools for UI layer- in server side architecture applications
  • Does not need Java to JavaScript compilation step that often takes time or makes tooling complicated in GWT projects - instead you have the Vaadin client engine
  • Provides server push out of the box with no extra code needed
B) Vaadin provides a large set of high level user interface components. For GWT one would need to use commercial Sencha GXT for comparable component set.  

C) Vaadin includes SASS based Valo theme engine that makes it easy to build good looking custom themes from your application. Valo is the latest theming for Vaadin.

D) Data binding: Vaadin has incorporated the ability to associate any widget directly to a data source such as database, file or anything else in the server-side. This enables to define default behavior of the widgets to act on data sources.
Labels:

Comments

Post a Comment

Popular posts from this blog

Detaching a process from terminal - exec(), system(), setsid() and nohup

Linux processes are created by fork() and exec(). The very first process of POSIX systems is init and subsequent processes are derived from the init as parent. These subsequent processes are child processes. During forking the parent process copies itself - with all I/O, address space, stack, everything. The only thing that is different is the process ID. The parent and child will have 2 different process IDs. The system() library function uses fork(2) to create a child process that executes the shell command specified in command using execl(3) as follows: execl("/bin/sh", "sh", "-c", command, (char *) 0); system() returns after the command has been completed. system() executes a command specified in command by calling /bin/sh -c command , and returns after the command has been completed. During execution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.  system() calls are often made within programs to execut
Post a Comment
Read more

C++ Callbacks using function pointers vs boost bind +boost function

In C, the most common uses of callbacks are as parameters to library functions like qsort , and as callbacks for Windows functions, etc. For example you might have a library that provides some sorting functions but you want to allow the library user to provide his own sorting function. Since the arguments and the return values do not change depending on the sorting algorithm, this can be facilitated in a convenient manner using function callbacks. Callbacks are also used as event listeners. onMouseClick(), onTerminalInput(), onData(), onConnectionStatus(), onRead() are probably some examples you've already seen in different libraries. The libraries have these callback functions and the users of the library are supposed to implement them. The library has a function pointer to these functions and calls them on their event loop which will invoke the code of the inherited classes of the library user. The implementation of function pointers is simple: they are just "code p
Post a Comment
Read more