On 27 Cze, 07:38, Nathan Weizenbaum <[email protected]> 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.
Greetings from Poland !
--
Jan Koprowski
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
