Nitrogen Web Framework - have you used it?

If so, where/how and what do you like about it? :003:

Nitrogen Web Framework is the fastest way to develop interactive web applications in full-stack Erlang.

1 Like

I sure have, for tasks ranging from straight CRUD applications to a UI for SaltStack. Mostly, these days, I aggregate data and do a lot of ETL work. (I cannot stress enough how big a win Erlang’s concurrency is for transformations!)

I picked Nitrogen because:

  • It’s possible to have a rich interactive UI without touching Javascript at all. There is nothing about programming JS that I enjoy.

  • Nitrogen is agnostic with regards to the model – in other words, it’s possible to use whatever backends and libraries are appropriate without fighting the framework. For instance, I almost always prefer hand crafted SQL to an ORM library like Ecto.

  • Emphasis is on code and not configuration (or – gasp – convention). This translates into (maybe) more code but also a lot less “magic” than I’ve encountered with other frameworks.

I emphasize these points in part because I don’t really write “web applications.” Almost all the work I do involves teeing up data for use by other applications and, honestly, most of it could be done without a web component at all. However, it’s 2021 and my users expect a web UI. I usually start with a DB schema, some SQL, maybe a few REST calls, and some bespoke transformations. Once that’s working via the REPL, tacking on the UI with Nitrogen is a couple of page modules and ErlyDTL templates.

I’ve been using Nitrogen long enough that I have a reusable libraries providing user and group management, authorizations, AD integration, auditing, PostgreSQL interactions, and so on. Once the business process is defined and implemented, the infrastructure-y bits are trivial.

In conclusion: most of my effort should be data modeling and writing the appropriate SQL. If I’m spending time trying to figure out how to update an HTML element with JS, that’s not actually getting the work I’m being paid for done.

I’m really interested in hearing other use cases.


I sure have! (I’m the project lead for it, so I’d hope so)

@bunny pretty much covered most of why I like it.

I’ve been using Nitrogen full time for about 10 years now, my primary use is for a web application for running sports leagues and tournaments that a few years back was acquired by SportsEngine/NBC Sports, but I have a handful of various contract projects built with it over the years, ranging from in-house Dropbox clones, to Truck scheduling to Telemedicine.

For those who have beef with Nitrogen not having an ORM, I have a light SQL-based framework called sql_bridge that has some very light ORM tools and is largely designed to run with Nitrogen.

Erlang really is a criminally underused language for front-end development.


I have made things deployed with nitrogen/n2o, it was fantastic for making a client-sided-feeling app driven from the server (think Phoenix’s Live pages thing now, but a bit more powerful and lower level), and this was even back in the days when something like GMail was a ‘new thing’. ^.^


That is so bizarre. I have been (slowly) working on the same thing, also in Nitrogen. Had no idea that parts of SportsEngine were running Erlang/Nitrogen.


Whoa! That’s nuts. The core SportsEngine product is obviously not in Nitrogen, but my small product that specializes in beach volleyball leagues and tournaments ( is.

I realize I’m the competition, but honestly, unless you’re specifically targeting the beach volleyball space, I don’t see it as that.

I’m curious if you’ve got an early beta (or if you’d rather fly under the radar, that’s fine too - I also I tried my best to fly under the radar for a bunch of years), I’d love to see it.

If you’d rather discuss this privately as well, feel free to hit me up on the Erlang slack or discord (I’m “chops” on there both). That’s fascinating to me that such a niche framework on a niche language would attract two products in the same market.


Feel very much the same as @bunny. I tend to build applications in SQL first. Relational databases are IMO the appropriate choice for a general-purpose data store about 90% of the time. I use a lot of stored procedures. Once I have my DB schema and stored procedures implementing all the functionality, then I build the UI on top of that. I don’t use ORMs. I have found building a web UI for my database to be very straightforward using Nitrogen (and I consider myself far from an Erlang expert – I like Erlang but have not used it regularly enough to become really fluent in it). One of my first managers used to say “get the data model right and the application writes itself” and over the past 30 years in IT and software development I have found that to be almost always true. What I like about Nitrogen is that it doesn’t force you into any particular backend model so it works well with this approach.