We are choosing between Electron and Compose Deskt...

# compose-desktop

[Alexander Suraphel]

We are choosing between Electron and Compose Desktop. What thing I feel will be missing is powerful charting libs. Web has powerful libraries like D3 and other derived from it. Are are great options for compose in that area?

[Colton Idle]

I don't do desktop dev, but in general it sounds like anything java swing based is stuff you're going to be able to reuse.

[Alexander Suraphel]

@Colton Idle aha. How powerful is the swing ecosystem compare to the web? Availability to 3rd party stuff etc..

[romainguy]

There are many many libraries. Swing has been around for 20 years :)

[romainguy]

Look at JFreeChart for instance

[Alexander Suraphel]

@romainguy you’re right! The web is rich with community contributions though. I’ll see if desktop on JVM pales in comparison..

[Alexander Suraphel]

BTW @romainguy do i need to learn Swing to take full advantage of compose desktop?

[romainguy]

The Swing community is/was extremely rich in community contributions too but I haven't paid much attention in the last few years. @Kirill Grouchnikov may have recommendations there

[Alexander Suraphel]

Thanks!

[jim]

@Alexander Suraphel You do not need to know Swing to be successful with Compose Desktop.

You'll need to dabble with Swing a tiny bit if you intend to pull in a swing widget like JFreeChart into your Compose app, but Swing is object-oriented, which means it's a little tedious to write but it is readily understandable for anyone who already knows Java. I wouldn't worry about it too much, you should be able to pick it up as you go along.

[Alexander Suraphel]

Thanks @jim! If you have followed the thread, I’m also interested what we will lose by abandoning web technologies which we can use with Electron.. If you have done web, is it as powerful in comparison?

[jim]

The biggest thing you lose is the ability to target both your website and desktop app, although this is somewhat mitigated by Compose for Web which allows you to build your project as an MPP project and share code for both. Sharing between website and desktop isn't super easy even with electron, but compose-mpp would be more complex.

I suppose with Compose, you get to trivially share with your Android application, so maybe that previous point is a wash on net balance.

The other thing you lose is some amount of stability. Compose for Desktop is still very young relative to a framework like React.js - although things are improving quickly.

However, when I'm making engineering decisions, I try to skate to where the puck is going. And perhaps I'm biased (or maybe I have more insight into the future of Compose than most), but if I were betting, I'd personally bet on Compose. I think the architecture we chose is going to let us do some incredible things in the future.

[Alexander Suraphel]

Thanks @jim for your insight!

[Colton Idle]

"I try to skate to where the puck is going"

– Wayne Gretzky
– Jim Sproch

[Michael Paus]

JFreeChart and its commercial variant OrsonCharts also work directly with Skija and can be used in Compose Desktop. See: https://github.com/jfree/skijagraphics2d

[Kirill Grouchnikov]

Prefacing this with the usual "these are my personal opinions, not to be taken as any present or future plans of any of the companies, blah blah".

Swing is a great, mature platform for writing cross platform desktop apps. It is also an evolutionary dead end, not because it can't be evolved, but because it has been deprioritized some time ago. I wrote about it back in 2008 [https://www.pushing-pixels.org/2008/11/05/sun-setting-down-on-the-core-swing.html] and it's still true today. There have been very few, very minor improvements and bug fixes to Swing since then, but it's dead. Jetbrains has bet on Swing for pretty much their entire line of IDEs, and they've been trying to fix what the platform does not - hence the need for their own runtime [https://confluence.jetbrains.com/display/JBR/JetBrains+Runtime]. On this end, I think they have also realized that they need something a bit better.

I personally see Compose for Desktop as Jetbrains' big bet on their own future for the next decade or so. It doesn't mean that in 2031 their entire product line has been rewritten to be in Compose for Desktop (CfD from now on). But I think this is the goal. The goal of moving away from a platform / UI toolkit that is dragging down their own productivity as a company, and using something that is more productive, but also - something where they can contribute to the overall direction and the feature set much more.

Hence (again, in my own personal opinion), the big investment in bringing Compose to the desktop OS world. Starting from Skiko and Skija as the underlying layers, but also JWM [https://github.com/JetBrains/JWM] for window management and probably JCEF [https://github.com/JetBrains/jcef] for browser integration.

In the short term, knowledge of the Swing world would be beneficial for those parts of CfD that are, perhaps, not as well developed. Good news on this part is that [IMO again] Jetbrains will be seeing the same gaps as you are seeing in your CfD apps, as they want their products to be worth enough for customers to part with their money for.

Now, on a slightly less positive note. Jetbrains is in the business of writing IDEs. These are complex pieces of desktop-grade apps, but they are still a rather narrow subset of all possible desktop apps that you can think of. I doubt that Jetbrains, for example, would want to be in a business of providing a fully functional pivot table, or a fully customizable and internationalized date picker, or a chart library. Or, for that matter, a 2D gaming engine that runs on top of Skija. All of these and more would be, IMO, left to interested developers to participate in bringing to the ecosystem.

The success of this new ecosystem will depend on both the vendors of the platform itself (core Compose and CfD), as well as on external developers building apps - and libraries - in CfD. In the short term, you can take some of the existing Swing libraries like JFreeChart, JIDE, etc - and embed them in CfD via the existing integration with ComposeWindow and SwingPanel. In the long term, it remains to be seen how the ecosystem will look like in 5-10 years. I personally plan to very much to be a part of that ecosystem with Aurora - https://github.com/kirill-grouchnikov/aurora

[spierce7]

The good news is that a large part of the desktop ecosystem will also be able to be driven from the Android ecosystem. I think that will help significantly

[darkmoon_uk]

Consider your actual graph/chart requirement. We needed a graph for real-time sensor data on our 100% Compose Android App (which is in production) and because the spec for our chart was quite focused and well defined, we plotted it ourselves using `Canvas`. Wasn't hard and (with the guidance of our UI/UX'er 😁 ) ended up looking great.