Proposal to turn floeproject.org into a static site

[Antranig Basman]

Hi Jon - I think this is a great idea - I'm actually keen to see us do this for much more of our 
infrastructure as well, for example, moving our main fluidproject wiki and documentation platform away from 
Confluence and to a static publishing system of the kind you mention - and have the underlying workflow 
operated by git, with the ability to issue pull requests, have review etc. for documentation updates just as 
we currently do for code. For consistency I'd like to see us adopt a platform operated in JavaScript on 
node.js - since there are a number of developments coming over the next couple of years with the 
Prosperity4All grant that might lead us to be able to helpfully "dogfood" our own architecture, especially 
as regards authoring, rendering and model-based development. So in that light a couple of promising 
platforms we had been kicking around include

Punch: http://laktek.github.io/punch/
Wintersmith: http://wintersmith.io/

some other more minimal and minor options include http://assemble.io/ , 
http://blog.nodejitsu.com/introducing-blacksmith/, http://marijnhaverbeke.nl/blog/heckle.html , and others 
mentioned on discussions such as 
http://stackoverflow.com/questions/7327929/whats-the-best-way-or-package-to-build-a-static-site-using-node-js

I think producing a working replacement by Monday might be a bit of a stretch, but I'm extremely keen to get 
the ball rolling on this as fast as we can. Our own renderer won't be ready for this kind of use for a long 
while, but in the meantime I'd like to see us using a templating system that resembles HTML as much as 
possible (e.g. something like "handlebars" rather than something like "jade"). "Weld" templates seem even 
closer in spirit to our own renderer. http://blog.nodejitsu.com/micro-templates-are-dead/

Cheers,
A

On 17/01/2014 11:19, Jonathan Hung wrote:
> Hi everyone,
>
> We are in the middle of updating the floeproject.org <http://floeproject.org> website and in the process
> started to have a discussion about transitioning that website from a Drupal instance to a static site
> (static site being a site written in plain HTML and CSS, with no databases or PHP).
>
> The advantages to using a static site are (but not limited to):
> - less software to maintain and less security issues
> - source documents and content can be version controlled using a code repository like github
> - platform agnostic - since the site is primarily plain HTML and CSS, it can be moved and migrated easily,
> and doesn't depend on any software platform.
>
> The primary disadvantages is a slightly more complicated route to modify and update content and less
> interactive features like native comments system, and wysiwyg editors  (although there are reasonable
> alternatives or equivalents).
>
> For floeproject.org <http://floeproject.org>, a static site makes sense because the site is rather small and
> the content doesn't change often.
>
> This raises some issues regarding the floeproject.org <http://floeproject.org> website update:
>
> 1. Should we do this floeproject.org <http://floeproject.org/> update using Drupal now and consider the
> static site conversion later? To do the update in Drupal will take about 1 day. To do the work using a
> static site (assuming all the infrastructure / processes are in place) it should take maybe 2 days.
>
> 2. If we go a static site route, we'll need to set up the infrastructure for generating static sites
> (kicking it old school using Win95 Notepad isn't going to work). We would have to choose a static site
> generator (like DocPad, Jekyll, or Octopress), decide on a repository for the content, and then create a
> process in which the content from the repository is deployed to a host.
>
> Personally I have been using DocPad (http://docpad.org/) which supports text formatting (markdown),
> templating (eco and jade), compilers (stylus, less, sass, coffee), minifiers, deployers (for github pages,
> AWS, Azure, dropbox), and automators (grunt). DocPad also runs on Linux, Mac OS, and Windows unlike other
> static site generators which primarily support Linux / Mac.
>
> The bigger implication of this discussion is that it can have an effect on other project websites such as
> fluidproject.org <http://fluidproject.org>, and even documentation sites like Infusion documentation, design
> handbooks etc.
>
> Where it makes sense, I think it's good to reduce the number of CMSes we are maintaining and patching.
> Perhaps the floeproject.org <http://floeproject.org> website would be a pilot?
>
> Thoughts?
>
> - Jon.
>