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

Server-Side Templating Engines for Node.js

ejs, handlebars, liquidjs, nunjucks, and pug are templating engines used to generate HTML on the server side within Node.js applications. They allow developers to embed dynamic data into static structures, reducing repetition and separating concerns between logic and presentation. While ejs and pug allow direct JavaScript execution, handlebars, liquidjs, and nunjucks enforce logic-less templates for better security and separation. Choosing the right engine depends on your security requirements, preferred syntax style, and need for template inheritance.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
ejs08,115211 kB283 months agoApache-2.0
handlebars018,6662.81 MB1134 months agoMIT
liquidjs01,8561.89 MB159 days agoMIT
nunjucks08,9811.77 MB3583 years agoBSD-2-Clause
pug021,85322.5 kB3335 months agoMIT

Server-Side Templating Engines: EJS vs Handlebars vs Liquid vs Nunjucks vs Pug

When building Node.js applications, you often need to generate HTML on the server. The ejs, handlebars, liquidjs, nunjucks, and pug packages all solve this problem, but they take very different approaches to syntax, security, and structure. Let's compare how they handle common templating tasks.

📝 Syntax Style: HTML vs Whitespace vs Tags

ejs embeds JavaScript directly inside standard HTML using angle brackets.

  • You write normal HTML and insert logic where needed.
  • Familiar to anyone who knows JavaScript.
<!-- ejs: Standard HTML with JS tags -->
<div>
  <h1><%= title %></h1>
  <% if (showFooter) { %>
    <footer>Copyright 2024</footer>
  <% } %>
</div>

handlebars uses double mustaches for data and blocks for logic.

  • HTML structure remains visible.
  • Logic is restricted to helpers and blocks.
<!-- handlebars: Mustache syntax -->
<div>
  <h1>{{title}}</h1>
  {{#if showFooter}}
    <footer>Copyright 2024</footer>
  {{/if}}
</div>

liquidjs uses single braces for output and percent signs for logic.

  • Designed to be safe for user editing.
  • Clear separation between data and logic.
<!-- liquidjs: Shopify-style syntax -->
<div>
  <h1>{{ title }}</h1>
  {% if showFooter %}
    <footer>Copyright 2024</footer>
  {% endif %}
</div>

nunjucks looks very similar to Liquid but with Jinja2 roots.

  • Uses {% %} for logic and {{ }} for output.
  • Supports powerful filters and extensions.
<!-- nunjucks: Jinja2-style syntax -->
<div>
  <h1>{{ title }}</h1>
  {% if showFooter %}
    <footer>Copyright 2024</footer>
  {% endif %}
</div>

pug removes HTML tags and uses indentation to define structure.

  • No closing tags needed.
  • Drastically reduces file size and typing.
// pug: Whitespace-sensitive syntax
div
  h1= title
  if showFooter
    footer Copyright 2024

⚙️ Logic & Control Flow: JavaScript vs Helpers

ejs allows full JavaScript execution inside templates.

  • You can call functions, loop arrays, and use variables directly.
  • Powerful but risky if users control the template.
// ejs: Full JS logic
<% users.forEach(function(user) { %>
  <li><%= user.name.toUpperCase() %></li>
<% }); %>

handlebars requires helpers for complex logic.

  • You cannot call arbitrary functions in the template.
  • You must register helpers in your JavaScript code.
// handlebars: Helper-based logic
{{#each users}}
  <li>{{toUpperCase this.name}}</li>
{{/each}}

// JS: Register helper
Handlebars.registerHelper('toUpperCase', (str) => str.toUpperCase());

liquidjs provides built-in filters for common transformations.

  • Logic is limited to what the engine allows.
  • Safe for untrusted input.
// liquidjs: Filter-based logic
{% for user in users %}
  <li>{{ user.name | upcase }}</li>
{% endfor %}

nunjucks supports filters and custom extensions.

  • Similar to Liquid but with more flexibility.
  • You can write custom filters in JavaScript.
// nunjucks: Filter-based logic
{% for user in users %}
  <li>{{ user.name | upper }}</li>
{% endfor %}

// JS: Add filter
env.addFilter('upper', (str) => str.toUpperCase());

pug allows JavaScript expressions but restricts statements.

  • You can call functions but not write loops easily without each.
  • Compiles to clean JS functions.
// pug: Expression-based logic
each user in users
  li= user.name.toUpperCase()

🧩 Layouts & Inheritance: Partials vs Blocks

ejs relies on includes rather than true inheritance.

  • You include header and footer files in every page.
  • Can lead to repetition if not managed carefully.
<!-- ejs: Includes -->
<%- include('partials/header') %>
<h1>Page Content</h1>
<%- include('partials/footer') %>

handlebars uses partials for reusable components.

  • You register partials and call them by name.
  • Good for components, less so for full page layouts.
<!-- handlebars: Partials -->
{{> header}}
<h1>Page Content</h1>
{{> footer}}

liquidjs uses sections and renders for layouts.

  • Supports {% layout %} or {% render %} depending on version.
  • Designed for theme development.
<!-- liquidjs: Sections/Render -->
{% render 'header' %}
<h1>Page Content</h1>
{% render 'footer' %}

nunjucks has robust template inheritance with blocks.

  • You define a base template and override blocks.
  • Best-in-class for complex layout hierarchies.
<!-- nunjucks: Inheritance -->
{% extends "base.html" %}
{% block content %}
  <h1>Page Content</h1>
{% endblock %}

pug supports extends and blocks natively.

  • Clean syntax for inheritance.
  • Very popular for layout management in Express apps.
// pug: Inheritance
extends base

block content
  h1 Page Content

🔒 Security & Sandboxing: Safe vs Powerful

ejs executes arbitrary JavaScript code.

  • If a user can edit the template, they can run server code.
  • Never use for user-generated content.
// ejs: Risky if user input reaches template
// <%= user.controlledInput %> could execute scripts if not escaped
// Use <%- %> carefully as it does not escape HTML

handlebars sandboxed by default.

  • No direct access to global objects or functions.
  • Safe for user-edited templates if helpers are controlled.
// handlebars: Safe execution
// Template cannot access process.env or require()
// Only registered helpers are available

liquidjs designed for security first.

  • Used by Shopify for merchant templates.
  • Async support without compromising safety.
// liquidjs: Secure sandbox
// No arbitrary JS execution allowed
// Filters and tags are strictly defined

nunjucks restricts JavaScript execution.

  • Safe for most use cases.
  • Custom extensions must be written carefully.
// nunjucks: Restricted execution
// Templates cannot call arbitrary JS functions
// Security depends on custom filter implementation

pug compiles templates to JavaScript functions.

  • Powerful but dangerous if users edit templates.
  • Vulnerable to XSS if locals are not escaped.
// pug: Compilation risk
// Template compiles to JS function
// User input must be sanitized before passing to render

🤝 Similarities: Shared Ground Between Engines

While the syntax differs, these libraries share core goals and features.

1. 🌐 Server-Side Rendering

  • All generate HTML strings on the server.
  • Improve SEO and initial load performance.
// All packages support similar render methods
// ejs.render(template, data)
// hbs(template, data)
// liquid.parseAndRender(template, data)
// nunjucks.render(template, data)
// pug.renderFile(path, data)

2. 🎨 Data Injection

  • All accept a context object to pass data.
  • Variables are accessible within the template scope.
// Common data passing pattern
const data = { title: 'Home', user: { name: 'Alice' } };
// Each engine maps these keys to template variables

3. 🛠️ Custom Extensions

  • All allow adding custom logic via helpers or filters.
  • Enables reusability across templates.
// Example: Adding a date formatter
// ejs: Use a function in locals
// handlebars: RegisterHelper
// liquidjs: RegisterFilter
// nunjucks: AddFilter
// pug: Use mixins or functions

4. ✅ Async Support

  • Most support asynchronous rendering for data fetching.
  • liquidjs and nunjucks have strong async stories.
// Async rendering example
// await nunjucks.render('page.html', { fetchUser() });
// await liquid.parseAndRender(template, context);

5. 📦 Ecosystem Integration

  • All integrate with Express.js via view engines.
  • Wide community support and plugins available.
// Express setup example
app.set('view engine', 'ejs'); // or hbs, liquid, nunjucks, pug
app.set('views', './views');

📊 Summary: Key Similarities

FeatureShared by All Engines
Core Goal🌐 Generate HTML from data
Data Passing🎨 Context objects / locals
Express Support📦 Built-in view engine integration
Custom Logic🛠️ Helpers, filters, or functions
Async Ready✅ Support asynchronous rendering

🆚 Summary: Key Differences

Featureejs / pughandlebars / liquidjs / nunjucks
Logic⚙️ Full JS or Expressions🚫 Logic-less / Restricted
Syntax📝 HTML tags or Indentation🏷️ Mustache or Liquid tags
Security⚠️ Risky for user templates🔒 Sandboxed / Safe
Inheritance🧩 Includes / Blocks🏗️ Partials / Blocks / Sections
Best Use👨‍💻 Internal apps / Legacy🛒 E-commerce / User templates

💡 The Big Picture

ejs and pug are like power tools 🔨 — they give you full control and speed but require caution. Ideal for internal dashboards, legacy Express apps, or teams that want to write JavaScript everywhere. Avoid them if users can edit templates.

handlebars, liquidjs, and nunjucks are like safety gear 🦺 — they restrict what can be done to prevent accidents. Perfect for SaaS platforms, e-commerce themes, or any app where users customize layouts. nunjucks offers the best inheritance, while liquidjs offers the best security model.

Final Thought: Security should drive your choice. If untrusted users touch templates, pick liquidjs or nunjucks. If it's all internal code, ejs or pug might save you time.

How to Choose: ejs vs handlebars vs liquidjs vs nunjucks vs pug

  • ejs:

    Choose ejs if you want a simple engine that lets you write plain JavaScript inside your templates. It is ideal for legacy Express applications or teams that prefer minimal abstraction over HTML. However, avoid it for user-generated templates because it allows arbitrary code execution. It works well when you need full access to JS utilities without writing custom helpers.

  • handlebars:

    Choose handlebars if you need a logic-less template system with a strong ecosystem of helpers. It is widely used in email templating and static site generators where safety is critical. The syntax is verbose but clear, making it easy for non-developers to read. It requires registering helpers for complex logic, which enforces a clean separation of concerns.

  • liquidjs:

    Choose liquidjs if you need a secure, sandboxed engine compatible with Shopify themes. It is the best option for allowing users to edit templates without risking server security. The syntax is clean and familiar to many frontend developers. It supports async filters and tags, making it suitable for modern data fetching within templates.

  • nunjucks:

    Choose nunjucks if you want powerful template inheritance and macros similar to Python's Jinja2. It is excellent for large applications with complex layout hierarchies. The engine is fast and supports asynchronous rendering. It strikes a balance between flexibility and security by restricting direct JavaScript execution.

  • pug:

    Choose pug if you prefer a whitespace-sensitive syntax that reduces HTML verbosity. It is great for teams that value concise code and don't mind the indentation requirements. However, it compiles to JavaScript functions, so it is not safe for user-edited templates. It works well for internal admin panels or projects where developer speed is prioritized over template safety.

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.