when rational discussion was still a possibility

[John MacFarlane]

+++ Andrei Fangli [Sep 06 14 07:08 ]:
>   Times without hardware specs mean nothing, please also provide some
>   hardware specs to get a more accurate idea about performance.

2010 era MacBook Pro, 2.4 GHz Core 2 Duo, 4GB RAM.  But the relative
numbers should speak for themselves.

>   The JavaScript version is only good for preview at client-side to avoid
>   posting to the server one to many times. To do client-side parsing and
>   sending it to the server in the final format is a serious security leak
>   (trusting that a post request sends a valid and harmless html is
>   wishful thinking).

You don't need to send the parsed version to the server.  Send the
original.  Let the client do all the rendering.

>   If you want to parse the Markdown text every time at the client side
>   using JavaScript will make parsing time dependent on the users device.
>   Think about someone using a smartphone to browse the Internet and gets
>   to a large Markdown text and the phone is required to parse that.
>   Dependencies with other JavaScript libraries has some part to do with
>   porting implementation to other languages. It also depends on how that
>   code is written (I haven’t peaked at it yet, just saying that how code
>   is written is another factor in porting effort).
>   The C implementation sounds promising, but to be able to use it
>   (speaking from a .NET point of view) I would need to compile it to a
>   dll and reference it through a wrapper CLI class that handles interop
>   such as string conversion to C char array, or C wide char array and
>   then back again with the result lest your code works only with files
>   which can complicate things.

All this will be possible.  The library is still being polished up.