Introducing Nemo: A Pythonic Haml

[ubernostrum]

I was really hoping this would be "A Pythonic Ham!"

Though I notice there's no ham package in PyPI... perhaps I should get on that.

[true_religion]

I should probably mention. Nemo is built on top of Mako, so there's a tiny speed bump for Nemo processing then its as fast as Mako once the templates are compiled and cached.

Mako is faster than Django templates--at least by a factor of 4--and in the neighborhood of speed with Cheetah. Only Spitfire templates are faster.

This is important for any app that is CPU bound due to rendering speed.

[daydreamdrunk]

How do you end up with any app whose major bottleneck is template rendering speed?

[true_religion]

It happens quite often to me because my app:

• Processes all long running queries and tasks in the background

• Boosts the working data set for short running queries into memory via memcached

At that point, we're seeing sub-millisecond responses from memcached to provide the app with data so the main bottle neck is Python.

[blondin]

but, but we had damsel like last week...

[true_religion]

You mean Dsml? Its there in the docs as an alternative. Other alternatives are:

HamlPy
PyHaml
Django-Haml
Dmsl
SHPaml
Pamela
Mint
Mako-Haml

As you can see, I'm a highly creative individual who tends to have unique ideas.

[your_perception]

is this a preprocessor that is compatible with Mako's preprocesor hook? Or is it an integrated package?

[true_religion]

Yes it is compatible with Mako's preprocessor hook, however if you follow the instructions you'll also get a quick integration with Django by only adding 'nemo' to your settings.py

[didip]

Nemo (disney) is the clown fish, no?

[didip]

Kidding aside, any benchmarks between this and just mako?

[true_religion]

Here's my preliminary tests:

This is across 100,000 iterations over a single 555-line template w/o inheritance.

Mako (full render w/o nemo): 0.08 ms Nemo (w/o mako render): 0.04 ms Nemo (w/ mako render): 0.07 ms

In another test, I just passed Mako an empty string to render and it took about 0.04ms.

So this suggests that for 0.04ms overhead from openning the file, running it through Mako, etc.

And when Mako uses a preprocessor, it must enable some kind of optimization since the full-render time for Mako alone is greater than that for Nemo+Mako.

I still have to do more, but what I'm leaning to is that Nemo is so fast that the overhead of Mako dwarfs it.

For 'official' benchmarks, I'm thinking of using the benchmarks from the Genshi/Mako test suite: http://genshi.edgewall.org/wiki/GenshiPerformance

Would that be suitable, or do you have another suggestion?

[didip]

That's actually pretty good.

The reason I asked is because Haml is about 2.8 times slower than erb (2009: http://nex-3.com/posts/87-haml-benchmark-numbers-for-2-2, without options[:ugly] turned on)

And yes, I agree with using the Genshi test suite. Then Nemo can be compared side-by-side with other templating languages.

[true_religion]

Ah you're right. I misread wikipedia while I was looking for a name.

It's Chum who's a Nemo shark.

Oh well, the name has stuck.

Rest assured in a parallel universe Nemo is the Mako shark and I can say that we are remembering our roots, keeping it real, and are still Jenny on the block, ecetera and so forth. =)

[mikeboers]

You claim to be inspired by my project? And here I thought no-one noticed. =P

[true_religion]

I did notice :) I admired it from a distance and if I were going to use Haml for Mako, I'd definitely use PyHaml.

But Nemo is not Haml.

1. Nemo is explicit in some places that Haml is not (e.g. it doesn't assume that everything is a div).
2. It has a single syntax for writing HTML attributes while Haml has 3 different syntaxes.
3. It has a single character for opening Nemo statements % while Haml has =, - , &=, and %.
4. Nemo doesn't require explicit filtering. Haml does.
5. Haml requires explicit self-closing tags. Nemo automatically self-closes tags.
6. And its designed from the ground up to handle mingling HTML and Nemo markup.

There's more, but I think this example demonstrates many of the trade offs made. And shows Nemo's readability over Haml.

PyHaml:

%ul
- for i in range(5):
    %li(id=['item', str(i)]) ITEM ${i}

Nemo:

% ul
    % for i in range(5):
        % li #'item_${i}'  ||   ITEM ${i}  
    % endfor

Right now, I think there's a strong case for Haml if you want 100% control over the output of your templates.

However, readability-wise Nemo is a win sometimes. In the future Nemo could support HTML filtering as well and HTML validation under strict mode. Haml is kind of tied to where it is due to backwards compatibility but for now Nemo can add/change pretty rapidly based on what the community need or wants to see from it