My problem is the mirroring itself. I don't want, taking your example, /posts/post1 just because post1 is under posts. You can get around this with some SSGs but this doesn't change the fact that they're path oriented. For example, I think it was possible to turn this off in Hugo, but then you had to do some workarounds for specifying templates because normally the templates have to be aligned with the paths. Plus it has a bunch of weird separated page "types" (archetypes, taxonomies, etc)
For comparison I now use my own metalsmith plugin which is the opposite of these types of SSGs. It only relies on the post metadata. I can basically say, pick all posts that match x criteria, use x route (it can dynamically generate them based on metadata variables), use x template for this route, and set basic settings (posts per page, etc). All from one place. Files can be organized however I think makes sense. There aren't different types of pages or anything. The only "special" thing I had to do was for /year/month/date/ archives, but I plan to remove that exception with the SSG I'm writing now.
Regarding the archives, bread crumbs are not what I mean exactly. I want the pages to also be paginated. So /year/ is not just a list of links to all posts or links to all months, it should paginate the posts list for that year as well if they pass the posts per page limit. Seems like this has never been implemented, see this four year old issue I found: https://github.com/gohugoio/hugo/issues/448
> What kind or degree of manipulation are you looking for.
I often want array manipulations. For example, to create tag clouds. I'm sure it's possible, but I doubt it's pretty. With something like EJS, I can just have the logic in plain javascript, right above the div that iterates through it. I will grant you, I'm not sure this is the best solution. With the SSG I'm writing, I've been playing around with the idea of having a header or footer section in javascript for the templates, where you can run this type of logic and the variables will be available in the template. Kind of how when you use a JS frameworks (e.g. Vue which I love) if you have something complicated to iterate over, you remove the logic from the template. This would make simple templating languages attractive again.
For comparison I now use my own metalsmith plugin which is the opposite of these types of SSGs. It only relies on the post metadata. I can basically say, pick all posts that match x criteria, use x route (it can dynamically generate them based on metadata variables), use x template for this route, and set basic settings (posts per page, etc). All from one place. Files can be organized however I think makes sense. There aren't different types of pages or anything. The only "special" thing I had to do was for /year/month/date/ archives, but I plan to remove that exception with the SSG I'm writing now.
Regarding the archives, bread crumbs are not what I mean exactly. I want the pages to also be paginated. So /year/ is not just a list of links to all posts or links to all months, it should paginate the posts list for that year as well if they pass the posts per page limit. Seems like this has never been implemented, see this four year old issue I found: https://github.com/gohugoio/hugo/issues/448
> What kind or degree of manipulation are you looking for.
I often want array manipulations. For example, to create tag clouds. I'm sure it's possible, but I doubt it's pretty. With something like EJS, I can just have the logic in plain javascript, right above the div that iterates through it. I will grant you, I'm not sure this is the best solution. With the SSG I'm writing, I've been playing around with the idea of having a header or footer section in javascript for the templates, where you can run this type of logic and the variables will be available in the template. Kind of how when you use a JS frameworks (e.g. Vue which I love) if you have something complicated to iterate over, you remove the logic from the template. This would make simple templating languages attractive again.
Thanks for the links btw.