Using Preact?

[shadowtime2000]

So, I want to use the Preact compat layer because it's smaller and my docs website already gets like a 50 perf score on lighthouse so I used babel-plugin-module-resolver to alias it but it seems Docusaurus/Webpack is still adding it to the final bundle lowering the perf score by a lot. Is there any other way to do this that is faster?

[slorber]

Hi,

I'm not very familiar with Preact but it's definitively something we'd like to support, as the docs sites generally don't need the most advanced features of React.

Not sure what should be done exactly but as we do SSR and import React in core, we may need more than just babel aliases.
Here's the Next.js integration: https://github.com/preactjs/next-plugin-preact

my docs website already gets like a 50 perf score on lighthouse

I'm aware of this and want to improve, but keep in mind that the perceived performance is not bad, almost everything on a Docusaurus site works even before the JS is downloaded.

[SethFalco]

Hey @slorber! Just wanted to share my experience with this.

I recently reviewed Preact for SVGO.dev, and the results look promising so we're likely going to adopt it. I have a PR with the steps we took to get it working. (With help from a maintainer of Preact.)

• chore: use preact instead of react svg/svgo.dev#37
• Using Preact with Docusaurus preactjs/preact#4832

However, would you be willing to chime in on the Preact discussion?

We encountered an issue where by migrating to Preact, SSR broke, the output was a CSR application. It seemed to have been caused by a few lines in @docusaurus-react-loadable but neither of us are sure why. By commenting them out, SSR seemed to work again though.

If you have any insight on this, I think it'd be valuable if you could share it! It'd especially be cool if something could be done to avoid the need to patch the package for Preact support.

[slorber]

Thanks for showing it's possible

I don't know why you get that React-Loadable error, but we do need the library. Maybe your patch is opting out of inlining all the required JS modules to the static HTML (so maybe it works, but introduces fetch waterfalls before hydration? need to compare static HTML before/after)

In the future we also plan to leverage RSC and <Activity> so I wonder if it will be possible to preserve the Preact support.

I also commented here preactjs/preact#4832 (reply in thread)

[SethFalco]

I don't know why you get that React-Loadable error

It wasn't an "error" in the sense I got an exception or the build failed. The build succeeded, but upon reviewing the output it was a CSR application. (So the website didn't work without JavaScript.)

Just in case it wasn't clear!

Maybe your patch is opting out of inlining all the required JS modules to the static HTML (so maybe it works, but introduces fetch waterfalls before hydration? need to compare static HTML before/after)

Thank you for the context, I'll compare this somewhere this week to confirm. I believe our landing page does the same number of requests as before, though!

I'll have to actually look at the distribution of JavaScript code/files, though.

---

Thanks for sparing time to look at this!

[rschristian]

It wasn't an "error" in the sense I got an exception or the build failed. The build succeeded, but upon reviewing the output it was a CSR application. (So the website didn't work without JavaScript.)

Not quite; the build was in fact failing, HTML wasn't being returned from the render call, though it wasn't surfacing errors. I'd have to dig into it again but I believe that context for loadable was failing, likely due to invoking the dual-package hazard, and this might've been silently caught & swallowed. As far as I could tell, that context use was largely superfluous (for this very specific use case), hence why I suggested (for now) commenting it out w/ a patch.

I was able to get it to throw an error correctly at some point though it required a lot of finagling with the deps; node_modules really didn't want to let go of react and react-dom 😅