From my understanding Vaadin consumes GWT and adds an engine on the browser end to interact with server side UI. In looking for a 'Confluence' Vaadin add on I came up with nothing. I would like to use Javascript instead of Vaadin pure Java to talk with Confluence 'rest'. However I believe that I found find some GWT Confluence plugins. Since Vaadin uses GWT already do you think a GWT confluence plugin is the way to go? Also there is a angularjs/vaadin addon and then I could us angularjs with Confluence. Your thoughts please...
The traditional Vaadin Framework consists of a java backend on the server and components which are rendered on client side. Most of those are client side rendering are written with Java/GWT.
In addition to this, there exist the Vaadin Elements, which are "pure" JS components for the frontend.
Is Vaadin Elements meant to be used with the Vaadin Framework?
If you wish to write a app with all logic client side (And perhaps calling some REST api), then you will need to write this in JS (perhaps with Angular/Polymer etc.).
In that case you could use the vaadin elements for some of the tasks, but you will remain in the JS world.
To answer your question:
Using a GWT thing and combining it with JS isn't the most up-to-date way to handle things.
GWT makes sense when you wish to write frontend code with Java but certainly not for JS.
I have a question, I was developing a desktop web application based on a REST API in Java using Servlets and JSP, but my boss said that it's not the best way to create a web application, because servlets and JSP are working as fat/thick clients( a request to the server make the application to download all content of data not a part like GWT does) and he suggested to go with GWT because it is working as a thin client.
As I was looking on the Internet I didn't see that servlets are working as fat clients, so my question is why is better GWT than servlets?
GWT solves a different problem than servlets. GWT is a tool to make clients, and servlets/JSP are tools for telling servers what to send to clients.
For example, my server uses a JSP to serve a GWT client, and servlets to connect the client to my database. I use all at once! You could use just one.
You can make your GWT client arbitrarily thick or thin. You can even run a GWT application with no server at all.
Use GWT if you want a nice tool for making complex, cross-browser web apps in Java. The decision to use JSP or servlets should be made separately.
I'm a seasoned Java developer but new to GWT.
Consider a 3rd party http POST based webservices api, not completely REST based since there's configuration of servlets, among other things, to invoke these services. I'm building gwt components extending the base gwt composites and using these 3rd party data services to fetch/mutate the data.
In the normal java world, I'd have build a REST wrapper on these services and exposed them as Pojos via JaxB Xml/Json. In GWT, however, I read GWT-RPC will be the fastest, given the serialization required. The data is expected to be large (several thousands, paginated).
What's the best way to design the 'bridge' between the 3rd party data services and the gwt client components?
I ruled out RequestFactory since we have a custom servlet provided by the 3rd party that fetches the webservices.
Adding a rest wrapper adds a 3rd layer of indirection (3rd party api+rest+gwt-rpc serialization) that felt too heavy
Suggestions for a low latency design, where I don't have to write too many wrapper classes for each service call (pojo)?
I'd like to consider jaxb on the server side, making schema as the new contract, and converting them to JSON for gwt-client.
I am using RestEasy on the server side, which uses Hibernate JPA to access database. With a little modification, I should be able to switch over to Datanucleus JPA.
I am using RestyGWT on client side.
With careful consideration on the DTOs, I am able to
- share the same DTO between server and client
- share the same REST interface between server and client (after running a script over the server side REST interface to transform the return type into an async callback).
Integrating multiple GWT applications into a pluggable platform.
Currently I am also trying to merge JPA DTO with REST DTOs so that I have a single set of POJOs between server, database and client. Each DTO POJO would therefore have a mix of JAX-RS, JAXB, Jackson JSON and JPA annotation.
To reduce unnecessary client-server traffic, I use JSP as GWT hosting file in tandem with GWT Dictionary class to transfer all session-specific session-static information to the client.
My Suggestion would be to use Spring RestTemplate, Gwt-RPC and have a RemoteServiceServlet/Spring bridge - that would give you RPC calls via a POJO from Server-Client and a clean tier to communicate with your external web services..
This will be lightweight and clean..
Is it possible to write a server side of GWT application in other languages then Java if yes how to use GWT-RPC mechanism, an sample code please
Thanks
Please read the GWT documentation Communication with the Server:
If you can run Java on the backend and are creating an interface for your application's server-side business logic, GWT RPC is probably your best choice. [...]
If your application talks to a server that cannot host Java servlets, or one that already uses another data format like JSON or XML, you can make HTTP requests to retrieve the data.
You can write your server in any language you choose, GWT is just JavaScript to be run in your users' browsers.
If you decide to go that route, you should look into using RequestFactory to communicate with your server instead of GWT-RPC, which is Java-specific. RequestFactory uses standard JSON, which any language can read/write.
Dont waist your time with GWT-RPC. It's bad. Use RequestFactory. I am surprised people are promoting GWT-RPC. It's a broken toy.
Can anyone suggest whether "GWT" or "Vaadin" are a better choice to design an application? Also: what are the differences in coding style?
In GWT application logic is normally run on client side. It only calls server when it needs to read/save some data.
In Vaadin application logic is on server side. Client side must normally call server after every user interaction.
GWT 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 is slower and introduces a lag in UI interaction which is annoying to user. If network is bad this will show in UI responsiveness.
Vaadin advantage:
App logic is run on the server so it can not be inspected by the user. Arguably (Vaadin claims) that makes it more secure.
A few more points:
A fundamental difference is that in GWT you have to separate your application into Client and Server code, no such distinction in Vaadin. This will affect the architecture of your application.
In GWT client code, you must code in Java, and have a limited subset of language features available (that the GWT compiler can translate into Javascript). In Vaadin, you can code in any JVM language, since everything runs in the server (I'm using Vaadin with Scala). This may or may not be relevant to you.
GWT compilation is VERY slow, although in development mode you have the emulator. This makes production environment updates painful (a GWT application I developed has grown pretty big, and currently takes around 15 minutes to compile).
It's very simple to extend GWT with 3rd party widgets, or roll your own. Creating new Vaadin widgets is more complex.
Another Vaadin advantage: you don't have to design or implement the client-server communication, that's built-in.
With Vaadin you can also use built-in GWT when you want to do something on the client-side. This gives you both simplicity of server-side programming model (no communications, no browser programming needed) with being full control of what happens in the browser.
Differences between Vaadin and GWT:
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.
Vaadin vs GWT
tl;dr
whether "GWT" or "Vaadin" are a better choice to design an application
It is not an “either-or” question.
With Vaadin, you get GWT (or its counterpart, Web Components) plus much more.
Vaadin is a framework for building desktop-style web apps by writing pure Java code on the server-side including declaring a user-interface. That user-interface is rendered in a web browser by Vaadin automatically generating on-the-fly the necessary browser code: HTML, CSS, JavaScript, etc. Business logic executes only on the server-side. User events (buttons clicked, data typed into fields, etc.) on the web client trigger Java code to run on the server side.
How that browser code is generated and executed, and how the client and server communicate, depends on 3rd party technology:
In Vaadin 8 and earlier, GWT
In Vaadin 10 and later, Web Components
Vaadin 8 and earlier uses GWT
Vaadin 8 and earlier was built on top of Google Web Toolkit (GWT). GWT has been spun-out of Google, as a fully open-sourced project: http://www.GWTProject.org/
GWT cross-compiles Java code into standalone JavaScript files. GWT provides other important features such as support of UI components and client-server communications.
The Vaadin Ltd company is a major supporter of GWT, including having hosted GWT developer conferences, and providing consulting expertise services.
Vaadin is only one of many products built on GWT.
Vaadin 10 and later uses Web Components
Vaadin 10 and later, known as Vaadin Flow, is a major rewrite of the framework. Instead of using GWT underneath, Vaadin Flow is built on top of Web Components technology.
Web Components is actually a suite of technologies including Custom Elements, Shadow DOM, and HTML Templates. These technologies are now built into most every modern web browser, and supported on many older browsers via polyfills.
Writing a new widget component for Vaadin is much easier with Web Components than with GWT. And most any existing Web Components based component can be wrapped to provide access via Java from the Vaadin server-side framework.
I don't have a source at hand to cite, but as I recall, Web Components based widgets may run faster and use less memory than their GWT-based equivalents.
By the way, both generations of Vaadin depend on some other technology, such as the Atmosphere library for help with WebSocket and HTTP.
I haven't tried Vaadin. I'm a GWT fan, but I CAN say that I've been a bit disappointed by the default widget set provided with GWT. You really need something like SmartGWT to fill the framework out.
I belive Vaadin is a much more advanced framework than GWT
BUT
When it comes to optimise performance on the client side there is nothing much you can do unless you build your own components (and that's where the beauty of Vaadin stops)
In a project i'm working right now 90% of the staff I've done worked as a charm
And then I had to use an event timeline next to a couple of tables. When I loaded more than 400events on the timeline my web page was almost unusable not to mention terrible slow on initialisation. I've been trying to optimise the code the last two months. At the end I used a GWT component.
As any application has to show display information coming from the server, a major requirement for simple coding is automated data binding to your forms and tables.
With Vaadin, this is as simple as a few lines of code.
In GWT, first you have no table mapping.
As for forms, you can map an object to a form, but to do so you have to implement a so called GWT Editor for your object (and one for every object inside of it). An Editor is nothing else than the definition of the form to use to show/modify the object. So all in all, there is no automation here.
GWT enables you to write web-clients with Java. The GWT cross-compiler creates JavaScript code for the client-side. You have to care for the server for your own as well as client-server communication. The generated client-code is already optimized for many browsers. My personal opinion is, GWT was very popular until Google focused on Angular. Today it is not much popular anymore.
Vaadin provides two different solutions:
1) a UI widget-set based implementing the web-component standard, and
2) the Vaadin serverside Java framework. It allows you to write web-clients with Java. However, Vaadin generates the web-client through runtime on the server dynamically. Vaadin cares for the entire client-server communication. For rendering the UI, Vaadin until version 8 used a pre-compiled UI widget-set. Vaadin from version 10 uses the Vaadin web-components.
Further benefits of Vaadin:
You do not get in contact with HTML and JavaScript and you need not bother for DOM manipulation, browser history and other low-level problems
The serverside architecture provides better security
Modern themes
Individual styling with CSS
RapidClipse provides a powerful UI builder for Vaadin based on Eclipse containing a Vaadin <> JPA databinding, internationalization, UI persistence, extended Hibernate tools, JPA-SQL query language and MicroStream integration for creating Java in-memory database apps and microservices