Is Preact 11 dead?

[ndt080]

Preact 11 has been under development for 4.5 years. Preact hasn't had major updates for about the same amount. The Compat package uses Preact 17, which already requires many packages to override peer-dependencies.
Are there any update announcements planned in the coming years?

[marvinhagemeister]

Preact is far from dead. We just ported most features we had planned back to Preact 10.x . Thanks to Preact's addon architecture we can add major new functionality through addons without causing breaking changes. Take signals for example, which are a major update to the way state is managed in an application.

Not everything happens in this repo as well, like our SSR renderer preact-render-to-string just received a pretty significant update to enable streaming rendering.

Now of course we could always bump the version number to make it look more exciting, but we're strict believers in proper semver versioning. So we'll only move to 11 when there really are breaking changes.

When it comes to React compatibility we're mostly focusing on libraries, less on copying React itself (React already covers that space pretty well). On top of that we feel like many recent developments in React itself are better and more elegantly solved with signals which remove an entire class of problems.

[ndt080]

I agree with you that Preact is not dead. It was about the development of version 11, the setting of requirements for which began back in 2020. I recently migrated a fairly large in-house project from React to Preact for performance reasons.

Preact currently has a number of issues that have not been resolved in any way:

• preact/compat does not perform its function properly. There are a number of large libraries in the React ecosystem that have the wrong behavior or don't work at all. For example, the radix packages.
• signals have undescribed behavior in the documentation.
  As far as I remember, passing a signal and concurrently a state from the useState hook as component properties disables the property validation mechanism and the component will not update when the useState of the state changes.
  From my observations, signal lifecycles do not coincide with state and component lifecycles. What I mean by this. For example, we have an array of elements that we want to render. We pass only indexes and the signal itself through context as properties of the list elements. When we change the size of the list, there is a high probability that computed functions will get an error that the element is not found.
  For many projects it is necessary to use 2 reactivity systems at the same time. Signals do not have hooks out of the box that would allow to change from useState to Signal. This is especially reflected in state management libraries (stores). A hook like useSyncExternalStore that would return a signal is needed. Currently we have to write 100500 different abstractions through other hooks, which creates unnecessary calls and sometimes rerenders.

Since Preact emphasizes on signals, is there any consideration to create a Preact mode without virtual DOM similar to Solid.js, Vue Vipor? I think this is what is expected from Preact 11, but after looking at issues on Preact 11, I haven't seen anything like this.

[rschristian]

preact/compat does not perform its function properly. There are a number of large libraries in the React ecosystem that have the wrong behavior or don't work at all.

I think you've misunderstood the goal. 100% compatibility is impossible, as then we'd just be a reimplementation of React, and therefore not a goal of the project. Instead, we aim to be as compatible as possible while also achieving our other targets for perf, size, etc. This is listed in multiple places in our docs.

For example, the radix packages.

For what it's worth, Radix has gotten comments from the React team due to how deep they reach into React internals -- so long as they do this, support will be pretty shakey.

[JoviDeCroock]

Let me first address a few comments before getting into the v11 part of things.

There are a number of large libraries in the React ecosystem that have the wrong behavior or don't work at all. For example, the radix packages.

Oh really, mind pointing us to them then? Afaik there's only a handful and it does the work for 90-95% of libraries...

signals have undescribed behavior in the documentation.

Did you ever create an issue for this on the signals repo?

From my observations, signal lifecycles do not coincide with state and component lifecycles.

That is intentional, signals are currently synchronous, we welcome any RFC to change that with proper reasoning.

but after looking at issues on Preact 11,

You mean the umbrella issue? The goal of Preact 11 was mainly to move to a backing node structure which would opt most people out of a lot of the GC work going on in JS.

I love that folks ask for v11, I have dedicated a lot of my time on v11 and I have backported many improvements that we discovered in v11 to Preact X. This is pretty beneficial to most of our users as it solved long-standing issues like

• Event bubbling to new nodes
• Diffing structures that did not work correctly
• Many performance improvements

The above are non-exhaustive but are some of the recent changes in X that were completely inspired from the research we did on v11. Now, am I saying that v11 is dead for that matter? No I am not, we just chose to land these improvements and do more research because who doesn't love free improvements without having to go through major breaking changes?

We have also been spending a lot of time on other ecosystem parts, our render-to-string implementation recently got two new pieces of functionality, renderToStringAsync and streaming rendering which sets us up for a lot of new features.

One of the downsides of moving to this backing node structure is that our extension architecture will change which means that things like signals/prefresh/devtools/... all need to change and rapidly adapt. That is no problem because we own them but there are more community members that own parts of the ecosystem, being on a major (X in this case) that gets maintained and improved is a sign of stability and honestly, we love that!

I see that you are expressing desires for v11, which I haven't seen expressed in any RFC's or issues, I encourage you to write them so we can collaborate and get them in wherever you like.

TLDR: all these explorations landing in Preact X have enabled us to see where it bugged/... but also enables us to look further in terms of ambitions... Maybe the Preact 11 we envisioned back then is dead, but maybe in the future there's a better one. I for one, appreciate the stability of being able to stay on Preact X.

[ndt080]

I have no goal to belittle Preact's development or the work of the developers. 11 is just a number, but discussions about it have existed for a very long time. At present it is almost impossible to understand the current state of preact without examining the release notes. The same issue "The road to Preact 11" has discussions every half a year. You don't hear about preact at all right now, and the blog on the official site is empty. I enjoy Preact. I created this discussion to clarify the situation, because before I thought that Preact 11 was a new branch of Preact development, and that research on it had been going on for a long time.

Some of the problems I described already exist in the form of other users' issues. The lifecycle problem was discovered by me recently.

By preact/compat issues, I include the problems of installing packages when you can't install them because of React 18 (and soon react 19) as peer dependencies.

"pnpm": { "peerDependencyRules": { "allowedVersions": { "sonner>react": "17", "sonner>react-dom": "17", } } }

This situation is common. The implementation of the useSyncExternalStore return signal is self-explanatory. The development of signals has stopped at first glance.

I, like many developers, cannot understand the direction of Preact's development, for it is not clearly stated anywhere.

[rschristian]

For a bit more context: https://preactjs.com/blog/preact-x

At present it is almost impossible to understand the current state of preact without examining the release notes

Reading the release notes and/or chatting w/ the maintainers (we have a Slack here) is always going to be the best way to understand the details of the current state of a project, Preact or otherwise. We'll continue to release notices when we feel they're important enough to be warranted, but outside of that, we're still happy to answer any questions when & if you get them.

[rschristian]

React 11 has been under development for 4.5 years. Preact hasn't had major updates for about the same amount.

I assume you mean Preact, though this doesn't really make sense -- how would Preact have a major version w/out releasing v11?

Regardless, it's also worth mentioning that by no means has Preact 11 been under active development for 4.5 years. As Marvin mentioned, with so much being able to land in v10, v11 has, by and large, just been an occasional testing ground for a few "nice to haves" like dropping IE11 support, using some newer JS features, etc. There's nothing too exciting there as the exciting stuff has already found a home in v10.

Once we feel there's enough breaking changes to make v11 worth it (please keep in mind that breaking changes often leave some users behind, which is something we want to minimize), then we'll switch over to more actively developing it.

[ndt080]

I'm sorry, yes, my mistake.
It's not about the version number per se, it's about the meaningful updates behind that number.

[rschristian]

Preact 10 has had 22 minor versions and a few dozen patch releases, which I'd call that meaningful.

10.0.0 is quite different from 10.22.0