Official Plugins: A Change in The Roadmap
Barely six months ago, we announced that we were adopting three plugins developed chiefly at Microsoft – Templating, Data Link, and Globalization – as official plugins, to be developed in accordance with the standards of and supported by the jQuery project. Today, we’d like to take an opportunity to share what we’ve learned in the interim and announce a change in course for these and the rest of jQuery’s “Official Plugins.”
There never has been a dedicated jQuery team for supporting Official Plugins. Prior to the adoption of Microsoft’s contributions, the plugins that the jQuery project supported – Color, Easing, bgiframe, Mousewheel, Metadata, and Cookie – were dead-simple, effective plugins for achieving a particular utilitarian end. They required little maintenance, stalwartly serving with little fuss from version to version of jQuery core. In recent months, as we noticed an uptick in questions related to the three new plugins, we realized there was a disconnect. Though development on beta versions of the plugins continued at Microsoft, the planned jQuery sub-team that was meant to collaborate with and adopt Microsoft’s work never formed.
As demand has grown, based on the existence of the beta versions of the plugins as well as promises made in the posts, we’ve sensed the rumbles, the confusion, and the confused exclamations: “I thought templating was going to be in 1.5!” Because of your concerns and ours, we’ve decided to eliminate the notion of Official Plugins altogether. It’s a difference that’s both semantic and symbolic, but this is its material impact:
Many of the original supported jQuery plugins (Color, Easing, and Mousewheel) will continue to be supported and maintained by the jQuery Core Dev Team. The Metadata plugin will be deprecated, in favor of similar functionality provided by jQuery 1.4.3 and above. The Cookie plugin will continue to be maintained by Klaus Hartl.
The jQuery UI project will take ownership over plugins on which it has a current or future dependency: Templating, Globalization, and bgiframe. The jQuery UI team plans to begin work anew on templating and globalization, starting with the normal process for UI plugins: Collaborative development on a spec. While some may perceive this as a setback, given existing progress on the current jquery-tmpl plugin, it is really an opportunity for us to work in tandem with the community — Microsoft included — to develop an implementation that will be effective and flexible. The “official plugins” Microsoft has been developing have always been in a beta state, subject to change and with significant revisions planned for the Beta 2 release, but we recognize (and appreciate) those of you who have jumped in and started to experiment and use them in your applications. The UI team is still in the early planning stages for the Templating and Globalization plugins, and we invite you to visit the planning wiki and share your thoughts about development.
Microsoft will continue to develop and support the Data Link plugin independently, and will take ownership of hosting the documentation for the existing plugins. In the short term, however, we’ll keep the documentation for these plugins on api.jquery.com, in order preserve a reference for anyone who needs it. For more on Microsoft’s plans for Data Link, please read their Official Plugins Update. We value Microsoft’s ongoing contribution to jQuery, providing developer time and financial support for a number of efforts, including the jQuery UI Grid and the jQuery conferences.
We realize that some of these details may seem in flux or merely organizational, but we know that it’s important to tell the community of changes like these as they’re happening so that you can make the best decisions for your applications as soon as possible. We hope you understand why we’ve had to make these shifts and encourage you to get involved and help us push these important projects along!
Addendum: So Why Weren’t Templates in 1.5?
Though we initially announced that the jquery-tmpl plugin would be part of jQuery Core in version 1.5, the plugin was, as it is today, still in the Beta 1 stage. Thus, when the time came last December to really evaluate new features for 1.5, it was not really considered ready for inclusion. Given what we’ve explained above, we hope it’s clear that we don’t plan to include templating directly in Core in the near future. The jQuery UI Templating plugin will be a standalone plugin with no dependencies on any other part of jQuery UI, and will become the only templating solution “officially” supported by the project, though jQuery will, of course, continue to work with any JavaScript templating engine that spits out good, old-fashioned strings of HTML.
I hope I share the community’s feelings when I say this is great news and also discouraging news. After playing with the jquery-tmpl library over the last few weeks, I had to decide against it as the API didn’t feel right yet. So this is good news that it’s going back to the drawing board. Also, it’s movement to the jQuery UI team makes sense architecturally and organizationally. I look forward to the jQuery templating engine, I feel like I’m suffering without it, but good things come to those who wait.
I just hope that the templating library won’t go the same way as many of the other libraries assimilated by jQuery UI.
I *just* want the templating library as a nice, clean library. I don’t want any of the other UI junk or having to include 4 other files just to make use of templating.
“We realize that some of these details may seem in flux or merely organizational”
Nope, it seems confusing and without vision.
I get the feeling that in 6 months there will be another post on JQuery UI explaining more “organizational changes” to these projects.
They feel so sluggish compared to the fast iterations the core goes through. Oranges and apples I know, but still, why so complicated?
Thanks for the update.
One thing about templating which is very important is to decouple the raw templating processing from the jQuery/DOM. It would great to be able to use the same templating engine in non-DOM runtime (i.e. server javascript). So, the model to give a string as a template and a JSON DOM as a model to get the result, should be “container” independent, and obviously convenience jQuery wrappers such as $(“tmpl-myTemplate01″).tmpl({name:”Jeremy”}) are also welcome
Just to be clear, what will happen to the current jquery-tmpl plugin? Will it evolved into the jQuery UI Templating plugin or both are separate plugins?
The jQuery UI Templating plugin will be a standalone plugin with no dependencies on any other part of jQuery UI, and will become the only templating solution “officially” supported by the project, though jQuery will, of course, continue to work with any JavaScript templating engine that spits out good, old-fashioned strings of HTML.
I vote to keep globalization as a separate, stand-alone plugin as well, with no dependencies on JQuery UI (similar to the proposal for the templating plugin)
What a shame but I hope the new template plugin will be even better. For now I will continue to use existing one which has worked very well for me thus far.
The Globalization plugin is now 100% pure JavaScript, with no dependency on jQuery. It has been renamed Globalize and has a wiki page at http://wiki.jqueryui.com/Globalize and the repo is at http://github.com/jquery/globalize/ . It is also listed in npm: http://search.npmjs.org/#/globalize
The Template plugin redesign is in-progress on the jQuery UI wiki at http://wiki.jqueryui.com/Template and wiki.jqueryui.com/Template-Comparison . So far the most up-to-date (and useful) sections are section 3 of the Template wiki page and the 5 rows under the “Core” features section of the table on the Template-Comparison wiki page. Like Globalize, the new template plugin will have no dependency on jQuery (so it can work server-side), but we will develop a jQuery plugin wrapper around it. While the jQuery UI team will only fully support use of the jQuery UI Template plugin in jQuery UI widgets, we envision users being able to swap in their template engine of choice as long as it can support the same core API, minimally a function that accepts a template string and a data object, then returns a string result.
Some more details on the history behind this change and what has occurred in the last six months since this announcement can be found at http://www.borismoore.com/2011/10/jquery-templates-and-jsviews-roadmap.html
Very frustrating… I suppose it’s my fault for incorporating beta 1 into my project. Hopefully, you guys will have something soon. The thing that sucks the most about javascript is the brittle nature of the dependencies that occur with the various plugins.
Worth mentioning here that there are a couple other options for client side templating engines for jquery.
JsRender and JsViews: Created by Boris Moore who also worked on jQuery tmpl and is now approaching Beta as of March 6, 2012. Check out http://www.borismoore.com/2012/03/approaching-beta-whats-changing-in_06.html
JSON2HTML: created by myself as a templating plug-in that uses a more simplified (in my mind) approach with json as the template instead of html markup. Worth checking out as it includes integration of jquery events as well
http://www.json2html.com
There are also a number of other ways to perform templating ‘like’ features on the client; an popular example is ‘Plates’ (formerly Weld). https://github.com/flatiron/plates
Anyhow lot’s of options poping up these days, it’s going to be interesting what sticks
I’ve read this post three times, and it still doesn’t make any sense. Can you rewrite this without saying “Microsoft” every third word, and with sentence structure that doesn’t read like it was drafted by a corporate communications department? Thanks in advance.
So you exchanged an excellent working template library for a none working version 0.0 vaporware. Was it because it was written by Microsoft, because I don’t see the compelling argument from these flimsy excuses which amount to: “That’s a complex plugin we don’t control, how about our non-working alpha vaporware instead?”