I’ve come to learn that Wt (and JWt) are opiniated frameworks. I like the word: Wt is not just different from other traditional web frameworks, but it is deliberately so.
Yes, Wt is a C++ library but focusing on this particular oddity is missing the point. It could have been implemented in any language, including your favorite. It just happens that we like C++, don’t believe that it is that complex (at least not compared to web application security) and wouldn’t trust anyone to implement a (secure!) web application who cannot manage a pointer deallocation.
Anyway, one of the unique things in Wt is how it handles URLs (traditionally called URL routing). Wt has an internal path API (implemented as three methods in WApplication) which allow you to:
attach URLs to application state
use the same URLs in plain HTML and Ajax sessions (with the common fragment trick)
use HTML5 history API to avoid the fragment trick in Ajax sessions (as of today in git) in modern browsers (Safari, Chrome or Firefox 4).
In short, you can create a modern Ajax application with perfect graceful degradation (or progressive enhancement) and search engine accessibility.
Recently, there was some controversy on the adoption by gawker.com of Google’s hash-bang workaround for indexing Ajax websites. This prompted discussion on whether this is breaking the core principle of the web : that URLs provide consistent access to resources.
Implementing the hash-bang workaround (or like Wt does, a plain HTML page with exactly the same contents so that it works for any search engine or browser without JavaScript, not just Google bot) in a traditional web framework, using RESTful APIs, is no small technical feat:
You need to use a cross-browser API for reacting to URL fragment changes, and update the DOM accordingly using JavaScript, pulling in the necessary contents from the server using Ajax. In a RESTful implementation, your servers expose a model using RESTful APIs and the View rendering is implemented in client-side JavaScript.
At the same time, you need to make sure that the server generates on its own (exactly!) the same web page when a google indexing robot asks for the same contents, directly from the server, requiring at least a duplication of the View logic.
It is then not a surprise that only the most sophisticated web applications (like Facebook and GMail) take the effort to properly implement this (and others fail).
|
Note
|
Now then, here’s an opinion: if you separate your Model (at the server) and your View (with JavaScript in the browser) and glue them together using a RESTful API and Ajax, you cannot degrade gracefully without painful code duplication, or an equally embarassing page that says "Sorry, not implemented". |
With the advent of the new HTML5 History API, there is no need anymore to use a hash-bang workaround, and you can have the same URLs in Ajax and plain HTML sessions. That eliminates the only draw-back of the hash trick, namely that a user could not pass on a URL from a Ajax-enabled session to a plain HTML session and have it work. Clearly, there is nothing about this that breaks the web, to a user (and search engines), URLs work in a predictable way.
But what’s the benefit?
Staying in the same page does not only give you performance benefits, it also allows you to include new functionality like a chat widget or anything else that requires a stateful presence in your page. You can open a WebSocket connection once for the entire stay of your use on your page. You can do things that are simply not possible otherwise. It is not a coincidence that Facebook moved to Ajax + fragments at the same time that they launched their chat functionality.
Wt and JWt implemented the hash-bang trick already for some time, and we have now added HTML5 History API support. There is no need for duplication of code since the library can render any update either as HTML or JavaScript, depending on what is needed.