Pure JavaScript-based clients

Question

I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?

My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.

How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.

Answer 1

Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.

Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.

Answer 2

I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:
https://beebole-apps.com?demo

So yes it is powerful and viable.

Answer 3

Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?

You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)

However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...

Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.

Answer 4

Disclaimer: I'm a member of the Vaadin team.

Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.

Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.

I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.

In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.