sass-site
sass-site copied to clipboard
sass
Migrate to Eleventy and onto Dart Sass
Recently, we've standardized Sass repos onto Github tooling by migrating away from Travis CI and onto Github Actions. If we're considering a website overhaul, a similar consolidation could make sense here.
The pros of Jekyll:
- First class support and integration with Github (automated build and deploy). No need for Heroku.
- Mature framework with good docs.
- Simple local development process.
- Can decouple Sass compilation (avoiding sassc).
- Similar enough file structure to Middleman (erb vs. liquid) to make migration straightforward.
@jina thoughts on this? I recently looked into migrating this repo onto Github Actions, but I felt like I was just adding more machinery and complexity.
The brunt of migrating would be converting Haml to HTML, and recreating the design token system. Otherwise the styles and markup could be copied over wholesale.
Would this even be desired, or is there a better direction? Happy to help as needed.
I had a contract to redo the infra and I was planning to move it to Eleventy. However, I didn't finish my work in time due to new job and other things and the budget is no longer available. I would still like to move it to Eleventy at some point. But if jekyll is preferred by the rest of the team I can work with that.
Well, deploying on Github pages does not requires the usage of Jekyll. any static site generator can be used.
For Jekyll, github will manage the build automatically. For Eleventy, it would require using Github Actions to run the Eleventy build and push the result into a repository hosting the built site (the one deployed with github pages, with jekyll disabled, which can be either a separate repository or a separate gh-pages branch in the same repo). That's totally doable.
Edit: see https://www.rockyourcode.com/how-to-deploy-eleventy-to-github-pages-with-github-actions/ for a blog post describing the setup. There is even already an action dealing with publishing a folder to the gh-pages branch.
Right. The key advantage of Jekyll is that we don't have to create/maintain any extra build steps, and can just let Github do it for us with minimal configuration.
I have experience deploying SSG builds to Github, but I'm unfamiliar with Eleventy. If that framework fits the needs of the site better, than building and deploying through Eleventy/Github Pages is certainly feasible.
I'm ok using Jekyll as long as we can use the Dart Sass implementation with it! :)
Jekyll uses the sassc gem, which wraps libsass. Compiling the scss files with dart-sass would require building them manually outside the jekyll pipeline (which then means doing the Jekyll build ourselves rather than letting github pages manage it, which becomes equivalent to deploying eleventy)
I'm ok using Jekyll as long as we can use the Dart Sass implementation with it! :)
Ah, good point. Since Jekyll uses sassc, we'd have to manually configure it to use Dart Sass. It doesn't look like there's a clean way to do this. And if we're manually wiring up its build process, Jekyll no longer has an advantage.
In that case, Eleventy might make more sense since it's Node-based, and would be able to use Dart Sass easily (https://www.d-hagemeier.com/en/sass-compile-11ty/). Jina I'll defer to your expertise here.
yes, let's use eleventy. I will try to get to this when I can. I also floated the idea to Natalie to consider working with Tatiana again — either way, it will get done!
This is actively under development at https://github.com/oddbird/sass-site
