what should we use to build the website?

so now that we've finally established a website team, we should discuss how to build the website! here's some suggestions:

• jekyll: integrates well with github pages (eliminating the need for hosting), has a flat file structure without any actual build code. i18n situation unclear, potentially incompatible with github pages
• metalsmith: tried and tested on the nodejs website, fairly antiquated, but also stable
• react: modern, but maybe too much for people that just want to add/translate content? jsx & co might be confusing to some. doesn't compile to static sites

if you have any other suggestions, please post them here! take into account things like translations, hosting and beginner-friendliness

/cc @ayojs/website!

[scotttrinh]

I agree that making the website a SPA is overkill at best and a hindrance to getting translation help, for sure. However, we could use react to create reusable components that the markdown content uses, when needed, just not sure how many times we'd need components that aren't already the stock HTML components. I don't think anything on the nodejs site is really interactive, right?

[nbarnes]

Jekyll is ruby-based. I'm professionally focused on Rails, so that's bully for me, but as ayo is a JS project, we might be better off not bringing in a language that many of the contributors might not know / be interested in.

react seems like way overkill.

metalsmith's i18n plugins all haven't been updated in two years or so, but maybe they're just stable? Dunno.

[scotttrinh]

@NoahDragon

I'd say this is appropriate place to put your vote in for Hexo. 😉

[Kataract]

Hugo may also be a good static site alternative, though I personally have not set up their i18n functionality and Go templates may be a problem point depending on everyone's experience.

Would it be worth it to spend some time figuring out things we need the site to do before choosing a base? That may help inform this decision a bit.

[eubenesa]

Would love to put my vote in for Gatsby, but I am down to give any help. :)

[scotttrinh]

From an outside-of-the-team's perspective, the two things I care about are accessibility and ease of contributing. I can't imagine the site needs any bells or whistles, just marketing, getting help/resources, and docs. Perhaps I'm overlooking a need or opportunity to improve on what node's website provides? Our focus on the humans of the project might highlight some interesting places where we might expand on what node is currently doing.

[mcataford]

We should probably first put together a rough outline of the content we want to feature and choose tools and processes around that.

I absolutely agree with @scotttrinh re:accessibility & ease-of-contributing. Depending on the kind of content and features we project implementing, we can probably pick the lightest / easiest to maintain structure and have a kick-ass site that shines by how easily people can use it to get to what they need. :)

[z0al]

I would vote for Gatsby too!

what type of contents do we have other than docs?

[joshclow]

I am most familiar with React, so selfishly that's where my vote would go, but if the consensus is that React introduces unnecessary barriers to contributing, then I'm absolutely willing to turn to other options.

[scotttrinh]

RE: React

To be clear, I am not saying we should "not choose React", as I don't see React being a framework for implementing a website, but a framework for writing composable components. The bulk of the website will likely be text and not interactive components, so I'm not sure how/where React would fit in.

Having said that, I would be happy if we reached for React (or Vue or Polymer or...) when/if some complex and/or interactive components were needed. Ultimately, using the existing Node website as a frame of reference, I don't see any reason to include a UI framework whatsoever, but I'm hoping someone might point out some ways in which we'd want to differ from what Node provides.

[joshclow]

Well, looking at Gatsby based on comments above, the flexibility in content management there does seem pretty attractive.
As for things we might do beyond what the Node site does, I don't want to make architectural decisions now that assume later work, but I think there's an opportunity to approach education/inclusion in a way that can reach visual learners and other folks not well supported by a wall-of-text model. But that's a very hand-wavy pie-in-the-sky thing that I've given exactly as much thought to as it took to write the post.

i'm imagining a very simple website (even simpler than the node.js website), more akin to the rust website, which is precisely why i don't see the need to include something as unintentionally confusing as react, and i'd prefer to stick to simple html or markdown pages and templates when possible. the docs are separately compiled anyways, and will likely not be directly hosted from this website (i think? @Qard)

[scotttrinh]

The nice thing about React is it is very lightweight and easy to integrate later, so I wouldn't worry too much about knowing ahead of time if we need it or not.