ejs vs handlebars vs nunjucks vs pug
Server-Side HTML Templating Engines for Node.js
ejshandlebarsnunjuckspugSimilar Packages:

Server-Side HTML Templating Engines for Node.js

ejs, handlebars, nunjucks, and pug are popular templating engines used to generate dynamic HTML on the server side within Node.js applications. They allow developers to separate presentation logic from business logic by embedding variables, control structures, and reusable components into static templates. While they all serve the same core purpose, they differ significantly in syntax style, logic capabilities, and how they handle template inheritance. Choosing the right one depends on your team's familiarity with JavaScript, preference for HTML-like structures, and requirements for template reuse.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
ejs08,111211 kB2611 days agoApache-2.0
handlebars018,6422.81 MB1122 months agoMIT
nunjucks08,9631.77 MB3553 years agoBSD-2-Clause
pug021,85222.5 kB3293 months agoMIT

EJS vs Handlebars vs Nunjucks vs Pug: A Technical Deep-Dive

When building server-rendered Node.js applications, selecting a templating engine is a foundational decision that affects developer velocity, maintainability, and security. ejs, handlebars, nunjucks, and pug are the four most established options in the ecosystem. While they all compile templates into HTML, their underlying philosophies differ — from embedding raw JavaScript to enforcing logic-less views. Let's examine how they handle real-world engineering challenges.

📝 Syntax Philosophy: HTML vs Abstraction

The most immediate difference is how closely the template syntax resembles standard HTML. This impacts how easily frontend developers can edit templates without deep backend knowledge.

ejs keeps standard HTML intact.

  • You write normal HTML tags.
  • JavaScript logic is embedded between <% and %> tags.
  • Best for teams that want to copy-paste existing HTML.
<!-- ejs: Standard HTML structure -->
<div class="user-card">
  <h1><%= user.name %></h1>
  <% if (user.isActive) { %>
    <p>Active Member</p>
  <% } %>
</div>

handlebars uses double mustaches for expressions.

  • HTML structure remains standard.
  • Logic is handled via helpers, not raw JS.
  • Keeps templates clean and focused on data.
<!-- handlebars: Mustache syntax -->
<div class="user-card">
  <h1>{{user.name}}</h1>
  {{#if user.isActive}}
    <p>Active Member</p>
  {{/if}}
</div>

nunjucks uses Jinja2-style delimiters.

  • HTML structure remains standard.
  • Logic blocks use {% %} and variables use {{ }}.
  • Familiar to developers coming from Python or Django.
<!-- nunjucks: Jinja2 style -->
<div class="user-card">
  <h1>{{ user.name }}</h1>
  {% if user.isActive %}
    <p>Active Member</p>
  {% endif %}
</div>

pug removes HTML tags' closing brackets and uses indentation.

  • No angle brackets for most elements.
  • Whitespace defines nesting.
  • Drastically reduces character count but changes visual structure.
<!-- pug: Indentation based -->
.user-card
  h1= user.name
  if user.isActive
    p Active Member

🔄 Logic & Control Flow

How much JavaScript can you run inside the template? This determines where business logic lives.

ejs allows raw JavaScript execution.

  • You can write loops, conditionals, and even functions directly.
  • Risk: Can lead to bloated templates if not disciplined.
// ejs: Raw JS loops
<ul>
  <% items.forEach(function(item) { %>
    <li><%= item.title %></li>
  <% }); %>
</ul>

handlebars restricts logic to helpers.

  • No arbitrary JS execution.
  • You must register custom helpers for complex logic.
  • Enforces cleaner separation of concerns.
// handlebars: Helper based loops
<ul>
  {{#each items}}
    <li>{{title}}</li>
  {{/each}}
</ul>

nunjucks offers built-in control structures.

  • Supports loops and conditionals out of the box.
  • More powerful than Handlebars but less free-form than EJS.
// nunjucks: Built-in control flow
<ul>
  {% for item in items %}
    <li>{{ item.title }}</li>
  {% endfor %}
</ul>

pug uses JavaScript-like syntax for logic.

  • Indentation drives the flow.
  • Supports iteration and conditionals cleanly.
// pug: Indentation logic
ul
  each item in items
    li= item.title

🧩 Template Inheritance & Partials

Large applications need reusable layouts. How do these engines handle composing pages from smaller pieces?

ejs relies on includes.

  • You include partial files manually.
  • No built-in block overriding system.
  • Requires manual management of layout structure.
<!-- ejs: Manual includes -->
<%- include('partials/header') %>
<h1>Page Content</h1>
<%- include('partials/footer') %>

handlebars uses partials registration.

  • Partials must be pre-compiled or registered at runtime.
  • Good for component-based UIs.
  • No native inheritance hierarchy.
<!-- handlebars: Partials -->
{{> header}}
<h1>Page Content</h1>
{{> footer}}

nunjucks supports full template inheritance.

  • You define a base template with blocks.
  • Child templates extend the base and override blocks.
  • Ideal for consistent site-wide layouts.
<!-- nunjucks: Inheritance -->
<!-- base.html -->
<html><body>{% block content %}{% endblock %}</body></html>

<!-- child.html -->
{% extends "base.html" %}
{% block content %}
  <h1>Page Content</h1>
{% endblock %}

pug supports includes and extends.

  • Mixins allow for reusable function-like blocks.
  • Extends works similarly to Nunjucks for layouts.
// pug: Extends and Blocks
// layout.pug
html
  body
    block content

// index.pug
extends layout
block content
  h1 Page Content

🔒 Security & Escaping

Preventing Cross-Site Scripting (XSS) is critical. How does each engine handle untrusted user input?

ejs escapes by default with <%=.

  • Use <%- for unescaped output (dangerous).
  • Developers must be careful not to misuse the unescaped tag.
// ejs: Escaping
// Safe: escapes HTML entities
<div><%= userInput %></div>

// Unsafe: renders raw HTML
<div><%- userInput %></div>

handlebars escapes by default with {{.

  • Use {{{ for unescaped output.
  • Strong safety defaults for most use cases.
// handlebars: Escaping
// Safe
<div>{{userInput}}</div>

// Unsafe
<div>{{{userInput}}}</div>

nunjucks escapes by default with {{.

  • Use the safe filter to allow HTML.
  • Auto-escaping is robust and configurable.
// nunjucks: Escaping
// Safe
<div>{{ userInput }}</div>

// Unsafe (explicitly marked)
<div>{{ userInput | safe }}</div>

pug escapes by default with =.

  • Use != for unescaped output.
  • Clear visual distinction between safe and unsafe.
// pug: Escaping
// Safe
div= userInput

// Unsafe
div!= userInput

📊 Summary: Key Differences

Featureejshandlebarsnunjuckspug
SyntaxHTML + JS tagsHTML + MustacheHTML + Jinja2Indentation
LogicFull JavaScriptLogic-less (Helpers)Built-in ControlJS-like
InheritanceIncludes onlyPartials onlyBlock InheritanceExtends + Mixins
Escaping<%= (Safe){{ (Safe){{ (Safe)= (Safe)
Learning CurveLowMediumMediumHigh

💡 The Big Picture

ejs is the pragmatic choice for teams who want to get started quickly without learning a new syntax. It feels like writing HTML with script tags. However, the freedom to write raw JS can lead to messy templates if not governed by strict code reviews.

handlebars is the disciplined choice. By forcing logic into helpers, it keeps templates dumb and fast. This is perfect for design systems where templates might be edited by non-developers or shared across different platforms.

nunjucks is the architectural choice for large sites. Its inheritance model is superior for maintaining complex layouts with multiple content regions. If you come from a Django or Jinja background, this will feel like home.

pug is the productivity choice for backend-heavy teams. It reduces boilerplate significantly. However, the whitespace sensitivity can cause frustrating bugs if indentation is inconsistent, and it creates a barrier for frontend developers used to standard HTML.

Final Thought: All four packages are mature and stable. None are deprecated. Your decision should rest on team preference and template complexity. For simple views, ejs or pug work well. For complex layouts, nunjucks shines. For strict separation, handlebars is best.

How to Choose: ejs vs handlebars vs nunjucks vs pug

  • ejs:

    Choose ejs if your team wants minimal learning overhead and prefers writing standard HTML with embedded JavaScript logic. It is ideal for projects where developers want full access to JavaScript features inside templates without learning a new syntax. It works well for simple views or when migrating legacy ASP/JSP styles to Node.js.

  • handlebars:

    Choose handlebars if you need a logic-less template system that enforces a strict separation between view and controller. It is excellent for projects where templates are shared between server and client, as the syntax is consistent across environments. Use it when you want to prevent complex logic from creeping into your HTML.

  • nunjucks:

    Choose nunjucks if you need powerful template inheritance and block overriding similar to Python's Jinja2 or Django. It is suitable for large applications with deeply nested layouts where content sections need to be injected into a master frame. It offers a good balance between logic capabilities and safety.

  • pug:

    Choose pug if you prefer a concise, whitespace-sensitive syntax that reduces typing and eliminates closing tags. It is best for teams that value brevity and are comfortable with indentation-based structures. Avoid it if your designers or frontend developers need to edit raw HTML files directly, as the syntax diverges significantly from standard HTML.

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.

Bundlers and alternate runtimes: as of v6.0, the published package imports cleanly under Rollup, Rolldown, tsdown, esbuild, Webpack, Vite, Browserify, Bun, and Deno. Earlier versions emitted module.exports = ejs; from inside the ESM source as a dual-mode shim; modern ESM-aware bundlers and Bun treated this as malformed ESM. The shim has been removed from lib/esm/*.js and moved into the lib/cjs/* compile step, so the published CJS surface (require('ejs')) is unchanged. For Browserify, pass --node so it picks the main entry instead of the prebuilt UMD bundle pointed to by the browser field.

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.
  • unsafePrototypeLocals When true, allows templates to resolve identifiers through the prototype chain of the locals object. Required if you pass class instances or Object.create(...) results as locals and rely on inherited properties at the top level. Defaults to false; enabling it disables the v6 prototype-pollution mitigation.
  • 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.