static site generators: what they are and when they are useful
TRANSCRIPT
Paul WalkHead of Technology Strategy and Planning, EDINA
[email protected]@paulwalk
Static Site Generators: what they are and when they are useful
contents
• what are static-site generators?
• why should you care?
• what do you need to use them?
• (I will use the example of the RIOXX website, which is built with an application called Hugo)
what are static site generators?
• a different kind of web-content management system, designed to publish content as static content to a bog-standard web-server.
• content is processed during the publishing operation, rather than when the user requests content (although client-side Javascript still supported)
• simple command-line application to generate content and serve pages
• no database - content in semi-structured text files
components - standard to most systems
1. content-model• folder hierarchy, text files
2. content pages• (markdown, front-matter)• blog type content is also often supported
3. templates (& themes)• (with some level of basic scripting)
4. generator software• typically a command-line script or application
5. configuration file6. other non-core features
• 'shortcodes'• data as content (i.e. data in structured files such as JSON or YAML)• plugins
1. content-model
• text files arranged in folder hierarchy
• folder hierarchy relates to URL path structure
• filename relates to URL
2. content pages
• "front-matter" metadata• often in YAML format like here
• main body in Markdown, arbitrary HTML also accepted where necessary
---author: Paul Walkcategories: []date: 2016-03-29T17:18:13+01:00description: ""draft: falsetags: ["eprints","oai-pmh"]title: RIOXX and metadata only recordstopics: []---I received the following query from Emma Sansby, Head of Library Services at Bishop Grosseteste University:
> I am currently leading a project to implement Eprints (hosted and supported by ULCC) at my institution. We have the RIOXX plugin installed and I have a question about the licence_ref attribute.> > I am creating a metadata-only journal article record into our repository which includes a DOI link to the
3. templates
• can reference metadata (e.g. 'page title') from content page
• can re-use 'partial' templates (e.g. a common 'header' & 'footer')
• often in a common templating language such as HAML• (example below is in Go's templating syntax)
= include partials/header.html .div.row-fluid div class="col-xs-12" h1.page-title {{if .Draft}}[**draft**]{{end}}{{.Title}} h2.page-title i {{.Params.author}}, {{.Date.Format "Monday, January 02, 2006"}} {{.Content}} = include partials/share_buttons.html . = include _internal/disqus.html .= include partials/footer.html .
4. generator software
• used to generate new content:
• also used to run a local sever to see how the site will look
deployment options
• SFTP (no one uses FTP anymore, right....?)
• Rsync (over SSH)
• git commit hooks (or GitHub webhooks)• requires the site to be built on the server, so more infrastructure required
• Dropbox
the case against big CMS (Wordpress, Drupal etc.)
• complexity (require infrastructure - notably a database)• more points of failure• overkill for small websites
• require frequent maintenance for security and resilience• even when the website is in 'legacy' mode
• replication for resilience and/or scaling is non-trivial
• responding to sudden peaks in demand is difficult
• backup and long-term preservation is very difficult• typically need to preserve complex software & a database
Pros and cons
• Pros• can manage many contributors,
with different levels of access• (non-tech) user-friendly
authoring env.
• Cons• significant sysadmin burden
• infrastructural reqs• plugins make this worse
• content preservation challenge
• Pros• developer-friendly authoring env• minimal sysadmin burden
• minimal infrastructural reqs• supports content preservation• very responsive websites
• Cons• basic access control (e.g. git repo)• (non-tech) user-friendly authoring
env.
Content Management System Static website generator
authoring tools
• a good Markdown-friendly editor with 'preview' support• any old text editor at a pinch....
• access to command line tool such as SFTP or Rsync for deployment
• web browser
• that's it :-)
when to consider using them
• if you need to build & manage a website which:• will have one, or a small number, of users• will be relatively simple• won't have major 'dynamic' requirements• will need to be preserved, even after it is no longer a live site
• in short - a project website is a good candidate!