Svelte VS solid

[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 are many libraries and frameworks that try to change the roles like Svelte, that creates precompiled JS code from a source, which is made of a melange of HTML and JS. Finally you have the choice to run your code on server- oder client side.

If your app requires high performance, consider using a framework that is specifically designed for performance, such as Svelte, Vue, or React. If you insist on using Angular, you can still optimize your application by following the tips below...

The strength of V-DOM definitely doesn't lay in performance. It made it easier for developers to write more maintainable interactive UI. Other than that I'd rather think of it as a compromise. Fortunately, frontend web dev continuously progresses and there are initiatives like https://github.com/ryansolid/solid which focus on compilation-time diffing.

You see I work 12 hours a day. 8 hours of that is my professional job where I am a developer on the Marko core team at eBay. Then after some much-needed time with my family, my second job starts where I am core maintainer of the under-the-radar hot new reactive framework Solid.

They’ve been well received, and the core ideas behind them have inspired the likes of Vue’s Composition API and a big part of Solid’s API.

After discovering solid js, I wondered how feasible it would be to write such a framework in Rust. After two days of hacking around, here is the result!

Solidjs UI library uses Proxies in order to make state reactive https://github.com/ryansolid/solid

The key thing to understand though is this is not a React-only approach. I make heavy use of this pattern in my Solid projects as it makes a really nice isomorphic solution and works really well with the next topic...

I wouldn't recommend using this library for all the mentioned reasons. But at sub 60 lines of code, you have all makings of a simple reactive library. And when you consider how many behaviors you can model with it, it should make more sense to you why libraries like Svelte and Solid with a compiler can produce such small bundles.

But what about non-VDOM libraries? At first thought, you might think of a compiler like Svelte or Solid. But this is not the same thing. While they reduce the code into real DOM instructions, which allows them to have a much smaller core runtime, this approach can actually increase the code size per component.

I've been liking solid-js. It's fast, compact, ergonomic and friendly. https://github.com/ryansolid/solid