Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify frontend build #10300

Open
pngwn opened this issue Jan 7, 2025 · 1 comment
Open

Unify frontend build #10300

pngwn opened this issue Jan 7, 2025 · 1 comment
Labels
brainstorming Brainstorming issue needs designing The proposed feature needs to be discussed and designed before being implemented svelte Frontend-related issue (JS)

Comments

@pngwn
Copy link
Member

pngwn commented Jan 7, 2025

I've attempted this once and it is difficult to find a generic solution, we need to either build something custom, hack around extensively, or wait for a generic framework to cover this usecase.

We have pretty complex needs when it comes to the built output, both. in terms of capability and 'shape'.

We have 4 'modes of consumption':

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
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

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 SPAs generate 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 application and build it for different usecases.

  • Generate node app that serves SSR/CSR version
  • Generate HTML entrypoint that serves the SPA (which we can then serve without. needing a Node server)
  • Generate a programmatic interface for launching the SPA
  • Generate a programmatic interface for launching the SPA with modified lite runtime.

The programmatic interface is the major issue right now, the SPA HTML entrypoint is also not quite there but we can kind of solve it, if we had that we could probably make all of the other cases work, although Svelte kit does come with certain opinions about how things are mean to work.

This is half tracking/ half brainstorming. Also chatting with the Svelte team, about this. WIll link the issue.

@pngwn pngwn added brainstorming Brainstorming issue svelte Frontend-related issue (JS) needs designing The proposed feature needs to be discussed and designed before being implemented labels Jan 7, 2025
@pngwn
Copy link
Member Author

pngwn commented Jan 7, 2025

SvelteKit issue: sveltejs/kit#13282

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brainstorming Brainstorming issue needs designing The proposed feature needs to be discussed and designed before being implemented svelte Frontend-related issue (JS)
Projects
None yet
Development

No branches or pull requests

1 participant