Sub Lists

The main advantages of this approach as opposed to proxying Notion's public HTML rendering include:

Notion's public hosting features are woefully unoptimized for standalone hosting.
Notion has some fundamental constraints around supporting fine-grained access control at the page, block, and asset level that any Notion-hosted site will have to contend with. By accessing Notion's API and rendering these pages and assets ourselves, we can bypass all of this fine-grained access control with site-wide access control that makes a lot more sense for hosting public websites.
We've spent a lot of time focusing on the performance of our hosted sites. For starters, we perform aggressive caching both at the API and Next.js levels for Notion data and pre-rendered pages respectively. We also rewrite all Notion image assets to go through a Cloudflare Worker for caching, image optimization, and use some neat tricks like identifying Unsplash images and adding some special imgix query params to them to ensure that all image assets load instantly. 💯
There's definitely room for improvement here as well. One of our roadmap items that I'm most excited about is experimenting with moving from SSR to incremental SSG. The difficult part of this will be keeping these statically generated pages up-to-date as edits are made in Notion, but I believe that this can mostly be addressed with content-based addressing.

What are the advantages of your custom approach to rendering Notion pages?

Notion2Site integrates with Notion at the API level and renders this structured data via Next.js and React.

The main advantages of this approach as opposed to proxying Notion's public HTML rendering include:

Notion's public hosting features are woefully unoptimized for standalone hosting.
Notion has some fundamental constraints around supporting fine-grained access control at the page, block, and asset level that any Notion-hosted site will have to contend with. By accessing Notion's API and rendering these pages and assets ourselves, we can bypass all of this fine-grained access control with site-wide access control that makes a lot more sense for hosting public websites.
We've spent a lot of time focusing on the performance of our hosted sites. For starters, we perform aggressive caching both at the API and Next.js levels for Notion data and pre-rendered pages respectively. We also rewrite all Notion image assets to go through a Cloudflare Worker for caching, image optimization, and use some neat tricks like identifying Unsplash images and adding some special imgix query params to them to ensure that all image assets load instantly. 💯
There's definitely room for improvement here as well. One of our roadmap items that I'm most excited about is experimenting with moving from SSR to incremental SSG. The difficult part of this will be keeping these statically generated pages up-to-date as edits are made in Notion, but I believe that this can mostly be addressed with content-based addressing.

Using structured Notion data as the source of truth gives us a lot more flexibility around rendering than if we were to use the unstructured HTML pre-rendered by Notion as the source of truth.
This makes it relatively easy for us to offer multiple themes, dark mode support, extensions like site-wide search, and interop with a large community of existing React components and NPM modules.