While I’m glad that Kotlin/JS gets more and more attention, I can’t really wrap my mind around publishing Compose for Web on jetbrains.com as alpha.
To be honest, it is a kinda slap in the face after spending about a year on a multi-platform framework (including client and server side), before putting it into alpha.
When I’ve seen Compose for Web, my first though was? Is it good? Should I switch my company from our own framework (see below) to Compose for Web? Then I’ve checked whats in Compose for Web and realised that it is very far from anything we can use.
JetBrains, please pay better attention to the community projects. I see that you are trying, the library developer survey was great. Still, you are not handling the community properly and that hurts.
If you wrote your post focusing less on your emotions and more on information and facts, then it would be much easier to understand, what do you actually mean. Do you suggest that Compose for Web is not yet ready to be released as alpha? Or maybe that instead of providing their own framework, JetBrains should be promoting yours?
First thing first: I don’t want Jetbrains to promote my framework.
Second: Yes, I mean Compose for Web is not ready to be released as alpha by Jetbrains.
What I would like to see is that Jetbrains does not officially announce projects as “alpha” before they actually reach that phase.
I feel that Jetbrains has an idea where they want to go (or forced to go, think Flutter) and they tell the world that they are going there but there are not enough resources to get there fast:
kotlinx.datetime
kotlinx.atomicfu
Compose For Web
It has a very strong meaning to see something on the official web site in alpha status.
Let me show you through an example what I mean:
Last year I wrote a few Android applications. Other Android programmers said: use Room with LiveData.
Why? I asked. The answer was that Google said, use Room with LiveData. However, all the programmers I asked misunderstood what Room + LiveData does (I actually went into the source code to see what’s happening).
I think you’re employing some definition of “alpha” which is not shared by all.
You said you realized you couldn’t swtich your project to Compose Web, well, that would have been my expectation, to be honest. If it’s alpha no user is expected to do anything “serious” with it.
Anyhow unless you provide some definition of “what is good to be labelled alpha” endorsed by jetbrains and show that compose web doesn’t respect that, there isn’t much of a case.
It’s a project written in Kotlin by jetbrains, but not a part of the language. Think of KTOR, it’s written in Kotlin by jetbrains, but it’s not part of the language.
I didn’t try Compose for Web yet, so I probably miss the whole picture, but I don’t see how what you described does not fit their “alpha” definition. “Alpha” does not mean that the project has all features implemented, it is at least 80% done or something like that. Project stability only specifies how the project is supposed to evolve in the future: in more backwards-compatible way or not.
For me (and apparently for Wikipedia) alpha release means: “you can do something with it”. Not necessarily anything useful, but at least you can see some results.
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
Thank you for the information and the article, it adds a bit more perspective to the problem.
I agree that Android and desktop parts of the compose project can be considered alpha, no problem there.
However, I feel that I am the only one who actually checked what is in Compose for Web. As of now - based on the tutorials - it is the beginning of a declarative wrapper over HTML.
This declares Compose for Web as “Technology Preview”. That’s fine, I will cheer on anyone who works on it, great to see that Kotlin tools are improving.
Remember, my original problem is that Jetbrains officially says it is in alpha.
Truth to be told, I’m getting a bit tired of nicely designed opening pages and then lack of content behind, hence my whole rant.
It is exactly just a declarative wrapper over HTML, that’s all. It’s in alpha because currently it hasn’t been heavily tested to make sure there’s no corner cases, and the API itself hasn’t stabilised because some features (like spans for example) might be rewritten to look a different way in the DSL. The important bit is that it’s just a base and not a fully-featured UI framework, and never will be really.
I agree with OP somewhat.
There are too many Kotlin/Jetbrains libraries/technologies:
in alpha status
not interoperable
failing for very simple sample code
unmaintained?
Besides, what I would expect from JetBrains is wonderful Idea support for their techs. The reality is that eg. the Gradle support of multimodule Kotlin projects felt very experimental, instable and buggy until recently.
Meanwhile they try to reinvent the wheel, eg.
Why spend time to develop a new HTTP engine (ktor) when all platforms have their own implementation? It would be the main purpose of Kotlin/MP to wrap and use the existing implementations.
Why develop a custom GC for Kotlin/Native when there is already a GC implementation for LLVM? Don’t they see how complex and resource consuming is to develop and maintain a GC engine (see the multiple GC implementations of the JVM).
I could go on.
They create very interesting stuff but the quality is sometimes surprisingly low. There are huge number of issues in each product/library/technology.
But it seems that they don’t try to fix those bugs and issues, instead they release another interesting alpha- quality technology.
I was very excited for Kotlin for a long time but after using it for years (for hobby projects only) I’m beginning to lose my enthusiasm
