DEV Community: Damian Kajzer

I built SSR in NGINX using njs. Here’s what I learned

Damian Kajzer — Thu, 09 Apr 2026 07:45:30 +0000

I built a minimal SSR runtime directly inside NGINX — and ended up using it in production.

For some time, I’ve been using NGINX with njs for things like CSP nonce generation and request-level logic.

This started as an extension of something I was already using in production (CSP handling in NGINX).

At some point I asked myself a simple question:

can this go a bit further?

This started as a small experiment — but it ended up running in production on my personal website.

What I built

👉 https://github.com/kraftdorian/nginx-njs-ssr-starter

A minimal SSR-like runtime using:

NGINX
njs (JavaScript inside NGINX)
simple component rendering patterns

No Node.js. No Next.js. Just NGINX.

The runtime is intentionally small and explicit — closer to a rendering utility than a framework.

How it works (high-level)

Instead of:

Client → Node SSR → HTML

I explored:

Client → NGINX (njs) → HTML

The idea is simple:

execute JavaScript during request handling (via njs)
generate HTML on the fly
return it directly from NGINX

In practice, this is a string-first rendering model — HTML is built directly as strings using small helper functions, without a virtual DOM or template engine.

What I learned

1. I underestimated how far NGINX can go

Before this, I treated NGINX mainly as:

a reverse proxy
a place for headers and routing

Working with njs changed that for me.

I learned that it can also:

execute request-level logic
generate dynamic responses
act as a very lightweight rendering layer

It’s constrained — but that constraint is actually part of the value.

2. SSR became much simpler once I stripped it down

While building this, I kept coming back to a simple realization:

SSR is just returning HTML from the server.

Everything else is layered on top.

This project helped me separate:

what SSR actually is
how we usually implement it

That distinction alone made the whole topic much clearer for me.

3. Constraints shape the system more than features

This project is intentionally limited:

synchronous rendering only
no external I/O
no hidden state
deterministic output

At first this felt restrictive.

In practice, it made the system:

easier to reason about
easier to debug
more predictable

I learned that removing capabilities can improve clarity more than adding abstractions.

4. The trade-offs are very different from typical SSR setups

What I gained:

no Node.js runtime
very fast execution path
minimal moving parts

What I lost:

full JavaScript runtime
ecosystem and tooling
familiar debugging patterns

This shifted my thinking from “application-level design” to something closer to “infra-level design”.

5. Rendering inside the infrastructure layer changes how concerns fit together

One thing that stood out was how naturally this integrates with:

CSP
headers
request validation

Because everything happens inside NGINX, these concerns don’t need to be split across layers.

That made the system feel more cohesive than I expected.

6. I learned how to coordinate between different types of AI tools

An unexpected part of this project was the development workflow itself.

I ended up coordinating between:

a text-oriented model (ChatGPT) — for reasoning, structure, and constraints
a code-oriented agent (Codex) — for implementation

The runtime itself was implemented with Codex, but always under explicit architectural constraints and iteration from my side.

In practice, this meant:

defining the shape of the system first
using Codex to fill in implementation details
validating everything against real runtime behavior

This separation turned out to be much more effective than trying to generate everything in one step.

When this approach makes sense (from my perspective)

I would consider it for:

small or mostly static sites
simple rendering layers
cases where control over HTML and security matters
infra-level experiments

I wouldn’t use it for:

complex frontend applications
heavy interactivity
teams relying on a large ecosystem

Setup (very simple)

If you’ve configured NGINX before, this should feel familiar.

This is intentionally close to a production-like setup.

Basic steps:

Install NGINX with njs
Clone the repository
Load the configuration
Run

Full instructions:
👉 https://github.com/kraftdorian/nginx-njs-ssr-starter

Final thoughts

This started as a small extension of something I was already using (CSP handling in NGINX).

It turned into a useful way to better understand:

how far rendering can be pushed into infrastructure
how constraints shape system design
what we actually need from SSR in practice

Building it — and running it in production on my own site — made those trade-offs much more concrete.

It also changed how I think about where frontend actually ends — and where infrastructure begins.

Sometimes removing layers teaches more than adding new ones.

Configuring CSP nonce for nginx 1.28 on Ubuntu 24 LTS using NJS

Damian Kajzer — Mon, 29 Dec 2025 17:12:33 +0000

Content Security Policy

CSP is a way to tell a browser that only the provided locations and/or resources should be loaded.

Learn more about CSP on OWASP.

Nonce

It is an expression of CSP's header fetch directive. Essentially, it's a way to tell the browser to only load styles and scripts that are having nonce HTML attribute's value matching whatever is present in the CSP's header.

Learn more about CSP's nonce expression syntax on MDN.

Example nonce configuration

Server responds with headers:
...
Content-Security-Policy: script-src 'self' 'nonce-foo';
...

HTML page:
...
<script nonce="foo">console.log('safe');</script> <!-- safe, foo === foo  -->
<script nonce="bar">console.log('unsafe');</script> <!-- unsafe, foo !== bar -->
<script>console.log('unsafe');</script> <!-- unsafe, no nonce value -->
...

Nginx

Nginx is an opinionated HTTP web server, which we'll be using for educational purposes of this article.

NJS

NJS (Nginx JavaScript) is a dynamic module of nginx that allows its advanced configuration via JavaScript-like sources.

It exposes useful APIs, such as Crypto.

The process

1. Adding nginx official repo to apt sources

Please follow nginx's linux packages instructions.

2. Installing nginx-module-njs

Since we're now having nginx's repo in apt sources - let's install njs as dynamic nginx module:

sudo apt install nginx-module-njs

3. Configuration of nginx to load njs module

We need to load the module in nginx.conf:

# /etc/nginx/nginx.conf
+ load_module modules/ngx_http_js_module.so;
+ load_module modules/ngx_stream_js_module.so;
http {
+  js_path "/etc/nginx/njs/";
...

Also, it would be nice to either allow passing secret key for nonce generation via docker's container env variable, or set it explicitly:

# /etc/nginx/nginx.conf
+ env NONCE_SECRET_KEY;
load_module modules/ngx_http_js_module.so;
load_module modules/ngx_stream_js_module.so;

4. Writing NJS script to generate nonce values

This is an example of NJS script that leverages nginx's request_id variable to create SHA1 HMAC hex string:

// /etc/nginx/njs/nonce.njs

import crypto from 'crypto';

function nonce(r) {
  const h = crypto.createHmac('sha1', process.env.NONCE_SECRET_KEY);
  h.update(r.variables.request_id);
  return h.digest("hex");
}

export default { nonce };

5. Setting CSP header using NJS

Now, whenever we need to apply the CSP header:

# /etc/nginx/nginx.conf, /etc/nginx/sites-available/yoursite, ...
...
+ js_import main from nonce.njs;
+ js_set $csp_nonce main.nonce;
+ add_header Content-Security-Policy "script-src 'self' 'nonce-$csp_nonce'";
...

Let's reload nginx configuration:

sudo service nginx reload

At this point we should see the header being set correctly in the response.

6. Setting nonce in HTML pages (OPTIONAL)

Since we're now having the csp_nonce variable in place, produced by NJS, let's use it in nginx's sub_filter directive:

# /etc/nginx/nginx.conf, /etc/nginx/sites-available/yoursite, ...
...
+ sub_filter_once off;
+ sub_filter CSP_NONCE $csp_nonce;
...

Let's reload nginx configuration:

sudo service nginx reload

Now, in HTML page we can reference it like this:

<script nonce="CSP_NONCE">console.log('nonce works!');</script>

Summary

We have successfully configured Content Security Policy header in nginx, using nginx JavaScript dynamic module.

Further enhancements and/or adjustments can be made to meet our particular needs.

Cover image

Cover image was generated using AI.

Creating React TypeScript component library - Testing with Jest, Summary

Damian Kajzer — Sun, 01 Aug 2021 22:03:27 +0000

Doin' it Right

To be sure that our component(s) work as expected, we can test them with the Jest and React Testing Library.

I used these references for purposes of this article:

Firstly, we need to install these libraries, obviously:

npm i --save-dev jest ts-jest @types/jest @testing-library/react

Then, we must add the Jest types to tsconfig.json:

"types": ["jest"]

Finally, if we want, we can use the Jest configuration tool.
If the first command doesn't work, you can use the second one:

jest --init
npx jest --init

It will ask you a few questions:

Done! It created a lot of config options for us, but these ones will suffice for our purposes:

// @/jest.config.js
module.exports = {
  moduleDirectories: [
    "node_modules",
    "src"
  ],
  moduleFileExtensions: [
    "js",
    "ts",
    "tsx",
    "json",
    "node"
  ],
  roots: [
    "src"
  ],
  testEnvironment: "jest-environment-jsdom",  // Use browser-like testing environment
  testMatch: [
    "**/__tests__/**/*.[jt]s?(x)",
    "**/?(*.)+(spec|test).[tj]s?(x)"
  ],
  testPathIgnorePatterns: [
    "\\\\node_modules\\\\"
  ],
  transform: {
    "^.+\\.(ts|tsx)$": "ts-jest"  // That one tells Jest to use ts-jest when dealing with TypeScript files
  }
};

Around the World (or the Project?)

If we want to be able to access our basic setup of React Testing Library easily, we can make use of TypeScript paths configuration in tsconfig.json:

"baseUrl": "src",
"paths": {
  "test-setup": ["test-setup"]
}

In a separate file, we create a custom render method that can include any stuff we need - store and theme providers, and more, to be used globally in our tests.

// @/src/test-setup.tsx
import React, { FC, ReactElement } from 'react';
import { render, RenderOptions } from '@testing-library/react';

// Here we can set all providers for themes, stores and other stuff
const AllTheProviders: FC = ({ children }) => {
  return <div>{children}</div>;
};

const customRender = (
  ui: ReactElement,
  options?: Omit<RenderOptions, 'wrapper'>
) => render(ui, { wrapper: AllTheProviders, ...options });

export * from '@testing-library/react';
export { customRender as render };

Voyager (through the component logic)

As we have completed the configuration, we can write a test for the Component:

// @/src/index.test.tsx
import React from 'react';
import { render } from 'test-setup';

import { Basic as Component } from './index.stories';

describe('Component', () => {
  it('renders without crashing', () => {
    const component = render(<Component />);
    expect(component).toBeTruthy();
  });
});

Now, run test command:

npm run test

If everything is good, then that's what should appear:

Summary

This article concludes the "Creating React TypeScript component library with rollup.js from scratch" series.

There are still a lot of things that could be made in our awesome component library, such as:

installing Styled Components,
adding husky/yorkie with precommit git hook that uses lint-staged to format changed source files with prettier,
exploring how we can publish our library to npm.

However, I believe, now as we have our basic project, it's not a challenge for you.

You can find the finished repository here, in case of any doubts:

kraftdorian / react-ts-rollup-starter-lib

React TypeScript components library built with rollup.js from scratch.

Component library starter template

Used libraries

Notes

This is a repository created for learning purposes, specifically to use one of my articles which you can find here.

View on GitHub

Thanks for reading!

Article cover photo by Michael Dziedzic on Unsplash

Creating React TypeScript component library - Adding React and Storybook

Damian Kajzer — Fri, 23 Jul 2021 22:31:48 +0000

The Core of the library

This article deals with the installation of React and explains npm peer dependencies.
In the end, we will be able to see our component in a browser.

Superheroes (React and friends)

This part is very easy. Just install React, React DOM, and types.

npm i --save-dev react react-dom @types/react

Now, we need to add react and react-dom to package.json peerDependencies. Why?
I recommend reading this great article that can be found on the npm blog: https://nodejs.org/en/blog/npm/peer-dependencies

It's just all about the fact, that we create some independent package:

What we need is a way of expressing these "dependencies" between plugins and their host package.

—Domenic Denicola, Peer Dependencies

So, you can add this above you devDependencies:

"peerDependencies": {
  "react": ">=16.8.0",
  "react-dom": ">=16.8.0"
},

Why 16.8.0? React Hooks were added in that version! :-)

Do you remember rollup-plugin-peer-deps-external dependency we added before? It automatically excludes peer dependencies that we just set from the bundle.

In case you missed that part or want to recall it, you can find it in my previous article:

Damian Kajzer

Jul 20 '21

Creating React TypeScript component library - basic rollup.js setup

#typescript #react #library #rollupjs

Comments

4 min read

Next, as we have properly installed React, we can update our rollup.config.js, and change the index file extension:

- input: ["src/index.ts"]
+ input: ["src/index.tsx"]

Finally, we can update our component to use JSX:

// @/src/index.tsx
import React from "react";

const Component: React.FC<{}> = ({ children }) => {
  return <div>{children}</div>
};

export default Component;

You can also view these changes in my GitHub repo.

Face to Face (of our component)

Now, how we are able to see our component in action?
Browsing many solutions available, a nice choice is to use the Storybook.
It's a great tool for UI development, so it's perfect for our case.

To install it, just run:

npx sb init

If it asks for permission to install sb package then it's fine, you can just confirm that.
This will create src/stories directory with some examples, you can delete them.
Also, you will find some new scripts in package.json.

Let's go ahead and create a story for our component!

// @/src/index.stories.tsx
import React, {PropsWithChildren} from 'react';
import { Meta, Story } from '@storybook/react';
import Component from "./index";

// This is meta information about our component
const meta: Meta<PropsWithChildren<{}>> = {
  title: 'My Component',  // What title to display in component story page
  component: Component,  // This one is obvious :-)
  argTypes: {  // Here we can specify configuration for our component's props
    children: {
      description: 'Content or elements to be rendered inside the Component',
      control: {
        type: 'text',
      },
    },
  },
};

// Create one template for our component's story to use in some custom variants
const Template: Story<PropsWithChildren<{}>> = (args) => <Component {...args} />;

// Basic variant of our component
const Basic = Template.bind({});
Basic.args = {
  children: 'Component',
};

export default meta;
export { Basic };

... And, that's it!

Now, to run Storybook in watch mode, run:

npm run storybook

This should open your browser at localhost with a 6006 default port.

You can also view these changes in my GitHub repo.

In any case, that's it for this article.
Thanks for reading!

Photo by Michael Dziedzic on Unsplash

Creating React TypeScript component library - basic rollup.js setup

Damian Kajzer — Tue, 20 Jul 2021 10:00:02 +0000

Intro

I have worked on several custom front-end projects and often thought about using the same styles and/or components, so other developers could use consistent UI.

Too long I was afraid of creating a separate library, so usually, I was ending up including the components directly in the project files.

That's not the case here!

What is it about?

This is the first article I have created in a series "Creating React TypeScript component library with rollup.js from scratch".
Hopefully, the title explains the article's contents.

It's all about configuration and installing proper libraries. I won't give it too much attention, just quickly explain what is necessary and why.

If you want to see the whole code as it is at the end of this tutorial, just feel free to visit this repo at my GitHub account.
Also, give it a star if you want!

Important note

This article is based on these sources:

A few words about the versions

As I am writing this article I'm using:

node v14.17.0
npm v6.14.10

Let's start!

Armory

Obviously, we need some new directory for our library:

mkdir my-ui-library
cd my-ui-library

Then, we initialize it (you will be prompted to type some stuff. If you don't want to be that specific, then you can use default values by constantly pressing ENTER):

npm init

In the end, make sure you set this file as your main script in package.json (it doesn't exist now, but we will build it!):

"main": "dist/index.js"

2021-11-24 UPDATE - TypeScript compiler only

If you want to use TypeScript compiler only, please have a look at this rollup.config.js instead, as well as the updated package.json.

Don't forget to create tsconfig.json as well.

Then, feel free to jump straight to the Finale section.

More details about the original issue are available here.

Arrival (of dev dependencies!) - compile with babel (legacy section)

We will compile our TypeScript components with Babel.
Types will be generated with TypeScript's compiler.

It's important to save these deps in dev dependencies - the project where we will put our library doesn't need to have them!

npm i --save-dev rollup rollup-plugin-peer-deps-external @rollup/plugin-node-resolve @rollup/plugin-babel @babel/core @babel/preset-env @babel/preset-react @babel/preset-typescript @babel/plugin-transform-runtime @babel/runtime @babel/plugin-proposal-class-properties typescript tslib rimraf

The Grid (where we will work)

How we are able to build our library? Just specify the build script:

"build": "rimraf dist && tsc --emitDeclarationOnly && rollup --config",
"tsc": "tsc"

If you're stuck here, feel free to check this package.json.

At this point, we need to somehow run tsc to initialize our TypeScript config. If for some reason tsc is not available for you, try adding it to package.json scripts.

npm run tsc -- --init

We don't need all the config options that tsc has created.
You can go ahead and grab the ones I prepared in this tsconfig.json.
You can read more about tsconfig here.

The important thing above is, we want to include our TypeScript files, but exclude node_modules and our built files directory.

"include": [
  "src/**/*.ts",
  "src/**/*.tsx"
],
"exclude": [
  "node_modules",
  "dist"
]

As for Babel, we need to configure it in the babel.config.json file:

{
  "presets": [
    "@babel/preset-env",
    "@babel/preset-typescript",
    "@babel/preset-react"
  ],
  "plugins": [
    "@babel/proposal-class-properties",
    "@babel/proposal-object-rest-spread"
  ]
}

Arena (rollup.js vs TypeScript)

Simply place this configuration in your rollup.config.js at the project root:

import babel from "@rollup/plugin-babel";
import resolve from "@rollup/plugin-node-resolve";
import peerDepsExternal from 'rollup-plugin-peer-deps-external';
import pkg from "./package.json";

// Array of extensions to be handled by babel
const EXTENSIONS = [".ts", ".tsx"];

// Excluded dependencies - dev dependencies
const EXTERNAL = Object.keys(pkg.devDependencies);

export default {
  input: ["src/index.ts"],  // What files we build?
  output: {
    dir: "dist",  // Directory where rollup.js will put the built files
    sourcemap: true,  // We want a source map to trace the original code
    format: "esm",  // Built files will follow ES Module format
    preserveModules: true  // This one is important for treeshaking features of our library
  },
  plugins: [
    peerDepsExternal(),  // https://rollupjs.org/guide/en/#peer-dependencies
    resolve(),  // Resolves node modules
    babel({
      extensions: EXTENSIONS,  // Compile our TypeScript files
      babelHelpers: "runtime",  // EDIT(2021-11-18): "inline" is not recommended. Please see the details in https://github.com/kraftdorian/react-ts-rollup-starter-lib/issues/1
      include: EXTENSIONS.map(ext => `src/**/*${ext}`),
      plugins: ["@babel/plugin-transform-runtime"]
    })
  ],
  external: EXTERNAL  // https://rollupjs.org/guide/en/#peer-dependencies
};

Next, create some simple TypeScript file:

// @/src/index.ts

const Component = () => {};

export default Component;

Finale

Congrats, you've made it to this place!
Now, simply run this npm script:

npm run build

If everything is good, you will see:

These files will appear in the dist directory:

Summary

We have just created a basic project that allows us to compile TypeScript to JavaScript with Babel, and the types are generated by the TypeScript compiler.

For further reference, all files I have presented here you can find in my repository:
https://github.com/kraftdorian/react-ts-rollup-starter-lib/tree/1.1.0

2021-11-18 UPDATE

Changed

Use "runtime" instead of "inline" in rollup.config.js as the "inline" helpers are not recommended. Please visit https://github.com/kraftdorian/react-ts-rollup-starter-lib/issues/1 for more details.

Article cover photo: https://unsplash.com/photos/-LFxVNhopfs

Thoughts on expression matching in JavaScript

Damian Kajzer — Tue, 04 May 2021 17:00:35 +0000

Context

Just one word - curiosity. It stays with me through the whole learning process of programming.

When I met Erlang's built-in mechanism of expression matching I couldn't stay inert and immediately started comparing it to what I know in JavaScript.

What does JavaScript offer

Let's consider these examples when it comes to matching some expressions.

Example 1 - if

What are we doing here is we describe how our expected value should look like, not to provide something to match.

For me, it also lacks readability because conditions are mostly used to express the logic and perform various value checks, not to directly deal with the data.

const response = {data: 'foo'};
if (response === true) {}
else if (response === 1) {}
else if (response.data === 'foo') {}
else if (conditionN) {}
// ...
else {}

Example 2 - switch/true

Similar to the conditions listed above we still describe the value we want to match.
However, for me, it is more readable.

const response = {data: 'foo'};
switch(true) {
  case response === 1: break;
  case response.data === 'foo': break;
  case conditionN: break;
  // ...
  case true: break;
}

Example 3 - switch

Here, things start to get more interesting.

const response = {data: 'foo'};
switch(response) {
  case {data: 'foo'}:
    console.log('matched!');
    break;
}

This won't work because of the way JavaScript compares the values.
I don't want to list all scenarios below, but you can learn more here.

{data: 'foo'} === {data: 'foo'} // false
{data: 'foo'} == {data: 'foo'} // false
Object.is({data: 'foo'}, {data: 'foo'}) // false
Object.is(response, response) // true

Example 4 - RegExp

Let's give it a try. It's the closest solution I can think of in terms of expression matching.

const response = {data: "foo"};
/^{"data":(.+)}$/.exec(JSON.stringify(response)); // ["{"data":"foo"}", ""foo"", ...

It's nice but has some cons. How about a tailored solution?

What does Erlang offer?

Let's just have a look at this code.

Response = {{data, "foo"}}.
case Response of
  {{data, "foo"}} -> io:fwrite("matched!");
  {{data, Data}} -> io:fwrite("matched ~p!", [Data]);
  1 -> io:fwrite("1");
  _ -> io:fwrite("default match")
end.
% matched!

We don't even know some values in the match expression but Erlang is still able to find them.

Experimenting with JavaScript implementation

After a couple of days where I couldn't write anything worth sharing, I have some POC, that you can find here.

const response = {
  status: false,
  message: "Error",
  some_dynamic_key: null
};
const template = {
  status: "<<expr@Status>>",
  message: "<<expr@Message>>",
  ["<<expr@DynamicKey>>"]: "<<expr@DynamicKeyValue>>"
};
const result = match_val(response, template);

console.log(result); // [true, [false, 'Error', 'some_dynamic_key', null]]

Summary

Overall, I think that an expression matching mechanism in JavaScript would be nice to have for specific use-cases as we have in functional programming.

Also, it's always nice to learn new things and how they could have been implemented.

Article cover photo by Michael Dziedzic

Prolog-ic JavaScript

Damian Kajzer — Tue, 06 Apr 2021 13:54:28 +0000

Firstly, a context

Recently, I've started learning programming languages present in amazing Seven Languages in Seven Weeks book by Bruce Tate.

I discovered a very special one - Prolog - as it is a declarative language.

It means, that the programmer does not provide ready implementation, but gives instructions on how to solve the problem and Prolog tries to figure it out.

How does it apply to imperative JavaScript?

A typical Prolog use cases are things like processing the natural language, specific expert systems, and even AI.
We use various JavaScript and TypeScript frameworks to specify how an application works and looks like.

So, what do these have in common?
We need to know, what we are trying to achieve.

Prolog is just giving us a lesson on how to ask questions efficiently, not to answer them.

A practical example

My very first thoughts of writing Prolog-based JavaScript algorithms appeared as a result of curiosity.
How do you even translate facts and rules to something that works for JS?

Let's have a look at an example - how list reverse algorithm written in Prolog is similar to a JavaScript one.

Making the question

When we are asking Prolog for a solution, we need to think about what the definition of the reversed list might look like.

One of the most used ideas when you are dealing with lists there
is to use the idea of accumulator - something, that will store the things we already know.

So, our first fact would be that reversing an empty list will result in.. empty list.

However, when we will deal with non-empty lists - we don't know their size.
In such scenarios, recursion is the way to process them.

Therefore, the refined first fact will be that reversing an empty list will result in some list and accumulator will be the same list.

list_reverse_state([], List, List).

The next step is to actually define our expectations for non-empty lists.
It's important to know here that Prolog uses tail recursion, so things can look confusing and out of order, but they actually work.
It sometimes takes a while to understand it, so I placed appropriate comments in the code.

Now we describe a rule, that the current list element needs to be placed before the accumulator (remember when I wrote - the things we already know?), as the original list is slowly going to be emptied.

list_reverse_state([Head|Tail], OutputList, ListStack) :-
  list_reverse_state(Tail, OutputList, [Head|ListStack]).

When it will become empty, the first fact will be met so the output will be the same as the accumulator.

... and that's it for Prolog!

list_reverse_state([], List, List).
list_reverse_state([Head|Tail], OutputList, ListStack) :-
  list_reverse_state(Tail, OutputList, [Head|ListStack]).

Translation to JavaScript

When we review our final question to Prolog above, the things are getting clear - we exactly know what we want to do.

It was a great experience for me, figuring out that the only work needed to be done in JS was to follow the same behavior as described in our question.

It can be actually simplified because the second argument is not needed at all, added it just to show the similarities.

const usePrologStyleList = (array) => {
  const [head, ...tail] = array;
  return [head, tail];
};

const listReverseState = (list, reversedList, acc) => {
  const [head, tail] = usePrologStyleList(list);

  // list_reverse_state([], List, List).
  if (head === undefined) {
    return reversedList = acc;
  }

  // (...) :- list_reverse_state(Tail, OutputList, [Head|ListStack])
  return listReverseState(tail, reversedList, [head].concat(acc));
};

const listReverse = (list) => listReverseState(list, [], []);

Summary

Hopefully, you will discover how appropriate problem descriptions written in declarative language can boost your imperative language skills.