Svelte VS qwik

> One example is being able to pass templates around.

Yeah I agree. It's not a big deal but I kinda miss this from JSX.

There was some discussion about adding templates or even components inside other components but it all feels very inelegant and not very Svelty.

https://github.com/sveltejs/svelte/issues/2940

> The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It's a core part of Svelte that you can't always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale.

The reactivity system in Svelte is really a joy to use, once you get used to it there's no turning back.

But the author did hit one of the ugliest pain points about it. Svelte can NOT correctly infer transitive dependencies when the variable being updated is inside a function. Meaning that the variable itself will be reactive (it will be invalidated every time it's assigned, even inside a function) but Svelte is not using that information to build the dependency graph, and falls back to the order in which the reactive blocks were defined, which may or may not be right.

I created this issue https://github.com/sveltejs/svelte/issues/5190 a couple years ago documenting it.

It's not so common, but when it bytes you it's pretty nasty.

The workarounds I found are the following

These are the workarounds I found:

- a repl with the issue: https://svelte.dev/repl/640736d3c91d40d3971afcc3eef8b25e?ver...

- workaround 1: manually reorder statements, need to figure out by yourself (and maintain!) the dependency graph: https://svelte.dev/repl/3ecd6aa918e045999db32d379270fc1c?ver...

- workaround 2 (my favorite): provide a redundant update as "hint" to tell the compiler that setY updates y: https://svelte.dev/repl/cbf98bb35f5e4dd4b037d13254853c90?ver...

(thanks to TylerRick for this: https://github.com/sveltejs/svelte/issues/5190#issuecomment-...)

in practice it means to do something like: `$: { setY(x); y = y };`

- workaround 3: put the update operations in order in a single block (it's just the workaround 1 with improved legibility, IMHO): https://svelte.dev/repl/074df362bb934312bbe6fd3aeccab771?ver...

I still think we could do better, at least explaining the issue and how avoid to fall into it (perhaps some linting warning?)

But I really hope svelte developers start considering this an issue to solve, it's inconsistent (meaning the variable is reactive but that reactivity is not taken into account to order the operation in "topological order" (Hey, I learnt about that from one of Rich's presentations, see https://rethinking-reactivity.surge.sh/#slide=19) and as I said before, when you stumble upon it is not so easy to understand what's going on.

[1] The question of removing the shadow DOM or creating the topic has been reported at the webcomponents/polyfills repository under issue #82 , and svelte/sveltjs issue #1748 .

I opened an issue on Svelte's GitHub here and they didn't like that feature :)

But if you're going to be guaranteed coding all your components from scratch anyway, i'd recommend svelte instead. Because it has less bloat (no vDOM / less complicated state lifecycle to care about), and is easier to style without other libs like tailwind or vanilla-extract.

The next step is to create and set up a new Svelte project for the ecommerce project. This Svelte commerce will use SvelteKit since it is the recommended setup method.

Svelte is a JavaScript framework that compiles your code into efficient JavaScript that surgically updates the DOM. It is a compiler that converts your code into a more efficient version of itself.

If I were starting something, (or even if I were incrementally moving over pages from a larger project as they were touched), I would use Svelte / Svelte Kit 100% of the time. It's effectively a language (the use of JS/TS, CSS, and HTML together but nicer) with a compiler rather than a runtime framework. It's dead simple and it produces insanely small and performant output by default. Both of those have excellent tutorials you can use right on their website without installing anything.

In 2023 there are a wealth of developer options for front-end: React, Vue, Svelte, Solid and many more.

There's already qwik, that does SSR and then converts the rest of the app into lazily loaded event handlers.

So there are many frameworks that can do SSR/SSG and hence generate HTML for the client. But most of them come with hydration costs. So for our example, we have chosen Qwik because it uses resumability instead of hydration to make the application interactive. Astro would have also been a good choice because it delays the hydration cost until the island is ready. Anything which does not add JavaScript on startup and produces HTML would have been a great choice.

They have different trade-offs sure, where bundling typically creates large opaque blobs of JS used by the entire SPA resulting in large initial download & parsing/execution time which is why it's preferable to only download & execute code needed which is easy to achieve with cohesive modules.

The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests.

[1] https://qwik.builder.io

An example of a framework that uses Hydration is NextJS and one that uses resumability is used by frameworks like Qwik

These days, you almost never need write all of that above crazy stuff by hand. Frameworks like NextJS and Qwik, as well as platforms like Cloudinary and Builder.io, provide image components that make this easy, and look instead like the below:

When you look at the current web ecosystem, you'll see players like Deno, Bun, Qwik all pushing the frontier on performance in their own domain.

Others worth a look:

- Qwik[1]: code is very similar to React, only the interactive parts are sent to the browser, and they only execute on demand (eg when you interact with the thing)

- Astro[2]: probably the most popular “islands” framework, lets you bring your own interactive framework

- SolidStart[3]: doesn’t mention in the docs yet for some reason, but also supports “islands” in SolidJS, which is also one of the fastest client frameworks and also will feel familiar coming from React

[1]: https://qwik.builder.io/

[2]: https://astro.build/

[3]: https://start.solidjs.com/getting-started/what-is-solidstart