eyelidlessness

> Note that if we did this we would need a way to differentiate between custom elements that should be server rendered and those that should not. I think we...

Ah I see your point. IMO this would be easier to address with something like #73, as Astro could support multiple props (e.g. `:static :load`) to signal intent for both...

> Dynamic components should probably work the same way as SSR components—include in bundle? On the fence about this I'm too new to Astro to have a solution in mind,...

I’ve thought about ways it could work (also tying in with #99), but after so many boondoggles around tests I’m definitely happy to keep it as small and focused as...

One more note on this because it’s something I’m tracking on my site: I tried a bunch of stuff locally with the contexts used to gather head/hydration to preload as...

I’m still in early caffeination stage but this feels like it might be an easy solve by making Preact a dev/peer dependency? That way for users there should only be...

Some more thoughts, on hydration, compiler, project scope and structure… ### Bikeshedding Is the `@` prefix intended to mirror the future `@key` in React JSX? FWIW I find Solid's use...

The other solutions are viable. The special token solution is used in multipart payloads (eg every time you submit an HTML form with file upload or open an HTML email,...

Another solution that’s probably a much bigger lift would be a huge win if possible: don’t mount with props at all. Effectively memoize on the server. The big cost (for...

That wouldn’t be a problem if the data is actually JSON treated as such, either: - escaped in the way it already is - serialized separately as a hashmap -...