Desktop Applications C# vs Java

Developing Desktop Applications is more fun in which language  C# or Java?

by "Fun" here I mean "ease of development and more freedom and customization in design"

Also, I recently came across a YouTube Video on the official Java YouTube Channel titled "JavaFX in the Web"


So does this mean we will be able to deploy our JavaFX desktop applications onto the web directly ?
does this also mean our JavaFX Desktop applications are now cross platform??

so, does Java has edge over C# in this case??

I know I've posted this in the JFX forum, but I am expecting mature and unbiased opinions

Kind of depends on your target audience.

Offhand, I'd vote C# (or C++! or Rust!) for desktop apps, as they don´t require installing and launching a heavy virtual machine to run.

On the other hand, C# apps are a hard sell and C++ at least isn´t cross-OS portable without buying in to one of the third-party "universal" libraries, which complicates the project considerably.

Java, of course, is "write once/run anywhere", but, again, you have to have a JVM launched to run Java apps.

Pure desktop apps are largely overshadowed by webapps or local webapps (Spring Boot) these days. They're more friendly to users with different OS's and hosted webapps don't have to deal with ensuring that the user-side code is up to date.

C# apps are a hard sell

why do you say that?

doesn't C# dominates the EU region ? specially in the Govt. , MedTech. industries and other niche areas??

Because C# is first and foremost the property of Microsoft and other OS communities - especially Linux - distrust Microsoft properties. After all, they tried (and failed) to hijack Java with J++.

Tomboy Notes is a very useful ¨sticky note" desktop app. However it was written in C# and people were upset. So upset, in fact, that a re-engineered clone of it was written (In C++) and is distributed as gnote. The gnote program, unlike Tomboy is specific to only the Linux OS. The original Tomboy was rewritten in FreePascal as tomboy-ng (it's OS-neutral) and the C# code version was discontinued in 2017.

FreePascal's last stable release was about 4 years ago, but commits to its github project have been made within the last hour.

What about javascript, html and css? Everyone has a browser, and css is mighty powerful, certainly in combination with javascri[t.

Piet Souris wrote:What about javascript, html and css? Everyone has a browser, and css is mighty powerful, certainly in combination with javascri[t.

That requires some sort of server, which locally would often be either NodeJS or SpringBoot. NodeJS in my experience, has proven to be rather fragile, though.

True, I use a program called 'TinyServer'. I used to use Google for that, but they stopped that service. Any IDE will run the lot as well.

Piet Souris wrote:... Any IDE will run the lot as well.

Bear in mind, however, that Swapnil just recently posted a question looking for a lightweight Java IDE and ended up deciding to use a program editor (Geany) instead. So using an IDE to run desktop apps isn't likely to appeal here.

Now as far as it goes, you can strip out the programming parts of Eclipse and use it as an application container (or use something like Apache Karafe), but then you still have the JVM plus the container plus the app.

Then again, the original question was "Developing Desktop Applications is more fun in which language  C# or Java?

Development "fun" isn´t necessarily the same thing as "happy users". But that's a lot more subjective.

Personally, if I was in it purely for fun and not rapid development, I´d consider Ada, but Ada doesn't really have a standard GUI API. Failing that, my choices are usually:

A) NodeJS - fast simple webapps
B) Python - fast algorithmic programs
C) Java      - Industrial-grade apps

Anyway, it is simple to use github or w3s as server.

Tim Holloway : "isn´t cross-OS portable without buying in to one of the third-party "universal" libraries"

They have something called project Avalonia, which makes desktop applications portable, one codebase for all platforms

Project Avalonia is a third-party "universal" library. For the .Net framework.

And, as I said, C#, which is as far as I know the only .Net language to be available outside Windows, is not popular outside Windows. Gtk is a popular "universal" GUI library for C++, though. Apps written with Gtk include the GIMP and Inkscape graphics editors, Gnucash accounting, Evolution (similar to Microsoft Outlook email client),  a whole raft of desktop utilities, including both Tomboy Notes and gnote, and many more.

Then there's the Qt universal framework, employed by Ableton Live, Autodesk, Bitcoin, The Calibre document manager, FreeCAD, Mathematica, TeamViewer, Oracle's VirtualBox, the VLC media player,  and more. It does have some license constraints, though.

It isn´t non-portability that keeps people from writing C# code for Mono, it's the fact that C# is beholden to Microsoft.

That might seem like an odd reason, since Java was once beholden to Sun Microsystems, but Sun was never accused of using its language products to screw over competitors. If it had, Java would likely have bombed. As it is, Oracle, which is more Microsoft-like, has seen a lot of shops flee their Java in favor of OpenJDK. Though much of that is simply license costs, as Oracle has not, so far, tried to warp the Java language for their sole benefit.

it's the fact that C# is beholden to Microsoft

Is it because Microsoft has had an image of Evil Tech Gaint??
If yes, hasn't that still changed over the years??

It's because Microsoft has a history of tainting things. J++ was one of the most egregious examples. They took the Java language and replaced its "write once/run anywhere" libraries with classes that tied directly into the Windows OS API. So no other OS could run apps written for it.

A more insidious crime was when they put special code  into Microsoft Word to ensure that it was running under Microsoft Windows.

In other words, Microsoft was acting as a "tar pit" designed to suck you into a single-vendor provider for all your applications and services. Hardly the only corporation to attempt that, and Oracle has some history there as well, but Microsoft did it bigger and more completely than anyone excepting possible IBM in its mainframe heyday.

While core C# is OS-neutral, it's perilously easy to transition it into invoking Windows-only class libraries, and that's why it hasn't caught on outside the Windows world. The fact that, yes, Microsoft was once actively campaigning against the "communist" "cancer" of Linux didn't make them many friends, either.

Again, while Oracle has its own complaints, Java is defined by a multi-participant process. The .Net framework is solely dictated by Microsoft itself.

I forgot to chime in here when I saw the post notification but I'm back! It seems nobody has actually defended JavaFX yet so I guess that falls to me. I'll have to watch the video later since it's kind of long. I'm not sure what you mean by running JFX in a browser unless he's talking about WebAssembly or something new.

Tim Holloway wrote:
Offhand, I'd vote C# (or C++! or Rust!) for desktop apps, as they don´t require installing and launching a heavy virtual machine to run.

I'm not understanding why JavaFX gets a bad mark for a "heavy virtual machine" but C# desktop, which also runs in a VM, doesn't? If you're thinking about AOT/Ahead Of Time compilation, I'm pretty sure we can do that in both cases. Most of the time I doubt it's needed, especially for a desktop application, and there are theoretical downsides to that vs JIT (I have no idea how that plays out in reality).

Also I'm still standing by my opinion that C++ and Rust aren't productive choices for a desktop application. Any higher level language has a large productivity advantage for that (being a major reason Java, C#, etc. exist in the first place), and nothing has changed there with Rust. What has changed for sure is the hype bubbling up with Rust, and as hype often goes, it doesn't make any sense. Rust is even less productive than C/CPP, and compiles slower! Why would I throw away the productivity of a high level language now when a major reason we use high level languages for the last 25 years is to be more productive than using C/CPP? I don't even see C/Rust as a serious competitor for desktop dev unless you need cutting edge graphics performance, as with a big budget game. (And most games today don't need that, look at how many are built with Unity/C#.)

I used to do C++ desktop application development many years ago. I know Tim is well aware that back then Java UIs were usually Swing--and Swing apps were/are absolutely horrible compared to JavaFX today. CPP was awesome at the time and a good option for desktop stuff, but it would be painful to switch back today. It's hard enough to finish a project even with the modern high level language productivity tools. This is one thing I say many Linux desktop enthusiasts are just wrong about, native desktop applications aren't the best default option unless you have specific needs. Non-developers love to ignore dev productivity factors.

---

But back to the original question of C# vs Java. Which is more fun between these two will likely depend on which you're better at using. I say that because both are solid choices for desktop development--so the one you're more productive with will probably come down to which you're more familiar with.

C# is a pretty good language that I've used a little, very similar to Java and I don't dislike it at all. I don't remember the history but it seems they basically took Java as the model and built C# to compete. For full disclosure, I do prefer Java/JavaFX, mostly because I want to avoid Microsoft (also I know JFX better). When I code in C#, I feel that Java's documentation and the sheer size of the Java ecosystem makes using C# feel slightly less productive. Maybe I just wasn't looking in the correct places or it was just bad luck; C# documentation seemed relatively thinner.

And I still say the C# code convention where they CapitalizeMethodNames the same as classes is confusing, evil and objectively wrong--fight me!  

Being a Linux user, I still can't trust Microsoft's intentions. But big progress has been made on the C# Linux ecosystem and I've run Avalonia C# desktop applications just fine. Both Java and C# are under the influence of corporations I consider untrustworthy, but it feels like Java is under that less these days, with a more diverse and distributed community.

So I would say that C# + Avalonia and Java + JavaFX are pretty close in terms of capability. Avalonia's GitHub does mention WebAssembly, so if that's what the presenter on the JavaOne video is referring to, I guess they can both do that. But will WASM ever see widespread adoption? It's taking forever and I kind of doubt it. When I look at the decisions the "front end web dev community" has made... I don't think they even want that space to improve. They seem to like things being a huge mess!

I have no idea what C#/Avalonia is capable of for 3D stuff, but at least as of a few years ago it was possible to integrate JavaFX with a performant 3D engine suitable for gaming. Then again, if you're doing 3D you're probably doing gaming - so C# + Unity has that covered. (I wonder if you can run an Avalonia UI inside a Unity application instead of using Unity's clumsy UI? Or maybe Unity's UI is more capable than I recall...)

It would be hard to go wrong with either C# or Java. But as usual it depends on what you're building, too. There's always exceptions to broad guidelines.

Just for fun here's a strongly opinionated TL;DR with some bonuses thrown in for the LOLs:
- Java Swing sucks and is 100% the wrong choice for a Java UI these days!
- C/C++ are just bad unproductive choices for a desktop UI unless you have specialized needs!
- Rust for desktop applications... hell no, this is a horrible mistake!
- Python UIs... get out of here with that rubbish!
- Go desktop development... can you find us an example of one?
- JavaScript + Electron desktop application... really, are you serious? Really?!
- C# is "okay" for desktop applications, a solid choice for gaming especially!
- Java + JavaFX is great! An excellent under-rated choice, suffering under the failed reputation of Swing, which doesn't get the attention it deserves!

JavaFX wasn´t discussed because, well ... JavaFX wasn't discussed.  Certainly it has its fans, although it's tarnished because the support infrastructure is iffy. And while you may hate Swing, I have no problems with it, although some (such as Eclipse and Pentaho) prefer SWT.

The main virtue of Rust is that it's more protective than C++. Apparently I'm the only person in the world who has never been bitten by C++ memory leaks.

C and C++ may not be good "git 'er Dun!" languages (same for Java), but they are still generally preferred for major commercial desktop products. Partly because you can find lots of talent, partly because they are extremely efficient, and finally because they can run as bare self-contained OS apps without a massive external language environment.

As for Go, a lot of stuff in Go is under the covers. For example, the Github clone Gogs/Gitea is a Go webapp. Netflix, DropBox and Uber are among the products with Go components.

Apparently no one loves VB.Net

Lou Hamers wrote:- JavaScript + Electron desktop application... really, are you serious? Really?!

Yes. I don't know about that electron-thing, but javascript with css can be an excellent (and very powerful) combination, depending on what you need.  And it is readily available, since everyone has a browser.

"JavaScript + Electron desktop application"

I've heard about this but, No offense to JavaScript but I'm personally not a big fan of Electron Desktop Applications, they are very resource hungry and not as snappy as other available options out there, I mean just look at Discord for example..  
but for Web Apps yes 👍🏽

My post was hyper focused on desktop development. It seems wrong to have this post put in the JavaFX forum, with a JavaFX video, and the OP asking about JavaFX, but not say much of anything about it.

One problem with Swing is that unless you're a JetBrains (who I think had to heavily customize Swing, which is no trivial task), making a modern looking application is a serious pain. And SWT UIs are just hot garbage... still to this day Eclipse doesn't have a very good dark mode, and looks seriously outdated. The inability for either of these to use CSS-like styling is a big hurdle.

With JavaFX, making something look modern is fairly trivial - mostly just a little CSS. Combine that with FXML for your less dynamic layouts, and it's not even a fair competition anymore. Except with Avalonia+C# -- that's a closer match up, with the only major downside being ties to Microsoft.

So yeah I was specifically talking about desktop applications when I was taking a swing (no pun intended) against Go, Rust, and so on. I'm aware of what they're better at... but that's not the topic here.

As the Spartan king in "300" calmly explained, "This is desktop development!" Or something like that, I may have gotten the Leonidas quote slightly wrong.

The desktop application front is a completely different story. JavaFX is definitely under-rated.

To be fair, Electron/JS is above the water line and not a *horrible* choice for desktop applications, but just barely. I just can't justify using an objectively worse language when you're not forced to use it, as in a browser. At least you can build a modern looking interface with it without bending over backwards to do it, which is more than you can say about languages that aren't targeting this type of thing.

The first WYSIWYG Java UI designer was Visual Café, from Borland, circa 2000. That product, alas, is no longer with us. And it did require Borland-specific support classes to run. Since I wanted open-source, I wrote a Perl script to process the Borland code into portable code.

IntelliJ added WYSIWYG development for Swing around 2006. At the time, at least, the code was pure Swing with no JetBrains additions. I checked very carefully.

I see that these days JavaFX is hosted as part of the OpenJDK source archives.

The last desktop app I developed in Java was written using JavaServer Faces as its UI.

JavaFX's WYSIWYG is first class, Scene Builder, now supported by Gluon. I've used a number of such UI designers over the years and Scene Builder's definitely the best of the bunch.

Not sure what you landed on; JFX used to be under OpenJDK, but was broken out years ago along with a bunch of other stuff. The project itself is called OpenJFX now.

There's even a modern website: https://openjfx.io/

I've tried scene builder recently, I suppose it is only for the UI, you don't get to tie events / functions with buttons isn't it?

Swapnil Mishra wrote:I've tried scene builder recently, I suppose it is only for the UI, you don't get to tie events / functions with buttons isn't it?

Yep you can!

Click on the "Code" part of the Accordion on the right side. You can also get a plugin for IntelliJ which will auto-generate or update all that stuff for you in the controller too. The "controller" class is specified on the very bottom of the LEFT accordion under "Controller".  A good JFX plugin will also create fields for any components that you give an fx:id, annotating them with @FXML so they get auto-injected.

I imagine other IDEs also have similar plugins but I only use IntelliJ for JFX stuff these days.



Like a lot of design software there's some things that you need to encounter and solve once before it becomes obvious. But I'm here out on the sparsely populated JFX ranch frontier for those questions.

That is to simply assign a pre-defined method to a button, you don't get to write a full-fledged method from scratch just like an IDE

Maybe I'm not sure what you mean?

You don't need to pre-define anything in the controller if you use the FXMLManager plugin in IntelliJ. I think NetBeans has one too, and I believe there's a plugin for Eclipse. But I forget how good they are.

https://plugins.jetbrains.com/plugin/14854-fxmlmanager

You just give a component an fx:id in Scene Builder, or add a method name in those handler inputs, and it'll create the field or method for you, with an @FXML annotation, including the correct type of event parameter.

You can also use pre-defined methods of course, but these plugins generate the code for you. But they're pretty trivial methods to create anyway. The event method parameters are also optional, you can remove them and the binding will still work fine.

If you're talking about doing something heavier like extending a Button class... actually you can do that (and there's a way to get it to work in Scene Builder). But that is where things get harder and less convenient, so I recommend avoiding that unless you really need it.

Also there's a bunch of 3rd party libraries that extend or re-implement some controls, or have entirely new controls.

Hi,

I'd like to share my experience. I build internal GUI tools with Java Swing and JavaFX.
For simple tools, Swing is convenient because the distribution of the application is simpler (Swing is included in the JRE while JavaFX requires external libraries),

I use https://www.formdev.com/flatlaf/ (free) and this gives very nice and modern L&F to Swing.  I also used JFormDesigner (paid) with Eclipse and IntelliJ.  Netbeans has Mattise which is a good GUI builder and is free.

For more complex or modern applications I have used JavaFX with SceneBuilder. In this case I use a JRE from BellSoft which includes the JavaFX libs and makes distribution easier.

JavaFX on the web is a paid product and you need run special software in the server. I would not use it for a new project, but if you have an existing JavaFX app then is a good option to convert it to Web application.

Joaquim

Yes that's a good take. That flatlaf site looks helpful if you're doing Swing. And it reminded me of another thing I don't care for in Swing - that horrible layout system. JavaFX layouts are done in a much more modern style, IMO.

I think I mentioned the initial setup curve with JFX. But we've got Java runtimes that have the JFX libs built in like Bellsoft's and Azul's fx builds, which make it pretty trivial.

And still, the ease of customizing theme with CSS (especially if you're used to HTML-like styling), and not having to rely on a GUI designer parsing Java code are great enhancements that JavaFX introduced. I remember the old Swing UI editors being slow, clunky and maybe a little picky or buggy when an interface gets complicated.

I feel like refactoring the UI is nicer in JFX too. IntelliJ will refactor things like component IDs even in FXML if you decide to change what something is named. You can probably do the same with Swing safely, but I remember big blocks of code with "DO NOT EDIT BELOW THIS LINE" or some such... yuck. I have some vague recollection of running into bugs that can leave that "DO NOT EDIT" code in a bad state. I was always afraid something goofy would happen that'd force me to revert changes back because the editor could no longer parse the UI code.

Definitely agree that a more complex interface is better done in JFX.

Welcome to the ranch BTW, Joaquim.  

Thank you