Svelte VS lit

Svelte's pitch has always been easy to understand. The official site describes Svelte as a framework that uses a compiler so components do minimal work in the browser. Older Svelte copy made the contrast even sharper: move as much work as possible out of the browser and into the build step. That is a powerful architectural statement because the browser receives code shaped around the application, not a general interpreter for a component model.

For teams that can’t migrate fully, Svelte 5 supports embedding Svelte components in Next.js 15 apps using the @sveltejs/react package, which lets you use Svelte components in React apps with zero overhead. This lets you migrate high-traffic pages to Svelte 5 first, while keeping the rest of your app in Next.js 15.

⭐ sveltejs/svelte — 86,439 stars, 4,897 forks

{ "version": "https://jsonfeed.org/version/1.1", "title": "Svelte 5 Migration Patterns", "_svelte_patterns_meta": { "total_patterns": 34, "filtered_patterns": 34, "usage_hint": "Each item._svelte_pattern.search_signatures contains grep-friendly strings..." }, "items": [ { "id": "https://svelte.cogley.jp/patterns/attachments", "title": "Attachments Replace use: Actions", "date_published": "2026-03-08T00:00:00Z", "tags": ["syntax", "all"], "_svelte_pattern": { "id": "attachments", "since": "svelte@5.29.0", "category": "syntax", "frameworks": ["all"], "search_signatures": ["use:action", "use:tooltip", "use:clickOutside"], "replacement": "{@attach (element) => { ... }}", "notes": "use: still works but is legacy. Attachments work on components too.", "release_url": "https://github.com/sveltejs/svelte/releases/tag/svelte%405.29.0", "docs": [{ "label": "Attachments", "url": "https://svelte.dev/docs/svelte/@attach" }] } } ] }

On my computer, the linked benchmark gives the following results.

Object.defineProperty getter: 82M ops/sec, Proxy getter 32M ops/sec => proxy get is 2.56x slower.

Object.defineProperty setter: 14M ops/sec, Proxy setter: 12M ops/sec => proxy is 1.17x slower.

However, in my simple self written benchmark that compares the time it takes to sum the property values (i.e., getter) of 100 million proxies vs plain objects, the result is that the proxies are 13x slower.

When benchmarking the setting of the property value of the 100 million proxies vs plain objects, the result is that the proxies are 35x slower.

My simple benchmark gives results that significantly deviate from the linked benchmark. Regardless, the relevance of the performance implications of proxies should be evaluated on a case by case basis.

Regarding the memoization, I was primarily referring to accessing the getter multiple times (i.e., not necessarily in DOM rendering), which can cause unnecessary computation in Gea (as far as I can tell). In my envisaged use cases, this could often lead to problems (with, e.g., large data sets).

My issues with async mainly relates to developer convenience (i.e., managing the async stuff can be cumbersome). For example, one can use await in a top-level module statement, but not in a class getter. There has been some relevant discussions about this in the context of Svelte, see, e.g., https://github.com/sveltejs/svelte/discussions/15845, https://www.youtube.com/watch?v=1dATE70wlHc and https://www.youtube.com/watch?v=e-1pVKUWlOQ.

Consider this conceptual example (i.e., async computed value):

  store0.url = "...";

Some of them are good (formerly Richard Harris - Svelte[0]) some of them should stop podcasting.

[0]: https://svelte.dev/

I've been very impressed, so far, with Datastar[https://data-star.dev], a tiny JavaScript library for front-end work; I've been switching a personal side-project from using Svelte for it's UI to Datastar, and as amazing as Svelte is, Datastar has impressed me more.

The core mapping engine is MapLibre GL JS, a powerful open-source web map library 3. The front-end web framework of choice is Svelte, which MIERUNE has adopted company-wide as its default stack.

Personally, I (@trueadm) have been involved in some truly amazing frontend frameworks along their journeys — from Inferno, where it all began, to React and the journey of React Hooks, to creating Lexical, to Svelte 5 and its new compiler and signal-based reactivity runtime. Along that journey, I collected ideas, and intriguing thoughts that may or may not pay off. Given my time between roles, I decided it was the best opportunity to try them out, and for open source to see what I was cooking.

TypelessForm — an npm package that adds voice input to any existing HTML form. It's a web component built with Lit. You add one custom element to your page, a mic button appears, users speak, AI fills the fields.

I am a web component developer, so I also have to wait until each of my web components is defined and has run its first update cycle before taking a screenshot. I use Lit which definitely helps a ton. Lit has a handy updateComplete property that is a Promise that resolves true each time the component render cycle is completed. But what if there are child web components in the shadow root? Waiting until every component has completed its render cycle is another way that false positives can plague us. There is just no simple way to know for sure, so we setTimeout for some random number and hope its long enough.

Kigumi takes a different approach. It’s built on Web Awesome, a library of 70+ production-ready web components powered by Lit. These are real HTML custom elements that the browser understands natively. Web Awesome also ships with an excellent design token system and layout CSS classes, built entirely on CSS custom properties, giving you full control over colors, spacing, typography, and more.

Let's take Lit, a Web Component framework that my team uses as an example. An experimental server-side rendering feature exists that relies on the declarative shadow DOM, but for correct hydration, components must be adhere to certain lifecycle constraints. For instance, if certain rendering logic is placed in improper lifecycle callbacks, a component may render as expected in Storybook but fail during server-side rendering. This results in significant time spent debugging discrepancies between development and production. Tooling for static analysis, such as linting and lifecycle enforcement, is relatively immature due to the feature's experimental status, and replicating server-side rendering-specific conditions in Storybook is currently not feasible.

Well, introducing Backlit -- a Drupal module that server-renders Lit web components with Declarative Shadow DOM. No Node.js, no containers, no external services. Two lines to install, zero infrastructure to maintain.

I'm a big fan of Lit and Shoelace (I've even donated to Shoelace — seriously, go check it out if you haven't — and consider donating to them, I have). They just didn't cover everything I needed for my projects, so I started building my own.

https://lit.dev/

That's the premise behind Lit! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.

It started at google and now is part of OpenJS.

Framework: Lit (Web Components) + Vite

This decision is a bit tricky to explain, so I‘ll show some code (in Lit because that‘s what I like and use daily.

https://developer.mozilla.org/docs/Web/API/Web_components

If that's not enough, Lit enhances it a bit such that either LitElement and/or litHtml can accommodate whichever style you want: https://lit.dev/