ejs vs handlebars vs mustache vs pug
Server-Side Template Engines for Node.js Applications
ejshandlebarsmustachepugSimilar Packages:

Server-Side Template Engines for Node.js Applications

ejs, handlebars, mustache, and pug are server-side template engines used in Node.js applications to generate dynamic HTML by combining templates with data. These libraries enable developers to separate presentation logic from application code, support partials or includes for reusable components, and offer varying levels of syntax abstraction and logic capabilities. Each provides compile-time and render-time APIs suitable for both server-rendered web pages and email templating.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
ejs08,091205 kB267 days agoApache-2.0
handlebars018,6112.78 MB1113 years agoMIT
mustache016,714-1155 years agoMIT
pug0-59.7 kB-2 years agoMIT

Server-Side Template Engines Compared: EJS, Handlebars, Mustache, and Pug

When building server-rendered web applications in Node.js, choosing a template engine affects how you write views, manage logic, and collaborate across teams. While all four — ejs, handlebars, mustache, and pug — serve the same core purpose (merging data with templates to produce HTML), they differ significantly in philosophy, syntax, and developer experience. Let’s compare them through real-world engineering lenses.

🧩 Syntax Style: HTML-Like vs Abstract vs Logic-Less

ejs uses plain HTML with embedded JavaScript inside <% %> tags. You write almost-valid HTML, making it easy to onboard frontend developers.

<!-- ejs -->
<ul>
  <% users.forEach(user => { %>
    <li><%= user.name %></li>
  <% }); %>
</ul>

handlebars uses double curly braces {{}} for output and block helpers like {{#each}} for iteration. It avoids raw logic but allows custom helpers.

{{! handlebars }}
<ul>
  {{#each users}}
    <li>{{name}}</li>
  {{/each}}
</ul>

mustache is strictly logic-less — no conditionals, loops, or helpers beyond what the spec defines. Everything must be prepared in the data context.

{{! mustache }}
<ul>
  {{#users}}
    <li>{{name}}</li>
  {{/users}}
</ul>

pug (formerly Jade) uses indentation instead of closing tags, resulting in very compact syntax.

//- pug
ul
  each user in users
    li= user.name

💡 Key takeaway: If your team includes non-developers (e.g., designers), ejs or handlebars are safer. If you want brevity and don’t mind a learning curve, pug wins. If cross-language consistency is critical, mustache is the only true logic-less option.

⚙️ Control Flow: How Much Logic Is Allowed?

ejs lets you embed arbitrary JavaScript, including conditionals, loops, and function calls directly in templates.

<% if (user.isAdmin) { %>
  <button>Delete</button>
<% } %>

handlebars restricts logic to predefined block helpers (if, each, with) but allows custom helpers for things like formatting.

{{#if user.isAdmin}}
  <button>Delete</button>
{{/if}}

mustache has no if or each — instead, it uses truthy/falsy sections. Loops require array-like objects in the data.

{{#user.isAdmin}}
  <button>Delete</button>
{{/user.isAdmin}}

pug supports JavaScript expressions and control flow using its own syntax.

if user.isAdmin
  button Delete

⚠️ Trade-off: More logic in templates (ejs, pug) speeds up development but risks mixing concerns. Less logic (mustache, handlebars) enforces cleaner separation but may push complexity into data preparation.

🔒 Escaping and Security

ejs does not auto-escape by default. Use <%- for unescaped output and <%= for escaped — but it’s easy to forget.

<!-- Unsafe if name contains HTML -->
<%- user.name %>

<!-- Safe -->
<%= user.name %>

handlebars auto-escapes all {{}} output by default. Use triple braces {{{}}} for unescaped content.

<!-- Auto-escaped -->
{{user.name}}

<!-- Unescaped (use cautiously) -->
{{{user.htmlContent}}}

mustache also auto-escapes standard {{}} tags. Unescaped output uses {{{}}} or &{}.

{{user.name}}        <!-- escaped -->
{{{user.content}}}   <!-- unescaped -->

pug auto-escapes interpolated values (= var) by default. Use != for unescaped output.

= user.name      // escaped
!= user.content  // unescaped

Best practice: Prefer engines that escape by default (handlebars, mustache, pug) unless you have strong linting/testing around EJS usage.

🧱 Reusability: Partials, Includes, and Layouts

All four support some form of template reuse, but with different ergonomics.

ejs uses <%- include('path') %> for partials and supports layout systems via middleware like express-ejs-layouts.

<%- include('header') %>
<main><%- body %></main>
<%- include('footer') %>

handlebars has built-in {{> partialName}} syntax and supports block-based layouts with helpers like {{#block}}...{{/block}} (via handlebars-layouts or similar).

{{> header}}
<main>{{{body}}}</main>
{{> footer}}

mustache supports partials via {{> partialName}}, but layout composition requires external tooling or manual data nesting.

{{> header}}
<main>{{content}}</main>
{{> footer}}

pug offers powerful mixins and extends/block for inheritance-based layouts.

extends layout.pug

block content
  h1 Welcome

💡 For complex apps: pug’s inheritance and handlebars’ block helpers provide the most scalable layout systems. ejs and mustache require more setup for advanced composition.

🚀 Performance Considerations

All engines support precompilation to JavaScript functions, which improves render speed in production.

  • ejs: ejs.compile(template) returns a render function.
  • handlebars: Handlebars.compile(template) is commonly used; templates can be precompiled to avoid runtime parsing.
  • mustache: Mustache.render(template, view) is simple but doesn’t expose a compiled function API directly — though caching is straightforward.
  • pug: Compiles to a JavaScript function by default; pug.compile() is explicit.

In high-throughput scenarios (e.g., email rendering at scale), precompiling templates with handlebars or pug yields measurable gains. ejs and mustache are slightly slower due to runtime parsing unless cached.

🌐 Real-World Fit

Scenario 1: Marketing Site with CMS Content

You’re pulling structured content from a headless CMS and need safe, designer-friendly templates.

  • Best choice: handlebars
  • Why? Auto-escaping prevents XSS from CMS input, and partials allow reusable components. Custom helpers can format dates or truncate text without touching the data layer.

Scenario 2: Internal Admin Dashboard

Your team owns both frontend and backend, and you need rapid iteration with conditional UI elements.

  • Best choice: ejs or pug
  • Why? Full JavaScript access (ejs) or terse syntax (pug) speeds up development. Security is less critical in authenticated internal tools.

Scenario 3: Multi-Language Documentation Generator

You’re generating static HTML from Markdown metadata across Python, Ruby, and Node.js services.

  • Best choice: mustache
  • Why? The same .mustache files work identically in all languages, ensuring consistency.

Scenario 4: Email Templating System

You need reliable, cacheable templates with layout reuse and internationalization.

  • Best choice: handlebars
  • Why? Precompilation, partials, and helper registration (e.g., for i18n) make it ideal for transactional emails.

📊 Summary Table

Featureejshandlebarsmustachepug
SyntaxHTML + JS{{}} blocksStrict logic-lessIndentation-based
Logic in TemplatesFull JSLimited (helpers)NoneFull JS expressions
Auto-Escaping❌ (manual)
Partialsinclude(){{> name}}{{> name}}include / mixin
LayoutsVia middlewareBlock helpersManualextends / block
Precompilation✅ (recommended)Limited✅ (default)
Cross-Language✅ (many ports)✅ (official spec)

💡 Final Recommendation

  • Stick with handlebars if you want a sweet spot: safe by default, expressive enough for real apps, and widely supported.
  • Go with ejs if your team lives in JavaScript and values familiarity over enforced separation.
  • Use mustache only when you truly need zero logic in templates and cross-language compatibility.
  • Pick pug if you prioritize developer velocity and don’t mind trading readability for conciseness.

None of these engines are deprecated — all are actively maintained and production-ready. Your choice should reflect team expertise, security requirements, and how much logic you’re willing to tolerate in your views.

How to Choose: ejs vs handlebars vs mustache vs pug

  • ejs:

    Choose ejs if you prefer writing templates that closely resemble standard HTML with embedded JavaScript. It’s ideal when your team is already comfortable with JavaScript and needs fine-grained control over rendering logic without learning a new syntax. EJS integrates smoothly with Express and supports client-side rendering reuse, but offers minimal built-in protection against XSS — you must manually escape output.

  • handlebars:

    Choose handlebars when you need a balance between logic-less design and practical helper functionality. Its block expressions, custom helpers, and partial system make it well-suited for complex layouts like dashboards or CMS-driven sites. Handlebars enforces separation of concerns more strictly than EJS but less rigidly than Mustache, and its precompilation support improves runtime performance in high-throughput scenarios.

  • mustache:

    Choose mustache if you require strict logic-less templates that work identically across multiple programming languages. It’s best for simple, highly portable templates where business logic must remain entirely outside the view layer — such as documentation generators or multi-language projects. However, the absence of built-in helpers means even basic formatting (like date display) requires external data preparation.

  • pug:

    Choose pug when you value concise, whitespace-sensitive syntax and want to reduce boilerplate HTML. It’s excellent for rapid prototyping or internal tools where developers are comfortable with indentation-based languages. Pug compiles to functions for fast rendering and supports mixins and inheritance, but its abstraction can make debugging harder and complicates collaboration with designers unfamiliar with its syntax.

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

Import or require

Supports both CommonJS and ES Modules.

import ejs from 'ejs';
// Or
const ejs = require('ejs');

Compatibility

Server: CommonJS approach (require) supports Node versions at least back to v0.12, likely older versions too. ES Modules approach (import) requires a Node version that supports ESM.

CLI: Requires Node v8 or newer.

Browser: EJS supports all modern browsers, but is very likely to work even in very, very old browsers. Your mileage may vary.

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>
<% } %>

Basic usage

const 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
  • 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. (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:

import ejs from 'ejs';
const 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:

import ejs from 'ejs';
import { LRUCache } from 'lru-cache';

ejs.cache = LRUCache({max: 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.

import ejs from 'ejs';

const 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 npx 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);

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:

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.