Zola?

[ozkriff]

Are we sure want to use Jekyll generator? I'm ok if we decide to stay with it, but want to make sure that it was seriously considered.

My only functional issue with Jekyll so far is that it requires to store posts and assets (images) in separate directories. That's not a critical thing, but it's a site of Rust working group and it seems a little bit weird to me not to use excellent rusty tools when we can.

Sorry for raising this a little bit too late when the first post is already published, but I'm a little bit worried that it will be difficult to migrate (if we finally decide to) after a few more posts.

Zola seems to work fine for another working group's site - https://github.com/rust-embedded/blog and also for @17cupsofcoffee's (https://seventeencups.net) and my (https://ozkriff.games) blogs.

[AlexEne]

I am quite sure due to a few factors:

1. Posts are markdown, and it's super easy. you can do html inline in case of emergency.
2. Magical integration with github so it allows you to basically just edit markdown without any tools installed to contribute to the site, thus allowing more people to contribute as it can't get easier than this (or if it can I am open to suggestions). And exactly 0 steps to publish the changes. Once a change is merged, it's live on the site
3. Storing images in a folder is not a big issue. We can have some guideline as the folder should be assets/post_name if needed for keeping things clean.

Post 2 is the biggest reason actually that I am reluctant to change this.

[17cupsofcoffee]

My position is "I'll go with whatever everyone else wants to use", for what it's worth 🙂

Point 2 is probably the main sticking point - Zola doesn't have GitHub Pages integration in the same magic way that Jekyll does. You either have to use a CI service to build and publish your site to the gh-pages branch, or use an external hosting service like Netlify which integrates with GitHub. It's not a ton of extra complexity, but it's extra complexity nonetheless, I guess.

[ozkriff]

As for the first point, Zola is no different here.

About the second part, as @17cupsofcoffee said, we only need to set up Travis scripts once and it will provide nearly the same experience for contributors. We don't even need to write our own scripts, we can just reuse scripts from Embedded WG repo.

As a nice bonus, using explicit Travis scripts will allow us to add automatic checks, like basic grammar, formatting or deadlinks linters.

Also, experimenting with the site locally won't require ruby installation.

[AlexEne]

But what is the advantage? Say we put up some scripts what's the advantage of using it? Does it really have a feature that makes a difference or is this just to use a rust tool?

[ozkriff]

For me, it's mostly about "just" using a Rust tool, yep. Dogfooding is a good thing for the ecosystem and in this case it doesn't seem that it will require significant resources.

[not-fl3]

Ruby installation for local testing looks like a serious roadblock for future contributors and couple of travis scripts to avoid this may be worth it.

[AlexEne]

Umm, you don't need local Ruby to contribute posts, i don't have it. You need it for style changes, but how often do they really happen?

[AlexEne]

@ozkriff is this an ask on me and 17cups to change this or are you offering to do the work?

I want to clarify this as I received no advice or contributions when the website issue was open.

As for dogfooding, I am not willing to be a beta tester for things that are generally unproven. E.g. rust for machine learning. If I want something done in machine learning I use a tool with support and proper documentation and learning resources and that allows the user to experiment like pytorch. Rust is just a tool.

So anyway unless there is a real advantage, the fact that it has a rust label is not enough in my view to put in the effort and switch. It needs proper tech advantages. That's why rust is successful in the system programming world.

Also when things go wrong with Jekyll there are plenty of resources online and I can't say the same about zola

[17cupsofcoffee]

I would be willing to work on porting the theme across if the consensus was that we wanted to switch. I do kinda agree that it seems like a lot of effort for not a ton of benefit, though.

[AlexEne]

It's more about the missed opportunity to suggest this in the 1-2 months when the website issue was opened(with me mentioning it in each meeting). I did a basic skeleton and until you came and did a lot of proper work there was no suggestion either. So the way I see it there was a large enough time window to get this proposed. Switching is not worth it now, after the fact as it seems of little benefit.

(Didn't mean to close, i am on mobile...)

[not-fl3]

It's more about the missed opportunity to suggest this in the 1-2 months when the website issue was opened

Sorry for missed timing, if the decision is made and we lost the FCP timings - its fine, jekyll is actually pretty good and definetly will works.

I just want to point out that there are actual advantages of Zola with custom travis scripts:

• ability to local tests and preview without all the Ruby dependencies
• more configurable uploading pipeline - ability to add more steps on travis, like spellchecking/doctests

Zola served well for some Rust related projects - like embedded WG or @ozkriff's blog. And is pretty easy to configure for Jekyll-like experience(I can make a PR with the migration if needed).

More than that there is some less rational thoughts on Zola - rust label actually means a lot for some members of rust gamedev community(myself included) and I think that with more rust used in the world - a lot of community members will be a bit more happy overall.

[ozkriff]

is this an ask on me and 17cups to change this or are you offering to do the work?

Yep, I can do the migration and CI setup, but I will need help with the templates if it's required to use the current theme (because I have almost no experience with templates editing).

[AlexEne]

I am still voting against this just because we had so much time to suggest changes and didn't and we invested work in this already. I am not willing to do work again to set up another framework.

But as you wish, you are free to open a PR for this migration as I see @17cupsofcoffee doesn't have any objections and you keep the looks. That's my only request.

[AlexEne]

I would still ask, is Zola the best alternative or are there others that will pop up in another issue next month or in two months?

[17cupsofcoffee]

If we're ruling out non-Rust static site generators, then the only other potential choice that could come up is Cobalt. That said, I've tried both Cobalt and Zola and found the latter significantly more pleasant to use.

[not-fl3]

Zola the best alternative

Yes, Zola is the only alternative - the only pure rust static website generator widely used across the community, well tested and mature enough to be considered as Jekyll drop-in replacement.

[not-fl3]

I've tried both Cobalt and Zola and found the latter significantly more pleasant to use.

I may be wrong here, but cobalt.rs is a bit outdated - Zola have way more live usage examples and is more alive in general.

[ozkriff]

I'd be happy to do the migration to Zola if the consensus is that it's the right thing to do, but I'm not going to push it through if that feels like I'm downplaying someone's work. That wasn't my intention and I'm sorry for the annoyance this discussion may have caused.

Perhaps some kind of explicit decision deadlines/FCPs may help prevent this in the future.

<...> is Zola the best alternative or are there others that will pop up in another issue next month or in two months?

I think that Zola is the best rusty tool at the moment but who knows how good it will be maintained in the future or what other tools will arise? I'd say that the best protection against repetitive migration/rewritings is to negotiate and explicitly document WGs collective value system about tooling and similar stuff.

I'll leave this issue open though, in case if other people have some new arguments or if we decide to discuss this again later.

[17cupsofcoffee]

Can only speak for myself, but I don't feel like my work was being downplayed, don't worry! 😄 Like you say, I think people just have different value systems when it comes to these kinds of tools.

Anyway, the layout of the site is pretty simple and non-Jekyll-specific - I don't think there's any danger of us getting too locked in (especially if we're not too messy with the assets folder - I like Alex's suggestion of seperating it into folders per post if stuff gets too hairy). Can always revisit this choice later 🙂

[zicklag]

For me, I like being able to build sites locally, because you never really know how it is going to look before you publish it, especially when GitHub won't render HTML that is embedded in Markdown. Because of that, I would much rather use a super easy-to-install tool like Zola than Jekyll, because of the pain that I've had building several other Jekyll sites, each with different requirements for the version of Ruby that I need. I think that that is a developer plus that could definitely help others contribute.

It seems to me that Zola would be a good idea. Switching early would be better than switching later, and if somebody is willing to do the work, then I don't see a disadvantage to it.

[berkus]

My favourite killer feature of Zola is integrated JS-powered site indexer/search.

You can see one in action at https://metta.systems (my blog).