I've been making web applications for 15 years, and while the technology has changed, I've noticed a pattern I see as being counter-productive and unnecessarily inefficient.
First, we grab some sort of server infrastructure and begin building server pages (call it xSP, e.g. JSPs, ASP, PHP or even Ruby on Rails). Regardless of the technology, the result is quite similar: A series of template files are combined with data on the server and fed to a stupid web browser as an HTML page.
But our users have smart web browsers and expect a certain amount of dynamic interaction. So we begin to carve off chunks from our server pages and re-implement them with some AJAX wizardry and lots of hand-waving (thank the FSM for jQuery, eh?). The end result is that we now have to maintain code in two places: JavaScript and our Server Page technology.
If the end result is a dynamic, AJAX-laden web application (rich client), why didn't we just begin with that path first and ignore the xSP bit altogether?
In making a dynamic web application, we need to deal with concrete bits, like sending a slice of bread to a web service and getting back buttered toast. This includes:
But there is also a fuzzy aspect of how these toast-like results are inserted back into this dynamic application, and our goal is to have a plugin that can help with both the fuzziness and the toastiness of a modern, dynamically-interactive web application.
That is what the jquery.fuzzytoast.js
plugin is all about. Making it easy to grab a template from a web
server, make a REST call for some data, combining it and inserting it
back into the document. The plugin moves the xSP template processing
from the server to the client, making the server development
significantly more straight-forward and easier.
This demo application is an written using the plugin. Everything on this site is dynamic and loaded as needed. Note: The "REST calls" really just download, static JSON files.