What a ridiculous comment. This is the first major release of SvelteKit in three years; the last major release of Svelte was two years ago.

We definitely do want to move in that direction!

For now, we have add-ons for stuff like drizzle and better-auth (https://svelte.dev/docs/cli/overview) which makes it relatively easy to set up these things without committing the framework itself to a particular set of choices. But I totally agree that a lot of the time it's nicer to just not have to think about it. Our current focus is on laying foundations (async Svelte, remote functions, custom renderers etc) but it's very much on our medium term radar.

I was not aware! That makes me happy!

The docs don't appear to cover progressive enhancement. Is this an oversight?

Hi Richard,

First let me admit that we are still giggling after seeing who send su this question! Big fans! :)

That being said... GolemUI is a client-side form runtime, the visibility rules, validation, computed fields, and repeaters all run in JS.

But we would be very interested in hearing from the community and specially ... from you! Do you think we are missing a big use case? Any advice?

I have to admit I get very disappointed when I see new form abstractions that don't take this seriously — especially if they make bold claims like 'the new paradigm'!. The whole point of forms is that they're part of HTML. You should not need JavaScript to submit a form, period.

I think about the woman in this story — https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven... — as an industry, we've lost our way if we don't care enough about people like her to make our apps work reliably. Not everyone has JavaScript: https://www.kryogenix.org/code/browser/everyonehasjs.html

Moreover, validation is something that belongs on the server. Client-first approaches to form validation are at best duplicative (because you need to repeat the validation on the server) and at worst dangerous (because it tricks you into thinking that's unnecessary).

I also notice that one of the first forms on your website doesn't adhere to common accessibility guidelines — the email field is marked invalid as soon as you start typing. Ordinarily, you shouldn't validate a field until it has been blurred.

So what I'd like to see from people building form abstractions is a) a full stack approach, b) progressive enhancement, and c) adherence to accessibility guidelines.

FWIW this is how we think about forms in the Svelte project: https://svelte.dev/docs/kit/remote-functions#form

Hi Rich,

thank you for taking the time to write this out. This is exactly the kind of harsh but true reality check we were hoping to get by posting here..

With regards to the accessibility point, you're right, marking the email field invalid as you type is not accessible. GolemUI allows you to specify different validation trigger modes via form config: 'blur', 'change', 'submit' and 'eager'. We should change that to 'blur' in our demo.

Regarding server-side vs. client-side validation, we fully agree. Because our library is strictly a frontend tool, we see them as complementary features that can coexist.

With regards to progressive enhancement and the full-stack approach, well, is a much harder architectural hurdle for how our engine currently works, but you have given us some food for thought. We will think about these features.

Seriously, thank you for the feedback!

The Svelte implementation is very inefficient. With a small change I was able to get it to the number two spot on both duration and memory, at least running on this machine. Thyn is in the top spot on both counts — not _hugely_ surprising for a brand new project, but impressive nonetheless.

React, needless to say, languishes at the bottom.

Will send a PR to fix the Svelte implementation.

Thanks for the PRs. Will update it soon.

No, if you're using `adapter-static` (or, if not using SvelteKit at all, just not doing any dynamic server-rendering) then you are not affected. But upgrade anyway!

Great, I love sveltekit for SPA apps... I am just not using any SSR at all. I would like it would become more straightforward to use it that way. I would say that large amount of apps are better of as just SPAs. Internal dashboards, desktop like apps, etc...

If you think 'helping developers meet their legal obligations to build sites that can be used by everyone' is 'woke', then you should go and use a different framework.

Three of us are employed by Vercel, and we're probably responsible for over 50% of commits. The core team is much larger than just us though

> I have no doubts they'll do the same with Nuxt, demanding they implement features that solely exist to pad out hosting costs while providing next to no actual benefits to end users and devs

has that happened with Svelte?

> they now have a monopoly over the most popular frontend meta frameworks (Next, Svelte/Kit, Nuxt, Astro)

this would be a surprise to the Astro team!

> this would be a surprise to the Astro team!

That's my bad, seems my memory failed me here!

> has that happened with Svelte?

Yes. There are features that have been deliberately kept on the platform level to force you to use the platform instead of implementing it on the framework level or guiding you through it with the docs.

https://svelte.dev/docs/kit/glossary#ISR

ISR _can't_ be implemented at a framework level without tying the framework to the platform. The fact that we instead chose to implement it via a platform-agnostic adapter API surely demonstrates the opposite of what you're implying

This would be true if you also provided an adapter-node, which would work on most traditional servers, and most non-serverless platforms.

The fact that you prioritize the vercel one and not the node native one proves what OP implies in my opinion.

It's platform agnostic but Vercel is the only one that supports it? At least that's in the docs I linked.

> $:{} for example is not explicit, I'd much rather use a slightly longer token (like useEffect) to help document what's going on

FWIW you're describing a legacy syntax — modern Svelte has explicit effects, and addresses your other concerns. I think you'll find it's much more to your liking https://svelte.dev/docs/svelte/$effect

This simply isn't going to happen.

Thanks for the work you put into the Svelte platform, competition helps keep ecosystems more honest

Just in case it wasn't clear: I mean this might be enough to prevent bad things from happening.

For sure — just wanted to be totally explicit that SvelteKit will always be platform agnostic