ejs vs handlebars vs mustache vs pug vs nunjucks vs liquidjs vs dot vs twig vs hbs
JavaScript Templating Engines Comparison
1 Year
ejshandlebarsmustachepugnunjucksliquidjsdottwighbs
What's JavaScript Templating Engines?

JavaScript templating engines are libraries that allow developers to generate HTML dynamically by embedding JavaScript logic within templates. They facilitate the separation of HTML structure from business logic, making it easier to manage and maintain web applications. These engines enable the creation of dynamic content by injecting data into templates, allowing for the rendering of views based on the application's state. Each templating engine has its own syntax, features, and use cases, catering to different development needs and preferences.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
ejs20,175,2427,856143 kB111a year agoApache-2.0
handlebars16,616,49518,1382.78 MB982 years agoMIT
mustache6,031,36316,581-1144 years agoMIT
pug1,657,672-59.7 kB-9 months agoMIT
nunjucks991,0828,6371.77 MB3432 years agoBSD-2-Clause
liquidjs546,9861,6001.76 MB39 days agoMIT
dot510,5795,028-295 years agoMIT
twig319,0791,8991.17 MB65a year agoBSD-2-Clause
hbs170,9901,66821.6 kB73 years agoMIT
Feature Comparison: ejs vs handlebars vs mustache vs pug vs nunjucks vs liquidjs vs dot vs twig vs hbs

Syntax and Readability

  • ejs:

    EJS allows embedding JavaScript directly within HTML using simple tags, making it intuitive for those familiar with JavaScript. However, this can lead to less readable templates if not managed properly.

  • handlebars:

    Handlebars offers a cleaner syntax with a clear separation of logic and markup, using curly braces for expressions and helpers. This enhances readability and maintainability, especially in larger projects.

  • mustache:

    Mustache's logic-less syntax promotes separation of logic and presentation, using simple tags for variables and sections. This simplicity enhances readability but may limit functionality for complex scenarios.

  • pug:

    Pug's indentation-based syntax reduces the amount of HTML boilerplate, making templates concise and easier to read. However, the learning curve may be steep for those unfamiliar with indentation-based languages.

  • nunjucks:

    Nunjucks provides a clean syntax similar to Jinja2, allowing for template inheritance and block definitions. This enhances readability and organization in complex applications.

  • liquidjs:

    LiquidJS uses a logic-less syntax that emphasizes clarity, with simple tags for output and control flow. This makes it easy to read and understand, especially for non-developers.

  • dot:

    Dot uses a simple syntax that resembles JavaScript object notation, making it easy to read and write. It is designed for performance and clarity, allowing developers to create templates quickly without much boilerplate.

  • twig:

    Twig's syntax is designed to be clean and expressive, similar to Jinja2, allowing for complex logic while maintaining readability. It supports template inheritance and macros, enhancing code organization.

  • hbs:

    HBS is essentially Handlebars for Express.js, maintaining the same syntax and readability benefits, making it easy to integrate into Express applications while keeping templates clean.

Performance

  • ejs:

    EJS performs well for small to medium-sized templates but may experience slower performance with larger templates due to its direct embedding of JavaScript.

  • handlebars:

    Handlebars is efficient, especially with precompiled templates, which can significantly improve rendering speed. Its performance is generally good for most use cases.

  • mustache:

    Mustache is lightweight and performs well, but its logic-less approach may lead to more templates being required for complex applications, which could impact performance.

  • pug:

    Pug is generally fast due to its compiled nature, but performance can vary based on the complexity of the templates and the use of mixins and includes.

  • nunjucks:

    Nunjucks offers good performance, especially with asynchronous rendering capabilities, but may be slower than simpler engines due to its feature-rich nature.

  • liquidjs:

    LiquidJS is designed for performance with a focus on simplicity, but its logic-less nature may limit its capabilities in highly dynamic scenarios, potentially affecting performance.

  • dot:

    Dot is optimized for performance, making it one of the fastest templating engines available. It compiles templates into functions, resulting in minimal overhead during rendering.

  • twig:

    Twig is optimized for performance, especially in larger applications, but its feature-rich nature may introduce some overhead compared to simpler engines.

  • hbs:

    HBS inherits Handlebars' performance characteristics, making it suitable for Express applications with efficient rendering capabilities, especially when using precompiled templates.

Extensibility

  • ejs:

    EJS allows for the inclusion of custom functions and partials, making it extensible for various use cases, though it may require more boilerplate for complex extensions.

  • handlebars:

    Handlebars supports custom helpers and partials, allowing developers to extend its functionality easily, making it suitable for larger applications with reusable components.

  • mustache:

    Mustache is intentionally minimalistic and does not support extensions, which may limit its use in more complex scenarios but keeps it simple and straightforward.

  • pug:

    Pug supports mixins and includes, allowing for code reuse and modular templates, making it extensible for larger applications with complex structures.

  • nunjucks:

    Nunjucks is highly extensible, allowing for custom filters, tags, and asynchronous support, making it suitable for complex applications that require advanced templating features.

  • liquidjs:

    LiquidJS supports custom tags and filters, allowing developers to extend its functionality while maintaining a logic-less approach, making it suitable for CMS applications.

  • dot:

    Dot is lightweight and does not offer extensive built-in features, but it can be easily extended with custom functions and helpers to suit specific needs.

  • twig:

    Twig is highly extensible, supporting custom filters, functions, and macros, making it suitable for complex applications that require advanced templating capabilities.

  • hbs:

    HBS inherits Handlebars' extensibility features, allowing for custom helpers and partials, making it easy to build complex applications with reusable templates.

Community and Ecosystem

  • ejs:

    EJS has a strong community and is widely used, resulting in a wealth of resources, tutorials, and plugins available for developers.

  • handlebars:

    Handlebars has a large community and ecosystem, with numerous resources, plugins, and extensions available, making it a popular choice for many developers.

  • mustache:

    Mustache has a smaller community, but its simplicity and logic-less approach have led to its adoption in various projects, though resources may be limited.

  • pug:

    Pug has a large community and extensive resources, including plugins and tutorials, making it easy for developers to find support and examples.

  • nunjucks:

    Nunjucks has a strong community and is well-documented, providing numerous resources and plugins, making it a popular choice for complex applications.

  • liquidjs:

    LiquidJS has a growing community, especially among CMS developers, with resources available but not as extensive as more established engines.

  • dot:

    Dot has a smaller community compared to others, which may limit the availability of resources and plugins, but it is still actively maintained and used in various projects.

  • twig:

    Twig has a robust community, especially among PHP developers, with a wealth of resources, plugins, and extensions available, making it a strong choice for complex applications.

  • hbs:

    HBS benefits from the Handlebars community, providing access to a wide range of resources and plugins specifically for Express.js applications.

How to Choose: ejs vs handlebars vs mustache vs pug vs nunjucks vs liquidjs vs dot vs twig vs hbs
  • ejs:

    Select EJS if you prefer a straightforward syntax that allows you to embed JavaScript directly in your HTML, making it easy to render dynamic content with minimal setup.

  • handlebars:

    Opt for Handlebars if you require a more powerful templating engine with features like helpers and partials, which allow for more complex templates and reusable components.

  • mustache:

    Select Mustache for its simplicity and logic-less approach, which encourages clean separation of logic and presentation, making it suitable for various environments.

  • pug:

    Choose Pug if you prefer a concise, indentation-based syntax that reduces boilerplate HTML, making your templates cleaner and easier to read.

  • nunjucks:

    Opt for Nunjucks if you need a powerful templating engine with features like template inheritance and asynchronous support, making it suitable for complex applications.

  • liquidjs:

    Choose LiquidJS if you need a templating engine that supports logic-less templates, making it ideal for scenarios where you want to separate presentation from logic, such as in CMS systems.

  • dot:

    Choose dot if you need a lightweight and fast templating engine that supports simple syntax and is easy to integrate into existing projects without much overhead.

  • twig:

    Select Twig if you are looking for a feature-rich templating engine with a syntax similar to Jinja2, ideal for PHP developers transitioning to JavaScript.

  • hbs:

    Use hbs if you are working with Express.js and want to leverage Handlebars as your view engine, benefiting from its features while maintaining a simple integration.

README for ejs

Embedded JavaScript templates
Known Vulnerabilities

Security

Security professionals, before reporting any security issues, please reference the SECURITY.md in this project, in particular, the following: "EJS is effectively a JavaScript runtime. Its entire job is to execute JavaScript. If you run the EJS render method without checking the inputs yourself, you are responsible for the results."

In short, DO NOT submit 'vulnerabilities' that include this snippet of code:

app.get('/', (req, res) => {
  res.render('index', req.query);
});

Installation

$ npm install ejs

Features

  • Control flow with <% %>
  • Escaped output with <%= %> (escape function configurable)
  • Unescaped raw output with <%- %>
  • Newline-trim mode ('newline slurping') with -%> ending tag
  • Whitespace-trim mode (slurp all whitespace) for control flow with <%_ _%>
  • Custom delimiters (e.g. [? ?] instead of <% %>)
  • Includes
  • Client-side support
  • Static caching of intermediate JavaScript
  • Static caching of templates
  • Complies with the Express view system

Example

<% if (user) { %>
  <h2><%= user.name %></h2>
<% } %>

Try EJS online at: https://ionicabizau.github.io/ejs-playground/.

Basic usage

let template = ejs.compile(str, options);
template(data);
// => Rendered HTML string

ejs.render(str, data, options);
// => Rendered HTML string

ejs.renderFile(filename, data, options, function(err, str){
    // str => Rendered HTML string
});

It is also possible to use ejs.render(dataAndOptions); where you pass everything in a single object. In that case, you'll end up with local variables for all the passed options. However, be aware that your code could break if we add an option with the same name as one of your data object's properties. Therefore, we do not recommend using this shortcut.

Important

You should never give end-users unfettered access to the EJS render method, If you do so you are using EJS in an inherently un-secure way.

Options

  • cache Compiled functions are cached, requires filename
  • filename The name of the file being rendered. Not required if you are using renderFile(). Used by cache to key caches, and for includes.
  • root Set template root(s) for includes with an absolute path (e.g, /file.ejs). Can be array to try to resolve include from multiple directories.
  • views An array of paths to use when resolving includes with relative paths.
  • context Function execution context
  • compileDebug When false no debug instrumentation is compiled
  • client When true, compiles a function that can be rendered in the browser without needing to load the EJS Runtime (ejs.min.js).
  • delimiter Character to use for inner delimiter, by default '%'
  • openDelimiter Character to use for opening delimiter, by default '<'
  • closeDelimiter Character to use for closing delimiter, by default '>'
  • debug Outputs generated function body
  • strict When set to true, generated function is in strict mode
  • _with Whether or not to use with() {} constructs. If false then the locals will be stored in the locals object. Set to false in strict mode.
  • destructuredLocals An array of local variables that are always destructured from the locals object, available even in strict mode.
  • localsName Name to use for the object storing local variables when not using with Defaults to locals
  • rmWhitespace Remove all safe-to-remove whitespace, including leading and trailing whitespace. It also enables a safer version of -%> line slurping for all scriptlet tags (it does not strip new lines of tags in the middle of a line).
  • escape The escaping function used with <%= construct. It is used in rendering and is .toString()ed in the generation of client functions. (By default escapes XML).
  • outputFunctionName Set to a string (e.g., 'echo' or 'print') for a function to print output inside scriptlet tags.
  • async When true, EJS will use an async function for rendering. (Depends on async/await support in the JS runtime.
  • includer Custom function to handle EJS includes, receives (originalPath, parsedPath) parameters, where originalPath is the path in include as-is and parsedPath is the previously resolved path. Should return an object { filename, template }, you may return only one of the properties, where filename is the final parsed path and template is the included content.

This project uses JSDoc. For the full public API documentation, clone the repository and run jake doc. This will run JSDoc with the proper options and output the documentation to out/. If you want the both the public & private API docs, run jake devdoc instead.

Tags

  • <% 'Scriptlet' tag, for control-flow, no output
  • <%_ 'Whitespace Slurping' Scriptlet tag, strips all whitespace before it
  • <%= Outputs the value into the template (escaped)
  • <%- Outputs the unescaped value into the template
  • <%# Comment tag, no execution, no output
  • <%% Outputs a literal '<%'
  • %%> Outputs a literal '%>'
  • %> Plain ending tag
  • -%> Trim-mode ('newline slurp') tag, trims following newline
  • _%> 'Whitespace Slurping' ending tag, removes all whitespace after it

For the full syntax documentation, please see docs/syntax.md.

Includes

Includes either have to be an absolute path, or, if not, are assumed as relative to the template with the include call. For example if you are including ./views/user/show.ejs from ./views/users.ejs you would use <%- include('user/show') %>.

You must specify the filename option for the template with the include call unless you are using renderFile().

You'll likely want to use the raw output tag (<%-) with your include to avoid double-escaping the HTML output.

<ul>
  <% users.forEach(function(user){ %>
    <%- include('user/show', {user: user}) %>
  <% }); %>
</ul>

Includes are inserted at runtime, so you can use variables for the path in the include call (for example <%- include(somePath) %>). Variables in your top-level data object are available to all your includes, but local variables need to be passed down.

NOTE: Include preprocessor directives (<% include user/show %>) are not supported in v3.0+.

Custom delimiters

Custom delimiters can be applied on a per-template basis, or globally:

let ejs = require('ejs'),
    users = ['geddy', 'neil', 'alex'];

// Just one template
ejs.render('<p>[?= users.join(" | "); ?]</p>', {users: users}, {delimiter: '?', openDelimiter: '[', closeDelimiter: ']'});
// => '<p>geddy | neil | alex</p>'

// Or globally
ejs.delimiter = '?';
ejs.openDelimiter = '[';
ejs.closeDelimiter = ']';
ejs.render('<p>[?= users.join(" | "); ?]</p>', {users: users});
// => '<p>geddy | neil | alex</p>'

Caching

EJS ships with a basic in-process cache for caching the intermediate JavaScript functions used to render templates. It's easy to plug in LRU caching using Node's lru-cache library:

let ejs = require('ejs'),
    LRU = require('lru-cache');
ejs.cache = LRU(100); // LRU cache with 100-item limit

If you want to clear the EJS cache, call ejs.clearCache. If you're using the LRU cache and need a different limit, simple reset ejs.cache to a new instance of the LRU.

Custom file loader

The default file loader is fs.readFileSync, if you want to customize it, you can set ejs.fileLoader.

let ejs = require('ejs');
let myFileLoad = function (filePath) {
  return 'myFileLoad: ' + fs.readFileSync(filePath);
};

ejs.fileLoader = myFileLoad;

With this feature, you can preprocess the template before reading it.

Layouts

EJS does not specifically support blocks, but layouts can be implemented by including headers and footers, like so:

<%- include('header') -%>
<h1>
  Title
</h1>
<p>
  My page
</p>
<%- include('footer') -%>

Client-side support

Go to the Latest Release, download ./ejs.js or ./ejs.min.js. Alternately, you can compile it yourself by cloning the repository and running jake build (or $(npm bin)/jake build if jake is not installed globally).

Include one of these files on your page, and ejs should be available globally.

Example

<div id="output"></div>
<script src="ejs.min.js"></script>
<script>
  let people = ['geddy', 'neil', 'alex'],
      html = ejs.render('<%= people.join(", "); %>', {people: people});
  // With jQuery:
  $('#output').html(html);
  // Vanilla JS:
  document.getElementById('output').innerHTML = html;
</script>

Caveats

Most of EJS will work as expected; however, there are a few things to note:

  1. Obviously, since you do not have access to the filesystem, ejs.renderFile() won't work.
  2. For the same reason, includes do not work unless you use an include callback. Here is an example:
let str = "Hello <%= include('file', {person: 'John'}); %>",
    fn = ejs.compile(str, {client: true});

fn(data, null, function(path, d){ // include callback
  // path -> 'file'
  // d -> {person: 'John'}
  // Put your code here
  // Return the contents of file as a string
}); // returns rendered string

See the examples folder for more details.

CLI

EJS ships with a full-featured CLI. Options are similar to those used in JavaScript code:

  • -o / --output-file FILE Write the rendered output to FILE rather than stdout.
  • -f / --data-file FILE Must be JSON-formatted. Use parsed input from FILE as data for rendering.
  • -i / --data-input STRING Must be JSON-formatted and URI-encoded. Use parsed input from STRING as data for rendering.
  • -m / --delimiter CHARACTER Use CHARACTER with angle brackets for open/close (defaults to %).
  • -p / --open-delimiter CHARACTER Use CHARACTER instead of left angle bracket to open.
  • -c / --close-delimiter CHARACTER Use CHARACTER instead of right angle bracket to close.
  • -s / --strict When set to true, generated function is in strict mode
  • -n / --no-with Use 'locals' object for vars rather than using with (implies --strict).
  • -l / --locals-name Name to use for the object storing local variables when not using with.
  • -w / --rm-whitespace Remove all safe-to-remove whitespace, including leading and trailing whitespace.
  • -d / --debug Outputs generated function body
  • -h / --help Display this help message.
  • -V/v / --version Display the EJS version.

Here are some examples of usage:

$ ejs -p [ -c ] ./template_file.ejs -o ./output.html
$ ejs ./test/fixtures/user.ejs name=Lerxst
$ ejs -n -l _ ./some_template.ejs -f ./data_file.json

Data input

There is a variety of ways to pass the CLI data for rendering.

Stdin:

$ ./test/fixtures/user_data.json | ejs ./test/fixtures/user.ejs
$ ejs ./test/fixtures/user.ejs < test/fixtures/user_data.json

A data file:

$ ejs ./test/fixtures/user.ejs -f ./user_data.json

A command-line option (must be URI-encoded):

./bin/cli.js -i %7B%22name%22%3A%20%22foo%22%7D ./test/fixtures/user.ejs

Or, passing values directly at the end of the invocation:

./bin/cli.js -m $ ./test/fixtures/user.ejs name=foo

Output

The CLI by default send output to stdout, but you can use the -o or --output-file flag to specify a target file to send the output to.

IDE Integration with Syntax Highlighting

VSCode:Javascript EJS by DigitalBrainstem

Related projects

There are a number of implementations of EJS:

  • TJ's implementation, the v1 of this library: https://github.com/tj/ejs
  • EJS Embedded JavaScript Framework on Google Code: https://code.google.com/p/embeddedjavascript/
  • Sam Stephenson's Ruby implementation: https://rubygems.org/gems/ejs
  • Erubis, an ERB implementation which also runs JavaScript: http://www.kuwata-lab.com/erubis/users-guide.04.html#lang-javascript
  • DigitalBrainstem EJS Language support: https://github.com/Digitalbrainstem/ejs-grammar

License

Licensed under the Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0)


EJS Embedded JavaScript templates copyright 2112 mde@fleegix.org.