CPAN modules for converting markdown to HTML
I've just published the first full version of my review of CPAN modules for converting markdown to HTML. There's still work in progress, particularly comparing the output generated by the different modules, but it's fairly complete now.
The following modules have been added since I put up the draft:
- DR::SunDown - which is based on the now-deprecated sundown library.
- Markup::Unified
- Text::Markdown::Hoedown - which is based on the hoedown C library, a fork of the sundown library.
- Text::Markup::Any
I'd like to hear about any markdown quirks you've come across when using markdown, regardless of what was converting the markdown, Perl or otherwise.
Perl hacker since 1992.
> 'd like to hear about any markdown quirks you've come across
Things I recently ran into (with Github markdown)
1. long prefromated text has a scrollbar only if formated with tab(s) https://gist.github.com/vsespb/7180071
2. you can format complex, nested, things with preformated text using "*" lists https://gist.github.com/vsespb/7179985, with other types of list (i.e. ordered lists)
I was unable to get it working right. This probably a feature.
3. Github automatically adds "a" tag with "name" attr for each header https://github.com/vsespb/mt-aws-glacier#file-selection-options but other libraries
do not so (including library that github, but standalone version). Also this feature broken in gists https://gist.github.com/vsespb/7180104
Another issue, when I tried to convert this Markdown https://github.com/vsespb/mt-aws-glacier/blob/master/README.md to MAN pages (to comply with Debian rules), I tried two different markdown2man tools, but in both cases output was a bit broken in few places. So I believe it's not trivial to make markdown look sane in html/github and in MAN, at same time.
Thanks for continuing to do these thorough reviews. As with HTTP clients, the "Moose tax" looks like 1-2 orders of magnitude more runtime and dependencies.
Thanks for these reviews.
What I would also like to see in a comparison is the amount of code (verbosity, complexity) necessary for the examples.
Maybe this needs some trials which measure out of
- lines of code
- keystrokes, or
- syntax nodes (maybe via PPI)
is useful.
Helmut: good idea! I'll have a mull on an appropriate / useful measure, and try to implement it for this review first.
Normally with perl sources, we would start from pod, and produce the other formats from that, so this is somewhat relevant: http://metacpan.org/module/Dist::Zilla::Plugin::ReadmeAnyFromPod produces both HTML and markdown from pod, via Pod::Simple::HTML and Pod::Markdown.
A few times I've thought I should add a SEE ALSO section to my reviews, where I could list modules that don't meet the review criteria, but are probably of interest given the topic. Time to do that now!
While Moose certainly has a significant startup and memory cost, it should have little to no impact on normal runtime operations. For WWW::Curl::Simple from the HTTP benchmarks, the slowness is not inherent to Moose itself but in how it is being used. It isn't using immutable classes, which is a significant performance drain. I've submitted a pull request to resolve that.
I haven't looked at Markdent in detail, but I suspect it is slower in part because it is doing a more complex job that the other modules.
I agree, to some extent, that "the slowness is not inherent to Moose itself but in how it is being used." But Moose seems to encourage that kind of use. By itself, it adds 10-20 dependencies to whatever you're doing, which may be worth it to you. Depending on what benchmarks you choose, it may or may not by itself slow things down much.
Somehow, though, Markdent ends up with more like *300* dependencies and an enormous runtime penalty. Looking into it briefly, it looks like DROLSKY -- a core Moose contributor -- wanted to write himself a wiki, and ended up with "an event-based Markdown parser toolkit" with a sizable dependency list. It seems like Moose encourages this kind of architectural astronautics, which often leads to slower programs.
I've just pushed an updated version of the review, which now has a See Also section at the end, listing other markdown-related modules. Thanks to @ether and Ron Savage for the nudge.
> It seems like Moose encourages this kind of architectural astronautics, which often leads to slower programs.
This is total FUD.
Moose uses modules that have clear abstractions and do one specific thing very well. Since it does a number of things under the hood, this is where the dependencies come from. But trying to conflate this with runtime slowdown is ridiculous.
@Ether,
> This is total FUD.
It does not sound like FUD to me. It's true about each and every technology I saw in my life.
More abstraction, more universal code - more overhead here and there and less flexibility.
> Moose uses modules that have clear abstractions and do one specific thing very well. Since it does a number of things under the hood
it sounds more like marketing material.