I haven't explored this deeply, but I think this VSCode extension could work: marketplace.visualstudio.com/items?itemNa...

But it needs Svelte support: github.com/zignd/HTML-C...

I'm guessing you want a very small SBOM, and be able to return to the codebase a year later without needing to migrate a lot.

Svelte + Vite is a reasonably safe bet, but nothing can beat pure HTML/CSS/JS if longevity is a major factor.

Anything with OpenAPI integration. It could be Fastify + oRPC, Hono, or maybe Elysia.

I definitely agree with leaning into evergreen or standard concepts. One thing that helps me is to write most logic and state server side so that my JS is evergreen, and the front end is mostly plain HTML and CSS without complex reactivity or local handlers.

Certainly a dependency-free project has the best longevity, but with Svelte you're not too far from JS/CSS/HTML standards, and the ergonomics pay off when you come back to the codebase regularly.

I like the equation, but I could put a light spin on it:

Difficulty to keep up with framework changes =

(number of lines of code that are framework-dependent)
* (number of hobbies you have)
* (number of children you have + 1)

It might be too sensitive because the in-page copilot chat has sample prompts such as, "How do I use Svelte for web apps?" Sometimes Svelte doesn't appear in Wappalyzer for me.

You also have the benefit of not needing to expose your external backend while still providing server-rendered pages to your users.

Remote functions are proprietary to SvelteKit; so they're useful when your remote functions run in a full stack SvelteKit deployment (such as with adapter-node) and then from SvelteKit's server you would access your external backend.

valsinatS olleH

Neat, can you share a playground link?

Agreed with tooling. I'd say Svelte's compiler warnings for accessibility (svelte.dev/docs/svelte/...) do a lot of heavy lifting since they analyze your code as well as any dependencies. And yes, headless UI libraries like react-aria are important, but they only cover one of the 4 WCAG principles.

I'm sorry to hear that. In addition to finding the issue, we could add Sveltia to github.com/sveltejs/sve... and add a health check.

Maybe for users that already have a build step in their project, they can be provided individual CSS or SCSS source code and can import particular source chunks that get prebuilt. Vite handles `@import` to inline CSS for production, for example.

Thanks for sharing. I consider these tradeoffs as well, especially in the context stack-agnostic UI library. Build steps do help a lot with optimizations, but if there are users running different stacks on production (PHP, Ruby, Go, Rust, etc) then the buildless approach may fit better for them.