Queries regarding the project "Migrate Floe and fluid project website to Hugo"

Wed Feb 26 13:10:04 UTC 2020

Hello again,
Thanks for the response, Jon. I'd try to keep the discussion in the mailing
list only so as to keep everyone updated and so as to get help from others
in the community also who have worked on similar technologies.
I researched about Hugo, Jekyll, and Eleventy ( as suggested by Ned above)
and found the following noteworthy points.

*Jekyll*:
*  Pros*:
    1) *Simple templating engine - *Jekyll uses the Liquid templating
engine which is easy to use and similar to Wordpress.
    2) *Strong Theme Library - *Jekyll has many ready-to-use themes to get
started.
    3) *Rich plugin library - *Jekyll has dozens of plugins to add the
features to our website.
    4) *GitHub Pages Integration - *Gh-pages is readily compatible with
Jekyll.
    5) *Built-in development server  - *We can access our pages at a local
IP address. A simple refresh will allow you to see the changes to either
your content or template.
  *Cons:*
    1) *Slower to build - * Jekyll is 35 times slower than Hugo.
    2) *Restricted file structure- *Data has to be stored in a _data folder
and iterating over files in data folder is not convenient or possible at
times.
    3) *No image editor- *No image manipulation tool for interactively
cropping and resizing images.
    4) *Building time as plugins increase - *Plugin availability can be a
Con as well. As our list of plugins grows, so does build time

*Hugo:*
  *Pros:*
    1) Supports TOML, YAML, and JSON for the front matter where Jekyll only
supports YAML.
    2) *Extremely fast - * Build times under 1s.
    3) *Enterprise-ready*. With support for multiple output types and
multilingual sites
    4) *Cross-platform -* Hugo has binaries for Windows, Linux, FreeBSD,
NetBSD, macOS, and Android for x64, i386, and ARM architectures.
    5) *Theme Library - *Hugo provides enough available themes to choose
from.
  *Cons:*
*    1) U**ses Go’s Template Package
<https://golang.org/pkg/html/template/> instead of Liquid* which is no
beginner friendly and people from different technical backgrounds may find
it difficult to understand.
    2) *No extensions*. Hugo doesn’t have plugin support, so adding highly
custom functionality isn’t possible.
    3) *No asset pipeline*. Hugo doesn’t have any asset processing at all,
so you need to use third-party tools.
    4) *No XML support for data feeds* Only JSON/CSV
    5) *No plugin support - * have to work with what Hugo’s got. Adding
highly custom functionality isn’t possible.

*11ty:*
  *Pros:*
     1) *Multiple template languages- * Eleventy supports currently 11
different templating engines. Multiple templates can be used in the same
project.
     2) *Zero boilerplate client-side JavaScript - N*ot required to use any
specific JS library or framework. We have a choice to pick whatever tools
we need. React, Vue.js or even jQuery.
     3) *Zero-config - *By default 11ty works with our project’s existing
structure. It doesn’t force us to use a specific folder structure unless we
want to. It transforms all files from our root folder.
     5) *It’s written in JavaScript - *and is very extensible, we can write
your own plugins and data processing tools as Ned pointed above.
  *Cons:*
     1)* Community, templates, and plugins* - Comparing to other JS-based
SSGs, Gatsby or Next.js, the plugin ecosystem is very small. There are just
3 official plugins + a few unofficial.

Since as Jon mentioned, build times are not a major problem and we don't
have much traffic on these sites. Build times should not be a factor in
choosing relevant SSGs. The major deciding factors should be easy of
making, building, and understanding the structure of websites. Support for
multiple templating languages provides an upper hand to 11ty. Moreover,
since 11th is written in JS, it's easy to write own plugins and increase
functionality.
To enable the flexibility of SCSS/SASS, Hugo has Hugo Pipes for
asset-processing—in this case, transforming one or more SCSS/SASS files on
the fly while you’re developing with `Hugo server`.
With Eleventy we can use the node-sass library
<https://www.npmjs.com/package/node-sass>and set up Gulp
<https://gulpjs.com/> to handle processing the SCSS/SASS files. Running
Gulp does the processing and watches constantly for changes, any of which
will trigger a new processing run. It Deletes the previous build—the
“_site” folder—on each run to ensure that we are looking at the
latest-and-greatest version.
Jekyll is quite blog-friendly and simple to understand the structure (in
the sense that all blogs can be stored as MD files in a folder).  Since the
floe project site majorly consists of news articles/blogs only, I'd
recommend using Jekyll for building it. However, we can opt for 11ty or
Hugo for the fluid project website due to a variety of 'things' to be
displayed. The News articles in the floe project can be stored as markdown
files and liquid templating can be used easily to iterate over them to show
the list of blog articles. Being compatible with the-pages, we can totally
leave the site on its own requiring no backend servers for hosting and
building it.
I hope there is no such restriction on using a consistent SSG for both the
sites.
Deciding upon the SSG should be the first step before everyone interested
in the project should start working on drafts of their proposals. It'd
really helpful if Jon, Justin, Clark, and Ned could provide more insights
into this so we can decide upon the SSG to be used.

Thanks and Regards
Sachin
@sachin10101998 on Github

On Tue, Feb 25, 2020 at 2:22 AM Ned Zimmerman <nzimmerman at ocadu.ca> wrote:

> Hi Sachin!
>
>
>
> One other static site generator you might want to explore is Eleventy (
> https://eleventy.dev). It’s very fast (like Hugo) and very flexible, and
> one other advantage it has is that it’s written in JavaScript and is very
> extensible, so if you can write JavaScript you can write your own plugins
> and data processing tools. Simon Bates and myself have both used it and
> quite like it.
>
>
>
> Cheers,
>
> Ned Zimmerman
>
> —
>
> Ned Zimmerman (he/him)
>
> Senior Inclusive Developer
>
> Inclusive Design Research Centre, OCAD University
>
> https://idrc.ocadu.ca
>
>
>
> *From: *fluid-work <fluid-work-bounces at lists.idrc.ocad.ca> on behalf of
> Justin Obara <obara.justin at gmail.com>
> *Date: *Monday, February 24, 2020 at 12:24 PM
> *To: *SACHIN CHOPRA <schopra at mt.iitr.ac.in>
> *Cc: *"fluid-work at lists.idrc.ocad.ca" <fluid-work at lists.idrc.ocad.ca>
> *Subject: *Re: Queries regarding the project "Migrate Floe and fluid
> project website to Hugo"
>
>
>
> Hi Sachin,
>
>
>
> If you’re going to look beyond Hugo, I might suggest also looking beyond
> Jekyll to see what else is available out there. You can see more options
> from https://www.staticgen.com and other places on the web.
>
>
>
> Thanks
>
> Justin
>
>
>
> On Feb 24, 2020, at 1:39 PM, Jonathan Hung <jhung at ocadu.ca> wrote:
>
>
>
> Hi Sachin,
>
>
>
> Apologies for this duplicate email. I had replied to your previous email,
> and I am now replying to the mailing list.
>
>
>
> Thanks for your interest in this project! I hope I can answer your
> questions:
>
>
>
>    1. The major goal is to make the website easier to maintain and
>    update. Speed of building isn’t a concern as these websites are relatively
>    low traffic. Docpad is no longer meeting our needs because Docpad is no
>    longer maintained by the creator, and lacks support for more modern
>    technology (for example, Docpad is not compatible with current versions of
>    node.js). Also Hugo is easier to work with, which is desirable when working
>    with people with different technical backgrounds.
>    2. For now we aim to keep the same design with some minor fixes and
>    tweaks. The work of this project is primarily focused on the backend of the
>    sites. If there is time, moving to a more modern CSS framework would be
>    desirable but not a requirement.
>    3. You are correct. Floeproject is made using hand-written HTML and
>    CSS which is hard to maintain (hopefully moving to Hugo can help). Both
>    websites are hosting on our own servers and deployed automatically using
>    webhooks. For this project, we will need to set up development site so the
>    any work can be done without affecting the website that is currently in
>    production.
>    4. We are using Hugo because it is a platform our organization has
>    used in the past for other websites. However, we would be open to using
>    Jekyll if there is a good reason. Perhaps part of your project proposal can
>    include research into both these platforms and report on the advantages and
>    disadvantages of both choices.
>
>
>
> I hope this answers your questions.
>
>
>
> Sincerely,
>
> -Jon.
>
>
>
> ---
> Jonathan Hung, Inclusive Design Collaborator / Researcher
> Email: jhung at ocadu.ca
> OCAD University
> Inclusive Design Research Centre
>
>
>
>
>
>
>
> *From:* fluid-work <fluid-work-bounces at lists.idrc.ocad.ca> *On Behalf Of *SACHIN
> CHOPRA
> *Sent:* February 24, 2020 11:41 AM
> *To:* fluid-work at lists.idrc.ocad.ca
> *Subject:* Queries regarding the project "Migrate Floe and fluid project
> website to Hugo"
>
>
>
> Hello fluid community,
>
> I am Sachin Chopra and I have few doubts/queries regarding the project
> "Migrate Floe and fluid project website to Hugo" . I posted these on IRC
> channel too but couldn't get the answers. I'd be really thankful if someone
> from the community could answer these.
>
>
>
>    1) What's the major goal behind this project? Are we trying to migrate
> to Hugo so as to achieve faster build times? What are the major issues with
> present format or Docpad that we have to rectify which Hugo can solve?
>
>    2) While migrating to Hugo, do we need a complete new design and look
> for the website or do we have to stick to the present design/UI?
>
>    3) Currently, floeproject is not using any static site generator and
> fluidproject uses docpad. Are they both being hosted on gh-pages or do we
> use third party services like AWS or Azure for hosting them?
>
>     4) Is there a restriction on using Hugo only as the alternate static
> site generator? Or can we discuss using Jekyll as an alternative to Docpad?
>
>
>
> I believe that everyone interested in this project would have these
> questions in mind and if one of the mentors could answer them, it would
> really point us in the right direction to move ahead with the project.
>
> Sorry if this mail causes any inconvenience.
>
>
>
> Thanks and Regards
>
> Sachin Chopra
>
> @sachin10101998 on Github
>
>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200226/2f0cde19/attachment.html>