Why we use a static site instead of X?

[rmehner]

We got a few questions at Twitter and via email why the new website is a static website instead of some node.js backed thing, as we are a JS community after all. Here's why:

• we want to focus on organizing great events, not on hosting a website or maintaining software
• GitHub pages has proven to be pretty stable and worked well for us and others in the past
• we want to make submitting a talk as easy as submitting a pull request
• we can merge the Pull Request from everywhere.
• no permission bureaucracy. Want to fix a typo? Submit a talk? Help out? Submit a pull request.
• easy backup
• easy to fork, which enables other meetup groups to use the resources and start their own (yay community!)
• clean history in case of something goes wrong, or a password got lost (and passwords do get lost a lot)
• zero dependencies for just adding something to the website
• no build process required

A note on the last point: We'll use Jekyll eventually, so to preview the site locally you'll have some dependencies then. Still, submitting a talk will be just markdown. Jekyll is fully supported by GitHub pages so you don't need to install it locally.

Hope that helps to understand the reasoning behind the website and why we do things like we do.

Thanks everyone for helping and giving feedback so far.

[theophani]

👍

[lalomartins]

After looking at the actual code, I'm finding it harder and harder to agree with these arguments.

• We're proposing to have 7 similar-looking pages (and one a little less similar but still with the same footer etc), without using any sort of templates.
• “As easy as making a pull request” is a non sequitur; fork (or merge if you already have a fork), edit, test, write pull request — that's a much longer workflow than filling a form somewhere. Still, if that's the way we prefer it done, we can store the data in json, yaml, markdown, or some combination of those.
• Fixing typos, bugs, helping out in general, can still work with a pull request. Forking is still trivial.
• If the data is in json/yaml/markdown files you still get easy backups.
• Clean history? I think git is a horrible implementation of history for this purpose; the only ways to know what talks were given on such and such months is to comb git history, or hope archive.org mirrored it on those dates.
• After each meetup someone has to go and update the site my hand, since the “next meetup” is now the “last one” and the way it's currently designed it's not even displayed anywhere... so update the date, replace all talks with placeholders, what if a given group has no next meetup scheduled ATM?
• No dependencies: except Sass?

If everyone's really committed to github pages and Jekyll, I'd say it's probably easier to transition to Jekyll right now, than to finish this version of the site without the help of any sort of templates. That's not the way I would go, but IMHO still an improvement.

[rmehner]

On 25.02.2013, at 15:52, Lalo Martins notifications@github.com wrote:

After looking at the actual code, I'm finding it harder and harder to agree with these arguments.

• We're proposing to have 7 similar-looking pages (and one a little less similar but still with the same footer etc), without using any sort of templates.

Not true, we'll use templates with Jekyll. We just don't have that yet. Sorry if that wasn't clear. @mbesser wanted to have the design ready before converting to jekyll and we just opened the repo to gather early feedback.

• “As easy as making a pull request” is a non sequitur; fork (or merge if you already have a fork), edit, test, write pull request — that's a much longer workflow than filling a form somewhere. Still, if that's the way we prefer it done, we can store the data in json, yaml, markdown, or some combination of those.

You can do that as a form, as Github has an edit button with a live editor :)

• Fixing typos, bugs, helping out in general, can still work with a pull request. Forking is still trivial.
• If the data is in json/yaml/markdown files you still get easy backups.
• Clean history? I think git is a horrible implementation of history for this purpose; the only ways to know what talks were given on such and such months is to comb git history, or hope archive.org mirrored it on those dates.

Should be easy with Jekyll, as we just have have to iterate through the folders. Will see as soon as we start converting (hope to get this done asap)

• After each meetup someone has to go and update the site my hand, since the “next meetup” is now the “last one” and the way it's currently designed it's not even displayed anywhere... so update the date, replace all talks with placeholders, what if a given group has no next meetup scheduled ATM?

Yup, we have to find a good solution for that.

If everyone's really committed to github pages and Jekyll, I'd say it's probably easier to transition to Jekyll right now, than to finish this version of the site without the help of any sort of templates. That's not the way I would go, but IMHO still an improvement.

Sorry if that didn't came out clear. As said: Jekyll is the plan, we just opened it before to get feedback and push the work forward.

—
Reply to this email directly or view it on GitHub.

[lalomartins]

Well, my feedback is extremely positive, the new site is great. I really wanted to lend a hand, but it seems most of what's missing is either copy or entirely new pages. If you want, I'd be happy to start working on a Jekyll branch, though.

[rmehner]

Don't get me wrong, I don't see anything negative in your feedback. Your arguments are well versed and thoughtful :)

If you really want to start the work on the Jekyll branch, I can give you access to the repo and you can start a branch. That way I can join in later on if needed. What do you think?

[lalomartins]

sounds great.

[rmehner]

You should have access now. Thanks for your help.