Static Site Generator Community Meeting (March 12)

[Colin Clark]

From my perspective, this can't just be about static sites in isolation from how we might use this tool later. Otherwise we run the costly risk that we commit to something that was fine for some things but doesn't fit our needs anymore. We should think of this as a tool we can grow into.

Notably, too, we've got several sites that sit in between this binary of static site vs. cms (ie mostly static sites but with some dynamic features).  We should consider an approach that will let us iteratively replace more of these with a unified solution. If these kinds of sites are already here, we should take them into account.

Colin

> On Mar 14, 2014, at 8:33 AM, Justin Obara <obara.justin at gmail.com> wrote:
> 
> I'm really just trying to refocus on the main point of this being about static site generators and not CMSs.
> 
>> On Mar 14, 2014, at 8:07 AM, Colin Clark <colinbdclark at gmail.com> wrote:
>> 
>> Hi Justin,
>> 
>> On Mar 14, 2014, at 7:57 AM, Justin Obara <obara.justin at gmail.com> wrote:
>> 
>>>> "A static site generator written in Node.js could be easily extended with features written using Infusion and other tools we already use every day (e.g. Grunt). Even more interestingly, we might consider the long-term possibility of integrating static site generation features into Kettle, so that developers could easily deploy blended sites that consistent mostly of static HTML but also include JSON feeds or some dynamically-generated pages.
>>> 
>>> I worry that this could start bringing us back to our heavy maintenance and security issues. If the dynamically generated pages are still read only (fully controlled by the server without user input from the client) it may be okay. Avtar, you're in a better position than I to know if this is a legitimate concern. Could you please weigh in on that?
>> 
>> A static site generator won't do everything for us. I'm suggesting a smooth path from static sites to light dynamicity when it's needed (and only when). Can you elaborate on how you think this is any more of a security or maintenance issue than if we were, say, writing our own custom Drupal modules from scratch?
>> 
>> Colin
>