2. If you can’t run. Dance.
So this chapter is about building a “real” application, as I understand. A job board called nitroBoard. That sounds good.
The difference between slim and non slim versions, slim ones do not include ERTS. It’s related to slim release. Didn’t knew that.
So the specs are clear, I need two pages. One for lobby display, one for visitor appointments.
I was wondering, for dev purpose if Nitrogen was able to do some hot reload, it can! In the bin/nitrogen console shell, I just need to type sync:go(). to get automatic reload. I got a big chunk of lines in the console which tells me that the process is running.
Let’s open index.erl under nb/site/src, it’s a plain old Erlang module.
So is it what you called Erlang records ?
These [#h1 {text="Welcome to Nitrogen},] stuff ?
With some modifications, a bit verbose I’d argue, you can do nice stuff. It really makes me feel like Elm, even if Nitrogen is older 
As far as I get through the book, it explains what is an arity, what is a module and thus, I reckon it doesn’t expect a particular knowledge of Erlang.
Ah page 34, the rendering is explained, it goes throught these steps:
- User hits a URL
- URL is mapped to a module
- Nitrogen calls
module:main
module:mail() typically returns a #template{} element- The
#template{} is sent to Nitrogen’s rendering engine
- The template includes raw HTML mixed with callouts back into the page module ( in the form of
[[[page:some_function()]]]
- Those functions return other Nitrogen elements
- Those elements are also run through Nitrogen’s rendering engine, converting all elements into HTML and JS
- This process continues until all elements have been converted
- Nitrogen sends the rendered output to the browser
I quote the book
Lists are big business in Erlang.
The routing is handled by naming.
Root page is mapped to index.erl inside src.
Nitrogen replaces / with _.
routes/to/a/module becomes routes_to_a_module
Well, as you said @OvermindDL1, a Nitrogen element is no more than an Erlang record that renders HTML.
So, when compiled a record is just a plain vanilla Erlang tuple. But the record definition provides the compiler with enough information to enable the programmer to address fields in the tuple by name.
By the authors themselves, using an Erlang records to solve this problem is a hack.
#label { text="Hello world" } is <label> Hello world </label>
Nitrogen provides basic properties like id, actions, show_if`, etc.
Well that’s all for today folks! 
typo. And I’m moving so the book is already in a box. Thanks.
