Change dev environment

[ggordan]

Stop relying on the jekyll cli to do everything for us because it is just so slow.

jekyll build and jekyll serve still work as commands and might be useful if all you would like to do is write a blog post.

Running npm run dev will watch for changes on the app and rebuild the sass, and js as well as refresh the page. Considerably faster than just relying on jekyll do it all for us.

• [ ] Look into a way to minify the rendered HTML
• [ ] Test to ensure that no existing functionality has broken
• [ ] Update the documentation on how to start the app

[petertait]

• Only suggestion would be to compress the outputs of the css.
• One question I have is: if we push changes to master will Github build the jekyll site like it does currently?

Other than that, this looks good to merge!

[ggordan]

@petertait thanks for the feedback. This approach has one caveat, and that is that we're required to build the css/js on our side. Github will still be able to build the site since jekyll build is working as intended, however it will assume that the assets in js/ and css/ are built and up to date.

Additionally, the fact that we are now committing built assets if multiple people work on the project there is a higher probability of merge conflicts..

[ggordan]

This can be configured to be a pre-commit hook, however this would need to be configured by by each person who is developing the app. And although that can be simplified by a small script, it's still not very robust since people can just forget to run it etc..

[shapeshed]

I guess the concern with this PR is that we are diverging from the library we are using (jekyll). Knowing how gh-pages will build the site is important for deploying and if Jekyll starts changing stuff the custom work we've done will be brittle.

I understand the reasons for the PR. We should just thrash out if it is the right thing to do.