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.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
