Extract simpleserialize.com Website to a Separate Repository

[nazarhussain]

Motivation

While monorepos offer benefits when multiple packages evolve in close coordination, the current state of the website diverges significantly from the core SSZ packages:

• The website does not consume local workspace packages — it instead relies on outdated, published versions.
• Its purpose and technology stack (React) differ considerably from the protocol libraries implemented in TypeScript and low-level serialization logic.
• It is not tested or deployed in conjunction with the latest protocol updates, creating a potential for stale or inaccurate documentation.

These factors suggest that the website and the core protocol packages are not sufficiently coupled to justify their co-location in the same repository.

Benefits of Separation

1. 🔍 Clear Separation of Concerns

• Protocol packages: Focused on serialization logic, optimized performance, and protocol compliance.
• Website: Dedicated to frontend concerns such as documentation, user experience, and education.

This separation aligns with the single-responsibility principle and avoids unnecessary coupling between unrelated concerns.

2. 👥 Improved Contributor Experience

• Frontend developers will feel more confident contributing to a standalone React codebase without needing to navigate complex protocol internals.
• Protocol contributors will not be distracted by frontend-related PRs, issues, or CI workflows.

3. 🔧 Tailored CI/CD Workflows

• The website repo can have its own:
  • Build and deploy pipeline (e.g., Vercel, Netlify)
  • Linting and testing setup
  • Preview deployments for pull requests

This improves developer velocity and decouples release cycles.

4. 📦 Better Versioning and Stability

• The site can track stable releases of the SSZ packages.
• It avoids the risk of presenting misleading or outdated information from old versions used internally.

5. 🔗 Greater Transparency and Openness

• Contributors can clearly see the purpose of each repo.
• Newcomers can discover and fork the site independently of the protocol codebase.
• It encourages community-driven improvements to UX, documentation, and examples.

Proposed Plan

Repository Name

ChainSafe/simpleserialize.com

Migration Steps

1. Add new remote to Git repo pointing to ChainSafe/simpleserialize.com and force push.
2. Remove all packages other packages
3. Move packages/simpleserialize.com to root level
4. This approach will preserve git history for the website.
5. Remove the packages/simpleserialize.com from original repo.

Summary

Extracting the website into a dedicated repository aligns with best practices for open-source project structure, improves contributor clarity, reduces cognitive overhead, and encourages clean architecture. As the project matures, this separation will help scale both the frontend and backend efforts independently. I recommend proceeding with this change in the near term to improve long-term maintainability and community involvement.

[wemeetagain]

We had a private discussion, we have consensus to move forward with this (after/ensuring that #465 gets included somehow)