URLs: pretty is good, RESTful is a liability

by koen on Tuesday, February 15, 2011 @ 16:12

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.

Ajax, SEO, hash-bangs and breaking the web

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".
HTML5 History API: nothing but goodness

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.

11 comments
anonymous 2 years ago
an awesome tool
anonymous 3 years ago
Koen wrote: "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."
I had to that the fact that there is lot of people out there who likes C++ and they found in Wt the right tool to not depend on XXX language script programmers.
qc7_ 3 years ago
Hi Koen,
You're right. It's the model (and abstractions) behind Wt that makes it such an awesome web development framework, not the fact that it's implemented in C++ (or Java). Though I agree that C++ is an ideal language to use for a web application.
I think in time others will come around to this view. The efficiency is hard to beat and direct integration opportunities with other code is very compelling!
Coding doesn't have to be a nightmare in C++, I guess it's just that so many of the current approaches are based on scripting languages that to many this just "feels" like the "right" way to do things. But boy are they missing out on something magical if they overlook Wt. Been playing with it for about a week now and it's like a light switching on :)
Cheers!
user 2 years ago
Thanks
anonymous 3 years ago
Hello Koen,
First of all, love the work of you and your team and I think that Wt is an absolutely stunning concept that make web application development such a joy.
But personally I prefer spending time making secure web applications instead of finding a leaky pointer or the cryptic source of irrational behaviour due to the usage of a desiccated pointer.
Secondly on performance, I will not argue that a C++ compiler produces more efficient code than a Java one. But lets be honest, hard core performance CPU performance has never been the issue for any serious Web App. The bottleneck of a web app has always been disc I/O, even when using an very slow language like PHP.
Lastly Java is not only a language but a complete and consistent enterprise framework that is widely used in the business world. C++ is not.
That's why I am thankful for the JWt project that answers business needs with a tool that business can understand. My only hope is that JWt doesn't become the limited clone of a brilliant framework that will only make sense to a limited number of people.
Voilà, that's it :). I once again applaud the vision and wish you all the luck with that amazing framework.
Thim.
anonymous 11 months ago
What? C++ is not a complete and consistent enterprise framework? Better tell GNU and Linux that; they've been leveraging C++'s consistant framework for decades, and they ARE the enterprise for servers. IIS and Solaris are not.
koen 3 years ago
Hey Thim, we get your message, and as I said, it's not about the language (C++).
The same post content would apply also to JWt. In fact, it's also avalaible from the latest JWt git. We are committed to JWt since several large projects on which we work depend on it. JWt is currently only limited in a few features for which we are waiting for Java delegates (stateless slot learning), and are hoping for better Servlet 3.0 container support (web sockets, async I/O). Also some things (like the XHTML render) have not yet been translated to Java. But they could be.
To put our money where our mouth is: I've just synced the JWt git with a version more recent than the Wt git ! :-)
anonymous 3 years ago
Nice to hear it. Thanks for the feedback ;).
Thim.
anonymous 3 years ago
They have a whole language for the Web and still are crying. What is that, a baby got offended?
anonymous 3 years ago
If you don't see the benefit and added value of JWt to the Java world, then a I am wondering if you see all the benefits of Wt.
And please don't be shy, sign those high quality comments.
Thim.
anonymous 3 years ago
Took two days to ponder an answer. A typical J-response. Could be a lot of benefits, the only question at what expense