Proposal to turn into a static site

Jonathan Hung jhung at
Fri Jan 17 18:19:33 UTC 2014

Hi everyone,

We are in the middle of updating the 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

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

For, a static site makes sense because the site is rather
small and the content doesn't change often.

This raises some issues regarding the website update:

1. Should we do this 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 ( 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 /

The bigger implication of this discussion is that it can have an effect on
other project websites such as, 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 website would be
a pilot?


- Jon.




*T:* 416 977 6000 x3951

*F:* 416 977 9844

*E:* jhung at


Inclusive Design Research Centre

205 Richmond Street W, Toronto, ON, M5V 1V3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list