Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create comparison marketing page #59

Open
jeremydw opened this issue Apr 12, 2021 · 0 comments
Open

Create comparison marketing page #59

jeremydw opened this issue Apr 12, 2021 · 0 comments

Comments

@jeremydw
Copy link
Member

We should create a "comparison" marketing page that compares Amagaki both to other static generators, and other tools in the website building space.

For example, we should compare at a minimum:

Static generators:

  • Grow
  • Hugo
  • Eleventy
  • Jekyll
  • Middleman

Webapp frameworks that can serve as static generators:

  • Gatsby
  • Next
  • React Static

Blog tools / CMS:

  • WordPress

Hosted software:

  • Squarespace, Wix, Weebly, etc.

Feedback from Vinod about why they use WordPress:

So the way the wordpress development is structured is just like building a web app in git, with all the usual development workflows, feature branches, integration pipelines that auto-deploy to a staging/development wordpress site, etc. The one difference is that all the development is related to layout and structure and "building" the wordpress admin UI's custom pages that the actual stakeholders then add content in. So code is easy to version control, and it does a good job of keeping the code DRY and following modern development principles while the content is added by someone else. The team size hasn't been a concern there.
I agree with the other issues though:
- version controlling content is hard. we basically don't do that on our custom pages. the non-technical folks would just add in the content needed
- deploying a part of the site on its own is not something we've entirely figured out. Because the DB migrations get in the way since the ACF fields/pages are all stored in the DB
- version controlling media is even harder because it's just a dump in the wp media library.
There are some benefits to wordpress like content approval workflows and all the plugins you get around optimizing things, SEO, etc. but we primarily chose it just as a CMS I guess. Maybe i should try out a static site generator next time, especially if the same people are updating content and code :thinking_face: . removes all that overhead of having to build the layout/fields for the admin UI that the content is updated via
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant