As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I want to build a site where the user can enter text and format it in Markdown. The reason I'd like a Javascript solution is because I want to display a live preview, just like on StackOverflow.
My site is not targeted at developers, however, so an editor control would be ideal.
I gather that on StackOverflow, the WMD editor is being used.
A quick search on Google also turns up Showdown library, which I think is actually being used by WMD.
Are there any other options? Are WMD/Showdown great tools already? What have been your experiences with the different options?
We've been pretty happy with WMD. There are a few niggling bugs in it, however. Nothing major, but I would love if John Fraser (the author) made the code open source so we can fix some of them. He's promised to do so but other real life projects are getting in the way.
I do follow up with John every week. I'll post on the blog once the WMD source is finally available. Haven't been able to contact John Fraser in over a year now.
We have open sourced both the JavaScript Markdown library
http://code.google.com/p/pagedown/
and the server-side C# Markdown library
http://code.google.com/p/markdownsharp/
If you're not averse to using Ajax to generate the live preview, then another option is markItUp!. markItUp! is a universal markup-editor, and very flexible. It does provide
an easy way of creating a markup editor, but unlike WMD, it doesn't provide its own live preview.
I used markItUp!, along with a simple JSP (using MarkdownJ) for one of my open-source projects (a Markdown plugin for Roller). If you're using another server-side technology, replace that simple JSP as appropriate.
I actually starting using this before I came across WMD. I'd agree, WMD is great, but has only just been open-sourced and is, at this stage, more difficult to customize the behavior of.
I would recommend marked, which is lightweight, efficient, easy to use and supports GitHub Flavored Markdown (GFM) as well. It can be used in either server(nodejs) or client(browser) sides.
As far as I know there really isn't any other browser-based editor for Markdown, at least none as extensive as the WMD editor.
Showdown is a Markdown converter in JS, which forms the basis for the HTML preview of WMD. They're both made by http://attacklab.net/.
And as far as I know there haven't been any big complaints about both (at least not on the Markdown mailing list). So go for it.
There is one named Showdown and it is currently hosted here: https://github.com/coreyti/showdown
And there is https://github.com/evilstreak/markdown-js :)
Strapdown.js, which was recently released, "makes it embarrassingly simple to create elegant Markdown documents. No server-side compilation required."
I've not tested this, but here is another option:
Markdown wysiwyg
The question is even more ancient now but also even more relevant since much of the mentioned code is several years out of date.
However, I did find a few that still seems current:
Jquery-Markedit - This was forked from wmd-edit quite some time ago and refactored to use jQuery. Seems good at first sight.
EpicEditor - is also still maintained, has a flexible parser and, as you can see below, the author is highly responsive (see below). IT seems to have good documentation as well. Sadly not working with IE9.
MarkdownDeep is a third option that is still current. The interesting point with this one is support for Markdown Extra. Has a dependency on JQuery (actually you can also implement without JQuery). Based on the .NET version so documentation is more aligned to that than the JS version. This also works with IE9. It is very easy to use (with JQuery) & very simple. No significant development happening with this though as far as I can see.
js-markdown-extra is a fairly accurate port of the PHP library and is still under maintenance. It supports Markdown Extra of course.
The question is ancient but hopefully this might help someone. I have just recently published a working version of my own Javascript markdown editor, uedit. You can find the source code here. It works on most browsers (including IE6+) and doesn't depend on any external JS libraries.
After trying with several plugins to solve my own needs of offering a MarkDown seudo-WYSIWYG I ended implementing my own one:
http://fguillen.github.com/MDMagick/
Maybe is not as powerful as all the solutions commented here but I think that none is as simple and easy to integrate and customize.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Context:
I am astounded by the number of front end developers that hack at HTML, Javascript and CSS all day long and that ignore tools like jQuery ( or other equivalent helper frameworks ) and refuse to use them. I am not talking about JavaScript gurus, I am talking about in the trenches every day Joe production developers. I get a lot of arguments that are more like excuses or personal opinions that I don't think have any technical merit, I want to make sure I am not missing something.
Question:
What are some empirical technical reasons not to use jQuery?
I am not looking for religious or dogmatic arguments or subjective opinions "like some other framework is better", consider jQuery the straw man for all comparable frameworks in the question.
Update 2015:
In this answer from 2011 I'm talking about libraries like jQuery, YUI
or Prototype. Today in 2015 that reasoning is still applicable to
frameworks like Angular, React or Ember. In those 4 years the
technology progressed tremendously and even though I see considerably
less prejudice against React or Angular than I saw against jQuery or
YUI, the same kind of thinking - though to a lesser extent - is still present
today.
Update 2016:
I highly recommend an article published few days ago:
Why jQuery? by Michael S. Mikowski, author of the Single Page Web Applications book
That article is basically a very detailed answer to this very
question. Had it been available when I was writing the answer below - I would have definitely quoted it.
Original answer:
I'll answer about jQuery but those are the same arguments that I've heard against using YUI, Prototype, Dojo, Ext and few others. Main arguments that I've heard:
file size, which in fact is 84.6 KB in case of jQuery 3.2.1 - probably smaller than the logo on an average website and can be served from Google's CDN which is likely to be already in the cache of most of your visitors. As using jQuery always means smaller file size of your own JavaScript files, it can actually mean smaller download, even if not already in the browser cache.
speed - writing pure JavaScript may be faster, but writing portable JavaScript seems to be impossible for most of the people. A website that is faster but doesn't work on every popular browser is useless in the real world. Besides jQuery uses some pretty heavy optimizations to actually be pretty damn fast and keeps getting even faster with every release, so it's actually not so easy to write faster code by hand for anything other than trivial examples.(*)
"intellectual property" - a company is scared using someone else's code - while in fact jQuery is open source and free software that is used everywhere from your grandma's blog to Amazon, from Twitter to Bank of America, from Google to Microsoft - if they can use it then any company can use it.
I can't remember hearing any other argument being used seriously.
(*) Here's a trivial example: getElementById('someid') vs. jQuery('#someid')
Is using getElementById faster? Yes. And of course everyone always checks the parentNode to catch when Blackberry 4.6 returns nodes that are no longer in the document, right? jQuery does. And everyone handles the case where IE and Opera return items by name instead of ID, right? jQuery does. If you don't do it then your code is not portable and you introduce subtle bugs that can be very difficult to find. And getElementById is the most trivial example that one could possibly find - don't even get me started on events and AJAX and the DOM...
Update:
There is actually a fourth result of asking why someone doesn't want to use jQuery. I forgot to put it on this list because it is not really an answer but rather the lack of any answer. The comment I got yesterday reminded me about it. This is hardly a "technical reason" to be added to the list but may be interesting nonetheless and may actually be the most common reaction.
What I personally suspect to be the main underlying reason to all of those reactions, though, is what I believe to be the biggest obstacle to progress in computer science: "I don't want to use it because I never did, therefore it must not be that important."
It was once the reaction to optimizing assemblers, compilers, structured programming, higher level languages, garbage collection, object oriented programming, closures or pretty much everything that we now take for granted — and today it's AJAX libraries. Maybe some day no one will remember that we once used to manually interact with the raw DOM API on the application level like now no one remembers that we once used to write programs using raw, unadorned, inscrutable hexadecimal numbers.
jQuery expresses everything in a DOM-centric paradigm which can be misleading and doesn't require any need to express things in an application pattern.
Many developers wind up programming themselves into a corner with this DOM-centric pattern and eventually realize they haven't created anything extensible or reusable.
Rebecca Murphey has a great write-up of her own switch to Dojo from jQuery - the blog post is more about why not jQuery versus why Dojo.
One reason not to use a framework - and this is an extreme edge case - is when writing embeddable code for another website, such as a banner. Arbitrarily inserting some complicated library or another will be polluting the namespace and potentially breaking someone else's site. Not that I wouldn't put it past some advertisers to try anyway, the pond-sucking scum, but I digress...
I disapprove of adding a framework when one is already present and equally capable. I see it all too often and it's my pet hate, I see it as unwarranted bloat. That is another question entirely.
Other than that I cannot think of a justified reason not to.
filesize - but really, beyond that, it's an absolute god-send for cross-platform javascript and browser differences. You would have to have some very good reasons not to want it in your toolkit (or be a fundamentalist developer idiot).
They can't justify the filesize (even though it is probably less than script which doesn't utilise the abstractions provided).
They don't want to rely on third party tools.
Their business does not want to run any libraries (for whatever reasons).
Their business does not want to run any JavaScript code not written by their employees.
Learning: To actually code everything, and learn more. (Rather than using pre-coded stuff)
Size: jQuery has TONS of features you might not need, why make the user download so much code if it's not going to be used?
Alternatives: at this point, there are dozens of more powerful, well structured web frameworks out there.
Flexibility: Although jQuery is really flexible, you might need something it doesn't provide.
By all means, I like jQuery, but there are some reasons not to use jQuery:
Download size/bandwidth: jQuery 1.5 is now over 200K uncompressed, for some the size of the library is too much to justify the benefit.
Performance: Writing native JS will always be faster than abstracting it behind a library.
Added complexity: Many people will download the entire jQuery library when really they only need a few neat features from it.
Application Dependencies: Introducing dependencies always has its hang ups. If there is a bug in jQuery, you can debug and edit the file, but upgrading later introduces problems. You could leave the bug, but now you are dependent on jQuery's time table for a fix, not your own.
Because quite often it's just unnecessary.
if all I want to do is validate some input, or hilight some field then it's just as easy to write simple javascript / dom code. And jQuery doesn't really help in such simple cases, so the question should be why use it?
Clearly there are many cases where it is very useful, but sometimes people seem to use it for no real reason too.
I would prefer to use jquery for dom manipulation or traversing the dom , which is really easy with jquery . Moreover, attaching an event or event delegation are so easy using jquery or other framework otherwise you have to write custom event attachment for IE or non IE browsers etc.
But it has some performance penalty when you use $.each instead of vanilla JS for and array.push()...
other issues like if you bind an event and remove that without unbind it will have memory leak....
My conclusion is only use any framework for complex dom manipulation and rest use vanilla JS
Why not use jQuery?
I can't think of a good excuse to use vanilla JavaScript over jQuery (aside from the intimidation factor of learning something new), but some people prefer other JavaScript frameworks (like the excellent MooTools) due to the philosophical differences between them.
Some people simply don't like jQuery's DSL-ish syntax, but they recognize the importance of using a robust JavaScript framework.
Personally, I love jQuery, but I know people who use other frameworks and are no less productive.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I like javascript, but I have problem with learning it :)
I mean, i use it at work but I would like to know more, and I think the best way to do it is to read and understand someone else's code.
I use ASP.Net MVC and there are some great opensource projects you can use to learn new technology, like NerdDinner, Oxite or SharpArchitecture or even MS starterkits.
I was trying to read frameworks like jQuery, but it's really complicated, and I don't think that it was created to learn new things from it.
Do you know any good JS projects that can help with learning javascript ?
I'll try to paste all good sources here :
Github - javascript
JS Made Easy
Nice JS tutorial: Eloquent Javascript
Have a look at some of the JavaScript projects hosted on Github: https://github.com/search?q=javascript&ref=cmdform
There's a great interactive tutorial for learning JS, Eloquent Javascript which I would really recommend. Since you already mentioned you tried learning jQuery by the source and it was hard, why not just go this route?
In essence all javascript is open source. You just go to the webpage and view source.
If you open the JS file directly you will see its source.
There are of course exceptions, with people trying to obfuscate javascript, but they are the minority.
Checkout jQuery and the jQuery plugins to learn more.
Another good source is the talks of Douglas Crockford on javascript. Google has a bunch of them, here.
I would recommend to take a look at OpenLayers project.
It's an open source javascript library for creating web mapping "Google Maps"-like applications.
It's a good example of how to write solid, testable and maintainable object oriented javascript code.
Did you check out the JQuery tutorial pages? They contain a lot of practical examples
http://docs.jquery.com/Tutorials
http://www.jsmadeeasy.com/
scripts exaples - learn by example
http://learn.appendto.com/
A FREE video course on Javascript/jQuery
The best thing I've found so far to grasp JS/jQuery quickly.
backbone.js # http://backbonejs.org/
Also,
The Narcissus meta-circular JavaScript interpreter - https://github.com/mozilla/narcissus
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What's a good book, or a good way to learn HTML, XHTML, and CSS? I recently graduated from school and I only know Java, and C++.
I would like to learn some web development so I am looking for some good books and resources.
If you ask me, whatever introductory level book you can find at your public library on html or css or "web programming" is a great place to start as far as books go. Typically, those kinds of books are a little bit "stale" as far as you're likely to find something that's not the latest greatest version of HTML, but for the most part very few parts of the HTML spec get deprecated or removed from version to version, so anything you'd learn from slightly obsolete books will generally still exist, but
There's a ton of great stuff online too about every specific topic you could want, for the most part, you could get by without buying any books
Here's a link (http://jwinblad.com/webprogramming/webdesign.php) to some of my personal bookmarks on web-development that I like to keep handy like the specifications for CSS and HTML that enumerate every possible tag or CSS property and give you a brief description of what each one means and is used for.
Of course, actually trying out different tags and CSS experimentally is sometimes much more helpful in learning. If there's a website that does something cool, you can often times learn how to they do their cool feature by viewing the source-code of the page or its style sheet using the tools provided in your web-browser. Create a hello-world demo-page and then work from there on adding extra tags and a style sheet and so on. If there's something specific you want to do, you can search for tips on how to do that particular thing
If you already know Java and C++, it should not be difficult to learn HTML/XHTML and CSS. But if you're looking at learning this with the hopes of it being a career direction or paying job, you will probably want to delve into more than just HTML, nobody seems to be looking for people to write webpages that look like they came out of 1998 or 2001, you can get nicer looking stuff that that with almost no HTML knowledge using WYSIWYG tools...once you get the basics of HTML understood and know where to look up tags and CSS descriptors, you may want to branch out either into a client-side scripting language like Javascript or a server-side programming language or framework (PHP, Ruby on Rails, etc) or trendy web-technology like Flash. It kind of depends what your goals are in learning web-programming.
If you are interested in online resources, The SitePoint Reference seems good. It covers HTML, CSS, and JavaScript. The information seems clear, and there is the capability to add user notes as well.
If you prefer printed material, I started out with HTML for Dummies - despite the common opinion on For Dummies books, they are actually useful for picking up a new subject. I keep handy the HTML/XHTML Definitive Guide and the CSS Definitive Guide - both from O'Reilly. Those two are good for references.
For JavaScript, I recommend Simply JavaScript from SitePoint, and Dom Scripting from Friends of Ed.
Based on personal experience, coming from no programming experience at the time:
View source is a great tool. Read other people's code. [EDIT: To access view source, right click on the page in your browser and choose view source from the context menu. Alternatively, you can look in the browsers "Page" menu, although the menu name and placement varies by browser and OS.]
I used a tutorial site on geocities (may it rest in peace) but there are many other good sites. Use a search engine.
Books - Jeff Zeldman's book "Designing with web standards" was one of my first reads a number of years back. Books do tend to get outdated, but that one is a keeper. I think that there is a new edition in the works. Also, Visual Quickstart books are a personal favorite, but hey teach particular things and not the whole languages. There is a Visual QuickStart book with fairly recent code and a great reference for your desk. ( I forgot the title...)
good luck! Bing is your friend!
If you know programming languages like Java, then I'd recommend checking out the HTML4 spec on the W3C site.
It is as close as you'll come to the official docs.
I'd also recommend learning the differences between HTML and XHTML, why XHTML has no benefits to today's web (IE, content types, error handling too unforgiving) and also I'd look into HTML5, just to keep current.
Here is a quick overview of differences between HTML and XHTML that I found whilst surfing Jessica's website.
IMHO, the best way to learn it is by doing it, make a plan for a website, and have a go at making it happen (repeat as required), by the time you put html, css, javascript, and eventually a server side framework together, it can be a bit of a dark art, and there is much learning that can only happen when you are actually doing it (and feeling the pain of IE 6).
As mentioned by others, Sitepoint, Smashingmagazine, W3Schools (to name a few) are all handy references.
Would also suggest learning jquery as you learn javascript, some good starting tutorials here http://docs.jquery.com/Tutorials.
Also install firebug in firefox so you can start digging under the hood of sites you like.
With regard to books, from personal experience, I have a stack of outdated technology specific books that I have not touched for quite a few years. The ones that focus on why rather than how get much higher rotation.
If you have learnt java and c++, the mechanics of the technologies shouldn't be too hard to pick up, but many programmers tend to suck at things related to UI, so if you were to get a book, I would recommend "Don't Make Me Think" or other books related to usability and interface design.
HTH. Good Luck.
I'd recommend Professional CSS: Cascading Style Sheets for Web Design. There apparently is a second edition now, but my first edition has:
Chapter 2: Best Practices for XHTML and CSS
The book (first edition) is basically comprised of case studies of css and xhtml implementations at ESPN, PGA Championship, and the University of Florida, with many great tips and explanations of why things are done a certain way.
I'm working through Head First HTML with CSS & XHTML. I have found it to be quite useful in staring me off with these technologies.
If you're looking for reference information, W3 Schools is a great place to start. Smashing Magazine is great for pretty much everything to do with web development. I'd also recommend A List Apart, which often has great articles about some of the more difficult CSS concepts. And last, but certainly not least, I'd check out the articles on 24 ways; while they only have 24 updates every year (in December), they are written by some of the best people in the industry.
Ans since you're interested in web development, you'll probably end up wanting to learn some Javascript as well. ppk's site quirksmode.org is a great place for that.
Well, I hope this can be some help to you, and wish you best of luck. Also, of course, you can always ask any question that you have here at Stack Overflow.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm gearing up to do some Ajax style client-side JavaScript code in the near future, and I've heard rave reviews of jQuery when it comes to this realm. What I'm wondering is:
What are all the cross-browser JavaScript libraries out there?
What is the experience using them?
An excellent resource is Jeff Atwood's post on JavaScript libraries.
He lists:
Prototype and Script.aculo.us
jQuery
Yahoo UI Library
Ext JS
Dojo
MooTools
ALL the cross browser JavaScript libraries out there? You do realize that there are
well over 100 libraries out there, so you should narrow this down a little, IMO.
A good place to start is with Wikipedia's Comparison of JavaScript frameworks, which covers Dojo, Ext JS, jQuery, midori, MochiKit, MooTools, Prototype & script.aculo.us, qooxdoo, YUI, and SweetDEV RIA.
Prototype FTW.
I do like jQuery, but Prototype serves my needs most of the time. It may just be because I'm more familiar with it, but I seem to get stuff done faster in Prototype than in jQuery.
I want to report this almost unknown library entitled: "BBC Glow".
Other libraries are praised for bells and whistles, but Glow is about cross-browser support. The project has a clear statement about its goals, and there is also a browsers support table.
It is a solid starting point.
Most of the existing answers are either gateways to slimy marketing or libraries long past their due date.
What is conveyed as "cross-browser" is most often "multi-browser", meaning a small umbrella of browsers. Libraries such as Dojo Toolkit and Ext JS (anything by Sencha, really) are guilty of this behavior. jQuery used to behave similarly before some loud calls for sane code arose (the project still has a giant mountain to climb yet). "Cross-browser" most often refers to abstractions for the DOM and a few other APIs.
I've recently completed an HTML DOM library that covers a very wide range of browsers, which I think may interest the community here. The current list is:
Internet Explorer 5-9;
Firefox 1-13;
Opera 5-12;
Safari 3.1-5;
Chrome 1-4 (presumed to work on all Chrome builds, but Chrome versions remain difficult to test independently); which is the second-widest coverage I've encountered, just trailing another, which I will mention in the next paragraph. The library I've created is entitled: "Matt's DOM Utils" (Utils) and can be accessed via GitHub[[0]] or my own site[1]. It's fully modular and focuses specifically on DOM traversal while providing other utilities such as an Element::classList module.
However, the most comprehensive DOM library on the Internet is David Mark's "My Library". The library contains a giant pile of utilities, with coverage for nearly all browsers beyond Netscape 4. It has a pseudo-modular build stage, and can be very minimal if desired. It can be accessed via GitHub[2] or David's site[3]. I suggest to anyone reading this thread to give that API a thorough glance. I have learned immensely from both the author and the code itself.
If you want to jump on the same bandwagon everyone else does, jQuery is the end-all, be-all. You don't have to think, just listen to everyone else. :P
Personally, I use and love MochiKit. It seems to do everything jQuery does, but the philosophy is a bit different and the community is by far smaller. There are not tons of additional plugins, but there are some. It was designed with a lot of Pythonic style and functional programming constructs, so if that sounds interesting to you, you might want to take a look.
jQuery.
(Added so as to have an entry for voting.)
Loads!
jQuery, Prototype, Ext JS, Dojo, MooTools, YUI, Mochikit, the list goes on!
jQuery is very popular, and an excellent choice. However, some frameworks are better for some things, and others better for others. If you could give us a better idea of what you want to do, or how you will be using it (or even which other languages you use) we'd be able to give you a nudge towards one or the other.
The list that Dori posted is pretty comprehensive, and I don't think that it's possible to list all the libraries out there since there might be one being written even as I type (it seems to be a passion for some people).
I feel that going with jQuery and/or Prototype will probably get you off the ground and building neat stuff pretty quickly, and chances are that you will fall in love with them as so many of us have.
Gucci had Thomas Fuchs (the creator of script.aculo.us) create their website without using Flash, but check it out, it looks amazing for being JavaScript / CSS only.
A post about it is Gucci Relaunches on Script.aculo.us.
These libraries are so powerful and versatile (with some nice plugins) that you won't "hit the wall" and start looking to other libraries anytime soon.
I have also seen people do some nice stuff with Dojo and Ext JS, but I have never worked with them myself.
I like jQuery. Prototype is very similar. There are several others but I highly recommend you evaluate them yourself.
I prefer Mootools because it is lightweight and is based on Prototype, but like Jay said you should check them out for yourself.
Do have a closer look at MooTools.
I can't think of doing any JavaScript development without using jQuery (also take a deep look to jQuery UI).
jQuery is a good choice. It leans towards the 'skinny and speedy' side, and allows for some fantastic DOM manipulation.
Of the popular ones are jQuery, Dojo Toolkit, Prototype (with Script.aculo.us) and MooTools. I'd encourage you to test out MooTools unless you're on ASP.NET in which case I'd encourage you to check out the project I am working on (Ra-Ajax) which is a fully server-side binded Ajax Framework for ASP.NET...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Any suggestions on which HTML template library would go well with JQuery? Googling turns up quite a number of libraries but I'm not sure whether there is a well recognized library that would stand the test of time.
Well, to be frank, client-side templating is very hot nowadays, but quite a jungle.
the most popular are, I believe:
pure: It use only js, not his own
"syntax"
mustache: quite stable and nice I
heard.
jqote2: extremely fast
according to jsperfs
jquery templates (deprecated):
there are plenty others, but you have to test them to see what suits you, and your project style, best.
Personally, I have a hard time with adding a new syntax and set of logic (mixing logic and template, hello??), and went pure js. Every single one of my templates is stored in it's own html file (./usersTable.row.html). I use templates only when ajaxing content, and I have few "logic" js files, one for tables, one for div, one for lists. and not even one for select's options (where i use another method).
Each time I tried to do something more complex, I found out the code was less clear and taking me more time to stabilize than doing it the "old" way. Logic in the template is an utter non-sense in my opinion, and adding it's own syntax adds only very-hard-to-trace bugs.
jTemplates
a template engine for JavaScript.
Plugin to jQuery...
Features:
100% in JavaScript
precompilator
Support JSON
Work with Ajax
Allow to use JavaScript code inside template
Allow to build cascading templates
Allow to define parameters in templates
Live Refresh! - automatic update content from server...
There is a reasonable discussion document on this topic here, which covers a range of templating tools. Not specific to jQuery, though.
jQuery Templates Plugin created by Microsoft and accepted as an official jQuery plugin.
But note that it’s now deprecated.
I would check out json2html, it forgoes having to write HTML snippets and relies instead on JSON transforms to convert JSON object array's into unstructured lists. Very fast and uses DOM creation.
A couple years ago i built IBDOM: http://ibdom.sf.net/ | As of december 2009, it supports jQuery binding if you get it straight from the trunk.
$("#foo").injectWith(collectionOfJavaScriptObjects);
or
$("#foo").injectWith(simpleJavaScriptObject);
Also, you can now put all the "data:propName" markers in class="data:propName other classnames" attributes, so you don't have to litter your application's content with those markers.
I've yet to update a bunch of the documentation on there to reflect my recent enhancements, but the i've had various versions of this framework in production since 2007.
To skeptics of this question:
Back when Microsoft invented with IE5 what we now know as XmlHttpRequest and the "ajax" pattern, part of the promise behind this was to purely exchange data between a web browser and the server. That data was to be encapsulated in XML, because in 1999/2000, XML was simply just so very hot. Beyond retrieving an xml document over the network with a call-back mechanism, MS's MSXML ActiveX component also supported a pre-draft implementation of what we now know as XSL-T and XPath.
Combining retrieving HTTP/XML, XPath, and XSL-T, afforded developers tremendous creativity to build rich "documents" which behaved as "applications", purely sending, and more importantly, retrieving data from the server.
Why is this a useful pattern? It depends on how complex your user interface is, and how much you care about its maintainability.
When building a visually very rich semantically marked-up interface with advanced CSS, the last thing you want to do is chunk-out pieces of markup into "mini-controller/views", just so you can .innerHTML a document fragment into the main document, and here's why.
One key tenet of keeping an advanced html/css user interface manageable, is to preserve its validation at least during its active phase of development. If your markup validates, you can focus on your CSS bugs. Now, if fragments of markup end-up getting injected during various stages of user-interaction, it all becomes very unwieldy to manage, and the whole thing gets brittle.
The idea was to have all of your markup UI constructs in a single document, retrieve ONLY DATA over the network, and use a solid framework which will at the very least simply inject your data into your markup constructs, and at the most replicate markup constructs which you flagged as repeatable.
This was possible with XSL-T and XPath in IE5+, but virtually no other browsers. Some F/OSS browser frameworks have been dabbling with XPath but it's not quite something we can rely on just yet.
So what's the next best thing to achieve such pattern? IBDOM. Get data from your server, inject it in your document. effortlessly.
You should get a look on Javascript-Templates, this is a small template engine used within the famous jQuery File Upload plugin, and developed by the same author, Sebastian Tschan (#blueimp)
https://github.com/blueimp/JavaScript-Templates
Follow the usage guide made by Sebastian, just remove this line
document.getElementById("result").innerHTML = tmpl("tmpl-demo", data);
Replace it with this one
$('#result').html(tmpl('tmpl-demo', data));
Don't forget to add the div result tag in you HTML file too
<div id="result"></div>
Enjoy