The art of creating code that is "environment agnostic" recognised as "Isomorphic JavaScript", allows us to render the views of the application from the server (during the initialisation of the app) and then keep rendering the other views directly in the browser (avoiding a full page refresh) while the user keep navigating across the different sections. One of the advantages of having ES6 renderer as template engine for the backend of a web application is that one have to deal only with javascript template literals as a single syntax across the web stack. With this in mind the engine can be seen as the perfect tool that facilitates logic sharing between the frontend and the backend in order to reduce the codebase duplication between the browser and the server to the bare minimun. Express ES6 temlpate engine is a minimal and flexible Node web application library, providing a robust set of features for building single and multi page, and hybrid web applications. As a framework-independent technology, ES6 Renderer is an engine one can adopt and hit the ground running with immediately.
A simple and lightweight vanilla library.
Grasping new syntax is not required.
Conditional operators and ternary expressions.
Native ways to iterate over arrays and objects.
Layout and partials support.
Precompiling and template caching.
Every developer has been in a situation where they simply want to try and evaluate a framework or library, without having to install it or include it in a project. The online compiler provides a custom environment to test and fiddle with Express ES6 template engine functionality right inside a browser and see the results as they type in real time. A quick tour of the engine logic implementation will give you a better understanding of what it provides and why you should use it.
The general rendering process of the engine is rather simple. es6Renderer('template', {locals}) compiles the provided source code into a javaScript function. Calling that resultant function with an object as an argument returns a string of HTML rendered with our data. This methods combine compiling and rendering into one step. The 'template' string used as a first argument is a reference to a 'template.html' file in a view directory with a content presented in the first text area below (see Template). The data object called 'locals' provided in the second text area (see Data) has properties that are local variables within the content.
It’s not uncommon that from time to time I am asked about what template engine do I use and why. After my reply, I get something like: “isn’t that one slow?”. Usually, when developers talk in regards to performance, I always utter something like: “well, that depends on …”, and there one can insert his slow performance reasoning of choice, if it can be bad or not that bad.
Benchmark testing was done with Marko's brilliant Templating benchmark suite. Testing ES6 Renderer performance was a great opportunity to see how it stacked-up beside others. Our speed test compiled one main template containing an array of string, an object literal and conditional statements.
| RUNTIME PERFORMANCE | ||
| ✓ es6Renderer | 300,987 op/s | (fastest) |
| ✗ pug | 155,015 op/s | (48.50% slower) |
| ✗ marko | 143,375 op/s | (52.37% slower) |
| ✗ dot | 129,364 op/s | (57.02% slower) |
| ✗ handlebars | 46,871 op/s | (84.43% slower) |
| ✗ swig | 43,996 op/s | (85.38% slower) |
| ✗ dust | 39,834 op/s | (86.77% slower) |
| ✗ jade | 21,373 op/s | (92.90% slower) |
| ✗ nunjucks | 18,313 op/s | (93.92% slower) |
| ✗ vue | 5,251 op/s | (98.26% slower) |
| ✗ react | 2,218 op/s | (99.26% slower) |
As we see from the chart above ES6 Renderer is the fastest of the all engines compared. It was almost twice as fast as the second place runner on the list. The data presented above is not intended to trash about any of the view engines. The procedure to make the comparison on performance is quite simple and not scientific at all. From a technical point of view it's up to the developer to choose the templating engine that makes him more productive. It is also important to bear in mind that for frontend designers accustomed to code in HTML only, the learning curve for them will be of relevance.
by Dian Dimitrov, MIT license