ECT - new performance focused template engine

[Вадим Барышев]

Hi All,

I want to show you new javascript template engine - ECT.

GitHub: https://github.com/baryshev/ect

Home page: http://ectjs.com (you can play with demo here)

General features:

• Excellent performance
  
• Inheritance, partials, blocks
  
• Templates caching
  
• Automatic reloading of changed templates
  
• CoffeeScript code in templates
  
• Tag customization support
  
• Node.JS and client-side support
  
• Powerful but simple syntax
• Compatible with express
• Backward compatible with eco

Now ECT is the leader in template engines performance. ECT 4 times faster than Eco and EJS, and 10 times faster than Jade. You can see benchmark suite for most popular template engines here: https://github.com/baryshev/template-benchmark

I will wait for your feedback, thanks.

[Chad Engler]

If I didn’t have to use CoffeeScript I would be all over it L

 

-Chad

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[jmartins]

+1

[Alan Hoffmeister]

Why there is no template engine that can handle async helpers / functions?

--
Att,
Alan Hoffmeister

2012/11/27 jmartins <jcma...@gmail.com>

[Michal Kruk]

Hi

 there is try using dust (the linkedin fork)

 i am using it to compose pages consisting of multiple components that are rendered in parallel, it is very nice IMHO :)

 just add your helpers to the base of your views

 http://linkedin.github.com/dustjs/

Regards Michał Kruk

[Вадим Барышев]

Can you show an example of really needed asynchronous helper in real world?

вторник, 27 ноября 2012 г., 19:33:19 UTC+4 пользователь Alan Hoffmeister написал:

[Alan Hoffmeister]

Take this example: I'm writing an eCommerce solution that allow our users to upload their template files. Bam! Problems! Our users can't interact with the database inside the template because all data must come from the controllers that they don't have access. We have some solutions like AJAX calls or even web sockets but that's too much for a front end developer. I really miss this in Node.js

--
Att,
Alan Hoffmeister

2012/11/27 Вадим Барышев <vadimb...@gmail.com>

[Oliver Leics]

On Tue, Nov 27, 2012 at 4:42 PM, Вадим Барышев <vadimb...@gmail.com> wrote:
> Can you show an example of really needed asynchronous helper in real world?

Dear list, please let me troll a little bit by rewriting that question into:

Can you show an example of really needed synchronous helper in real world?

[Alan Hoffmeister]

Oliver it's true.. Template systems in Node.js really bother me.

"Ok, now let's call the top 10 user list right here with this template system that rule the world using this awesome V8 engine! Ops, I can't. But I can make it uppercase." - Derp

And Dust.js in my opinion it's a greate template system that was aimed to core devs, not front end devs.. Can you imagine that eCommerse team trying to explain Dust.js to an 40 years guy that have been selling clothes for all his life, that just wan't to change the case of the eCommerce logo?

PS: You have done a real nice job with ECT and I love Node.js, this is just an outflow from a devop that still need PHP to read template files with easy markup and database abstraction helpers :(

--
Att,
Alan Hoffmeister

2012/11/27 Oliver Leics <oliver...@gmail.com>

[Вадим Барышев]

Template engine just a part of view layer of MVC. Any asynchronous operations here will impact perfomance. All commony used filters/helpers like capitalization, truncating, sorting are synchronous. Although their use is also not desirable. The best practice is prepare all data inside of controllers, cache them and pass to template engine. Any complicated operations that requires asynchronous requests should be performed inside of controller.

вторник, 27 ноября 2012 г., 19:55:51 UTC+4 пользователь Oliver Leics написал:

[Alan Hoffmeister]

Some times I don't like this "all performance" ecosystem that Node.js had created :)

You can't drop an ideia just because it "impacts performance".

--
Att,
Alan Hoffmeister

2012/11/27 Вадим Барышев <vadimb...@gmail.com>

--

[Jeff Barczewski]

@Oliver Here is an example where an asynchronous template engine like dust could provide a nice optimization in time to render a page from server to browser.

Let's say a dynamic page on the server is rendered from a layout and it depends on several pieces of data from the database all of which can vary from page to page:

- javascript 

- css 

- main data

I can fetch all of them in parallel from one or more databases and as soon as I have the javascript and css, I can start rendering and streaming the head, so the browser can fetch and parse, then when the data is ready, I stream the rest.

Assuming the javascript and css data can be fetched more rapidly than the main data (which could be using a complicated query), then I am not wasting time waiting for everything, the browser can be using the time to prepare what it has, then when the final data arrives, it can instantly finish the render.

Given this template:

<html>

  <head>

    {javascript}

    {css}

  </head>

  <body>

    {mainData}

  </body>

</html>

It can stream the template in chunks from the server to the browser, blocking at {javascript} until it has that data, then blocking at {css}, then {mainData}. 

So as the data becomes available, more chunks can be delivered to the browser. Assuming these are all fetched in parallel and that javascript and css return first, we will have a nice optimization by being able to get the browser javascript and css to parse, while it is waiting for the main part of the page.

It is mostly useful for rendering templates on the server. If you are rendering on the client, then you will likely be synchronous.

Jeff

[Вадим Барышев]

Rendering of templates is very-very fast Task, because it just concatenation function. Less than 0.1ms. What wasting time do you mean? You can waitng all data, and push it all into template engine. It will be faster than if you do it by parts, because synchronous algorithm of template engine faster and easier than asynchronous.

вторник, 27 ноября 2012 г., 20:26:56 UTC+4 пользователь Jeff Barczewski написал:

[Jeff Barczewski]

I don't believe you understood my example. 

It is the fetching of the main data that will be expensive in my example, maybe it is the result of many hits to multiple databases, complex join, or a map reduce.

However the browser also needs to fetch and parse all the other resources it needs to be able to display the page.

So rather than wait for everything before you deliver the page and then it still may have to fetch and parse javascript and css after it gets the page, if you instead were streaming the page and the head went first, then the browser could be fetching any resources it needs, parsing them and be ready once the data can be delivered.

We are talking about optimizing the time it takes for the browser to have a usable page (meaning it has fetched all its resources and parsed them).

If you wait and deliver only a fully rendered template, the browser might still need to fetch and parse other resources after it receives the HTML, so there will be a delay and possibly the data could be presented without style until it has time to fetch and re-render.

Thus with async rendering, you can potentially improve the time it takes to be ready to use a page by doing things while waiting on others.

[Oliver Leics]

What about this MetaTemplate:

<html>
<head>
{css}
</head>
<body>
{header} <- fast - gives the user the "that site answers quick"
{breadcrumbs} <- slower than the header but displays quicker than the next:
{db crud stuff} <- slow. sometimes realy slow.
{footer} <- fast too, but has to wait for {db crud stuff}
{javascript}
</body>
</html>

The idea is to give the user the "that site answers quick" experience.

--
Oliver Leics @ G+
https://plus.google.com/112912441146721682527

[Alexey Petrushin]

@Jeff @Oliver thanks, at last I got a good example when asynchronous rendering can be very useful - streaming partially-ready html to the client. Seems like such technique can be quite useful in some cases.

[Michal Kruk]

Hi

 OK lets assume you have a sidebar that shows some dynamic content:

 sidebar.dust:

<ul>

  {#sidebar}

    <li>{.}</li>

  {/sidebar}

</ul>

and you reference this template from the main tamplate with simple {>sidebar/}

you also have an initialized view base like so:

var base = dust.makeBase({

        sidebar: function(chunk, context, bodies){

            return chunk.map(function(chunk) {

                setTimeout(function() {

                    chunk.render(bodies.block, context.push('a'))

                         .render(bodies.block, context.push('b'))

                         .render(bodies.block, context.push('c'))

                         .end();

                }, 1000);

            });

        }

    }

the {#sidebar} will call the function  and the body will be rendered after the timeout 3 times and the outcome will be 

<ul><li>a</li><li>b</li><li>c</li></ul>

the setTimeout is to only simulate that there is some io going on

this approach is very nice if you have multiple such views that need to do some io as it will be done in parallel and thus will lower the total wait time for the user

this is only an example and i don't recommend on putting all your helpers i the base of all your views :)

btw, while working on my project i created a module to load dust templates and bind snippets when ill have time to make it publishable ill announce it here

Regards Michał Kruk

[Jeff Barczewski]

@Alexey yeah even non-evented web frameworks like Rails saw the benefit of this and started to add that capability to Rails 3+. It was added late and thus most people have to rewrite code to take advantage of it.

So it would be a shame for a true evented system to abandon the capability too quickly.

Yes, you don't always need it, but there are some valid reasons, especially when it comes to optimizing for the user experience.

[Martin Heidegger]

I do agree that a event based system would be nice to have, however: that doesn't mean that a fast compiling template engine doesn't have its merits.

My question about ECT: How good is the "compilation speed" ? In some cases I want fast start-up speed too and I wonder how well ECT performs on that regard.

[Вадим Барышев]

ECT does not have compilation as separate operation. Compilation occurs during first render of each template. Compiled functions are cached by template engine and can be removed automaticaly after template changed (with `watch` option).

I just tested first render time on serveral templates. My hardware core i5 2.4gz, 8gb ram. OS: Ubuntu 12.04

400B - 28ms

4Kb -100ms

16Kb - 280ms

Overall compilation time is comparable with other engines because it have not fundamental differences here.

 
среда, 28 ноября 2012 г., 13:44:26 UTC+4 пользователь Martin Heidegger написал: