bevry/staticsitegenerators-website

Side Project: ChooseSSG — A TodoMVC equivalant for Static Site Generators

Opened this issue · 10 comments

balupton commented

Original tweet: https://twitter.com/balupton/status/422310475930419200

I'm considering that we could setup a project called ChooseSSG, where every SSG generator must produce the exact same output for a decided blog skeleton.

The questions here would be:

  • Pre-Processors allowed? Which?
    • CSS
      • Stylus
      • SAAS
      • Less
    • JavaScript
      • CoffeeScript
      • LiveScript
  • What features should be in the blog skeleton?
    • Content Listing
    • About Pages
  • Should it be a minimal feature set, or a max feature set?
balupton commented

I'm thinking:

  • Pre-Processors
    • SASS as the only allowed CSS Pre-Processor
    • No JavaScript Pre-Processors
    • Whatever templating engine they feel is best
  • Blog Features:
    • Blog Listing Page: blog posts showed with title and description, ordered by newest first
    • Blog Post Pages
    • atom.xml
    • Page Menu (about, home, blog)
    • Home Page
    • Layouts

That should be a good feature set, that any SSG should have to be considered serious.

ajmalafif commented

@balupton I think it's a great idea. I'm not sure about having a preference like "SASS as the only allowed CSS Pre-Processor" would reflect the purpose of the equivalent of todoMVC for SSG.

I guess you could start something like opinionated todoMVC with the above requirements. I like that minimal/maximum feature sets to help distinguish which SSG has certain set of features that other SSG don't have.

dogada commented

IMO it's also need to implement dynamic menu of blog posts (highlight current blog post list item and disable link for it). It's also interesting to linking with external Javascript, for example integrate Disqus comments -- so each SSG can be discussed right on the page.

dogada commented

IMO better to give this project simple name like StaticBlog rather than ChooseSSG.

RobLoach commented

There is no reason to limit yourself to a certain solution set. There are many solutions to any given problem, limiting your focal range limits your seeing the best solution for you.

I like the idea of having an example set of tools out aiming to all solve the same problem. Would be interesting to see what the outcome of it would be.

balupton commented

There is no reason to limit yourself to a certain solution set. There are many solutions to any given problem, limiting your focal range limits your seeing the best solution for you.

The problem though, is it would risk having a listing of things like:

  • DocPad Standard
  • DocPad with Grunt
  • DocPad with Brunch
  • DocPad with Grunt + Jade
  • DocPad with Jade
  • DocPad with Eco + Stylus

There really should only be one example for each static site generator, using as much standard functionality as possible. With everything else covered or explained in the readme. As that way, it is more of a fair comparison of the SSGs, rather than the effort the skeleton authors put in.

RobLoach commented

Got it. Definitely see the value of having a common set across SSGs.

Kind of off topic, but do you see http://github.com/robloach/generator-docpad helping out with this at all? I've discovered some interesting possibilities when it comes to building the content out:
http://github.com/RobLoach/generator-docpad/tree/master/templates/docpad/documents

vikramrojo commented

I like the concept because by leaving the feature set and skeleton open ended it resembles something like a theming layer where folks add blog packages.

dertuxmalwieder commented

How about gradually extending the usual SSG list by additional fields like "can do themes", "has WordPress import" etc., so this could be just an additional set of optional filters on the standard list?

  • 👍2