List view
https://feedback.clerk.com/roadmap/b79da4a2-694c-4468-bea2-fb1d3570601a
No due date•62/62 issues closedhttps://feedback.clerk.com/roadmap/b79da4a2-694c-4468-bea2-fb1d3570601a
No due date•43/43 issues closedIn our current architecture, the `clerk-js` package contains the majority of Clerk's Javascript auth SDK. To make urgent fixes and new functionality available to our users as soon as possible, we currently use a 'hotloading' strategy: `clerk-react` (and the other packages that depend on this) hotloads `clerk-js` during Clerk's initialization phase on the browser. This architecture allows our users to benefit from the latest releases without having to rebuild and redeploy their apps; however it also leads to some interesting issues, such as: - SSR limitations. We went to great lengths to seamlessly support SSR on all major frameworks (NextJS, Remix, Gatsby), however, we cannot reliably hotload `clerk-js` in the server during SSR - even if the auth state and user data are available on the server, our prebuild components will only render on the client. - Increased bundle size. Tree-shaking a hotloaded lib is difficult, as we do not know which features will be used during build time. The recent rise of all SSR-enabled frameworks makes it clear that the benefits of making our prebuilt auth components support SSR far outweigh the benefits of hotloading. Removing the hotloading mechanism will allow us to: - Support true SSR for all prebuilt components. - Greatly reduced bundle size for all of our packages. - Greatly increased initialization times, even for CSR-only apps. - Let our users have complete control over the code that is shipped on every release. This milestone will be used to track any tasks related to the above.
No due date•1/1 issues closed