Originally posted by Steffo
View Post
Announcement
Collapse
No announcement yet.
OpenJDK Java's Native Wayland Support Progressing
Collapse
X
-
Originally posted by caligula View Post
Only morons use Java on the client side. Competent programmers learnt it the hard way. VM startup takes forever. GC absolutely kills the performance. Toolkits look ancient. Applets are a joke. Oh applet support is actually deprecated in all modern browsers.
If you want to use a dynamic client side language, Python 2 or 3 would be the best. Ref counting has much better interactive performance. Qt bindings also look decent and the Qt company provides excellent open source support for free. Qt has much better performance. Also each Kde release has lots of Wayland fixes, which helps Qt.
- Likes 10
Comment
-
Originally posted by caligula View Post
Only morons use Java on the client side. Competent programmers learnt it the hard way. VM startup takes forever. GC absolutely kills the performance. Toolkits look ancient. Applets are a joke. Oh applet support is actually deprecated in all modern browsers.
If you want to use a dynamic client side language, Python 2 or 3 would be the best. Ref counting has much better interactive performance. Qt bindings also look decent and the Qt company provides excellent open source support for free. Qt has much better performance. Also each Kde release has lots of Wayland fixes, which helps Qt.
- Likes 3
Comment
-
Originally posted by tildearrow View Post
Python being interpreted absolutely kills the performance.
- Likes 2
Comment
-
Originally posted by slagiewka View Post
Yup. JetBrains must be utter dum-dums. Due to that awful decision their products are useless and literally no one will ever pay for them
- Likes 1
Comment
-
Originally posted by ssokolow View Post
While I agree, if you're talking about pure "how responsive does this feel to the user?", PyQt or PySide feels much snappier than Swing, SWT, or JavaFX on X11 in my experience. No idea why and I'll admit I've never compared QtJambi.
Swing took 1 second to read a 3870 file directory, whereas Qt at best takes 10 seconds on the same directory.
- Likes 3
Comment
-
Originally posted by tildearrow View Post
Surprise, surprise: Qt is better for the most part, but... Swing's file picker is 10 times faster than Qt's (on HDD).
Swing took 1 second to read a 3870 file directory, whereas Qt at best takes 10 seconds on the same directory.
I know that whatever version Kubuntu 20.04 has takes longer to become responsive than GTK's during the process of loading a very large folder, but I don't know how it compares to Swing's, and I consider it a necessary evil to get a file picker that supports things like renaming, deletion, and non-buggy "type a path in" support right in the picker, like every other sane common dialog picker in the world.
(I'd also point to the support for per-application bookmarks, but they haven't rearchitected that yet, so it sees the portal host rather than the requesting applications as the "application" to scope the per-application bookmarks to.)
Comment
-
Originally posted by caligula View Post
Only morons use Java on the client side. Competent programmers learnt it the hard way. VM startup takes forever. GC absolutely kills the performance. Toolkits look ancient. Applets are a joke. Oh applet support is actually deprecated in all modern browsers.
If you want to use a dynamic client side language, Python 2 or 3 would be the best. Ref counting has much better interactive performance. Qt bindings also look decent and the Qt company provides excellent open source support for free. Qt has much better performance. Also each Kde release has lots of Wayland fixes, which helps Qt.
- Likes 8
Comment
-
Originally posted by caligula View Post
Both Java and Electron based IDEs ship with a VM of their own. Jetbrains isn't even compatible with the standard OpenJDK, thus there's a need for a custom VM.
And the Jetbrains Runtime is fully open source and rebases with upstream frequently, so you can just use it as your bundled JDK if you want. And while doing GUI programming with Java swing is a bit painful, the JVM has a lot of nice languages which makes GUI programming much nicer then python, i.e. https://github.com/scala/scala-swing.
And yeah Python is trash when it comes to performance for GUI apps. Its GIL design means that its hard to offload rendering to the UI thread because shared data structures are slow as hell, where as Java solved this problem 20+ years ago and Scala/Kotlin have much nicer concurrency abstractions (Scala has an ExecutionContext for Swing UI thread, Kotlin has a coroutine dispatcher for swing, see https://kotlinlang.org/api/kotlinx.c...outines-swing/) for easily handling this problem.
Last edited by mdedetrich; 25 September 2022, 02:51 PM.
- Likes 4
Comment
Comment