Discussion: Is Jekyll necessary?

[timwis]

This project started out as almost entirely a Jekyll site, with a /datasets page, a /categories page and /organizations page but I pulled back on that because of a couple Jekyll limitations, such as:

• Pagination only works on posts on github-pages-built sites
• The where filter doesn't work for arrays (PR)
• The group_by filter doesn't tell you the size of each group (PR)

I realized I could build most of that functionality in JavaScript alone. As the JS footprint has increased, I'm now wondering whether Jekyll is a necessary part of the stack. What if JKAN were just a static JS single-page-app that read/modified local JSON/YAML files the same way it does now?

Pros of this approach

• Simpler architecture, lower barrier to entry for collaborators
• Faster build times (no build process)
• GitHub-as-a-filestore could be abstracted, theoretically allowing other filestores with similar APIs
• Liberation from the shortcomings of Liquid templates

Cons of this approach / benefits of Jekyll

• Jekyll provides faster build times by generating static HTML pages for each dataset
• Changing a dataset in a JavaScript-only architecture would require 2 HTTP requests: (1) Change the dataset's JSON, and (2) change the dataset in the full list (datasets.json) (maybe a 3rd to fetch datasets.json)
• Hashbang links are kinda ugly (demo.jkan.io/#datasets/foo-bar/)
• Jekyll makes it easy to add other content ("about" page, blog posts, etc.) (though this could be done with ajax)

The most important thing is that both Jekyll and JavaScript begin with J, so we're still good on the name JKAN :P

What do folks think? @jalbertbowden @JJediny @waldoj @chriswhong @mheadd

[mheadd]

Something else to consider - the ease of creating / implementing custom theming for a JKAN site.

I talk to a lot of jurisdictions looking at open data portals, many of them small or midsized municipalities. Theming - and the ability to quickly and easily make UI changes - is a recurring issue.

Not sure if one or the other of these options makes it easier or harder to implement custom themes - I've looked into Jekyll themes, but not all that deeply - but that might be worth factoring in.

[timwis]

Good point @mheadd - theming should have about the same level of difficulty whether a Jekyll site or a JS single page app (a bunch of .html files in a templates directory with tags inserted into them), but that doesn't mean they're easy to customize.

[JJediny]

I think Jekyll is a core component of what makes this feasible. I agree that pure JS should continue to be used for github workflow of auth/edit and for the sites filter/search. But I think the true appeal of JKAN is the ability to customize the theme and tweak rendering, css/template html of jekyll is well known/used/documented. A pure JS implementation would narrow the pool of people that would be able to make these kind of changes and lose alot of its appeal of simplicity

[waldoj]

If it were me, I'd keep in Jekyll (since it's a widely-adopted technology, and not a major barrier to use), and use Javascript to plaster over Jekyll's shortcomings. The amount of work required to rewrite this in Javascript would be significant. I know I couldn't be bothered, but you may just be a better human than I am. :)

[scuerda]

This might complicate the build / deploy process, but what about building some custom Liquid filters to handle some of these filtering issues and then building site via Travis to get around the Jekyll/github-pages limitations. You can publish back to the gh-pages branch of a repo and get the same github-hosting benefit w/ the benefit of the full range of Jekyll functionality.

[timwis]

Good idea @scuerda - believe it or not, I started JKAN with that approach, which led me to create this demonstration repo. I decided against it because (1) it complicated the installation process (having to setup travis, add your oauth secret as an environment variable, etc.), and (2) it increased the build time significantly (a couple seconds to roughly 4 minutes). Thanks for the thought though.

[hampelm]

My understanding is that single-page or js-only apps still have significant SEO problems, so static rendering has serious findability benefits. With the rate things are changing, I may be wildly wrong by now (and would be happy to be!)