Proposal to turn floeproject.org into a static site
antranig.basman at colorado.edu
Fri Jan 17 19:14:45 UTC 2014
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
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
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
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/
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?
> - Jon.
More information about the fluid-work