Preact VS lit

> React is a small rendering library

Sorry, can't agree. React is a state management library that also attaches efficient rendering on top of the DOM diff it computes as it propagates the state changes.

This allows React apps to remain so simple (one function per component) and so composable without turning into an unmanageable dish of callback / future spaghetti.

There is a number of other VDOM libraries, but what sets React apart is the data / state flow strictly in one direction. This allows to reap many of the benefits of functional programming along the way, like everything the developer sees being immutable; not a coincidence.

Regarding the size, preact [1] is mostly API-compatible, but also absurdly small (3-4 kB minified), actually smaller than HTMX (10 kB). But with preact you likely also want preact-iso, so the size grows a little bit.

[1]: https://preactjs.com/

Performance and user experience have become the lifeline of modern web development. Two libraries that have gained immense popularity among developers for developing interactive user interfaces are React and Preact.

For rendering the map, I went with Preact and deck.gl.

This command creates a new Vite project with React. Feel free to replace “react” with “vue” or “vanilla” if that’s more your jam. Svelte, Preact, Qwik, and others are supported, too!

Note: Astro supports a variety of popular frameworks including React, Preact, Svelte, Vue, SolidJS, AlpineJS and Lit with official integrations. While for other frameworks e.g. Angular and Qwik, you may still benefit from this tutorial and you would need to further set up the community maintained framework integrations.

GitHub | npm | website

In this post, we get to know more about Preact, one of this year's trending libraries. And we'll compare it to React to see which one suits better for our projects.

Similarly to Promises/A+, this effort focuses on aligning the JavaScript ecosystem. If this alignment is successful, then a standard could emerge, based on that experience. Several framework authors are collaborating here on a common model which could back their reactivity core. The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

Those who want to develop a library that can be used by any other reactive framework. I often see SignalLike type that tries to subtype it.

https://github.com/preactjs/preact/blob/757746a915d186a90954...

The official Preact documentation.

This works but it's not a good idea to create these manually. Since that creates a lot of maintenance and we can run into out of sync issues with the api. To make this less tedious. Both Lit (see here) and Stencil (see here) provide a cli to create these automatically. However the need to create these wrapper components in the first place is additional overhead. If the framework of your choice properly supports web components you shouldn't have to create wrapper components.

Lit - A library that helps you build native web components

In this example I will be using Lit, but these features and principles can be applied to any environment.

NOTE: The code examples are using Lit, but the principles discussed here can be applied to other libraries and frameworks.

Lit is a library for developing Web Components, mainly developed by Google. According to the official introduction, the Lit development team participated in the formulation of the Web Component standard.

Lit is a small library, built on top of web components, that makes it much easier to build interoperable web components. The team released Lit version 3 last year, and I just got around to trying it out. I'm impressed with what Lit is capable of. There are a few things missing that I'd want to see before building out a major application, like a router API, but it seems like a great fit if you need to build some web components to drop into an existing site. It might even be nice for a framework agnostic design system.

I dig WebComponents because I love building on standards which promote interoperability across frameworks and have long term lifelines. Standards reduce platform + dev lock-in and reduce framework balkanization and frankly chaos in many cases. You are a better developer if you understand the root standards and core systems, which WebComponents get you closer to.

I also like the Lit Framework (https://lit.dev/) from Google which is rarely mentioned but it is quite nice for some of the simplifications and extras you might need when building them but it doesn't get in the way or try to take over your entire domain with dev-lockin.

Whether going direct to WebComponents or a higher level simplification like Lit, they really are a freedom from dev lock-in that is nice to see.

For a basic tree with, I prefer using a menu with custom-rendered menu items using a custom Lit element, as I will demonstrate in this example.

Although web components offer a modular and reusable approach to UI elements, these challenges can limit their viability. However, if supporting web components is a requirement, you can use Mitosis to generate them from a single source of truth. Mitosis supports Stencil, Lit, and raw web components as outputs.