Translate HAML on client side

[Jan Koprowski]

Hi !

From last few days i consider some extra scenario for using HAML.
How If HAML wasn't be translate on framework (server) side but a
little bit later on client side. Exactly in browser. This idea is was
submited on "Make the Web Faster" initiative Google Group.
How this could work ? For instance like web extension with high
performance HAML translator wrote in JavaScript - which we can use in
almost all web browsers as GreasMonkey script or in Google Chrome
natively. Maybe there is the better way to make and use there extra
efficient C implemented translator.
From C implementation is a short way to make HAML translation
entirely putting it to webservers for example as Apache 2 module,
nginx module.

What do You think ? Is this a good goals for make this cool HAML stuff
more popular and web faster ?

Greetings from Poland !
--
Jan Koprowski

[Nathan Weizenbaum]

It's almost definitely going to be faster to do it on the server. Not only are many servers going to have more computing power to devote to the task than your average browser (and remember, in-browser Javascript runs slowly, although it's getting faster), but Haml is much, much slower when it needs to be parsed. On the server, Haml templates are cached; they only need to be parsed and evaled once, and from then on it's no more expensive than calling a Ruby function. Client-side, though, every browser would need to parse the Haml every time it loads a page.

Not to mention that a significant portion of what makes Haml nice is its templating facilities - it allows you to embed Ruby code in a nice way. That wouldn't work at all, and you'd probably need an additional templating language just to insert server values into the templates.

[Jan Koprowski]

On 27 Cze, 07:38, Nathan Weizenbaum <nex...@gmail.com> wrote:
> It's almost definitely going to be faster to do it on the server. Not only
> are many servers going to have more computing power to devote to the task
> than your average browser (and remember, in-browser Javascript runs slowly,
> although it's getting faster), but Haml is much, much slower when it needs
> to be parsed. On the server, Haml templates are cached; they only need to be
> parsed and evaled once, and from then on it's no more expensive than calling
> a Ruby function. Client-side, though, every browser would need to parse the
> Haml every time it loads a page.

In the face of HTML 5 cache ability this probably wasn't a problem.
Entirely HAML is better for whole Internet because HAML notice is the
most brief notice i have ever seen. On the other hand client side HAML
implementation could support caching interior.

> Not to mention that a significant portion of what makes Haml nice is its
> templating facilities - it allows you to embed Ruby code in a nice way. That
> wouldn't work at all, and you'd probably need an additional templating
> language just to insert server values into the templates.

As I say: i look HAML notation as brief and legible at the same time.
From this point of view HAML could drastically decrease data transfer
between browser and web server. I don't know statically how much HAML
is smaller then full XHTML site source but i think this is enough to
think about sending HAML to web browser instead (X)HTML or anything
else.

This is cool and innovative technology :] and deserve for publicity.

[Mislav Marohnić]

On Sat, Jun 27, 2009 at 08:01, Jan Koprowski <jan.ko...@gmail.com> wrote:

As I say: i look HAML notation as brief and legible at the same time.

From this point of view HAML could drastically decrease data transfer
between browser and web server. I don't know statically how much HAML
is smaller then full XHTML site source but i think this is enough to
think about sending HAML to web browser instead (X)HTML or anything
else.

I respect your enthusiasm, but I have to agree with Nathan. Once you take Haml out Ruby, it decreases a lot in value. Haml is designed to generate HTML4-5 or XHTML, not to replace all of that by being handled client-side by user agents. I also don't think a JavaScript implementation can be as efficient as compiled Haml templates on the server combined with caching (both server and good ol' HTTP).