Related
I know this topic is likely to become subjective, therefore it is not about my particular web application I am working on.
For JavaScript, I haven't worked with MVC libraries like Backbone.js but I see the advantage in decoupling logic and views. On the other hand, it may just not be worth the time to learn the framework and adapt the application to make use of it. Moreover, handling all views in JavaScript makes SEO much harder, I guess.
So how should I decide whether it makes sense to use Backbone.js or a similar framework given the concept of a web application? On what depends the decision?
Any help to make the question more objective is welcome.
There are many client side javascript MVC (or MV*) frameworks out there. Most seem to have a different idea of what MVC is and how it should work together with your web application.
You should consider an MV* framework if the complexity in your client side javascript is becoming difficult to manage. If you have a team building a highly dynamic single page application (SPA) that does a lot of asynchronous communication with the backend then you will want to consider it. It's easy to end up with very messy javascript code otherwise.
An MV* framework will help you in one or more of the following ways:
by defining how the code should be structured. This is done to various degrees depending on how opinionated the framework is. Backbone for instance considers itself a library rather than a framework and thus leaves more of the decision making up to the user
by binding html to model. So if your data changes the page will be automatically updated (and vice versa)
by providing useful features such as URL history (for single page apps) and validation
I think it depends on your project. Here is a checklist which can help you in deciding whether you should use frontend MV* framework or not.
Lots of ajax request to backend
Many of your functionality doesn't require full page reload. Like adding a comment, pagination or infinite scroll.
You have models/REST API at backend. You can just replicate/use same structure at front end.
You are sharing logic/dom manipulation functions across different pages.
I will add more if I find any more points. This is what I can think right now and this is not a complete list. Any suggestions are welcome.
As You Know MVC structure can be included in javascript by using
backbone.js with
underscore.js and other similar libraries mainly focusing on each form field as property in an entity such that entities can be used different purposes MVC structure is maintained for easy manipulation in javascript
These structure good for event binding,dom manipulation ,serialization,etc
It depends on application's purpose for choosing which structure suitable whether its mvc or mvvm structure for javascript. MVVM structure can be included in the javascript through angular.js or knockoutjs or other libraries for dynamic binding to view component Javascript can be used
MVVM architecture will be usefull for maintaining form field binding without reloading or ajax There are a lot of application by maintaining the architecture in js and i have pointed out only a few .
for eg : Serialize form inputs to JSON using Backbone.js
In this example the form values are retrieved as model and then it can be manipulated and can add business logic and can be serialized or event binding and can do print or any thing
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My goal is to migrate an existing web application to a RESTful single page application (SPA).
Currently, I'm evaluating several Javascript web application frameworks.
My requirements are as follow:
RESTful data layer (like ember-data)
MV*-structure
Dynamic routes
Testing-support
Coding by convention
SEO-support
Browser-History-Support
Good (API-) documentation
Production-ready
Living community
Backbone
The current application is using backbone.js. Overall, backbone.js is a nice project, but I'm missing well-defined structures that determine where what has to happen and how things must get implemented. Working in a bigger team with changing developers this leads to some kind of unstructured code, difficult to maintain and difficult to understand. This is why I'm searching now for a framework, that already defines all this stuff.
Ember
I looked into ember.js the last days. The approach seems very promising to me. But, unfortunately, the code changes almost daily. So, I won't call it production-ready. And, unfortunately, we can't wait for it to be version 1.0. But I really like the idea behind this framework.
Angular
Angular.js is a widely spread framework as well, maintained by Google. But I could not get familiar with angular. For me, the structure seems kind of unclear, explanations are missing of the overall responsibilities of each part of the framework, and the implementations feel circuitous.
Just to get this straight: this is just my personal impression and might be based on missing knowledge.
Batman and Meteor
As I understood, both frameworks need a server part as well. And since we just want a RESTful backend - no matter what language, technic or software, this is not what we want. Further, the backend API does already exist (RoR).
Knockout, CanJS and Spine
I did not go any deeper into these three candidates. Maybe this will be my next step.
So my questions now:
Am I missing any good SPA-frameworks?
What framework would you suggest/recommend?
Would you avoid any of the mentioned frameworks?
What is your experience in bigger SP applications?
PS: I'd would like to recommend a great blogpost from Steven Anderson (core developer from Knockout.js) about the "Throne of JS"-conference (from 2012) and javascript frameworks in general.
PS: Yes, I know there are already some question on SO. But since the development is so rapidly and fast for SPAs, most of them are already out-of-date.
I recently had to decide on a JavaScript SPA framework on a project too.
Ember
Looked at Ember early on and had similar thoughts as you about it - I really liked it but it felt like it was still too early to use... about half the tutorials I read didn't work with the current version because something had recently changed in how templating works.
Backbone
Backbone was the first frameworks we seriously looked at. I'm not sure I understand why you think it doesn't have "well defined structures"? Backbone is pretty clear about how to divide up Model and View code. Maybe you mean there's not some kind of app template? Anyway, Backbone seems really focused on the model/REST-binding part, but doesn't really prescribe anything for view binding. If model binding's important to you and you're using Rails it should be a breeze to do this. Unfortunately, the web services for my app didn't really match up, and I had to write my own .sync and .parse methods for everything. The separation of Model and View code was nice, but since we'd have to write all our bindings from scratch it wasn't worth it.
Knockout
Knockout is like the Yin to Backbone's Yang. Where Backbone is focused on the Model, Knockout is a MVVM framework and is focused on the View. It has observable wrappers for JavaScript object properties and uses a data-bind attribute to bind properties to your HTML. In the end we went with Knockout since view binding was mainly what we needed for our app. (...plus others, as discussed later...) If you like Knockout's view binding and Backbone's model bindings there's also KnockBack which combines both frameworks.
Angular
Looked at this after Knockout - unfortunately we all seemed pretty happy with how Knockout did view binding. It seemed a lot more complex and harder to get into than Knockout. And it uses a bunch of custom HTML attributes to do bindings, which I'm not sure I like... I may take another look at Angular later, because since I've come across multiple people who really like the framework - maybe we just looked at it too late for this project.
Batman, Meteor, CanJS, Spine
Didn't really look too closely at any of these. Though I know Spine is a similar framework to Backbone with explicit Controller objects, and is written in CoffeeScript.
Afterword
As I mentioned, we ended up using Knockout because, for our project, focusing on view binding was more important. We also ended up using RequireJS for modularization, crossroads and Hasher to handle routing and history, Jasmine for testing, as well as JQuery, Twitter Bootstrap, and Underscore.js (and probably more libraries I'm forgetting at the moment).
Javascript app development is more like the Java ecosystem than the Rails ecosystem. Rails provides a solid core of stuff you're going to use for every app (Rails framework), and the community provides a lot of customizations on top of that (gems). Java provides... a language. And then you can choose Java EE or Spring or Play or Struts or Tapestry. And choose JDBC or Hibernate or TopLink or Ibatis to talk to the database. And then you can use Ant or Maven or Gradle to build it. And choose Tomcat or Jetty or JBoss or WebLogin to run it in. So there's more emphasis on choosing what you need and what works together than choosing THE framework to use.
it's been a year since we started development on our Cloud services project with numerous SPAs, so it was a big decision, which javascript framework to use for our UI to satisfy our RESTful architecture needs.
and after a lot of researches we ended up using Dojo framework .
main features you'll love:
educated community and a team that came up with a perfect design pattern. great conventions and modular/object-oriented architecture. with CrossBrowser programming attitudes :)
MV* structure. build UI widgets with external .htm templates and for production, build all your javascript & templates into a single, minified and small .js
build classes with inheritance. property setters, a lot of function tools.
pub/sub mechanism (named topics in dojo)
a lot of UI controls, from validation form control, dialogs/tooltips to a heavy featured, highly customizable (but lightweight) chart & data-grid solution.
a good unit test system named DOH. it also have a robot to reproduce mouse/keyboard actions.
a querying tool (like JQuery) named NodeList with all jquery features and even a lot of it's plugins.
and the good but not so complete part. it has a JsonRest module to use with your REST services. its a handy tool but it lacks a lot of features.
to overcome these issues, we developed an AJAX poller, error handling and universal, loading & notifications solution.
we did it very easily using dojo framework conventions and structures.
if you don't want to do that, perhaps you have to use another framework for this part.
looking at great SPAs around the web you'll find out all of them are customized and using multiple frameworks. but our experience with Dojo alone was fantastic. and therefore I suggest you to don't think of any other framework since all of them are incomplete for a SPA. but ultimately you have also another option (which I don't recommend and have no details information on). go with a JAVA framework that is capable of building SPAs, by automatically generating UI & javascript.
I only know one js library and that is jQuery.
But my other coders in the group are changing AngularJS as their default library in new project.
I don't know anything about it. How is it different from jQuery?
I already have a set of functions done for similar tasks in jQuery. Can I still use jQuery stuff with AngularJS?
While Angular 1 was a framework, Angular 2 is a platform. (ref)
To developers, Angular2 provides some features beyond showing data on screen. For example, using angular2 cli tool can help you "pre-compile" your code and generate necessary javascript code (tree-shaking) to shrink the download size down to 35Kish.
Angular2 emulated Shadow DOM. (ref)
This opens a door for server rendering that can address SEO issue and work with Nativescript etc that don't work on browsers.
The official document site
Day one keynote from ng-conf 2016
Resource links
Original:
Basically, jQuery is a great tool for you to manipulate and control DOM elements.
If you only focus on DOM elements and no Data CRUD, like building a website not web application, jQuery is the one of the top tools. (You can use AngularJS for this purpose as well.)
AngularJS is a framework. It has following features
Two way data binding
MVW pattern (MVC-ish)
Template
Custom-directive (reusable components, custom markup)
REST-friendly
Deep Linking (set up a link for any dynamic page)
Form Validation
Server Communication
Localization
Dependency injection
Full testing environment (both unit, e2e)
check this presentation and this great introduction
Don't forget to read the official developer guide
Or learn it from these awesome video tutorials
If you want to watch more tutorial video, check out this post, Collection of best 60+ AngularJS tutorials.
You can use jQuery with AngularJS without any issue.
In fact, AngularJS uses jQuery lite in it, which is a great tool.
From FAQ
Does Angular use the jQuery library?
Yes, Angular can use jQuery if it's present in your app when the
application is being bootstrapped. If jQuery is not present in your
script path, Angular falls back to its own implementation of the
subset of jQuery that we call jQLite.
However, don't try to use jQuery to modify the DOM in AngularJS controllers, do it in your directives.
Update:
Angular2 is released. Here is a great list of resource for starters
I want to add something regarding AngularJS difference with jQuery from a developer's perspective.
In AngularJS you have to have a very structured view and approach on what you want to accomplish. It is scarcely following a linear fashion to complete a task, but rather, the exchanges between various objects take care of the requests and actions, which, then, is necessary as angular is an MVC-Based framework. It also requires an at least general blueprint of the finalized application, since coding depends much on how you want the interactions to be completed.
jQuery is like a free poetry, you write lines and keep some relations and momentum appropriate for your task to be accomplished.
Though, in Angular JS, you should follow some rules as well as keeping the momentum and relations proper, maybe it is more like classical Spencerian sonnet (a famous classical poet) whose poem is structural and tied to many rules.
Compared against AngularJS, jQuery is more like a collection of codes and functions (which is, as already mentioned, great for DOM manipulation and fast-effect achievement), while AngularJS is a real framework which gives the developer the ability to build an enterprise web-application with a lot of data-binding and exchange within a superbly organized-routing and management.
Furthermore, AngularJS has no dependency on jQuery to complete its task. It has two very superb features which are not found in jQuery in any sense:
1- Angular JS teaches you how to CODE and accomplish a goal, not just accomplish a goal by any means. Worth to mention that AngularJS fully utilizes the core and heart of Javascripts and paves the way for you to incorporate in your app, the techniques such as DI (dependency-injection). To work with angularJS you should (or must) learn more elevated techniques of coding with Javascript.
2- Angular JS is fully independent to handle directives and structure your app; you might then simply claim that jQuery can do the same (independence), but, indeed, AngularJS, as several times mentioned within the above lines, has independence in the most excellent possible structurally MVC-Based way.
A last note is that, there is no war of Names, since it is far disturbing to be biased, or subjective. jQuery's magnitude and greatness has been proved, but their usages and limitations( of any framework or software) are the concerns of the discussion and similar debates around.
Update:
Using AngularJS is decisive as it is expensive in terms of implementation, but founds a strong base for future expansion, transformation and maintenance of the application. AngularJS is for the New World of Web. It is targeted toward building applications which are characterized by their least resource consumption (loading only necessary resources from the server), fast response time and high degree of maintainability and extendability wrapped around a structured system.
AngularJS :
AngularJS is for developing heavy web applications. AngularJS can use jQuery if it’s present in the web-app when the application is being bootstrapped. If it's not present in the script path, then AngularJS falls back to its own implementation of the subset of jQuery.
JQuery :
jQuery is a small, fast, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler. jQuery simplifies a lot of the complicated things from JavaScript, like AJAX calls and DOM manipulation.
Read more details here: angularjs-vs-jquery
I think this is a very good chart describing the differences in short. A quick glance at it shows most of the differences.
One thing I would like to add is that, AngularJS can be made to follow the MVVM design pattern while jQuery does not follow any of the standard Object Oriented patterns.
They work at different levels.
The simplest way to view the difference, from a beginner perspective is that jQuery is essentially an abstract of JavaScript, so the way we design a page for JavaScript is pretty much how we will do it for jQuery. Start with the DOM then build a behavior layer on top of that. Not so with Angular.Js. The process really begins from the ground up, so the end result is the desired view.
With jQuery you do dom-manipulations, with Angular.Js you create whole web-applications.
jQuery was built to abstract away the various browser idiosyncracies, and work with the DOM without having to add IE6 checks and so on. Over time, it developed a nice, robust API which allowed us to do a lot of things, but at its core, it is meant for dealing with the DOM, finding elements, changing UI, and so on. Think of it as working directly with nuts and bolts.
Angular.Js was built as a layer on top of jQuery, to add MVC concepts to front end engineering. Instead of giving you APIs to work with DOM, Angular.Js gives you data-binding, templating, custom components (similar to jQuery UI, but declarative instead of triggering through JS) and a whole lot more. Think of it as working at a higher level, with components that you can hook together, instead of directly at the nuts and bolts level.
Additionally, Angular.Js gives you structures and concepts that apply to various projects, like Controllers, Services, and Directives. jQuery itself can be used in multiple (gazillion) ways to do the same thing. Thankfully, that is way less with Angular.Js, which makes it easier to get into and out of projects. It offers a sane way for multiple people to contribute to the same project, without having to relearn a system from scratch.
A short comparison can be this-
jQuery
Can be easily used by those who have proper knowledge on CSS selectors
It is a library used for DOM Manipulations
Has nothing to do with models
Easily manipulate the contents of a webpage
Apply styles to make UI more attractive
Easy DOM traversal
Effects and animation
Simple to make AJAX calls and
Utilities usability
don't have a two-way binding feature
becomes complex and difficult to maintain when the size of a project increases
Sometimes you have to write more code to achieve the same functionality as in Angular.Js
Angular.Js
It is an MVVM Framework
Used for creating SPA (Single Page Applications)
It has key features like routing, directives, two-way data binding, models, dependency injection, unit tests etc
is modular
Maintainable, when project size increases
is Fast
Two-Way data binding
REST friendly
MVC-based Pattern
Deep Linking
Templating
Build-in form Validation
Dependency Injection
Localization
Full Testing Environment
Server Communication
And much more
Think this helps.
More can be found-
jQuery vs. AngularJS: A Comparison and Migration Walkthrough
"Thinking in AngularJS" if I have a jQuery background?
What are the key differences between jQuery and AngularJS?
jQuery Vs AngularJS – A Good Comparison
What is the difference between jQuery and AngularJS?
Jquery :-
jQuery is a lightweight and feature-rich JavaScript Library that helps web developers
by simplifying the usage of client-side scripting for web applications using JavaScript.
It extensively simplifies using JavaScript on a website and it’s lightweight as well as fast.
So, using jQuery, we can:
easily manipulate the contents of a webpage
apply styles to make UI more attractive
easy DOM traversal
effects and animation
simple to make AJAX calls and
utilities and much more…
AngularJS :-
AngularJS is a product by none other the Search Engine Giant Google and it’s an open source
MVC-based framework(considered to be the best and only next generation framework). AngularJS
is a great tool for building highly rich client-side web applications.
As being a framework, it dictates us to follow some rules and a structured approach. It’s
not just a JavaScript library but a framework that is perfectly designed (framework tools
are designed to work together in a truly interconnected way).
In comparison of features jQuery Vs AngularJS, AngularJS simply offers more features:
Two-Way data binding
REST friendly
MVC-based Pattern
Deep Linking
Template
Form Validation
Dependency Injection
Localization
Full Testing Environment
Server Communication
How should a complex single-page JS web application be structured on the client-side? Specifically I'm curious about how to cleanly structure the application in terms of its model objects, UI components, any controllers, and objects handling server persistence.
MVC seemed like a fit at first. But with UI components nested at various depths (each with their own way of acting on/reacting to model data, and each generating events which they themselves may or may not handle directly), it doesn't seem like MVC can be cleanly applied. (But please correct me if that's not the case.)
--
(This question resulted in two suggestions of using ajax, which is obviously needed for anything other than the most trivial one-page app.)
MVC architecture of PureMVC/JS is the most elegant IMO. I learned a lot from it. I also found Scalable JavaScript Application Architecture by Nicholas Zakas helpful in researching client side architecture options.
Two other tips
I've found view, focus, and input management are areas that need special attention in single page web apps
I also found it helpful to abstract away the JS library, leaving door open to change mind on what you use, or mix & match should the need arise.
Nicholas Zakas's presentation as shared by Dean is a very good place to start with. I was also struggling to answer the same question for a while. After doing couple of large scale Javascript products, thought of sharing the learnings as a reference architecture in case someone needs it. Have a look at:
http://boilerplatejs.org/
It addresses common Javascript development concerns such as:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation
etc.
The way I build apps:
ExtJS framework, single page app, every component defined in a separate JS file, loaded on-demand
Every component contacts its own dedicated web service (sometimes more than one), fetching data into ExtJS stores or special-purpose data structures
The rendering uses standard ExtJS components, so I can bind stores to grids, load forms from records, ...
Just choose a javascript framework, and follow its best practices. My favorites are ExtJS and GWT, but YMMV.
Do NOT roll your own solution for this. The effort required to duplicate what modern javascript frameworks do is too big. It is always faster to adapt something existing than to build it all from scratch.
Question - What makes an application complex ?
Answer - The use of word 'complex' in the question itself. Hence, a common tendency will be to look out for a complex solution right from the beginning.
Question - What does the word complex means ?
Answer - Anything that is unknown or partially understood. Example : The theory of Gravity even today is COMPLEX to me but not to Sir Isaac Newton who discovered it in 1655.
Question - What tools can I use to deal with complexity ?
Answer - Understanding and simplicity.
Question - But I understand my application . Its still complex ?
Answer - Think twice, because understanding and complexity does not co-exist. If you understand a huge huge application, I am sure you will agree that it is nothing but an integration of small and simple units.
Question - Why all of the above philosophical discussion for a question on
Single Page Application (SAP)?
Answer - Because,
-> SPA is not some kind of core technology that is newly invented for which we need to reinvent the wheel for a lot of things that we are doing in application development.
-> Its a concept driven by the need for better performance, availability, scalability and maintainability of web applications.
-> Its a fairly newly identified design pattern, so an understanding of SPA as a design pattern goes long way in making informed decisions about the architecture of a SPA.
-> At the root level no SPA is complex, because after understanding the needs of an application and the SPA pattern, you will realize that you are still creating an application, pretty much the same way you did before with some modifications and re-arrangements in the development approach.
Question - What about the use of Frameworks ?
Answer - Frameworks are boiler plate code / solution for some commonly identified and generic patterns, hence they can take off x% (variable, based on the application) load from application development but then not a lot should be expected out of them specially for heavy and growing applications. Its always a good case to be in complete control of your application structure and flow but most importantly the code for it. There should be no grey or black areas in the application code.
Question - Can you suggest one of the many approaches to SPA architecture ?
Answer - Think of your own framework based on the nature of your application. Categorize application components. Look for an existing framework that is close to your derived framework, if you find it then use it, if you do not find it then I suggest going ahead with your own. Creating framework is quite an effort upfront but produces better results in long run. Some basic components in my SPA framework will be:
Data Source : Models / Collections of Models
Mark Up for presenting data : Templates
Interaction with the application : Events
State capturing and navigation : Routing
Utilities , widgets and plug-ins : libraries
Let me know if this helped in any way and good luck with your SPA architecture !!
The best thing to do is to look at example uses of other frameworks:
TodoMVC showcases many many SPA frameworks.
You can use javascript MVC framework http://javascriptmvc.com/
The web application that I am currently working on uses JQuery and I would not recommend it for any large single page web application. Most frameworks i.e. Dojo, yahoo, google and others use namespaces in their libraries but JQuery does not and this is a significant drawback.
If your web site is intended to be small then JQuery would be ok but if you intended to build a large site then I would recommend looking at all the Javascript frameworks available and deciding which one most meets your needs.
And I would recommend applying the MVC pattern to your javascript/html and probably most of your object model for the javascript could be done as the json that you actually return from the server through ajax and the javascirpt uses the json to render html.
I would recommend reading the book Ajax in action as it covers most of the stuff you will need to know.
I'm using Samm.js in several one page applications with great success
I would go with jQuery MVC
Check out http://bennadel.com/projects/cormvc-jquery-framework.htm Ben is pretty sharp and if you dig around on his blog he has some nice posts about how CorMVC is put together and why.
Alternative: take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.
Or have a look at https://github.com/flosse/scaleApp
NikaFramework allows you to create single-page application. Also allows you to write HTML, CSS (SASS), JavaScript into separate files and bundle them into only one output file in the end.
I would recommend to explore Yeoman. It allow you to use existing "best practice" for your new project.
For example:
if you decide to use Angular.js, there is a Yeoman generator, that give you a structure for routing, views, services, etc. Also allow you to Test, minify your code, etc.
If you decide to use Backbone, checkout this generator
I would like to create a database backed interactive AJAX webapp which has a custom (specific kind of events, editing) calendaring system. This would involve quite a lot of JavaScript and AJAX, and I thought about Google Web Toolkit for the interface and Ruby on Rails for server side.
Is Google Web Toolkit reliable and good? What hidden risks might be if I choose Google Web Toolkit? Can one easily combine it with Ruby on Rails on server side? Or should I try to use directly a JavaScript library like jQuery?
I have no experience in web development except some HTML, but I am an experienced programmer (c++, java, c#), and I would like to use only free tools for this project.
RoR is actually one of the things the GWT is made to work well with, as long as you're using REST properly. It's in the Google Web Toolkit Applications book, and you can see a demo from the book using this kind of idea here. That's not to say that you won't have any problems, but I think the support is definitely out there for it.
There's a neat project for making RoR/GWT easy that you can find here (MIT license). I haven't had a chance to try it out yet, but it looks like a good amount of thought has been put into it. One catch is that it looks like it hasn't been fully tested with 2.1 Rails yet, just 2.0, so you may run into a few (probably minor and fixable) errors.
If you are looking to integrate GWT with non-Java backends such as ROR, PHP etc., you should bear in mind that GWT 1.5 now supports JavaScript Overlay types. This feature lets you write classes that can be mapped over the top of native JavaScript objects to easily provide accessor methods for properties of those objects and other extended functionality.
See this link for more details:
JavaScript Overlay Types
So you could return JSON encoded data from your backend via AJAX calls, parse it into a JavaScript Object and then access the data through your GWT Java code using the overlay classes you've created. Or when you render your page you can render static config data as JavaScript Objects and read it in via this mechanism, rather than having to do an AJAX call to grab the data.
If you know JAVA, and have somewhere you can host it (like a tomcat or glassfish container) I would recommend that much more than using Ruby for the back end. The main reason is that then you can share all of your objects, and use the built in RPC mechanism. I've done this for quite a lot of our projects and it's a huge timesaver, not to mention that the code is less error prone, because you don't convert your java objects to anything and then back again.
I have linked my GWT with Rails before, using the to_json function in Rails and then reading the JSON in GWT. It's all supported, but it is far more annoying than just doing the back end in JAVA.
Of course if you have cheap hosting, then Java containers are pretty much out of the question, in which case I would think Rails would be the next best thing.
GWT is very high quality with a great community. However you do need to know CSS if you want to adjust the look of things (you will) - CSS can do a lot of the layout, just like regular web if you want it to. Libraries like GWT-ext or ExtGWT can help a bit as they have stunning "out of the box" looks but for a price (extra size to your app).
You can code everything in Java using GWT, and you can integrate existing 3rd party javascript libraries with it. It's very good. I've never used RoR much though, so can't say anything about that.
If you're experienced in Java but not in Javascript/CSS, then GWT is going to be a lifesaver (unless you want to learn them, of course). CSS has so many little fiddly details. It is not uncommon to spend half a day fixing a 2 pixel misalignment that only occurs in IE6.
I am not sure about how easy it would be to use ROR for the back end... It is possible, I am sure, since GWT ajax communication is just servlets. But they provide some really nice functionality for passing Java objects back and forth which you won't be able to utilize if your server isn't also using Java.
I wrote about some of the disadvantages of GWT recently. Mainly, the disadvantages are: long deployment cycle for changes to some parts of the application and a rather steep learning curve. As a seasoned Java programmer, the second should be less of a problem and if you use a seperate backend, the first is also mitigated (as a complete redeploy is primarily required when you change the 'server' part of the application).
GWT is a wonderful framework with lots of potential. Keep in mind that it's still quite new, though. There are some unresolved bugs that can really annoy you, and they usually require ugly workarounds to get past. The community is great but you'll probably end up with a few problems sooner or later that Google can't answer yet.
But hey, I say go for it. The potential for GWT is awesome, and I bet it's future will be bright.
You should definitely use GWT for a new project (it's pretty easy to use in an old project too).
I my experience it's very fast to learn and use. The compiled javascript code is much better than anything you could ever write by hand and it works fast too.
Another benefit is the ability to debug you're code (which is hell with javascript alone)
This blog has inputs from many experienced users of GWT and have some great discussion points. I personally have huge experience with varied UI Frameworks. I will add my two cents. Lets look at fundamental advantages and disadvantages of GWT
Fundamental Advantage
GWT takes the web layer programming to JAVA. So, the obvious advantages of Java start getting into play. It will provide Object Oriented programming. It will also provide great debugging and compile time checks. Since it generates HTML and Javascript, it will also have ability to hide some complexity within its generator.
Fundamental Disadvantage
The disadvantage starts from the same statement. GWT takes the web layer programming to JAVA. If you know JAVA, probably you will never look out for an alternative language to write your business logic. It's self sufficient and great. But when it comes to writing configurations for a JAVA application. We use property files, database, XML etc. We never store configurations in a JAVA class file. Think hard, why is that?
This is because configuration is a static data. It often require hierarchy. It is supposed to be readable. It never requires compilation. It doesn't require knowledge of JAVA programming language. In short, it is a different ball game. Now the question is, how it relates to our discussion?
Now, lets think about a web page. Do you think when we write a web page we write a business logic? Absolutely not. Web page is just a configuration. It is a configuration of hierarchical containers and fields. We need to write business logic for the data that will be captured from and displayed on the web page and not to create the web page itself.
Previous paragraph makes a very very strong statement. This will explain why HTML and XML based web pages are still the most popular ones. XML is the best in business to write configurations. A framework must allow a clear separation of web page from business logic (the goal of MVC framework). By doing this a web designer will be able to apply his skills of visualization and artistry to create brilliant looking web pages just by configuring XMLs and without being bothered about the intricacies of a programming language. Developers will be able to use their best in business JAVA for writing business logic.
Finally, lets talk about the repercussions in direct terms. GWT breaks this principal so it is bound to fail. The cost for developing GWT application will be very high because you will need multiskill programmers to write web pages. The required look and feel will be very hard to achieve. The turn around time of modifying the web page will be very high because of unnecessary compilation. And lastly, since you are writing web pages in JAVA it is very easy to corrupt it with business logic. Unknowingly you will introduce complexities that must be avoided.
You could also consider Grails ("Groovy on Rails") which gives you the benefits of a Rails framework and the use of the Java VM.
Our team recently asked the same question, and we chose to go with GWT, especially since the designer plugin made working with GWT more accessible to non-java experts on the team. Whoever makes this choice, just beware you DON'T use the GWT Designer plugin !! It has not been updated (in at least a year, apparently) to create a GWT application that is compatible with IE8.
Our team had almost completed our application layouts, which were working perfectly in Chrome, FF and Safari. Then they blew up in IE. IE 7 would load partial pages (but not composite includes), and IE8 was not even able to load up the application. It just hung.
The designer plugin has buttons that allow the user to add CellTable widgets that are not IE compatible (CellTable, DeckPanel, Horizontal Panel, Vertical Panel, among others). These will cause intense pain when the layouts have to be re-done in java without assistance from the designer.
Experienced GWT users love it, but the designer plugin will kill you.