- 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
* 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
> - 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
>> - 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<https://github.com/baryshev/template-benchmark>
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
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
On Tue, Nov 27, 2012 at 4:42 PM, Вадим Барышев <vadimbarys...@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?
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 :(
> On Tue, Nov 27, 2012 at 4:42 PM, Вадим Барышев <vadimbarys...@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?
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 написал:
> On Tue, Nov 27, 2012 at 4:42 PM, Вадим Барышев <vadimb...@gmail.com<javascript:>> > 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?
> 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
> написал:
>> 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?
@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.
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.
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 написал:
> @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.
> 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.
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.
On Tuesday, 27 November 2012 10:35:59 UTC-6, Вадим Барышев wrote:
> 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 > написал:
>> @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.
>> 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.
<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.
<jeff.barczew...@gmail.com> wrote:
> 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.
> On Tuesday, 27 November 2012 10:35:59 UTC-6, Вадим Барышев wrote:
>> 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
>> написал:
>>> @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.
>>> 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 @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.
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
On Tue, Nov 27, 2012 at 6:45 PM, Oliver Leics <oliver.le...@gmail.com>wrote:
> <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.
> On Tue, Nov 27, 2012 at 6:00 PM, Jeff Barczewski
> <jeff.barczew...@gmail.com> wrote:
> > 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.
> > On Tuesday, 27 November 2012 10:35:59 UTC-6, Вадим Барышев wrote:
> >> 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
> >> написал:
> >>> @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.
> >>> 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.
@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.
On Tuesday, 27 November 2012 12:48:56 UTC-6, Alexey Petrushin wrote:
> @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.
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 написал:
> 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.
