Ivy looks great. That said, every time I see a new SSG in Python, I get all excited about it for a minute. Then I remember this bit of advice: "Just use Jekyll".
> Jekyll is not better than the rest for any fundamental design reason; it’s better because it’s enormously popular and therefore excels in the long tail of details.
> ...
> If, like me, you secretly believe that everything is better if it’s written in Python, I still suggest you start with Jekyll (which is done in Ruby). In my experience, using Jekyll does not require writing or reading a single line of Ruby.
Agree. I haven't tried many alternatives, but had a need for a quick website recently and Hugo was exceedingly easy to use and has a lot of nice looking themes.
OK - Serious questions for things I've done in Pelican:
1. Can I get Jekyll to use Org files without writing any Ruby code?
2. Can I get Jekyll to handle math using MathJax without writing any Ruby code?
3. Can I get a "next article for a given tag" in Jekyll without writing any Ruby code? (What I essentially need: A post usually has "next" and "previous" article links. I want a "next" and "previous" article for every tag the post is tagged with).
Not at home so I can't see what other custom code/plugins I use, but this is a good list to begin with.
I'm a very novice user, so I don't know the answer to your (1) or (3). I'm fairly certain that I've done (2) though. IIRC the main trick was switching to the Kramdown parser, as recommended here: https://jekyllrb.com/docs/extras/
It requires writing a plugin for Pelican too, but I was a little irritated with the claim that Jekyll will do whatever you want without needing to write Ruby.
It's a little funny that the major caveat written in the linked post is the unqualified terribleness of Jekyll's template engine if the benefit of Jekyll is that you only need to work with templates and not Ruby code
It can be difficult to extend/modify the SSG in case you don't know the language. So I would still recommend picking one based on the language you're most at home with.
For a minimalist static site generator, I think it's hard to beat just writing your own that does exactly what you want and nothing else. In a hundred lines or less of Python, you can have your minimal generator, know exactly how it works and how to extend it, and be able to refresh your memory on conventions/configuration with thirty seconds of scrolling through the source.
I've found that for static html it's easiest to put all the files into one directory, manually create an index file, and copy a five-line Makefile into the directory that compiles everything to html using Pandoc. I wasted too much time using something written the way others wanted it. When I wanted to change something, I'd be digging through bad documentation (if it was documented at all). I'd have to remember a gazillion different configuration options. Sometimes automation makes things worse, because you'll never use most of the options, yet they get in your way, and it's at best just good enough, never the way you want.
Mine is exactly 46 lines long. Most of these crappy site generators are anywhere from 20000 to 300000 lines.
It takes longer to read the introduction to most static site generators than it takes to read and understand a proper minimal static site generator's source.
mysite/
site.py # site configuration file
ext/ # extensions directory for plugins
inc/ # includes directory for menus, etc.
lib/ # library directory for themes
out/ # output directory for html files
res/ # resources directory for static assets
src/ # source directory for text files
Isn't this way too messy?
What are the advantages of this over the other 1000000 static site generators?
It's really only problematic if you want businesses to use it. They don't just want the right to use it, they want to be given permission explicitly. One reason is that public domain is not recognized everywhere. It's unlikely a static site generator needs to worry about being public domain.
Tables are good for tabular data. I'd argue that it's potentially arguable that this may actually be tabular data. Either way, now that you mentioned it, I don't know whether my knee-jerk reaction would have been that it's good or bad, or if I'd even notice it at all, heh.
No disrespect, but, seriously, given that project was created 9 months ago, "minimalistic static site generator" isn't really sufficient project description, let alone marketing slogan. What I want to know is why to use it over
We use Hugo for our site's blog and we really appreciate the speed of compilation and the overall simplicity [1]. That said, it can be frustrating that it's not really possible to add or modify markdown extensions. If you want to do something as simple as adding some custom classes to tables and rows then you're pretty much out of luck. The closest that you can get is to switch out the renderer for mmark and use inline attributes, but that's still extremely limited. We often end up writing HTML in the templates when I would much rather be able to extend the renderer. I understand that this is a trade-off and that there are benefits to each side, but I wish that I understood the limitations better before deciding to go with Hugo.
On the other hand, python-markdown is an extremely well-designed library and it's an absolute joy to hack on and extend. Once upon a time, I used it to throw together an API documentation renderer for Mono class library documentation on a now dead product [2]. Overall, I enjoyed that a lot more than my experience with Hugo and I will probably use something python based for my next static site.
I've tried a few static site generators and I've written my own in Python. But they all sucked at some point - despite Hugo! Hugo is incredible fast, offers many features and is pleasant to use. But the killer feature is: Hugo just works out of the box without the need for an annoying setup. Just copy the binary and you are done!
As an interesting aside, the fact that you can organise your pages in a hierarchy reminds me of cat-v's "werc" website framework[0]. It's not a static site generator, but it will read the directory and file tree into a navigation menu, so you can navigate the tree using a sidebar. It will render pages using markdown on the fly.
Perhaps the "killer feature" is that you can run multiple subdomains using one instance. If you configure your web server correctly, a request to x.y.com will serve the website stored in the x.y.com directory etc.
Never took a close look at werc. Pretty cool idea. I wish it were a more modern theme, but I'm guessing that can be changed/fixed easily. The idea stands and it's written in a simple way which is nice.
What do you know, someone's actually working on it now!
Last time I checked (a few months ago), the project had gone about 2.5 years with no releases, no public mailing list activity, and almost no non-trivial source code commits. Bug reports, whether trivial or show-stopping, were consistently ignored, e.g. https://issues.apache.org/jira/browse/IVY-1485
It looks like some of the Ant contributors finally got around to picking up the project again a couple months ago. Here's hoping that they can get things back on track.
Not sure but I tried Pelican recently and found it clunky. Perhaps not fair as I was comparing it to Sphinx which I've a lot of experience with and is quite advanced.
I've used Pelican before and I'm currently using Jekyll, but this looks interesting enough to try on a small blog/project, and I like what I see. I wish it were more blog-oriented, or have a blog plugin, so it makes creating/managing blogs easier.
Would appreciate a motivation section in the readme, specifically whether this addresses needs better than others (especially Lektor which seems aimed at the same use case).
Or not, it's your project, can just be because you wanna :)
Your comment intrigued me because I've never heard of syntex. I must say, it's hard to find. Not only is Syntex apparently a commonly used company name, but .stx is already used by another markup language, "structured text".
The sheer number of lightweight markup languages is truly amazing.
What I think would be awesome is a html "rename" tool, which is to rewrite all the relative urls and filenames in HTML/css files when changing their location. Does anyone know?
> Jekyll is not better than the rest for any fundamental design reason; it’s better because it’s enormously popular and therefore excels in the long tail of details.
> ...
> If, like me, you secretly believe that everything is better if it’s written in Python, I still suggest you start with Jekyll (which is done in Ruby). In my experience, using Jekyll does not require writing or reading a single line of Ruby.
http://www.cs.cornell.edu/~asampson/blog/jekyll.html
This matches my own experience pretty well.