C#. Or Python if you must. Don't use Javascript.
this post was submitted on 07 Jun 2024
35 points (88.9% liked)
Programming
17022 readers
234 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
Most people use JavaScript for this nowadays, but most commentary also hates on it.
I'll be real with you. There's a reason JavaScript keeps being chosen despite the hate. It's so much easier and the dev experience is much more polished for creating desktop apps.
The reason it's hated on is that it is running a browser in the background, which people view as too bloated for a desktop app. Moreover, JS tends not to play well with system-wide themeing like GTK or QT.
But in the end, as a developer, you'll be dealing with a lot of messiness going with anything else. If you're up for a challenge, do try other things. But if you just want something that works and looks nice, do Js
JS or really anything you'd make a web app in (I use Rust with something like Dioxus/Yew/Leptos/Tauri), C#/.NET (I use F# because OO-style languages are ugly and a hot mess, especially C# and Java), Java/JVM (I use Scala whenever I can and Kotlin otherwise), C++ with GTK or Qt. There are a lot of options but obviously anything that's not C++ or web is gonna give you a lackluster experience (though I have a thing against web apps and will go through a lot of hoops to have my application use a native interface)
For a desktop app I would go with none of those.
If cross platform is the goal, the more important question, and independent of the programming language, is which GUI framework you will use.
Your best bet, at least if you are looking for a stable GUI framework, the best candidate may be C++ and Qt. But that's a hassle in its own right - both C++ and Qt.
TypeScript will have some solutions for you, with web rendering as a desktop app. Golang will have Qt bindings or other more experimental/not thoroughly established+popular GUI frameworks.
My personal favorite ecosystem is .NET. It has an official cross-platform UI project MAUI, but without an official Linux target. Community extensions probably exist. Personally, I dislike the way the UI is declared and bound though (XAML).
My current interest, which I have not explored or validate yet, is using .NET but then host a web or Blazor app in it with Webview2. .NET supports cross-boundary programming, crossing web+managed/native development, and crossing web(HTML+JS)+managed.
Most of the time GUI and the framework technology is a hassle. Your question is too broad and unspecific, so there's not a good answer.
If it's not a "serious" project that you depend on [for your livelihood], pick and start with whatever [looks good or interesting] and go from there. If it is a "serious project" do a bit more GUI framework exploration and assessment, and pick and commit to something. If it's a big commitment or risk, do prototyping with your candidates for verification and assessment - beyond the most simple examples, and for your specific usage.
Personally, I dislike the way the UI is declared and bound though (XAML)
You can write the MAUI UI in C#. No need to use XAML anywhere.
You can count Ruby out immediately. Terrible language.
Also replace JavaScript with Typescript. It's strictly superior.
I don't think Go has any mature GUI libraries.
For desktop GUI your main options are:
- Qt, via C++. Probably the best option but if you don't know C++ that's a huge barrier.
- Qt, via Python. Reasonable but Python is quite a shit language. It's very slow and the tooling/infrastructure is absolutely abysmal. Be prepared to bang your head against the wall trying to e.g. get relative imports to work.
- Dart/Flutter. This is quite nice but not super mature for desktop apps. Also the Dart ecosystem is very small so libraries you want may not be available.
- Electron/Typescript. This is quite a good option. Nobody here will recommend this because nerds have a slightly weird hatred of Electron because the minimum download size is like 80MB. But normally it doesn't really matter. Especially for big apps.
For the web frontend you basically want Typescript. For the backend you can use literally any language.
I would recommend Electron for the GUI and Typescript for the web frontend and Electron GUI. It means you can use the same language everywhere and you won't need to even implement the same program twice.
If you're worried about the download size / RAM usage you can look into Tauri which uses your OS's browser engine. I've never used it though.
Regarding tauri: One and a half years ago I looked into it as a potential alternative to using electron.
Back then I had to decide against it for my use case, because when the goal is that it's a cross platform app, then one has to make sure that whatever "webview version" is used on all target OS, they all have to support the features one needs re one's own app codebase.
Back then I needed some "offscreen canvas" feature that chromium supported (hence electron), but which webkit2gtk (used on Linux) didn't at the time.
https://tauri.app/v1/references/webview-versions/
So it's not always easy to give a clear recommendation on using tauri over electron. One really has to get somewhat clear on what kind of "webview requirements" the resp. app will have.
But I do hope this will (or maybe already is) less of an issue in upcoming years (things are moving fast after all).
You can count Ruby out immediately. Terrible language.
wow.
Ever tried to follow a large Ruby codebase like Gitlab? Absolutely nightmare. Not only does it not have type annotations, so you can't follow code by clicking, but you can't even follow it by grepping because Rubyists seem to love generated identifiers. Even the syntax of the language makes grepping worse, e.g. the lack of brackets prevents you from grepping for function calls like foo(.
You’re talking about rails. That’s like saying Kotlin is a terrible language because your only exposure to it is with something that decided to use Glassfish Webfly Swarm and Camel.
type annotations
You can literally follow code perfectly fine in an IDE like RubyMine. It actually works much better than Python because Ruby is incredibly consistent in its language design, while Python is an absolute mess (same with JS. Try opening a large Python or JS project in PyCharm or WebStorm).
No clue what you’re talking about with grepping though. Use an IDE like I said and you can literally just “Find all usages” or “Jump to declaration”, etc.
In any case, you shouldn’t be using any of these for large projects like gitlab, so it’s completely inconsequential. Saying something like “Java is terrible, have you ever used it for a CLI? It’s so slow it’s impossible to do anything!” is idiotic because of course it is. That’s not what it’s built for. Ruby is a scripting language. Use it for scripting. It kicks Python’s ass for many reasons, JS is terrible for scripting, and while you can use something like bash or rust, the situation is incredibly painful for both.
None of this has absolutely anything to do with the language design. You’re talking about language design and equating it to being terrible and then saying it’s because you don’t use any sort of tools to actually make it work.
You’re talking about rails.
Maybe other Ruby code is better, but people always say Rails is the killer app of Ruby so...
Use an IDE like I said and you can literally just “Find all usages” or “Jump to declaration”, etc.
That only works if you have static type annotations, which seems to be very rare in the Ruby world.
In any case, you shouldn’t be using any of these for large projects like gitlab, so it’s completely inconsequential.
Well, I agree you shouldn't use Ruby for large projects like Gitlab. But why use it for anything?
Maybe other Ruby code is better, but people always say Rails is the killer app of Ruby so…
I've literally never heard anyone say that...
That only works if you have static type annotations, which seems to be very rare in the Ruby world.
no. it literally works for any ruby code in any project. you do not need static type annotations at all. I can tell you've literally never even tried this...
Well, I agree you shouldn’t use Ruby for large projects like Gitlab. But why use it for anything?
because it's a fantastic scripting language with a runtime that is available on almost every platform on the planet by default (yes most linux distributions include it, compared to something like python which is hardly ever included and if it is it's 2.x instead of 3.x). It's also much more readable than bash, python, javascript, etc. so writing a readable (and runnable everywhere) script is dead simple. Writing CLIs with it is also dead simple, while I think Python has a few better libraries for this like Click, Ruby is much more portable than Python (this isn't my opinion, this is experience from shipping both ruby and python clis for years).
I’ve literally never heard anyone say that
Well you didn't listen then. Google the phrase.
I can tell you’ve literally never even tried this…
I do not need to try it to know that this is fundamental impossible. But I will try it because you can go some way towards proper type knowledge without explicit annotations (e.g. Pycharm can do this for Python) and it's better than nothing (but still not as good as actual type annotations).
It’s also much more readable than bash, python, javascript, etc. so writing a readable (and runnable everywhere)
Bash definitely. Not sure I'd agree for Python though. That's extremely readable.
Jump to declarations or usages has absolutely nothing to do with types so I have no clue why you think type annotations to make jump to useful.
Oh really? How would an IDE go-to-definition on x.bar in this code?
def foo(x):
return x.bar
Best it can do is heuristics and guesswork.
By using the AST? Do you really not know how languages work? I mean seriously, this is incredibly basic stuff. You don’t need to know the type to jump to the ast node location. Do you think that formatters for dynamic languages need to know the type in order to format them properly? Then why in the world would you need it to know where to jump to in a type definition!?!
Edit: also in the case of Ruby, the entire thing runs on a VM which used to be YARV but I think might have changed recently. So there’s literally bytecode providing all the information needed to run it. I highly recommend reading a book about how the Ruby internals work since you seem to think you understand but it’s quite clear you don’t, or for some reason think “jump to” is this magical thing that requires types.
I think you're getting a bit confused. How do you know where x's type is defined and therefore where x.bar is defined if you don't know what type x is? It's literally impossible. Best you can do is global type inference but that has very big limitations and is not really feasible in a language that wasn't designed for it.
Do you think that formatters for dynamic languages need to know the type in order to format them properly? Then why in the world would you need it to know where to jump to in a type definition!?!
Not sure if that is a serious question, but it's because formatting doesn't depend on the type of variables but going to the definition of a field obviously depends on the type that the field is in.
Maybe my example was not clear enough for you - I guess it's possible you've never experienced working intellisense, so you don't understand the feature I'm describing.
class A:
bar: int
class B:
bar: str
def foo(x):
return x.bar
Ctrl-click on bar. Where does it jump to?
Not sure if that is a serious question, but it’s because formatting doesn’t depend on the type of variables but going to the definition of a field obviously depends on the type that the field is in.
formatting does depend on the type of variables. Go look at ktfmt's codebase and come back after you've done so...
Maybe my example was not clear enough for you - I guess it’s possible you’ve never experienced working intellisense, so you don’t understand the feature I’m describing.
Lol, nice try with the insult there. I code in Kotlin, my intellisense works just fine. I just think you're quite ignorant and have no clue what you're actually talking about.
Ctrl-click on bar. Where does it jump to?
it gives you an option, just like if it was an interface. Did you actually try this out before commenting? Guessing not. And how often are you naming functions the exact same thing across two different classes without using an interface? And if you were using an interface intellisense would work the exact same way, giving you the option to jump to any of the implementations.
I'm sorry, but you clearly haven't thought this out, or you're really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).
formatting does depend on the type of variables. Go look at ktfmt’s codebase and come back after you’ve done so…
I skimmed it. It appears to visit the AST of the code and format that, as any formatter does. ASTs have not been type checked.
Can you give an example?
it gives you an option, just like if it was an interface. Did you actually try this out before commenting?
Precisely! It doesn't know the answer so it has to guess, or make you guess.
And how often are you naming functions the exact same thing across two different classes without using an interface?
You mean how often does the same field name come up more than once? All the time obviously! Think about common names like id, size, begin, children, etc. etc.
I’m sorry, but you clearly haven’t thought this out, or you’re really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).
I'm sorry but you clearly haven't thought this through, or you're just happy to ignore the limitations of Ruby. I suspect the latter. Please don't pretend they aren't limitations though. It's ok to say "yes this isn't very good but I like Ruby anyway".
All three are scripting language. Don't touch JavaScript, but consider typescript instead. Your requirements are vague, but python should probably be your first choice. It honestly does not matter which one you choose
Take a look at Dart+Flutter.
Python would be OK. Ruby is nearly dead nowadays. JS itself is used rarely, better consider using TS (however I don't recommend using them for anything other than web frontend). Go is a great language but it's unpopular in GUI development.
Interesting bunch of takes...
Take a look at Dart+Flutter.
Google just laid off those teams so I doubt this is a good thing to learn if you want something useful in the long-term
Ruby is nearly dead nowadays
Demonstrably false. My career has been in the Ruby/Rails world and I just went through a job hunt where I found tons of Ruby positions
JS itself is used rarely, better consider using TS (however I don’t recommend using them for anything other than web frontend)
Full-stack JS/TS is very popular in the web-dev world.
Go is a great language
I disagree, but this is 100% a personal opinion of mine 😄
I think it would help narrow things down if you described what kind of website you want to build.
Spend a week or two with each if you can, even if you don't stick with any you'll be able to tell what parts you did or didn't prefer or found difficult or easy that might help make a more informed choice. You might prefer the language features or syntax of one, but the tool chain or frameworks of another.
Maybe you should consider a server & client architecture to use the right tool for the right job on each platform.
Definitely JS if you want to also have a website. Use electron to turn your website into an executable for the desktop. Python+qt is ok for Desktop apps, but does not work for a website.
Languages that compile to wasm would also be an option, (e.g. https://egui.rs with rust), but as far as i am aware none of the languages you've listed are in that set. (Only go would even be a contender between python, ruby, js and go)
Electron is the way to go for what the OP described
You're probably looking for Java. Not JavaScript, Java.
They explicitly said they want to build a website. Not that you can't go far with a Java server + HTML(X) but JS is the de facto standard for interactive websites.
Idk how I missed that. I only saw the desktop program part and the languages listed after it. I completely overlooked the website part, unless it was edited or something. But yeah, for websites JavaScript is the go-to for front-end and there are even some decent back-end options these days, although development and deployment gets a lot more complicated if you go that route. Java is still popular as a backend language for website development, and there are frameworks that have out of the box components that give you the JavaScript for free, but they're typically expensive enterprise solutions like Adobe Experience Manager.
Edit: I just checked and it was edited, so they might have added that part after I wrote my reply.
Why java
I missed the part where you said you're also interested in building a website. Java is a popular and powerful programming language for desktop and mobile development. You can also use it with a framework for back-end website development, but there are better options out there. If you want something that does everything you posted then JavaScript is actually a good option. You'll need frameworks for back-end website development and desktop development, but it's kind of a beginner friendly language, and ChatGPT can help you set up the frameworks. It does get complicated working in the different stacks though. What do you want to build first?
Because it's 2003
desktop application for Windows, macOS, and Linux
Nothing does cross-platform desktop apps as well as Qt.
Definitely not Electron, which is very wasteful of system resources and has endless desktop integration bugs. Not Flutter. Not WxWidgets. Not Gtk. Not any of the various Java or Rust frameworks. Not Dear ImGui. Nothing. (Well, I haven't tried Lazarus yet, but it requires a language that's not on your list, so is probably not relevant here.)
Some of the newer frameworks might shape up eventually, but it would take years of focused effort. This is an area of computing that is difficult to do well.
I’ve been considering Ruby, Python, Golang and JavaScript
Of those languages, I would choose Python with either PySide or PyQt. If my interface needs were very simple, I might also consider Qt Quick, which lets you build GUIs with JavaScript and a declarative language called QML.
Thanks i will look into PySide and PyQt. I also think all kde apps are build with Qt
I can vouch for PyQt, it works quite well for what it is. Be aware you might have to dig into the C++ docs if you're trying to do something non-trivial.
If you like, you can use Qt Creator to build the GUI template, and then basically import into Python and build all the logic.
Just a bit more perspective for you:
https://survey.stackoverflow.co/2023/#technology-most-popular-technologies
More than half of professional developers use at least some JavaScript, and almost half of us also use Python.
So both of those are likely to be worth the effort to learn.
That said, as a diehard Python programmer, if I was forced to pick a single language to focus on, it would be JavaScript. JavaScript runs almost everywhere, and it specifically is the only decent option in a few places, such as Web app browser code.
But also, while I'm fluent in a couple dozen languages, my preferred go-to language is still Python.
Im biased here, ive been learning python for almost 16 months and only dabbled in Javascript and never did any Ruby, but for a first language, i think python is fantastic. Its "easy" enough to keep you feeling like your skill is actually improving, while still being able to do pretty much anything (where performance is not a high priority). I also just think javascript is ugly to look at.
One of the reasons I think JS gets a lot of hate is the tooling is a bit of a mess. If you go that route I encourage you to generate or find a barebones project to start from. Getting that very first "Hello World" app to run can be a massive pain in the ass.
I also don't think the requirement to a desktop app and website in the same language is being fair. It's definitely possible but different languages have different strengths. It shouldn't make your brain explode to deal with more than one language and I think you could benefit from a shift in mindset. When I'm in JS world I know l I've gotta let go of performance and security desires (i.e. JS in the browser is a "clear box" and users can fully control it). When I'm in Java I know those things are highly important but also to not stress about "presentation".
view more: next ›