The jQuery Templates API and JavaScript’s Future
On October 4th (two days ago) jQuery announced that they had promoted three Microsoft projects as official jQuery plugins: The jQuery Templates Plugin, the jQuery Data Link Plugin and the jQuery Globalization Plugin. See the announcement here. It’s definitely worth a read if you use jQuery at all.
Now, in my opinion the new Data Link and Globalization APIs have yet to prove themselves. They really seem like Microsoft steering jQuery-style JavaScript towards the way ASP.NET Web Forms works, and time will tell whether that ends up making sense in JavaScript’s evolution. What I’m really excited about is the jQuery Templates API, and that’s what I think makes this a significant milestone for how we’ll be doing JavaScript in the future.
For Context…
The jQuery Templates Plugin allows you to generate HTML to represent data stored in JavaScript objects, similarly to PHP or ASP. For example, if your page contains the following template…
<script id="resultsTemplate" type="text/x-jquery-tmpl">
<li>
<a href="${Url}" target="_none">
${Description}
</a>
</li>
</script>
…This template can be selected by jQuery, rendered with data and then appended to the page. For example…
// Data stored in an object:
var resultsData = [
{
Url:"http://www.google.com/",
Description:"Google Search"
},
{
Url:"http://blog.thatscaptaintoyou.com/",
Description:"Wyatt Allen's Blog"
}
];
// Select the template,
// render it with the data (making it a bunch of LIs),
// and stick it in the page:
$("#resultsTemplate")
.tmpl(resultsData)
.appendTo("#myDivId");
… Very easy and maintainable.
What This Means…
Part of the significance of this is that templates mean we can build more interface into the browser’s language. We won’t need the server to render all our HTML for us, and, with the weight of many Ajax applications, we shouldn’t have to. This API is a wonderfully clean and manageable way of accomplishing this.
The other half of the significance here is has to do with how we build GUI frameworks. Sometimes I compare building web interfaces to building native interfaces on something like Windows. Early on, we’d build Windows programs by talking directly to the Windows API – using something like “windows.h”. Progressively, however, frameworks were built to make this process a lot cleaner and reasonable such as the MFC library. This transition really signifies ironing away the hard parts of an API using an object-oriented abstraction; complete with inheritance, polymorphism and the whole collection of OOP ideas. It’s an age-old, tried-and-tested, Gang-of-Four design-pattern, and we love it.
The way I see JavaScript DOM programming and the current state of HTML is that it’s still in the early “windows.h” stage of evolution. A good, strong object-oriented abstraction for programming web interfaces would meaningfully improve the development process, maintenance, security and richness of the web. The reason that I feel nobody’s build something like this yet is because JavaScript’s OOP approach is so unusual. Tools like inheritance and polymorphism as they’re implemented in JavaScript simply don’t lend themselves well to frameworks.
I believe that this new jQuery Templates API is a BIG push in the right direction. It will allow us to deal with interface components with varying degrees of abstraction and join data to markup in a responsible, semantic fashion. I encourage every JavaScripter to try jQuery Templates out for themselves. I’m going to be using them and closely watching how they’re being used in expectation that it will lead to an emergent, more properly-abstracted approach to our web applications.
Updates to Validity and Roadmap
I’ve gone through and updated the Validity documentation plus plenty of tweaks here and there to the whole site. Check it out!
The next steps for Validity itself are:
- Improved support for radio buttons.
It seems like most of the problems I’m helping people with have to do with radio-buttons. Consequently, we’ll be adding tools to validity to make this validation as straightforward and helpful as possible.
We feel that it’s important for using Validity to feel natural, and radio-buttons are an area that can be improved a bit.
- Improved support for password validation.
We’re planning to introduce a
semanticPasswordvalidator. This will allow you to specify the complex validation parameters needed for passwords (such as minimum non-alphanumeric characters, password strength, etc.) in a manner that makes sense.The goal is to make the way you validate a password on the server the same as the way you do so on the client. If, on the server you specify the minimum number of non-alphanumeric characters with an integer value (such as commonly in ASP.NET) you won’t have to translate that into a regex for validity. A regex would be less manageable. Less manageable is bad.
They’re exciting times for Validity. Look for a new version soon!
Welcome
Welcome to the That’s Captain to You blog! At this place I plan on writing about things I find or am working on. Likely, most of it will be related to web development and design.
A quick, tiny autobiography: I a student finishing up my Computer Science degree in Oregon. I work as a programmer at a software company that deals mostly with ASP.NET web-applications.
I also manage a open-source jQuery form-validation plugin called jQuery.validity. I do a lot of work in JavaScript.
Anyway, my hope with this blog is that I’ll be able to supply information which will be useful to somebody. Enjoy.