Svelte/SvelteKit parity beyond the initial renderer

[cervantesh]

Summary

OpenUI already has initial Svelte support through @openuidev/svelte-lang and examples/svelte-chat, which appears to address the original Svelte renderer request in #302.

I would like to help improve the next layer of Svelte/SvelteKit parity with the React-first experience, but I want to align on scope before opening implementation PRs.

This is intended as a roadmap/discussion issue, not a request to merge one large cross-package change.

Existing related issues

• Svelte Renderer #302 added/requested the initial Svelte renderer and SvelteKit example. This issue should not duplicate that work.
• Add tool provider support for Vue #498 tracks tool provider support for Vue, which looks like a similar parity concern for non-React runtimes.
• Improve DX for Schema & System Prompt Generation Across Backends #368 discusses DX for schema/system prompt generation across backends.
• Add tests for the React OpenUI Lang renderer #549 notes that Vue/Svelte renderer tests already exist and can be used as references for React renderer tests.

Current state

From the current repo structure and docs:

• @openuidev/svelte-lang exists.
• examples/svelte-chat exists as a SvelteKit + AI SDK example.
• The main CLI create flow is still documented as scaffolding a Next.js app.
• React has a broader product surface through:
  • @openuidev/react-lang
  • @openuidev/react-headless
  • @openuidev/react-ui
  • examples/openui-chat
  • CLI scaffolding

Proposed contribution areas

I would like maintainer feedback on splitting this into small PRs:

1. Svelte/SvelteKit parity matrix

   • Document what is supported today in Svelte/SvelteKit vs React.
   • Separate intentional React-only areas from gaps that should be closed.

2. Svelte renderer/runtime parity audit

   • Compare @openuidev/react-lang Renderer behavior with @openuidev/svelte-lang.
   • Check advanced runtime concerns such as:
     • tool provider support
     • Query / Mutation execution
     • loading and error reporting
     • state hydration
     • parse callbacks
   • Close small gaps where maintainers agree they should be supported.

3. SvelteKit example hardening

   • Make examples/svelte-chat a strong canonical SvelteKit reference.
   • Verify setup docs, environment variables, generated prompt flow, dev/build commands, and examples.
   • Add tests/checks only where they follow existing repo patterns.

4. CLI SvelteKit scaffold

   • Add a create option such as openui create --framework sveltekit, if maintainers want the CLI to support framework selection.
   • Reuse examples/svelte-chat as the source template if that fits the current CLI architecture.

5. Future discussion: Svelte headless/UI packages

   • Discuss separately whether @openuidev/svelte-headless or @openuidev/svelte-ui should exist.
   • I would not start with new packages unless maintainers want to expand the public package surface.

Non-goals for the first PRs

• No large all-at-once parity PR.
• No duplicate implementation of the initial Svelte renderer already covered by Svelte Renderer #302.
• No new public Svelte UI package without maintainer approval.
• No broad refactors of lang-core or React packages unless needed for an approved scope.
• No attempt to copy React APIs 1:1 where SvelteKit conventions call for a different API.

Suggested first PR

If this direction is acceptable, I suggest starting with either:

1. a small Svelte/SvelteKit parity matrix doc, or
2. a focused audit/fix PR for @openuidev/svelte-lang renderer/runtime parity.

Questions for maintainers

1. Is this next layer of Svelte/SvelteKit parity something the project wants to accept incrementally?
2. Should the CLI grow a SvelteKit framework option, or should SvelteKit remain example-only for now?
3. Should tool provider / Query / Mutation parity be handled for Svelte similarly to Add tool provider support for Vue #498 for Vue?
4. Are new package surfaces like svelte-headless / svelte-ui in scope, or should contributions stay limited to svelte-lang, examples, docs, and CLI?
5. Which first PR would be most useful to review?