That’s because there’s fundementally a difference between Compose for Web and any other web framework: Compose for Web simply manages the DOM as a Composition, that’s it! Sure, Jetbrains might eventually build something on top of it, but currently it is simply just an adapter, if you will, that allows you to manage the DOM In a purely Compose fashion and gives you the reactive goodiness with that. It is simply the bare-bones representation of the DOM tree in a declarative style. Now, you can build many many nice and neat things on top of it, but keep in mind that again, it is not a web framework per se.
This confusion actually comes down to a point that Jake Wharton had talked about months ago where basically
Compose actually refers to 2 things, which I’ll refer to as Compose Core and Compose UI from here on out.
Compose Core is a tree management tool. In Wharton’s words:
What this means is that Compose is, at its core, a general-purpose tool for managing a tree of nodes of any type. Well a “tree of nodes” describes just about anything, and as a result Compose can target just about anything.
and so Compose Core can manage the DOM tree since it is just a tree of nodes, and that is exactly what Compose for Web is aiming to do.
On the other hand, there’s Compose UI. Compose UI is the actual multiplatform UI bit that Compose promises. Compose UI is what you see in Jetpack Compose for Android and Compose for Desktop. Both of them can effectively more or less share a big chunk of UI code. If you look at Compose for Desktop, you’ll see that it definitely looks more
alpha in your definition. That’s again because it actually is a proper UI toolkit, unlike Compose for Web, which is a base, if you will, for toolkits to build on.
I guess Wharton’s prophecy that the equivalent naming will cause confusion really did become true. If Compose for Web was called Crane for Web, or if Jetpack Compose UI was called Jetpack Crane and therefore Compose for Desktop was called Crane for Desktop, then this confusion wouldn’t exist