Look into using a component framework

[seancdavis]

The nunjucks solution is cool, but as it's growing, it's starting to feel like it's getting in the way. I'd like to be able to work more consistently and efficiently. Having the ability to test with Storybook would be a bonus. This is at least worth a spike.

Adding it to Fun Features. It's not fun, but it's also not entirely necessary, so I'd rather it wait a bit.

[seancdavis]

I've been considering this for awhile and decided to do some research on it.

tldr

What I want is to be able to organize my code with components that can be hydrated only when necessary, so as to not ship more JS to the client that necessary.

At this point, it seems like Astro could work. However, Astro is not technically production-ready, and there would be a bit of manual work involved, as components within markdown files aren't supported out of the box.

Because there is so much active development on Astro right now, and because what I am to add to my site is almost entirely static features, styled with Tailwind, I think the right move is to continue using Eleventy. I'll keep an eye on Astro and make the switch when it feels like all the features I need are available. This should make the switch less painful and won't slow down my momentum.

Additional Information

How difficult would it be to render MDX with 11ty?

It can certainly be done, with caveats. For now, this issue is not prioritized, but there is an ability to add custom template extensions. I could use a bundler like mdx-bundler and then render statically with React DOM server. Or I could do it manually.

In either case, it will result in using React DOM server to render statically.

And then we're golden ... unless we want interactivity, which some of these components definitely will. In that case, I'll want to hydrate the components. Currently looking into that. After some more digging, I'm concluding that it can be done, but it's going to take quite a bit of work to get there.

Furthermore, it makes more sense to go with something like Slinkity rather than build my own solution. He's going to be way ahead of me with this stuff and will have community support. But they are in early alpha days.

Can Astro render MDX statically?

Sounds like it was originally prioritized for Astro, but is not available. And I haven't seen mention of whether it's a priority. Here's a recent conversation on the topic.

Is that process different and/or easier with Next?

I've done some testing with Next.js and it will work just fine. Here's a good writeup on behavior. The problem I have is that it just feels like overkill. If I'm using Next.js purely because it's the easiest way to use components, that's not a good enough argument. I'm going to end up shipping all this unnecessary JavaScript to the client.

Does Astro work better if I structure posts as component blocks? And what would that editing experience look like?

Without much testing here (but a lot of experience), I would go so far as to say that any framework is going to work better like this — being able to take structured data and translate that into components. The problem is that it sacrifices the editing experience.

The thing that makes the most sense in this scenario is either a) using Stackbit v2, or b) trying to get Astro to work with Stackbit. The former requires that I use an existing theme, do a bunch of customizations, and the latter sounds challenging and is unlikely to be officially supported.

Can I have a content directory outside the project directory for Astro? This would set me up for being able to use Astro and Next concurrently. I know I can with Next.

Theoretically, yes. Astro has support for dynamic routing, which means you could read content from files and then process them. Eleventy supports paginating items in the _data directory, or custom collections, but I'm not sure either could result in pull the data out of the project directory.

In this way, Astro could essentially do what Next.js can do in terms of static rendering. So I could build out static pages using dynamic routing and process the content as MDX. This is certainly doable. Long-term, Astro will support putting components in markdown files, and that's all I really want.