4 ms·

It seems a case of "I didn't understand this engine's documentation, so I'm making my own engine to do this exact same thing".

by bighi 11y ago

nnq 11y ago
Nope. The whole point of a "static site generator" should be for it to be SIMPLE. If it takes me more than 15 min to understand almost everything about it, I consider the said generator a failure. This is why I never bothered with Jekill or Pelican after trying to get them to do what I wanted and couldn't in less than 30min. ...and I fall back to my script which does "php + php -S to temporarily serve + wget to generate the actual static site". sssgen seems like a breath of fresh air to me and I will actually use it. Thanks OP!!! Also, thanks again for the sound decision of using Mako so I can actually have python code in my templates instead of wrestling with another "crippled" template language. And for jumping off the maddening "convention over configuration" wagon... I love configuration and explicitness for anything non-obvious
- jnbiche 11y ago
  > The whole point of a "static site generator" should be for it to be SIMPLE. This is incorrect. The point of a static site generator is to generate static site content. You may use it in a simple manner, but there are many projects and companies that maintain huge, complex websites using static site generators like Middleman and Jekyll (along with various proprietary static site generators), in combination with content managers like Contentful. I'm talking hundreds if not thousands of pages, ecommerce, massive blog, multiple content types, etc. etc. I've worked on such projects, as have many others around here. I'm glad that enlightened companies are increasingly open to using static generators for such websites, since many (possibly most) of them don't need to run PHP or Rails if the site doesn't have dynamic content on the frontend. For such organizations, the point of static site generators is to produce vastly more secure and faster sites that are much easier to maintain and less expensive to host. Not to mention the ease of caching. The OPs project, nice as it is for a small, simple project, would be impossibly simple for such projects. Anyone who tried to use it for a project of the scale I've described would just end up re-writing an inferior version of Middleman. ssgen sounds like a cool project, and it also sounds like you're using the right tool for the job in your projects, but don't make the mistake of discounting a tool as useless or too complex just because it's not the right one for your purposes.
  - edmundhuber 11y ago
    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.

It seems a case of "I didn't understand this engine's documentation, so I'm making my own engine to do this exact same thing".

by bighi 11y ago

It seems a case of "I didn't understand this engine's documentation, so I'm making my own engine to do this exact same thing".

nnq 11y ago

Nope. The whole point of a "static site generator" should be for it to be SIMPLE. If it takes me more than 15 min to understand almost everything about it, I consider the said generator a failure. This is why I never bothered with Jekill or Pelican after trying to get them to do what I wanted and couldn't in less than 30min. ...and I fall back to my script which does "php + php -S to temporarily serve + wget to generate the actual static site". sssgen seems like a breath of fresh air to me and I will actually use it. Thanks OP!!! Also, thanks again for the sound decision of using Mako so I can actually have python code in my templates instead of wrestling with another "crippled" template language. And for jumping off the maddening "convention over configuration" wagon... I love configuration and explicitness for anything non-obvious

jnbiche 11y ago
> The whole point of a "static site generator" should be for it to be SIMPLE. This is incorrect. The point of a static site generator is to generate static site content. You may use it in a simple manner, but there are many projects and companies that maintain huge, complex websites using static site generators like Middleman and Jekyll (along with various proprietary static site generators), in combination with content managers like Contentful. I'm talking hundreds if not thousands of pages, ecommerce, massive blog, multiple content types, etc. etc. I've worked on such projects, as have many others around here. I'm glad that enlightened companies are increasingly open to using static generators for such websites, since many (possibly most) of them don't need to run PHP or Rails if the site doesn't have dynamic content on the frontend. For such organizations, the point of static site generators is to produce vastly more secure and faster sites that are much easier to maintain and less expensive to host. Not to mention the ease of caching. The OPs project, nice as it is for a small, simple project, would be impossibly simple for such projects. Anyone who tried to use it for a project of the scale I've described would just end up re-writing an inferior version of Middleman. ssgen sounds like a cool project, and it also sounds like you're using the right tool for the job in your projects, but don't make the mistake of discounting a tool as useless or too complex just because it's not the right one for your purposes.
- edmundhuber 11y ago
  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.