3 ms·

Not taking a side here. :) What do you think sssgen is missing that I could rip off of Middleman? Or in general, what do you think is missing from sssgen to m

Not taking a side here. :) What do you think sssgen is missing that I could rip off of Middleman? Or in general, what do you think is missing from sssgen to make it feasible to use for 100K+ -page sites? I'd really like to hear your thoughts.

jnbiche 11y ago
I think your approach is great. There's clearly a demand for simple static site generators that favor configuration over convention, so unless you really want to pursue the Middleman audience, I'd keep on keeping on. But I'll offer a few thoughts for your purposes: 1. I think a small, well-tested core like you're doing is great. I also think for your purposes, Mako templates are the right way to go, since they allow super flexible logic in the templates. 2. If you want some inspiration from a kinda sorta similar approach, take a look at Metalsmith and its plugin ecosystem if you haven't already. 3. A great asset to any static site generator would be a collection of "starter themes/sites" that already have things like a static asset pipeline set up (using Gulp, Grunt, or whatever floats your boat). If you really want to accommodate the bigger static sites, a few critical features: 1. Super fast compile times. This is why Hugo is rapidly gaining ground despite not having a plugin API. When you have thousands of static files, it's not fun waiting 10 or 20 minutes for each compile (Middleman and Jekyll have gotten faster, but they're still slow relative to Hugo and the Node-based static site generators). 2. With huge sites that are built by large teams, flexible templates like Mako almost become a liability, since careless team members can overload logic into templates. For these teams, you may wish to offer an alternate template choice, like Jinja. 3. Some kind of feature similar to Middleman's dynamic proxy pages, which would allow users to dynamically generate hundreds of pages basic of Contentful's API or their own JSON files. See: https://middlemanapp.com/advanced/dynamic_pages/ https://middlemanapp.com/advanced/dynamic_pages/ Finally, features Middleman's url helpers have proved to be a significant help on large static sites I've worked on, since the URLs are no longer hard-coded. There are a lot of small but significant features like this: localization extensions, pagination, etc. But if you have a good plugin API, all of these things can be created and offered as plugins. But again, I think your current approach is just fine. If I were you, I'd perfect a simple core generator and then try to build up the ecosystem.

jnbiche 11y ago

I think your approach is great. There's clearly a demand for simple static site generators that favor configuration over convention, so unless you really want to pursue the Middleman audience, I'd keep on keeping on. But I'll offer a few thoughts for your purposes: 1. I think a small, well-tested core like you're doing is great. I also think for your purposes, Mako templates are the right way to go, since they allow super flexible logic in the templates. 2. If you want some inspiration from a kinda sorta similar approach, take a look at Metalsmith and its plugin ecosystem if you haven't already. 3. A great asset to any static site generator would be a collection of "starter themes/sites" that already have things like a static asset pipeline set up (using Gulp, Grunt, or whatever floats your boat). If you really want to accommodate the bigger static sites, a few critical features: 1. Super fast compile times. This is why Hugo is rapidly gaining ground despite not having a plugin API. When you have thousands of static files, it's not fun waiting 10 or 20 minutes for each compile (Middleman and Jekyll have gotten faster, but they're still slow relative to Hugo and the Node-based static site generators). 2. With huge sites that are built by large teams, flexible templates like Mako almost become a liability, since careless team members can overload logic into templates. For these teams, you may wish to offer an alternate template choice, like Jinja. 3. Some kind of feature similar to Middleman's dynamic proxy pages, which would allow users to dynamically generate hundreds of pages basic of Contentful's API or their own JSON files. See: https://middlemanapp.com/advanced/dynamic_pages/ https://middlemanapp.com/advanced/dynamic_pages/ Finally, features Middleman's url helpers have proved to be a significant help on large static sites I've worked on, since the URLs are no longer hard-coded. There are a lot of small but significant features like this: localization extensions, pagination, etc. But if you have a good plugin API, all of these things can be created and offered as plugins. But again, I think your current approach is just fine. If I were you, I'd perfect a simple core generator and then try to build up the ecosystem.