Nodejs/npm dependency

[curioussavage]

Cool project! It was fun to learn I have a fellow Nim enthusiast nearby!

Any thoughts about dropping the node dependency? It looks like it's used for:

• building a small amount of SASS
• getting 3 JS deps (network, dom stuff, and highlight) and bundling them.

Usage of both the JS and SASS is minimal so it would be pretty easy to remove them with CSS (or use the nim sass compiler package) and Nim compiled to JS (with a version of the highlight js just included in the repo or linking to a CDN).

[jasonprogrammer]

Glad you like the project! One thing I was hoping to do eventually was to provide pre-built binaries that could be used to scaffold and serve a site without writing much/any Nim back-end code. Since JS is ubiquitous on the front-end, using Nim -> JS/CSS could complicate things for that use-case (since any consumers would pretty much have to use Nim to customize the look and feel of their site). I wonder if there's a good way to provide a plugin layer of sorts, so that the base library could remain mostly front-end agnostic.

[curioussavage]

Avoiding nim plugins seems hard. Comments in particular seem really tied in to the nim code so I don't see how you would be able to allow any meaningful customization there without nim. But just because the sass compiler is a nim module doesn't mean they need to know nim to modify their styles. Same for the JS, the cli could just dump the generated JS files compiled from Nim into their project where they could modify them. Though modifying the comments JS seems pointless unless they are picky about some small details. Can't really modify the flow without modifying nim.

The syntax highlighting seems like it could easily be a "plugin" as in a user can just download highlightjs stick it in an "assets" dir to be served and then modify a code block in the base template (or base blog template) to initialize the lib. That might even be preferred since they can then easily enable highlighting for languages they want. Right now you would either need to generate that JS file so they customize it or just include all the langs it supports.

[jasonprogrammer]

The commenting endpoints are already contained in their own routes, so the commenting back-end can be replaced pretty easily by not using the existing routes. If the commenting system, both back-end and front-end, wasn't a part of the base Gerbil library, but was rather an optional piece (plugin), then maybe it could be more easily swapped for a commenting system written in a different way. As far as the front-end commenting pieces, you don't have to use Node with the project; you can replace the front-end code with whatever you prefer. The web directory is expected to be changed (even drastically) by the consumer. I'm not looking to rewrite the existing front-end pieces in favor of Nim compilation though, as I prefer writing front-end pieces in JavaScript.

As far as the syntax highlighting, while it is true that it could easily be swapped out for CDN-sourced JavaScript, I don't personally want to source my JavaScript from servers I don't control. It has privacy implications for people visiting my site, isn't great for testing locally without an internet connection, the files can be removed without any notification, CDNs can have down-time, and they also sometimes block consumption based on geographic region and other criteria.