Develop Reference

What is the best practice for Dojo dijit creation? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the best practice for Dojo dijit creation?
A purely declarative approach (D)
A purely programmatic approach (P)
A combination of the two (D&P)
Criteria
Easiest to maintain
Fastest to develop with
Most intuitive
Best performance
Most functionality and flexibility
Context
I've been working with Dojo for a little less than a month now, and I've recently started working with the dijit library. One of the well-advertised aspects of dijits is that they can be declared programmatically or declaratively. I always like to approach a new set of tools with an understanding of best practices and some general idea of which approach has which strength/benefits for a particular application.
The information below comes from some personal experience with both styles, as well as the reference material I've been able to find, which isn't a whole lot. This link is the only one I've found in the official Dojo documentation on the subject, and this post provides some outside perspective with a basic presentation of how the code for each looks for simple scenarios. Both links are for older versions of dojo, before AMD was introduced in version 1.7.
Programmatic
Separates Dojo from HTML, which preserves semantic purity of HTML
Puts event handlers and widgets in the same place, increasing readability
Seems to make it easier to assign values to attributes dynamically (e.g. create unique IDs using a function)
Declarative
Rapid development -- intuitive, implied nesting, widgets defined like normal HTML elements
Valid HTML5 through use of data-jojo-* attributes
Does not preserve semantic purity of HTML
Event handlers come from outside scripts, creating some complexity and reducing readability
Initial parseOnLoad can slow up-front widget setup
A note on responses: Please address each of the criteria in your response. Feel free to propose any additional criteria you think are important. I am by no means an expert at evaluating best practices.
Update:
After browsing around for more info on this, I found another post with similar thinking, which provides some useful context on what implications these style differences have.

I don't think there isn't a best practice. Personally I like to use a combination of both programmatic and declarative code.
I think it makes more sense to seperate the presentation layer from the business logic layer (somewhat like the n-tier architecture). I mean, what's the difference between a dijit/form/TextBox and the standard <input type="text" /> HTML element? They're both part of the presentation layer and they both have the same purpose. The only difference is that the one is a custom element while the other one isn't.
But on the other hand, I consider event handling and validation as business logic, so I would put these into a JavaScript. You could also declare your dojo/store objects declarative, this is also something I don't like because it doesn't have to do with my presentation layer.
Now, back to addressing your points:
Easiest to maintain: If I had to change a dijit widget, then I would probably look into the HTML (seperation of concerns; presentation <--> business logic). It's also easier to find. For example, if you know that the dijit widget is right below the title and just above a button, then you exactly know where to look for in your HTML code. If we made it programmatically, it could be anywhere in your code.
Fastest to develop with: Well, maintaining and developing is a bit the same, but another advantage of declarative markup is that the markup you write actually serves as a placeholder while programmatically you will have to assign each property to a value.
Most intuitive: I also address this in the first part (easiest to maintain). I also think that it's pretty good that they also use a few standard HTML attributes like title, value, placeholder, ... . I don't think this pollutes your HTML markup, but increases readability too.
Best performance: It's not the fastest way, I'm well aware of it. But the margin is pretty small, it's not that it is a huge difference. You could also tweak it by disabling parseOnLoad and manually parse the nodes you need to be parsed. Another nice thing is that the end user "sees" something. For example, if you write the following code:
<select data-dojo-type="dijit/form/ComboBox"></select>
<input type="text" placeholder="Text..." />
The end user actually sees something when he loads the page (and it's pretty representative of the real result), even is the page is not parsed. When you create everything programmatically, the only thing the user will see is a white page.
Most functionality and flexibility: Because I think combining declarative and programatically way of developing, I can enjoy the benefits of both. You're somewhat blocked in doing everything in a declarative way (event handling really looks messy if you put it all in your HTML), but I would write those in JavaScript code.
On the other hand, it really looks messy when you're creating a widget programatically (that's an opinion), so I can define these in HTML where it's a lot easier.
So in the end I like to write a combination of both. Event handlers indeed come from outside scripts, but if you write proper MVC applications, they always will (since it is a part of the controller while the markup itself is part of the view).
I'm not saying you have to put all event handlers in one file, no, thanks to the AMD loader you can easily add other scripts. If you group all interaction of a certain widget (or a group of widgets) into files and name these correctly, it's pretty easy to find things.
The more files, the smaller the files usually are and the easier they can be read (so complexity goes down and readability goes up). You might end up with a lot of files, but if you name these correctly (and document them maybe), there should be no problem.
But in the end, this is an opinion, there are probably other opinions too which are as good or even better than mine. Sometimes it's also depending on the situation, if performance really is one of the biggest requirements, then defining everything in JavaScript might be the best solution too. It's not like these rules are carved into a stone somewhere.

Is unobtrusive JavaScript outdated? [closed]

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.
When I first read the principle of unobtrusive JavaScript in the Web Standard Curriculum I thought it's a really great thing.
Unobtrusive JavaScript is more of a programming philosophy than a technique. By far its most important component is a clear sense of which functionality belongs in which layer. All absolutely crucial site functions should be coded in plain HTML, but once you’ve created that base you can add a JavaScript layer on top of the basics in order to give browsers that support it a nicer, cleaner, faster-seeming interface.
Further, unobtrusive JavaScript:
separates structure and behaviour, in order to make your code
cleaner and script maintenance easier
pre-empts browser incompatibilities
works with a clean, semantic HTML layer
For my current project I use this approach. When I turned JavaScript off for some other kind of work I had to do I was surprised how many websites are completely broken without JavaScript: missing functionality, as well as absent of a lot of important information, which were not present at all in the whole DOM.
These were especially social network sites. It should be no surprise that this were the case, the required development time and user experience might be a lot more important than the accessibility.
Still I am asking myself, whether unobtrusive JavaScript is not out of date. I mean which browser does not support JavaScript already natively? Is it still an approach which fits for the year 2012? I started doubting it.

There are two ways of approaching a website and the use of JS:
JS as an enhancement
These types of sites are like "documents" in a sense that they are analogous to newspapers, books and letters. You don't need fancy effects to read and use the content. And with this comes progressive enhancement: Building a basic functionality and add on complexities without sacrificing the purpose.
Most (large) websites use this scheme to preserve its usefulness even when using a non-capable browser. An example is StackOverflow, which even works on a lynx command-line browser!
______
| JS | - JavaScript for (optional) enhancements
|------|
| CSS | - CSS for (optional) style
|------|
| HTML | - (mandatory) HTML with base content
'------'
JS as a platform
For web apps, it's reasonable (more like mandatory) that they are build upon JS for real-time, dynamic content and functionality while HTML and CSS serves as the view. It's synonymous to other programming languages, where you can go "headless" with your program (no UI) like libraries and plugins.
Graceful degradation comes with this approach: "Backwards support only to a certain extent, otherwise you get none at all"
____________
| HTML | CSS | - (optional) HTML and CSS view
|------------|
| JS | - (mandatory) JS platform
'------------'
It generally boils down to a question of "Is it a document, or an app?"

Different companies take different approaches. For example Google for their search uses unobtrusive javascript which degrades gracefully, but for GMail they maintain a separate HTML only site which they developed later after GMail JS version.
To me it depends on
Complexity
Functionality,
Cost
Impacted user count
to decide whether to do Graceful degradation using unobtrusive JS or to build a dedicated HTML only site or to ignore that user base completely.

What are some empirical technical reasons not to use jQuery? [closed]

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.

jQuery vs. Yahoo UI API design [closed]

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 am baffled by the difference in design between jQuery and Yahoo UI APIs. Disclaimer: I have a strong dislike of the jQuery api, but I am also a huge ignorant in web programming and javascript in general, so I could be dead wrong and come back here begging for redemption. so long...
The point of my question is the following. The two designs are different. jQuery puts the DOM at the center, and adorns the DOM by executing a "trigger" enhancer method on it. example
$("#flexigrid").flexigrid()
A requirement of jQuery is that you must, in some cases, follow a very specific conventional structure for your html beforehand. Example:
<div id="accordion">
<h3>First header</h3>
<div>First content</div>
<h3>Second header</h3>
<div>Second content</div>
</div>
and then
$("#accordion").accordion();
Moreover, the returned entity in general does not provide any mechanism to hide the DOM through a convenient programmatic method. To manipulate your jQuery entity you have to access the DOM via selectors, access that in some case is not guaranteed to be easy to know, like in the case of internally generated ids. Suppose that you want to swap the accordion programmatically, what you do is
$('#accordion').accordion('option', 'active', 2);
and not a more intuitive
myAccordion.setActiveTab(2);
On the other hand, yahoo ui focuses on javascript objects, you create them passing the DOM node selector (e.g. myDataTable = new YAHOO.widget.DataTable("container_id")) and then perform all manipulations through the object methods. Want to add a new row ? call myDataTable.addRow(). The DOM is hidden. You are not concerned with what's going on behind the scenes.
Now, my experience with Trolltech QT maps nicely to Yahoo UI. Clear, defined API of the widget objects, eventual freedom to reimplement part of them via inheritance, opaque rendering unless you want to open the box and get your hands dirty. QT is a winning API, works well, it's easy to use, and Yahoo UI is kind of similar in the design style. On the other hand, jQuery works in a counterintuitive (to me), very open box way, with reduced API on its objects.
Enough ranting. The point is that I assume I can be dead wrong on this, but I'd like to know why. What are the design advantages of having a jQuery-like interface (where the DOM is clearly exposed and you potentially have to hunt for stuff that jQuery plugins create automagically, so you can finally $(select) them and attach events or modify their content) instead of hiding everything behind an objects and commodity methods like YUI does ?
I'm not talking about speed, or code size, or amount of typing. I'm talking about design concepts like encapsulation, focus on interfaces, and ease of access. What design is better, in what situations, and why?

I don't think your argument is directed at jQuery, but more the APIs provided by plugin authors.
Unfortunately, no two plugin authors will create a plugin with the same API. The level of programmatic access is not limited by jQuery itself, but rather by the author/s of the plugin.
Also, as you said, jQuery is all about the DOM -- I see this as a benefit because it means jQuery doesn't get all mixed up in the "logic" (eh, "business logic") of the application... It's quite fine on it's own level of abstraction -- it deals with the DOM, and that's all!
You can create an unlimited amount of data structures and additional APIs for your application. jQuery doesn't hinder you in this respect.
You've added more details to your question -- this 'edit' is in response to those details.
I think what you're experiencing is common when you reach a certain stage with jQuery... The API becomes insufficient. You don't want the DOM... You want a nice clean API for your module, whether it's an accordion or a data-grid.
Personally, I don't think that some things should be bundled into a "jQuery plugin" -- doing so normally means sacrificing the API -- or having to resort to jQuery's mechanisms such as psuedo-event triggering through "trigger":
var someModule = $('#contain').someCoolModule();
someModule.trigger('initiate');
I get what you're saying, and I think I agree, but I also think it's important to have jQuery on an entirely separate level -- forget about it -- only utilise it when you need to attack the DOM.

jQuery doesn't require any kind of special markup - you can write a selector for any object. You can also use an existing DOM reference, and turn it into a jQuery object like so: $(domObject). Actually simpler and more capable than Yahoo UIs.
It's not required to know your dom selectors if you already have a DOM reference... That might be the source of your misunderstanding.
Having worked with both Yahoo UI and jQuery, let me tell you they are both great libraries. They're for different roles, but both have great approaches.
jQuery is kind of a wrapper, simplifying everything that has to do with the DOM, Ajax, selecting objects, doing graphics. It has a very concise and brilliantly simple API that abstracts all the browser compat nonsense away.
jQuery uses radically different design concepts than most newbie programmers are used to. It is really the poster child for how Javascript should be used. A few years back, there was a lot of ignorance about the power of Javascript. Mostly, because most of the javascript on the internet was terrible. Now, I think most people have realized that Javascript is one of the most capabable languages. It supports several paradigms: functional, imperative, object-oriented (prototype, not class-based), data literals....
jQuery uses Javascript to its full ability, using each aspect of its design to solve each problem in the most effective way.
I tell all people learning javascript to read the jQuery source over and over until they understand it.... It will be hard, but they will finish by being much better programmers, with a much larger assortment of tools in their toolbox.
It's kind of perpendicular to the Java/.NET brainwashing, which is to give every developer a screwdriver (OOP), and tell them it is the perfect soltion to every problem in programming and life.
Which, it's not. Every problem needs a different tool. OOP is good, but often a bad idea for some problems.
jQuery's mixin-style plugin architecture is really good. Different, but highly effective, fast, and easy to use.
jQuery is #1 for a reason - it's simple to use, and incredibly powerful.
Yahoo UI is a different approach, for a different problem. It's a UI toolkit that has very heavy abstraction from the DOM (vs. jQuery's lightweight approach).
You'll find yourself speding a lot of time modifying it if you intend to something outside the norm. (That's the downside of the heavyweight approach).
It's not a framework for developing apps. It's a bunch of GUI widgets.
I've used both together. There's no reason you can't use both jQuery and Yahoo UI on the same page, they're two different tools for different problems.
I suggest including jQuery site/app-wide, then including jQuery UI plugins as needed. If you need heavyweight stuff, add Yahoo UI. But stick to jQuery for your plumbing code...
Learn from jQuery. Understand the power of array programming, callbacks, data literals, treating code as data, and keeping things concise. And that using the right tool for each problem means much shorter, simpler code.

In my opinion, YUI is weaker in DOM manipulation, but is way ahead in design.
JQuery is designed for those with little or no JavaScript (or general coding) experience. Its very easy to get an application up and running.
YUI is more readable, and any programmer can pick it up and go very quickly because of the wide use of best-practice methodologies.

jQuery is a great library for DOM manipulations, and centering it's API around selectors is one of the reasons why it's so popular today. The thing is, jQuery wouldn't be needed if the browsers DOM APIs were more consistent and easier to use. And I agree with Robert Harvey (commented above) that as an abstract layer over the DOM jQuery does a very capable job.
But as I understand, you dislike jQuery plugin system and the jQuery UI, not the core library itself. Personally, I prefer a YUI style API for components and widgets, because at the higher abstraction level DOM elements become less important. I think the reason why jQuery UI authors chose this design is to make API more consistent with their main product, jQuery library. But I don't agree that this was a good decision.

jQuery is designed to work with the DOM (i.e. it's a language highly optimised around web pages).
you potentially have to hunt for stuff that jQuery plugins create automagically
Presumably if it's appropriate, a plugin returns a jQuery object that you can manipulate, unless it's badly written. In which case that's obviously the plugin's fault.
If you're using a method that autogenerates IDs then jQuery may not be for you. However for example I've used jQuery with Google Maps without too much trouble.
If you wanted to add a row to a table automatically, I'm sure there's a plugin out there. If not, it wouldn't take much to write one.

I agree with Computer Linguist. OOP is not a perfect fit for every possible for problem.
In case of web development one first has to decide upon the kind of solution that one has to design. Is the solution essentially a web page with interactive widgets embedded at places that enhance the interactivity or is it a full fledged RIA. JQuery,I believe is fit for the first case and it is basically targeted towards ease of handling of the DOM.
In case of RIA applications, toolkits working at a higher level of abstraction are prefered because the developer in this case is dealing with widgets and layouts rather than the HTML and css that lies underneath. In such case using Object Oriented Toolkits like YUI, Dojo or ExtJS are more convenient as they bring the desktop application development approach (with its associated advantages) to the web domain.

Is there any good Markdown Javascript library or control? [closed]

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.