astrofordocs VS roadmap

We've built a sample project called Astro for Docs (see source code: GH: Astro for Docs) to showcase how straight-forward and flexible it is to use Astro for Beginners.

Nonetheless, the Astro team is already thinking and working on the build engine. So it will only become better.

Astro shines with statically generated content. Even if there is no SSR or ISR like Next.js, Astro is considering per-page support for SSR in their 2022 Q4 roadmap.

What better time to combine the two, jump on the hype train, and create a Cloudflare Worker adapter for Astro. While looking into creating this adapter, I admittedly got slightly sidetracked; If I can create an Astro adapter for Cloudflare Workers, an environment that's so similar to Service workers, why can't I run Astro in a Service Worker? 🤯. As it turns out, you totally can, and I wrote all about my crazy experimentation in that area here, are you excited for a streaming future via SWSR (Service Worker Side Rendering)? I know I am!

There's currently some discussion ongoing in this RFC discussion on the Astro repository. If this is a future that you're excited for, please do leave a comment to signal some interest to the maintainers. There is a cost, however. There have also been other feature proposals that would make streaming responses impossible, like for example post-processing HTML, or the concept of a element, where a child component can append to the head. Both of these things are not compatible with streaming responses. Although, perhaps these features dont have to be mutually exclusive; maybe renderers could even be made configurable by Astro via the astro.config.mjs:

Since Astro currently doesn't really have a middleware system, it's been kind of tricky to figure out how to protect static assets, or how to kind of... intercept a request.

But this turned out not to be possible yet. Hopefully something like this will be implemented in the future, I created a RFC here.