More flexible output options

[pngwn]

Describe the problem

In Gradio we have some relatively complex demands about how the resulting 'application' is consumed'.

Gradio is a python based 'app generator'. You write some python and a web app/ web site is generated. This 'app' can be launched/ run in different modes. The core usecase runs a python server that serves things up for you but you can programmatically instantiate the app as well.

Broadly speaking things look like this:

Name	Architecture	Language	API	Notes
Gradio (SSR)	SSR + CSR	python	app.launch(ssr_mode=True)	Node server serves the HTML file via a python proxy
Gradio (SPA)	SPA	python	app.launch(ssr_mode=False)	Python server serves the HTML entrypoint directly
Gradio Embed	SPA	js/ html	<gradio-app>	This the SPA but with a programmatic/ CE interface. We need the ability to pass props.
Gradio Lite	SPA + custom runtime	js/ html	<gradio-lite>	This is essentially the custom element SPA app but with a modified JS runtime and injected wasm-gradio runtime in place of the python. Also need the ability to pass props.

We currently cover these cases by doing three separate builds:

1. Gradio SSR via Svelte Kit
2. Gradio SPA via custom vite app
3. Gradio Lite via custom vite app

We additionally parse the SPA's generated HTML page to create a programmatic way to initialise the SPA in order to support embeds/ webcomponent usecases.

This comes with a number of tradeoffs. It triples our frontend build times, balloons the repo with multiple apps, complicates our tooling, introduces inconsistencies between the 3/4 app types, and increases the maintenance burden as we need to update some things in three different places!

While we are sharing a lot of core logic which reduces the maintenance burden somewhat, it still isn't an ideal situation.

We really need some way to have a single build with multiple outputs.

Describe the proposed solution

Purposefully not digging too much into solutions but I'll list a few options:

• Additional Capabilities: It is possible that the ability to provide multiple adapters could address this. This way we would have one build and 2-4 'adaptions' that only produce adapter code but share the app core. Haven't thought it through, might not work.
• Async SSR in svelte - This is actually a limitation for us in general but this support could reduce our reliance on kit and allow us to pursue other options. It could also have ramifications for Kit in general, if Svelte can handle some of what kit is currently doing, kit might be more flexible/ modular which could potentially work for us.

Alternatives considered

• Hack shit
• Write something custom, don't use kit
• Leave things as they are and suck it up
• Adopt the foetal position and sob gently

We are currently doing a combination of these things.

For a holistic solution, the only option we have is to build something custom and migrate away from kit. We have punted this issue temporarily but we'll need to address it in a few months.

Importance

i cannot use SvelteKit without it.

This is partly true, we are using Svelte Kit but this issue is blocking a full migration.

Additional Information

No response