S9 really looks nice - however, it is not self contained in the sense that I was referring to. p_slides is essentially a single HTML file (with the other assets hosted somewhere).
For S9, Ruby and usage of the command line is required. For a developer, that's not a big issue, of course. Myself, I'm a Ruby/JS/Clojure dev, so I do not mind installing one more gem(; However, my goal was to _really_ make p_slides self-contained. There is no need to install anything, run any pre-compiler or run the slide within a web-server. It doesn't even use npm or bower to install the assets. With this methodology, p_slides certainly is technologically less complex (or interesting^^), but it continues to work after years without any change on any computer that has a browser. That's just not happening with Ruby or Node or any other dependency. I'm not saying the latter is bad (it is not at all!), I'm saying this simplicity ability to be completely self-contained with no tooling required was the specific design decision for p_slides and it served me and a couple lecturers well. I basically made no advertisement for it, I just wrote it, because I wanted something that just works and I can distribute to students, too.
* reveal-js is _much_ bigger whereas p_slides relies on well tested and established software. For example many features that you can find on the reveal-js README are also included in p_slides, because it uses W3Org slidy-js[1]. p_slides actually is only very little code itself as it glues together very well established and good existing libraries. reveal-js does a lot by itself. Both options are valid, yet they are different(;
1. https://www.w3.org/Talks/Tools/Slidy2/#(1)