I’ve been using Jekyll and love Julia, so thought I’d give Franklin.jl a try.
But comparing the solution in Franklin.jl for generating a list of posts:
{% for post in site.posts %}
<li>
<a href="{{ post.url }}">{{ post.title }}</a>
</li>
{% endfor %}
has me a little spooked.
Is there a reason something so seemingly natural should require such a cumbersome (and I fear fragile) solution rather than having a pretty straightforward / built-in approach?
There’s a few parts to answering this but, at the end of the day, if Jekyll works for you, maybe just stick with it?
The answer you copied from is not an apple to apple comparison with the Jekyll solution, you could have something pretty close to that. Here what the user is doing is likely quite a bit more complicated than what is necessary but if it works for them, why not.
There was a deliberate choice to offer the possibility for users to code the way they want stuff to happen, and, for instance if they want to order the posts from a given folder in a specific way with a specific logic, all in Julia. The solution a user might end up with can be considered fragile by others but if it works for the users, I wouldn’t be one to blame them.
Baking things in the code may seem natural but it also adds surface that I have to maintain where people might keep asking for the “seemingly natural” to be extended for specific stuff they might want in their specific cases. So rather than baking this kind of stuff into the code, the hope was that, in the longer run, people would provide light “helper packages” or “plugins” that would provide hfun_* (and other similar things) that work well for common use cases, so that I don’t become (more of) a bottleneck. A bit like with the packages / .sty files that people use with their LaTeX document.
Anyway you may disagree with the above approach but, right now, the main item I’m working on and that I will be working on for the foreseeable future is to bring about the next version of Franklin which is basically an in-depth re-write of the code base. There are a number of things that grew organically with Franklin (e.g. pagevars) and ended up requiring an in-depth re-design. This can already be experimented with at Xranklin.jl. Even with that though, the philosophy will remain that, as I don’t want to become more of a bottleneck than I already am, I would like to provide a robust core, that people can write things around and possibly put into packages. But I don’t want to grow the feature set much beyond what it is now, and so quite likely will not provide what you might like soon.
Super helpful context and very thoughtful answer. Thanks for it, and for all your work on Franklin!
(Edit: I should have added, vis-a-vis my own context / motivation, that I have a landing page in Jekyll, but wanted to experiment with something more complicated that would feature posts etc. As it’s a natural inflection point and I don’t understand Jekyll at all but just have it “working” in the sense that the page builds, I thought before I went too far down the Jekyll path, I might experiment with recreating what I have in Jekyll in Julia, which if successful would provide a superior setting in which to move forward.)
For users coming from a Jekyll / Hugo experience, there’s definitely less of an “out of the box” experience with Franklin (and, of course, if you intend to use some of the specific features like code evaluation). I think the reward comes if/when you want to finely control the logic that goes into building a specific page. In the beginning things might seem clunky and h-funs a bit weird, but I take them a bit like I take CSS: once it does what you want, don’t look at it anymore!
Side note that (in case you’re not already aware) there’s a #Franklin and a #Xranklin channel on the Julia Slack where I try to be responsive (and others help out too 
), people don’t usually stay stuck very long.