[HN Gopher] Graphics for JVM
___________________________________________________________________
Graphics for JVM
Author : agluszak
Score : 497 points
Date : 2020-11-17 09:29 UTC (13 hours ago)
(HTM) web link (tonsky.me)
(TXT) w3m dump (tonsky.me)
| tomcam wrote:
| First of all... WOW! This is an exciting project. Second of all,
| the blog is beautifully designed and has a hilarious author
| portrait at https://tonsky.me/projects/. He appears to be from
| either Florida or Okinawa, not sure which.
| mtnygard wrote:
| I'll take a minute here to plug Defold (https://www.defold.com).
| It's a game engine with a dedicated IDE for building games. The
| IDE is built mostly with Clojure and JavaFX.
|
| Of course I'm biased, because I helped build the IDE, but I think
| it looks and feels great. It has a 3d modeling view that does
| pan, rotate, dolly, all at somewhere between 30 and 60 fps.
| vips7L wrote:
| It looks good, but the pictures are a bit hard to see :)
| cjohansson wrote:
| PR for JetBrains? I think there are plenty of good looking JVM
| desktop apps which are equally or more good looking as JetBrains
| stuff. Electron and JVM is bad because they require a lot of
| resources and that occasionally JVM has security issues
| munro wrote:
| I love the night mode setting on the top right of this site.
| Totally useless, but amazing lol. It feels like I'm reading the
| site in the dark with a flashlight.
| outadoc wrote:
| I'm glad to see this and Compose arrive on desktop. It feels like
| a potential good middle-ground between a fully native OS toolkit,
| a cross-platform native toolkit, and an embedded web app. I don't
| think Java is inherently bad for the job, just that the previous
| UI toolkits were not what we needed.
| jmartrican wrote:
| This is a great idea. Can't wait to try it out.
|
| In a past life I created a video game in JavaFX. Its on Steam. It
| was hard to do, but I really didn't know what I was doing when I
| started. I also do not know if JavaFX was missing any features
| that would be desired for video games, that maybe other libraries
| have. Nonetheless, for selfish reasons more libraries in this
| space is welcomed.
| touisteur wrote:
| "Why hasn't it been done yet?
|
| Patience, I think. We are so used to things we can hack together
| in a week, nobody is thinking in terms of years. And good UI
| requires years of work. It's a big commitment."
|
| That's quite an observation, thinking of the hundred thousands of
| man-hours probably spent on both Swing and JavaFX and SWT, and
| they power a huge lot of high-quality, highly polished
| applications, including real-time graphics.
|
| I'm sure this work is great, but no need to put the competition
| down...
| agumonkey wrote:
| Ah I wished for something like this for so long. Very nice
| surprise.
| pier25 wrote:
| > _The first reason is performance. JS is a great language for
| building UI, but it is much slower than JVM._
|
| Is it?
|
| Looking at these benchmark they seem to be in the same ballpark
| for most results:
|
| https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
| mumblemumble wrote:
| The picture I'm seeing is that it would seem that they're in
| the same ballpark, and v8 may even be a smidge faster, for
| general purpose business object flogging type stuff, but Java
| is significantly faster for straight-up number crunching. The
| one where there's the starkest difference, k-nucleotide, Java
| gets to take advantage of a fastutil collection. I don't think
| an equivalent to that hash map could be built in JavaScript.
|
| Those benchmarks don't cover this, but I wouldn't be at all
| surprised to discover that Electron can does actual UI drawing
| more efficiently than Java can. In Electron, that whole layer
| is a bunch of (presumably) carefully optimized C++ code, while
| in Java the bulk of it's still going to either be managed code,
| or be taking a lot of marshalling hits if it's calling into OS
| APIs.
|
| Long story short, it would appear that, based on those
| benchmarks (which, we all realize benchmarks are a lie, but
| still) the only spot Java clearly beats JavaScript is in
| applications where someone who cares all that much about
| performance would choose neither Java nor JavaScript, anyway.
| pier25 wrote:
| I agree.
|
| Also, when you look at UI benchmarks for web frameworks
| replacing/updating thousands of DOM elements per second, I
| have serious doubts the problem of web-based UIs is
| performance.
|
| I agree Electron is a cancer, but not because it uses web-
| based UIs, but because every app ships its own version of
| Node + V8.
|
| A couple of years ago I built a cross platform app using the
| native web view on each platform (WKWebview on macOS/iOS,
| WebView on UWP, Chrome web view on Android and ChromeOS). The
| app for macOS was like a 4MB download from the Mac App Store
| and it consumed like 15-20MB or RAM.
| altrunox wrote:
| "Wasm can be fast but implies C++ or Rust."
|
| Oh BTW, you can do WASM with Blazor (C#) now.
|
| https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
| x87678r wrote:
| There was a thread on /r/Java about Java GUIs. Seems Jetpack
| Compose is a potential new player that looks promising. No one
| seems to know if JavaFX or Swing is the recommended route.
|
| https://blog.jetbrains.com/cross-post/jetpack-compose-for-de...
|
| https://www.reddit.com/r/java/comments/jrqjex/whats_being_us...
| lewisjoe wrote:
| I'm studying how to rewrite our online word-processor in a stack
| that allows us to render documents to android/iOS/desktop
| natively.
|
| Skia stands out as the obvious choice as a rendering library, Our
| team though is essentially a JS/Java workshop and writing C++
| will be shooting our own foot.
|
| I found Skija a while back but it looks like we need JVM and the
| JVM story on iOS is complicated (non-existent even?)
|
| Fluttter does a good job at abstracting away Skia and exposing
| Dart APIs that is truly cross platform (Web/Desktop/iOS/Android)
| - but Flutter will never expose low level Skia APIs because
| that's not their goal. The abstraction is too high to write a
| word-processor.
|
| I'm yet to find a reasonably iOS friendly abstraction over Skia
| that targets both iOS/Android and desktop platforms.
| Darmody wrote:
| I've been using Java mostly for stuff that runs from the terminal
| and I always wondered why there are almost no games developed
| with it. I know this submission is not about games but it's
| related.
|
| The very few games that run on the Java platform are very
| resource hungry, even more than some alternatives made in JS
| which is supposed to have a worse performance.
|
| All that while C# is booming on indie game dev.
| lasagnaphil wrote:
| C# is better for gamedev for quite a lot of reasons, but most
| importantly because it has value types (structs) that aren't
| boxed. In gamedev you use a lot of small-size types such as
| Vector3 or Vector4 for all sorts of math, but if you implement
| them naively in Java you have to always heap-allocate them,
| which brings severe penalties in terms of cache locality and
| GC. Modern Java gamedev libraries like JOML tries to avoid this
| by using NIO buffers (JVM provides some utilities to manually
| alloc/dealloc memory), but the API is quite finicky as a
| result. (Plus, there is no operator overloading in Java, which
| is another bummer.) Project Valhalla is trying to add proper
| value types to the JVM, but sadly as of today the project seems
| a bit abandoned... (See
| https://wiki.openjdk.java.net/display/valhalla/Main)
| djhworld wrote:
| > Project Valhalla is trying to add proper value types to the
| JVM, but sadly as of today the project seems a bit
| abandoned...
|
| The repo seems to have very recent activity, has commits from
| today! https://github.com/openjdk/valhalla
| didibus wrote:
| Agree, and not just gamedev, I think for desktop apps this is
| an issue as well. The memory profile of a Java app suffer
| from lots of unnecessary boxing. Also, the GCs are not
| designed and tuned to desktop apps, but to backend services.
| So they'll exhibit behavior like never releasing memory back
| to the OS and hording 100% memory.
| skocznymroczny wrote:
| As lasagnaphil mentioned, lack of value types (structs),
| operator overloading makes it trickier.
|
| Also, Java doesn't have as many bindings to gamedev C
| libraries, so it's harder to get started, and the interop with
| C is harder in Java than in C#. C# has some cool features like
| sequential StructLayouts.
|
| C# is actually rarely used for making game engines, but it's
| popular as an embedded scripting engine for games. I think C#
| has a better embedding story, because I've never heard of any
| projects embedding Java (I am sure they exist though).
|
| Lastly, Java has a bit of a stigma for being a low performance
| language. While that may or may not be true, and there's been
| many popular games written in Java, such as Minecraft or most
| of the Android games, the stigma still remains and jokes about
| Java being slow are very popular.
| lvh wrote:
| Happy to see new developments here, though FWIW, I've mostly had
| a good time with JavaFX, especially in Clojure, where there's a
| neat Reagent-style (a React wrapper) library called cljfx[0].
|
| It's true that Oracle has mostly divested here but I'm excited to
| see what teams like Gluon do with it, especially for mobile
| development. It's nice (though perhaps a mixed blessing) to be
| spoiled for choice in Clojure land, since you also have great
| access to the React Native ecosystem.
|
| [0]: https://github.com/cljfx/cljfx
| vijaybritto wrote:
| I am a web developer and I'm only used to developing in
| JavaScript and a complete beginner in Java.
|
| I had an idea for a desktop app and wanted to try out something
| in javafx as that's what google pointed me to. The build setup
| for java projects seems to be incredibly complex and I don't find
| any sort beginner friendly tutorials related to javafx that work
| on windows without any issues. Then I looked at Android
| development setup and it's even more insane in size and
| complexity.
|
| I think if the entry into java app development was as easier as
| electron it would be amazing! I get that it's a well mature
| platform with a massive ecosystem but it needs to be have
| something like npm or yarn for javascript development.
|
| And importantly are there any thin and light JVMs that can be
| bundled with this? I'm thinking AdoptOpenJDK openJ9. It seems to
| be well suited for this use case. would it be efficient in the
| RAM and CPU usage? If not I'm not sure why this would be any good
| since we can develop stuff much faster with electron at the
| moment.
| LandR wrote:
| > C# would do, too, but it doesn't have Clojure.
|
| Do you mean .NET would do too?
| spacemanmatt wrote:
| Probably means CLR. And there is technically some Clojure for
| CLR but it's not as regularly maintained.
| joppy wrote:
| Some Clojure libraries have a hard dependency on Java (or
| JavaScript, in the case of libraries supporting
| ClojureScript) - Clojure does not cover all use cases. For
| example, if you want to do anything more complicated than
| find-all-matches with a regular expression you need to call
| the underlying Java classes from Clojure. I expect this is
| probably the biggest obstacle to getting Clojure on CLR
| working properly: the language is not the issue, the
| libraries are.
| harperlee wrote:
| I have not used CLR but last time someone said here it was
| abandoned (I know, not what you said!), Alex Miller response
| was that it was up to date with the JVM version:
|
| https://news.ycombinator.com/item?id=21192321
|
| Admittedly this was a year ago! Time flies...
| nlitened wrote:
| I am pretty sure Clojure is "stable" so nothing changed in
| the past year.
| harperlee wrote:
| This is only incidentally correct (last stable release
| was June 6, 2019), because clojure is still evolving,
| just slowly and stably. A new prerelease was announced
| September 4, 2020 at https://insideclojure.org.
| mhd wrote:
| Java had the issue that it was hard to build a consumer desktop
| app, because Swing etc. were a bit removed from native (L&F,
| behavior etc.). Those didn't matter as much for desktop apps,
| which always looked gross. (The issue that they were less usable
| than the terminal apps they sometimes replaced is another issue)
|
| These days, I'm not sure if fixing that is enough. I long for the
| days when minor UI inconveniences like Borland-ish button icons
| or that weird Basic thing in the early days of OS X were the
| worst offenders. Quite often it's _required_ that you deviate
| from your platform quite a lot, as we've embraced form over
| function with mobile- and web-like "experiences". Whitespace
| everywhere, mystery meat navigation and non-conformant widgets
| and shortcuts that make you long for the skeuomorphic mistakes of
| the late 90s. Neither Apple nor Microsoft seem to be too much
| into HIGs these days, and Linux never was.
|
| So if this delivers the bricks, what kind of houses would we
| build with it?
| quanticle wrote:
| "Those didn't matter as much for desktop apps, which always
| looked gross."
|
| I don't understand what you mean by this. I don't think desktop
| apps "look gross" at all. Or did you mean that _Swing_ desktop
| apps looked gross because they didn 't conform to the native
| look and feel of the platform they were running on?
| mhd wrote:
| Ooops, very bad typo, totally obscuring my whole point, I
| meant to say "enterprise apps". Where looking good wasn't a
| selling point.
| Cloudef wrote:
| >People crave for native apps. Nobody wants to work from the
| browser.
|
| Ah the irony
| Cloudef wrote:
| Not sure why this is getting downvoted, but JVM is just as
| native as browser is. The jetbrains IDE mentioned in the
| article is especially very clunky and slow resource hog. In
| fact so much, that I would actually prefer using electron app
| over it.
| kaba0 wrote:
| Whaat, I would not call intellij unbelievably fast, but it is
| a resource hog because it does a million thing at once.
| Compare it to visual studio, which is something that barely
| works and has inferior auto-complete, etc.
|
| An electron app of that complexity would require a
| supercomputer to even start
| [deleted]
| maynman wrote:
| For sure. In the case of IntelliJ resource usage, you get
| what you pay for.
| PedroBatista wrote:
| Do you have any idea the complexity and amount of stuff
| Intellij does behind the scenes?
| Cloudef wrote:
| The complexity of getting in the way, melting your computer
| and not allowing you to write single line of code at the
| end of the day?
| masa331 wrote:
| > People crave for native apps. Nobody wants to work from the
| browser.
|
| Some do, some quite the opposite. Me personally i want to have as
| few desktop apps installed as possible. They are warranted only
| in few special cases - browser, video & music player, Excel.
| Other than that there really is no need to have any desktop app
| nowadays.
|
| > Both of them were recording it on a desktop, in a desktop
| application, while having a call over another desktop
| application.
|
| Yeah this can be easily done from browser also
|
| > it's hard to select text, hard to search on a page, hard to
| have multiple tabs, hard to move data between apps
|
| excuse me? It's harder to select text or search text in browser
| than in desktop apps? What? Text search is one ctrl-f away on ANY
| web page. Switching between tabs in a browser is alt-num.
|
| Desktop apps have no tabs and a lot of times you switch between
| completely different UIs.
|
| Moving data between apps depends completely on the app itself. It
| either offers some kind of data export or does not. It doesn't
| have to do anything with desktop apps or web apps in general
|
| > For example, you are adding an event to the calendar. You need
| to lookup an address for the event in the mail, which has a link
| that opens a browser.
|
| Yeah in a web apps you at least have some unique link to it.
| Linking to something on your local computer in some desktop app
| isn't even possible
|
| > Ability to have multiple windows open at the same time is the
| desktop's superpower.
|
| You know you can have multiple tabs open in one browser right?
|
| I like Nikita's articles and if he or anybody prefers desktop
| over web that's fine. Also the library he is starting - great.
| But the announcement could really omit the nonsensical
| comparisons and generalisations of web vs desktop
| tleb_ wrote:
| I believe he talks about mobile platforms:
|
| > And I've been on both sides. I lived without a desktop for a
| few weeks once.
|
| Mobile platforms, on which selecting and searching text is
| hard, switching between tabs is slow and multitasking between
| apps is made complicated by:
|
| > By the time you found what you needed and returned to the
| calendar, it has been unloaded from memory and all context is
| lost
| d3nj4l wrote:
| > > it's hard to select text, hard to search on a page, hard to
| have multiple tabs, hard to move data between apps
|
| > excuse me? It's harder to select text or search text in
| browser than in desktop apps? What? Text search is one ctrl-f
| away on ANY web page. Switching between tabs in a browser is
| alt-num.
|
| That is clearly about mobile in contrast to Desktop.
| masa331 wrote:
| Ah ok, thanks. This makes more sense now.
|
| But on a seconds thought - there are people who really "work"
| on phone? I just can't do anything serious from phone be it
| native app or web app. The experience is so much worse for me
| that it didn't even cross my mind it's about phones.
| d3nj4l wrote:
| Not all the incredible, to be honest. Apple has pushed the
| iPad as a laptop replacement, and that was well before it
| got the desktop-ish features it has now.
| tannhaeuser wrote:
| What's wrong with Java 2D, Swing, and SWT _specifically_ , rather
| than being old? Saying that IntelliJ IDEA is the only Swing app
| that doesn't suck isn't really an argument to fragment the Java
| desktop space even further when new desktops apps (Java or
| otherwise) haven't been developed for well over a decade.
| LoSboccacc wrote:
| SWT had a lot of weird cross platform quirks which were
| unbearable to diagnose, it's been 10+ years now so I can't
| recall all details, but every time I tried under the premise of
| the better components, as the UI got complex, there was no
| other solution but escape back to Swing, where the tooling and
| facilities around where miles better.
| AshamedCaptain wrote:
| SWT is not even mentioned, being literally the other big
| elephant in the room (Eclipse). Grosso modo it does not look
| like due diligence has been done...
| Debug_Overload wrote:
| The author also lumps AWT, Swing and JavaFX together. They're
| different, and some were created to solve issues others didn't
| address, and/or improve them (never mind that JavaFX is its own
| beast, and is quite different from the other two, which are
| relatively close). But they're all GUI toolkits, and they all
| suck doesn't make sense.
| blablabla123 wrote:
| I really liked Processing [1] It's possible to create practically
| every thinkable visualization from scratch with surprisingly
| little design knowledge/programming effort. Not only is it far
| more intuitive and flexible than d3.js but also it can be
| directly called as Java program. Apparently the Arduino UI is a
| fork of its editor. FWIW it's hard to tell that the Arduino IDE
| is not a native app.
|
| [1]
| https://en.wikipedia.org/wiki/Processing_(programming_langua...
| suyash wrote:
| Processing is getting an update Processing 4 and it would be
| nice if they incorporate this library.
| dimitar wrote:
| There are lots of fast, usable JVM gui applications.
|
| Some OSS examples:
|
| http://www.sweethome3d.com - This one has been the one app I've
| recommended to people outside the tech bubble! It also focuses on
| graphics and 3d.. really deserves to be showed off more often
|
| http://xmind.net
|
| https://dbeaver.com/
|
| http://www.mucommander.com/
|
| http://www.jedit.org
|
| What they have in common is that they are old project - often
| more than 10 years old and are not on Github. Goes to show how
| important hype and trendiness is in our industry.
|
| edit: fixed formatting
| jmnicolas wrote:
| Dbeaver is certainly not fast. It requires several seconds to
| start on a machine with a Core i5, 32G ram and a NVME SSD!
|
| In fact VSCode starts faster.
| fayten wrote:
| Start time is not a great measure of overall performance.
| Also you are comparing two very different types of
| applications.
|
| A text editor that can be extended vs a platform application
| is the same argument we've been having about vim vs emacs for
| years.
|
| DBeaver is an incredibly powerful application that had
| allowed me to work in Postgres, Teradata, and Oracle
| databases for years. Could I do the same kind of work in
| VSCode? Absolutely not, unless I wanted to build out an
| entirely new interface on top of VSCode. By the time that
| work is done it could be equally slow to start up. DBeaver
| has an absolutely massive feature set tailored for database
| work and it has to load all those plugins at some point.
|
| Another counter point is VSCode with java-lsp could never
| handle the 300k loc code base we developed on, where intelij
| and eclipse do just fine. Yes, they startup slowly, but at
| least they provided meaningful and fast autocomplete without
| the need to wait for the language sever or VScode to
| unfreeze.
|
| Again these are purely anecdote, but please don't purely
| judge an application by it's startup time if it saves you
| time in the end.
| InfiniteRand wrote:
| One thing I've noticed is I don't care about start time if
| I'm going to be in one app for several hours, but if I'm
| doing a lot of switching between apps, without one app
| taking my primary focus, I become very sensitive to start-
| up time.
|
| I also think the optimizations for high performance with a
| relatively small amount of data are fundamentally different
| than the optimizations for high performance with a very
| large amount of data, I have not really seen any GUI
| approach that scales smoothly from small amounts of data to
| large amounts of data without some complexity on the back-
| end
| jmnicolas wrote:
| I talked about speed not usefulness or features since
| parent said:
|
| > There are lots of fast, usable JVM gui applications.
|
| I used VSCode as an example because it's touted as the
| fastest electron app.
|
| Now I have no idea how to benchmark DBeaver once it's
| running but since my use case is to launch it once in while
| to run a quick SQL query, startup time is important for me.
|
| For years I have said I need a kind of SQL pad: a native
| app, that launches ultra fast, directly shows me the tables
| once connected (hide all the complexity of the DB) and let
| me run some SQL immediately. I guess I'll probably have to
| scratch my own itch once I find the time.
| nicoburns wrote:
| Table Plus has native versions for macOs and windows
| https://tableplus.com/
| e12e wrote:
| I recently came across Beekeeper Studio in a comment here
| on hn, and I really like it so far.
|
| I generally use pgcli for talking to postgres, and I
| occasionally need sql developer for Oracle - but with Bk
| i might standardize on it for ms sql server, postgres and
| sqlite.
|
| It's foss and electron. That it's snappier than sql
| developerto start isn't saying much... I guess.
|
| https://www.beekeeperstudio.io/
|
| https://github.com/beekeeper-studio/beekeeper-studio
|
| https://www.pgcli.com/
|
| I tried ms azure data studio or what it's called, and I
| think Beekeeper is a good alternative. It doesn't do all
| that sql server mgmt studio does - but then it also
| doesn't need to run in a windows vm..
| fayten wrote:
| A co-worker that lived in his terminal used jsqsh[1] for
| simple queries to an Oracle DB when he did not need
| DBeaver. Jsqsh appears to no longer be maintained and I'm
| not quite sure how fast it is, but it still might be
| worth looking into. There is also usql[2] that you might
| be able to build something on top of.
|
| [1]https://github.com/scgray/jsqsh
| [2]https://github.com/xo/usql
| bballer wrote:
| The JetBrains suite (ie IntelliJ, Datagrip etc) while not open
| source, are a testament to what can be done with JVM based GUI
| applications.
|
| Have you ever used the merge tools? So dang cool.
| orybak wrote:
| IDEA Community edition is opensource:
| https://github.com/JetBrains/intellij-community
| scaladev wrote:
| https://github.com/JetBrains/intellij-community
| anentropic wrote:
| The JetBrains merge tools are the best ones I've found!
|
| I have it configured as my git mergetool
|
| The only problem is it takes absolutely ages to start up,
| which is maybe a JVM thing
|
| I wish there was a way to have git pass all of the
| conflicting files in a merge to the mergetool at once.
| Instead of having to wait for JetBrains to load up for each
| individual file and close after each one :(
| chrisseaton wrote:
| > I have it configured as my git mergetool
|
| How are you doing this? I haven't seen any merge tool, let
| alone a standalone one, in the JetBrains toolbox. What am I
| missing?
| cataphract wrote:
| You invoke it with "idea.sh merge <left> <right> <base>
| <out>". TBH, I don't think it's anything special; I've
| been using p4merge for years.
| anentropic wrote:
| By the steps here
| https://stackoverflow.com/a/47712453/202168
| thu2111 wrote:
| JVM apps can start in <100 msec, and IDEA has a 'lite' mode
| now where it's more like a text editor. That starts very
| fast.
|
| IDEA is slow(ish) to start because it's an IDE so it's
| loading tons of plugins, a project database etc. Though
| actually recent versions only take a few seconds on my
| admittedly high end MacBook.
| CountHackulus wrote:
| There's also some AOT options for the JVM to get a faster
| startup, along with -Xquickstart. I definitely agree with
| the "you're loading an entire IDE" statement.
| anentropic wrote:
| I wish I could launch just the diff interface without all
| those plugins then
|
| TBH I never got on with PyCharm and still use Sublime
| Text... but I keep PyCharm installed just for the
| mergetool!
| funcDropShadow wrote:
| I do it the other way around, I let git write the default
| conflicting files. And then switch to IntelliJ, press
| Ctrl-a and type "resolve", press enter. And voila I am in
| IntelliJ's git resolution windows where each conflicting
| file is listed.
| ubercow13 wrote:
| IDEA still has a horrible GUI in my opinion. All sorts of
| weird subtle bugs relating to the very fundamental UI
| interactions that make the whole experience very frustrating.
| The main one I remember is that certain buttons in the UI are
| simply unreliable - depending on what processing is going on
| (sometimes if nothing heavy is being processed), certain
| buttons in the UI will not respond when clicked. I used IDEA
| for years and very often had to click a button 4-5 times
| until it would activate, especially while using the debugger.
|
| If the UI toolkit can't get a button right, it is completely
| broken IMO. Even including intelliJ products, I have never
| used a Java GUI which was good.
| twic wrote:
| The stop/run button in the Run pane often doesn't work for
| me - i mouse over, it doesn't highlight, and clicking it
| does nothing. Minimise and maximise the pane, and it works
| fine.
| whizzter wrote:
| Sounds more like an IDEA bug rather than a Swing bug. I've
| implemented an editing tool (realtime video generation
| parameter editing w/ feedback from the generator) that
| really has a lot of issues.
|
| Part of them because i didn't fully understand Swing when i
| began the project and partly because synchronizing GUI's to
| another live process is a quite error prone task.
|
| A debugger process is almost certainly not living in the
| same thread as the Swing UI of IDEA so this almost surely
| more of a thread synchroniztion issue rather than Swing
| issue. (You really don't watch to do any cross-thread
| touching with Swing apart from for a very limited set of
| components built for this).
| ubercow13 wrote:
| Yes it's certainly something to do with threads. Still
| the way it manifests is weird. For example sometimes in
| apps like Chrome or Firefox the tab bar will freeze
| momentarily while the UI is hung waiting for something,
| however if you click something like a tab close button
| during this period your click will be processed once the
| UI un-hangs.
|
| In intelliJ it was like whenever the UI was not
| immediately responding to mouse events, it would often
| just lose the event instead of it being correctly
| processed once the UI thread was freed up.
| whizzter wrote:
| Chrome/FF in this case has an UI thread that becomes
| unresponsive for whatever reason and doesn't empty it's
| message-queue (that contains the mouse/keyboard/etc
| events).
|
| In the case of IntelliJ there is probably some of their
| code accepting the event and then probably has some ad-
| hoc message passing by setting a field that is polled by
| the receiver thread under the assumption that the
| receiver always runs faster than a human can act, however
| as soon as that assumption is broken by some pause you
| get what you describe.
| chinhodado wrote:
| I've never experienced anything like that in IntelliJ, and
| I've used it everyday for years now. Granted there are bugs
| especially around big releases, but I've never seen any UI
| bug like you described. Everything is always smooth and
| responsive.
| ubercow13 wrote:
| I just fired it up to see and it's still kind of there.
| For example when loading a project, there's a popup
| progress bar and the UI kind of janks around while it's
| loading. If you click anything in the UI while that's
| happening like a menu, the event is lost.
|
| OK - it's loading so that's not unexpected. However my
| previous experience was that the same thing would happen
| to the UI at all sorts of surprising moments when other
| processes were ongoing, such as linting or using the
| debugger. Kind of hard to reproduce without a large
| project at hand though.
|
| Then I had to stop testing and SIGKILL it because the
| whole application got into an infinite loop of NPEs in
| the UI event loop of all places!
|
| I too experienced using intelliJ for many years and this
| seems largely in line with what I remember.
| vijaybritto wrote:
| Most of the hate towards electron is only because of its
| resource usage problems and not because of its capabilities.
| Vscode is it's testament for capabilities. Jetbrains suite is
| great but they're not resource efficient in any way!
|
| If the JVM based apps do not yield a significant performance
| benefit then there is no point in going after that.
| levosmetalo wrote:
| It's not only resource usage, but performance in general. I
| can feel lagging when typing slowly in VSCode editor, even
| in plain text files without even trying autocomplete or any
| IDE feature. IntelliJ IDEA doesn't have any lag, Eclipse
| too, and both offer more IDE capabilities than VSCode.
| dathinab wrote:
| And the DOM, and the size overhead and it's JS/TS and some
| other parts from dev (i.e. not user) perspective.
|
| Through tbh. I don't see much reason to spend time for a
| Java UI framework, Java for desktop is just kinda annoying
| and somewhat even more dead then Java for servers (which
| isn't really dead tbh).
|
| Through I guess idea/Intellij would love to replace the low
| level parts with something which works more reliable.
| vijaybritto wrote:
| Yeah the reasons for choosing JS/TS don't have to be
| stated from developers' perspective because its the goto
| tool for new products nowadays.
|
| Also I don't think the desktop app market for java is
| small in any way. But if there's no difference between
| electron and JVM UIs then there is no incentive for teams
| to switch.
| funcDropShadow wrote:
| But what about the teams coming from classical desktop
| application development. Perhaps they don't want to
| switch to Electron-based web development.
| barnacled wrote:
| The article covered another factor:
|
| >The second is the DOM. It is a horrible collection of
| hacks that make simple things hard and hard things
| impossible. I have thought many times "if only was I
| drawing this control/layout directly, I would've finished
| hours ago."
|
| As a user of electron apps there are clearly limitations on
| what the UI can do as a result and the style of rendering
| it is clearly webish.
|
| Another issue I keep on seeing with web based apps, moreso
| on android, is they seem utterly incapable of dealing with
| the slightest network non-connectivity. The UI tends to
| freeze.
|
| I do take your point entirely on the fact that perhaps
| java's inherent performance limitations might result in a
| fairly comparable poor experience however.
| maynman wrote:
| I use IntelliJ for work every day and I agree, so many of its
| features make work so much better.
| dathinab wrote:
| Yes, but they are also an example of why people don't like
| Java UIs.
|
| I.e. the amount of UI problems you have with it when using a
| tiling wm or wayland (or both) are just sad and make it
| unusable. Other widely used UI's might also have problems but
| at least are somewhat usable under wayland and/or tiling wm.
|
| Ironically many of this problems go back/are rooted in to
| AWT...
|
| In the past Intellij did work if started directly by x
| (without a wm) which was pretty cool for some very very neach
| use cases, but sadly (through reasonably) this isn't the case
| anymore.
| wtetzner wrote:
| Just out of curiosity, what issues do you run into using
| them in a tiling WM?
| dathinab wrote:
| Context menues not being at the right position, directly
| closing after opening (so fast that you can't really see
| it) as well as menu items sometimes not being selectable.
|
| Especially the quick command/search menues doesn't work
| at all and context menues sometimes don't work either.
|
| (Edit: And context/popup menues not working is _the_ main
| theme of problems with Java GUIs, hence my parent post,
| also setting the "magic" no-reparenting env variable
| doesn't fix it)
| _bin wrote:
| I can second these issues using i3 and arch. I've had
| subtle issues like these in Ghidra and when I once tried
| Armitage (I wanted the Hail Mary feature), it was so
| messy I've never used it since.
| fnord123 wrote:
| Skija (the graphics library in TFA) is in the JetBrains
| organiation... https://github.com/JetBrains/skija/
| anthk wrote:
| >There are lots of fast, usable JVM gui applications.
|
| Debatible, argueable.
| darkwater wrote:
| Big plus for SweetHome 3d, I designed my new bathroom with it
| (nothing fancy, just some render to get the idea of how various
| options could look like, but given how bad I am at those things
| it was a great success!)
| tealpod wrote:
| Tealpod Image Compresssor for MacOs is built using JavaFX.
| https://www.tealpod.com/compressor/ Windows version is built
| using .NET, C#.
| wtetzner wrote:
| Interesting that they have two versions, when the JavaFX
| version should be cross-platform. Is it because they built
| the .NET version first?
| 0x445442 wrote:
| mucommander is on Github
| rodamaral wrote:
| Dbeaver is really ugly, though. To the point of being unusable
| due to aesthetics, like many Java apps.
| nevertoolate wrote:
| How aesthetics make it unusable?
| loxs wrote:
| The main reason (JVM apps are not more popular) is that the
| average JVM desktop app does not perform better (or use less
| resources) than the average Electron app. I know this is not
| supposed to be that way, but one way or the other, it is. On top
| of this the web UI developer community is orders of magnitude
| larger.
| eythian wrote:
| I don't think that's really true. Years ago, I maintained a
| Java desktop application, using SWT as the graphics library
| (not even mentioned by the post author which is weird.) It
| wasn't a big application, but also not stupidly trivial. It
| would start fast, run fast, and didn't need much RAM at all.
|
| There are of course examples of slow, heavy java applications,
| but I don't think it has to be that way. I'm not totally sure
| what I did differently aside from consider my dependencies
| (e.g. using a lightweight dependency injection framework rather
| than something like Spring), but it's definitely not a given
| that Java desktop applications have to use a bucketload of RAM.
| loxs wrote:
| Of course it's not "really" true and of course it's not
| "given"... it's just the sentiment. And the sentiment affects
| decision making a lot.
| suyash wrote:
| Java is way faster than JavaScript and the benefits of Java
| ecosystem including libraries puts it above electron. Native >
| Web for UX.
| munro wrote:
| > Patience, I think. We are so used to things we can hack
| together in a week, nobody is thinking in terms of years. And
| good UI requires years of work. It's a big commitment.
|
| Lol what? After years, Apple is already on to the next user
| interface. All the "good UI" happens in Figma, you're just
| programming it, hopefully fast & without bugs, what is taking so
| long? And as a fellow programmer, no thanks, I would not like to
| spend years developing a UI that could be done in weeks.
|
| We had an engineer that said it was going to take 3 months to add
| a sticky header to the site, because he needed to do it "right",
| using his home grown state machine library on Github with 3
| stars. He was shortly let go.
| vonnieda wrote:
| The author is referring to writing a UI library, not writing an
| application or UI using an existing UI library.
| munro wrote:
| Yea I hope so, I can see how you're interpreting it like
| that. It's really hard to comprehend the true meaning, the
| more I reread it.
| grandinj wrote:
| We build all our desktop products using Swing, and it works
| pretty well. Looks pretty native (if you want it to), is
| thoroughly battle-tested, reasonably performant, and has a
| bazillion open-source extras floating around (of varying
| quality).
|
| If you need 3d, we drop into OpenGL and use that (e.g. when
| integrating WorldWind).
|
| Sometimes I feel bad about how easy it is to write desktop UIs in
| Java - the API is stable, nobody keeps changing it under me, I
| don't have to wonder what Microsoft is pushing this year, it is
| (mostly) easy to debug, has open source forms designers
| (Netbeans), etc, etc.
| swiley wrote:
| You would have thought after 40 years there would be some
| standard GUI toolkit all the major OSes would adopt but stuff
| like swing, html, and TCL/tk are all we have...
|
| and of course vt100 escape sequences for some reason.
| barnacled wrote:
| I guess not globally adopted but Qt to me is a pretty
| workable cross platform solution, nicely performant and
| reasonably easy to work with with great community support and
| problem googleability as well as pretty damn nice docs.
| ta988 wrote:
| Unfortunately not easily usable with the JDK...
| bmn__ wrote:
| https://github.com/tilialabs/qtjambi5 exists.
| coldtea wrote:
| Well, the idea between "major OSes" is that they try/do/offer
| different things. And the UI is large part of that. If they
| all have adopted the same, we might as well use a single OS.
|
| That said, there should have been one, good, cross platform
| GUI toolking, and Qt, for various reasons, isn't it. The best
| we have is Electron...
| CyberDildonics wrote:
| > stuff like swing, html, and TCL/tk are all we have...
|
| They are all you have if you don't know about FLTK, QT, Juce,
| GTK, wxWidgets and many others.
| mmm_grayons wrote:
| I think an option could be GPU-accelerated drawing. It won't
| look native, but one can create a UI that performs well on
| just about any platform. Vulkan greatly improves the
| portability of such applications (compared to the OpenGL vs.
| OpenGL ES mess), and Skia has a nice set of primitives on
| which one could build.
|
| It's also worth pointing out that creating a cross-platform
| API is better for new players than for entrenched ones.
| yjftsjthsd-h wrote:
| You're just inventing your own toolkit, which is going to
| end in tears for everyone since you will have to recreate
| every component from scratch, rediscover all the
| interesting edge cases thereof, fail to reimplement some
| expected behaviors (triple-click text selection, drag-
| scroll, whatever), and break every accessibility tool in
| the process.
| zepto wrote:
| This is exactly what the linked article is proposing.
| ptx wrote:
| My issue with Swing is the glitchy-looking result, the opposite
| of Wayland's "every frame is perfect" motto. When I tell Swing
| to display a simple window with some simple widgets, Swing will
|
| 1. First display the windows in some random place on the
| screen,
|
| 2. Then move it to the position I actually specified.
|
| 3. Draw all the widgets with a slightly wonky layout,
|
| 4. Then erase all the widgets and redraw them with the correct
| layout.
|
| This happens in every Swing app I've ever used when you open a
| new window, even IntelliJ. (The moving window position is not
| always observable.)
| hutzlibu wrote:
| Well, the author did not say, Swing etc. does not work. But
| that it is incredibly hard to make a UI with it, that looks
| good and is performant. And this matches my experience with
| java 10+ years ago, when I tried it out and left in horror ...
| for: flash.
|
| (Flash had many, many drawbacks: proprietary, security, ... but
| it was really easy, to make something nice looking, that also
| run smooth - it was designed for that and later taken to higher
| level with flex)
| grandinj wrote:
| Yeah, your mileage may vary.
|
| I was writing UIs in Swing 10 years ago, and we managed fine
| even back then, but our target customer is technical people
| so maybe our definition of "looks good" is somewhat easier.
| ksec wrote:
| I remember how horrible Swing was 10+ years ago I ran to
| SWT. Along with GCJ trying to compile everything into
| native executable.
|
| And even SWT was far from perfect. It is one of those thing
| you can immediately tell by its looks, SWT, Swing, Linux,
| Mac , Windows. While the looks has been vastly improved, it
| still remain mostly true today.
| hutzlibu wrote:
| "so maybe our definition of "looks good" is somewhat
| easier."
|
| Yup, there is the difference. My target audience are common
| people, so I have to care more.
| AnIdiotOnTheNet wrote:
| You really don't. I interact with "common people" every
| single day and they couldn't give less of a shit how the
| UI looks as long as they can do their job or whatever it
| is they need the program for.
|
| The people who care about "looks good" are managers and
| designers because they never actually have to use the
| damned thing.
| hutzlibu wrote:
| Depends, if you have people needing to do a (unpleasant)
| job, sure, they also care more about functionality, than
| form. Nobody cares about a smooth animation, if he cannot
| get his job done.
|
| But given the choice, they prefer the better looking one.
| In consumer facing apps much more. Especially younger
| people, used to shiny websites/html point out quickly,
| how ugly something looks. And then not use it.
| AnIdiotOnTheNet wrote:
| > In consumer facing apps much more. Especially younger
| people, used to shiny websites/html point out quickly,
| how ugly something looks. And then not use it.
|
| As far as I can tell, this is a narrative that only
| exists in the heads of people who never have to use the
| thing they are insisting "look good". Sales people,
| managers, developers, etc.
|
| I will accept that I'm wrong when I either experience it
| in the real world for myself or see some actual evidence.
| ywei3410 wrote:
| Anecdotally, a significant number of recent criticisms
| towards Emacs and vim are that they're ugly compared to
| VS code -- that seems to be a solid counterpoint to your
| argument that among users, aesthetics don't matter.
| hutzlibu wrote:
| "I will accept that I'm wrong when I either experience it
| in the real world"
|
| Well, here in the real world, (because of the need of
| Windows) I just recently started to use Notepad++ again.
| It really pains me to do so. The only way to tolerate it,
| is by removing all UI and only keeping the text. But even
| then some ugly, contrast breaking window pops up, when I
| use search etc.
|
| So I will likely switch to sublime text (even though I
| only have to work on windows sometimes). Simply because
| of aesthetics I choose a solution nicer for my eyes, when
| I have the choice, which I do.
| JackFr wrote:
| There is a certain level of professionalism your UI has
| to reach for people to trust it. If your product looks
| sketchy, people will treat it as a sketchy product. And
| if you lock into a look and feel that is 10 years old,
| people may use your product but they're going to be
| surprised if it behaves in the most up to date fashion.
| 0x445442 wrote:
| One of the best examples of this are old POS systems,
| which are mostly ncurses type applications. The people
| that use these fly around the interface so efficiently
| and are very productive.
| thequux wrote:
| Most of those old POS systems were actually either 3270
| or (more likely) 5250 applications; i.e., block mode
| terminals instead of character mode terminals. While the
| difference between block mode and character mode
| terminals is a fundamental technical difference, that
| difference impacts the UI in two major ways: 1) Most
| interaction is local, and therefore quick. All of the
| editing, jumping between fields, and even basic
| validation happened on the terminal itself. It was only
| when you submitted your changes or loaded a new screen
| that the server would even get involved (much like a web
| form without Javascript); therefore, even in an
| installation with a lot of active terminals, these green
| screen applications would be incredibly responsive. 2)
| Every screen and application had exactly the same user
| interface. Even function keys were mostly standardized
| (ever wonder where F1=Help came from?), so what you
| learned in one place in the UI would trivially generalize
| to everywhere else in the UI.
| 0x445442 wrote:
| > Every screen and application had exactly the same user
| interface.
|
| IMO this is an extremely important idea and where I think
| the modern GUI went off the rails. I also, think it's
| gotten much worse with web applications.
|
| I agree with the Raskins' that the fundamental issue with
| modern HCIs are applications. A common UI context in
| which to run commands would be more preferable in most
| use cases. I'm thinking of some mashup of the normal
| social media timeline with Emacs M-X functionality to run
| commands.
| formerly_proven wrote:
| Well many of these do come with their own specialty
| keyboards, so there's that. The display is really just a
| display for these: all buttons are actual physical
| single-purpose buttons. No mouse.
| breakfastduck wrote:
| The people who care about "looks good" are also usually
| decision makers and funders, so yes, it does matter -
| regardless of your opinion on whether it should or
| shouldn't.
| AnIdiotOnTheNet wrote:
| If we're talking about appeasing the bullshit gods, sure,
| there might be something to that but my experience is
| that they talk about "looks good" a lot but when push
| comes to shove they'd rather have something that works.
|
| Case in point: people still use Windows, and I've never
| had anyone tell me it's because it looks good.
| breakfastduck wrote:
| Certainly a good counterpoint! Now that I think of it,
| I've never heard a single person tell me they use Windows
| because of good looking UI!
|
| Unfortunately the bullshit gods usually have more
| influence than should be allowed. But making something
| 'look good' in a sprint demo where the CEO is present
| potentially releases a lot of pressure and gives the team
| _more time_ to build something that works.
| vbezhenar wrote:
| When I wanted to write application, I used Swing and I didn't
| find it horrible. Quite the opposite. I didn't care about the
| looks, though, it was not a major concern. That was before
| Java 8. I could imagine that writing callbacks would be even
| easier with lambdas.
|
| When people don't laugh at Electron applications, I don't
| know what could be wrong with Swing. Nobody cares about
| native toolkits anymore (what is native toolkit for Windows
| or Linux?).
| hutzlibu wrote:
| Yeah well, " I didn't care about the looks, though, it was
| not a major concern"
|
| There is the difference. This post is for people who do
| care about the looks. (or do care, that their users care)
| Some users don't care, which is fine to serve them, what
| they want, but most actually do.
|
| "When people don't laugh at Electron applications, I don't
| know what could be wrong with Swing"
|
| People do not laugh at electron apps, because they use html
| which is designed for good looking. In other words, usually
| much better looking. It is just not performant, unless you
| use native modules etc.
|
| And native toolkits are still a thing. Gtk for linux for
| example.
|
| Personally I also care about the looks, but I prefer
| function over form, meaning I want a functioning app first
| and secondly it should look good. But I like to have both.
| galaxyLogic wrote:
| > I want a functioning app first and secondly it should
| look good
|
| One thing to keep in mind is that you want a functioning
| app first with less than great GUI but then you also want
| an app that is "skinnable" in other words it should be
| easy to replace the look and feel without having to touch
| the application code. CSS-stylesheets attempt to
| accomplish that.
| sime2009 wrote:
| > And native toolkits are still a thing. Gtk for linux
| for example.
|
| You mean Qt?
| _bin wrote:
| I don't know why you got down-modded so much. There is no
| official "native" toolkit for Linux; Qt is just as native
| as GTK.
| panta wrote:
| gtk is not native (there are no native widgets on X
| Window System & family)
| ptx wrote:
| It's native to a user's desktop full of Gtk programs.
|
| If there were a complete Swing desktop environment, Swing
| apps would be native to that environment. But even Sun's
| Java Desktop System was based on GNOME.
| thu2111 wrote:
| HTML isn't designed for good looking. The default
| stylesheet for HTML is impossibly ugly. Heck look at HN,
| hardly a thing of beauty.
|
| However, most people do a lot of work to make web sites
| and apps attractive. You can do that work with Swing or
| JavaFX too. I've done it before, it was fine, I ended up
| with a modern web-ish feel to the UI.
| hutzlibu wrote:
| By now, html is totally designed to be good looking. Look
| at all the amount of work, that went into CSS and co.
|
| Things that cost me a line in CSS, like text-shadow,
| probably would require me to implement a shader libary in
| swing.
| abraae wrote:
| Funny. We just built it new platform in gwt. It's an
| unashamedly retro approach but there's a lot to be said from
| using Java on the front end as well as the back. Productivity
| was really high.
| splittingTimes wrote:
| Indeed. JavaFx is not to slow to build RealWorld GUI Desktop
| Apps. Here is an example of a Desktop CAD/CAM Application for
| Digital Dentistry written in Java using JavaFx and OpenGL. It
| is smooth and performant, otherwise noone would use it.
|
| https://youtu.be/36dWOXyQWmo?t=124
| MaxBarraclough wrote:
| Do you plan on trying JavaFX?
| grandinj wrote:
| Sigh. I had such high hopes for it, and then Oracle abandoned
| it.
|
| But we are trying it, and opinions (internal to my company)
| are varied. Some people like it, but I don't. Because (a) it
| has missing functionality here and there (b) it still has a
| long road to go to become battle-hardened (c) I don't see any
| of the current supporters having deep enough pockets to fix
| (a) and (b)
|
| So we're taking a mostly wait-and-see attitude.
|
| But we have an existing deep and wide investment in Swing in
| our products, so our risk profile is probably somewhat
| different to yours.
| apta wrote:
| > Sigh. I had such high hopes for it, and then Oracle
| abandoned it.
|
| As far as I'm aware, it was only pulled from the JVM into a
| separate dependency, as did several other components, in
| order to keep the JVM slim. Are you saying development on
| it stopped altogether?
| grandinj wrote:
| Oracle has mostly disbanded the team that was working on
| it, leaving only one or two staff to manage community
| contributions.
|
| There are however, a couple of small companies, and some
| individuals using it, and providing contributions.
| fayten wrote:
| Javafx is very much alive at: https://openjfx.io/
|
| Gluon also provides builds for LTS and latest here:
| https://gluonhq.com/products/javafx/
| usrusr wrote:
| Sometimes a setup like that is the best setup possible,
| no ambitious team trying to make their mark by replacing
| something that doesn't require replacing or that they
| can't replace well enough. I doubt that JavaFX would have
| more impact if they put a team of dozens on it (or,
| shudder, hundreds) but they would surely make life harder
| for those who still build on FX. A larger team might have
| already declared javaFX dead entirely, urging everyone to
| port to some exciting new javaFY and losing many of the
| remaining users in the process, without attracting any
| new ones. Arguably Swing to FX was already a bit like
| that.
| vips7L wrote:
| As far as I know Gluon has taken over the development of
| JavaFX.
| cmiles74 wrote:
| It's not easy to get JavaFX working for development and
| it's tricky to get it bundled properly for deployment. I
| can see why they wanted to split out big parts of Java
| but I think it does discourage developers from using the
| library.
| cashewchoo wrote:
| I have a long history with Swing and as painful as it is to use
| sometimes (e.g. "There are Swing developers with _low_ pain
| tolerances? ") it's astonishing how _productive_ Swing feels
| compared to React even so many years later. Maybe I 'm just
| warped but GridBagLayout, while containing a certain base level
| of frustration, is O(1) for frustration. Whereas CSS are
| absolutely O(n) or worse. One of the best feelings in the world
| is replacing a complicated nesting of buggy BorderLayouts et al
| with one nice (slightly verbose) GridBagLayout that actually
| works.
|
| In my imaginary company that I own where we all run linux
| laptops that are managed by puppet or something, I think we
| might make a strong case for building many internal tools in
| Swing.
|
| The biggest hurdle I see nowadays to using Swing is all about
| distribution: both of the jvm and the program. Imo that's
| really where the web won - certainly not because of its dev
| productivity. So it's definitely a no-go for your actual
| software product.... but for internal tools where you have a
| lot more leverage over the environment, I think it looks
| extremely attractive.
|
| Regarding JavaFX... Honestly, I really like it. I have a
| personal project that was originally in Swing and I ported it
| to JavaFX because HiDPI is in a lot better shape there (though
| I think Swing has since figured it out?). And it's a lot better
| in many ways. I love-love-love using SceneBuilder for designing
| the view layer and the Observable pattern, I think, yields a
| lot of nice QOL/verbosity-reducing things.
|
| That said, I think it did have a slightly higher O() for
| frustration than Swing's O(1). And I think the community, as a
| whole, just understands it less (less prior art etc).
|
| So if someone said "build a usable high-quality GUI asap or you
| die" to me, I'd go to Swing immediately.
| spelunker wrote:
| GridBagLayout... haven't heard that one in a while. After
| dealing with CSS madness for years perhaps I should give it a
| try again.
| FollowSteph3 wrote:
| For distribution check out Install4J
| specialist wrote:
| My buddy worked on a niche volumetric (voxel) renderer for
| ages. I helped with some of the OpenGL bindings and plumbing.
|
| Java Web Start (JNLP) worked great. It just worked. His
| customers loved him.
|
| I've always wondered why something like desktop JNLP didn't
| happen.
| gorjusborg wrote:
| I owned development of a JNLP app around a decade ago.
|
| JNLP did a good job of solving the app distribution/update
| problem, but required that you already had the JRE
| installed. Not too much different from assuming a browser
| is installed, but I found it much less likely that a user
| would take the initiative to install a JRE than a browser.
| They just don't understand what they are doing or why in
| the case of the language runtime.
|
| That said, it did work very well, in my experience.
| monknomo wrote:
| I'll echo this. I owned a jnlp app, and most of the
| support we had was around walking people through
| installing a sufficiently correct jre. Not always easy to
| do that
| coliveira wrote:
| Why apps don't just install a copy of the JRE (I believe
| it is redistributable).
| nitrogen wrote:
| When I was developing a Swing app, I ended up just
| distributing an NSIS installer that would automatically
| download and run the JRE installer if Java was old or
| missing, for that reason.
| oezi wrote:
| It failed because,...
|
| A.) ...they never figured out a good/unobtrusive update
| process for the JVM itself.
|
| B.)...Sun faltered when they picked up steam. (Remember
| when IBM threw 1 billion USD at writing Eclipse in Java?)
| cocoa19 wrote:
| And Eclipse was hands down the best tool for Java
| development... Until it was left to rot, and JetBrains
| came along.
| goatinaboat wrote:
| _I 've always wondered why something like desktop JNLP
| didn't happen._
|
| Wasn't that Marimba/Castanet?
|
| https://www.wired.com/1996/11/es-marimba/
| jfim wrote:
| I'd strongly recommend looking at miglayout [0] if you have
| to do another UI in Swing (haven't tried it with JFX). It's
| pretty much the best layout library I've seen, bar none, for
| developing UIs in Swing. You can think of it of GridBagLayout
| on steroids, and it even handles things like reordering
| buttons on a per platform basis (eg. Ok and Cancel on a
| dialog are in Ok/Cancel order on Windows, Cancel/Ok on Mac).
|
| [0] http://miglayout.com
| manishsharan wrote:
| Ahh ! Gridbaglayout! I hated it so much ! Then I had to work
| with CSS and JS and I began to realize the genius of the
| Gridbaglayout!
| mmm_grayons wrote:
| > I think swing has since figured [HiDPI] out
|
| I hear Java GUI has supposedly gotten better, but all of the
| Java GUI apps I see look awful. For instance, try telling
| that to Ghidra and it's butt-ugly text that shows up super
| thin on my hidpi display. I like Ghidra, but for a graphical
| RE tool, Cutter is so much prettier with its QT interface. Of
| course, r2 is great and works from CLI.
| spullara wrote:
| JetBrains products are all Java GUI apps and people love
| them. Depends on the team building it more than the
| technology.
| naikrovek wrote:
| But they're ugly and impossible to use, for some of us.
| Just awful and horrible UI and flow... I simply do not
| get the love for IntelliJ _anything_.
| patrec wrote:
| I say that some who likes Jetbrains and buys their
| products:
|
| No one in his right mind loves the UI of Jetbrains Apps
| and the Linux experience has always been a between a
| shitshow unless you were using Gnome or KDE. Because
| Swing does not implement the XWindows protocol properly.
| So yeah, a great team can still make a functional app
| with terrible GUI technology -- but there is a world of a
| difference to something that's really polished, fast and
| enjoyable to use.
| ClumsyPilot wrote:
| I think IntelliJ has the best UI of all IDEs I've seen,
| it sure as hell beats Visual Studio (the paid one), it
| beats Netbeans, Eclipse.. What else?
|
| VsCode and atom are simpler, but they just don't provide
| UI, for many setting you have to go to config files, and
| some functionality is missing outright.
|
| Can you think of an IDE with better UX?
| ptx wrote:
| We love IntelliJ _despite_ Swing because its other
| qualities make up for the slightly off-looking Swing font
| rendering, the glitching Swing layout redrawing and the
| glitching Swing window focus. Also, the menu bar in
| IntelliJ was reimplemented from scratch to make it work
| properly - the Swing menu bar would have been unusable
| with submenus.
| scns wrote:
| Take a look at Bitwig
| monknomo wrote:
| I am right there with you on gridbaglayout. And tools like
| WindowBuilder make it so fast to generate basically
| acceptable guis
| naikrovek wrote:
| "basically acceptable" is such a low bar.
| Rebelgecko wrote:
| JavaFX also has much better emoji support IIRC
| alzoid wrote:
| I feel the same way. I was writing a desktop Windows/Mac app
| using swing 10 years ago. The look and feel that came out of
| the box was fine. At first it was metal. It was a light blue
| with gradients to white on the buttons. Then they came out with
| Nimbus - I think that one was based on SVG or something
| similar.
|
| No client complained about either of those. And at the end of
| the day you could always call a method to get the platform look
| and feel and it could look like Windows or Mac OS. I had a menu
| to change this in the app itself.
|
| I never found the UI development hard. I was hand coding it in
| the beginning. I thought the Layouts were pretty straight
| forward (except grid bag which I never used). Eventually
| NetBeans had a decent UI designer and I used that.
|
| I think the sloppy or slow UI's came from developers who never
| took advantage of the Observable / MVC aspects of the UI
| components.
| specialist wrote:
| Swing is mostly fine. Ideologically, it's cousins with Qt.
|
| I don't think Swing's MVC strategy worked out. It was worth
| trying. But maybe 40%-50% of the framework could be safely
| removed.
|
| Some kind of DSL would be nice. JavaFX ain't it. In my own
| noodling, Swing's UI component hierarchy needed to be
| refactored to be fully composable. By the time I created enough
| shims to make Swing truly composable, I wish I'd started from
| scratch. (I haven't done Swing work in ages, so maybe this
| happened.)
|
| An event loop is the biggest thing missing from Swing and other
| UI toolkits of that era. Meaning all modifications are handled
| by the framework, no client code (or non event loop threads)
| can modify the UI. My bestie George Smith's Juipeter (?) took
| the Win32 API approach, preserving the Swing API and all
| dispatch was handled under the hood. This is kinda how a
| browser's event loop is implemented. I much prefer an exposed
| event loop and Command objects. (It's easier to stepwise debug.
| Every desktop app I've ever created also had Undo/Redo; so
| you're gonna do Command objects one way or another.) And then
| make the framework pretty with some kind of DSL over the top.
|
| Sadly, though inspired, I think Swing's LookAndFeel plumbing
| proved unnecessary. Sun believed everyone who said it mattered.
| Maybe it did for a while. But the world moved on. I still have
| no firm opinions on how I'd make an app reskinnable. (I should
| probably look to see what Qt's doing these days.)
|
| Edit: I didn't mention AWT/Swing layout managers. Just peeked
| at Google/JetBrains Compose. Meh. I like that it uses Kotlin;
| less syntactic vinegar than Java. Alas, Compose repeats the
| mistake of not separating out the layout code. After doing way
| too much layout code -- some Australians did a hysterical
| GridBagLayout rage meme video, back in the day -- The Correct
| Answer[tm] is custom layout managers. Still include some stock
| managers in the JDK. And make the layout hooks API easier to
| implement and debug.
| R0b0t1 wrote:
| >Sadly, though inspired, I think Swing's LookAndFeel plumbing
| proved unnecessary. Sun believed everyone who said it
| mattered. It maybe it did for a while. But the world moved
| on. I still have no firm opinions on how I'd make an app
| reskinnable. (I should probably look to see what Qt's doing
| these days.)
|
| Well, if they didn't bake LookAndFeel in from the start, all
| of the work would fall on the application developer to manage
| these things. Having had to look into doing this the way they
| chose _is_ the best way, what most people have a problem with
| is the UI didn 't look fully native on most platforms for a
| long time.
| mmm_grayons wrote:
| Honest question: can someone explain the focus a lot of the
| HN crowd seems to have on "native"-looking UI? I've used
| plenty of applications that don't look "native" and it
| doesn't bother me. Is there a reason to prefer it? I get
| that performance can be an advantage, but one can easily
| write a very performant application using something like
| Skia, or doing one's own GPU acceleration, without having
| any native look.
| Bjartr wrote:
| If an app follows the UI conventions of the system it is
| running on, there is less cognitive overhead for users.
| However, with the rise of web apps users have at least
| become a little more used to interacting with a variety
| of UIs, though the problem is not entirely eliminated.
| Daishiman wrote:
| We've also eliminated a ton of crappy UI conventions and
| settled on some common paradigms in all platforms. I
| remember the four-layer-deep right-click context menus
| and I kinda shudder now.
|
| There were also some really good ideas that I wish had
| caught on (I was a huge fan of focus-follows-mouse and I
| still use the X select-into-clipboard), but the general
| uniformity of UI patters nowadays is very much calming.
| nitrogen wrote:
| I really like the context menus in GIMP. Much less mouse
| travel than trying to hit the top of the window or
| screen.
| specialist wrote:
| True.
|
| Main benefit to me is deflecting spurious input. All that
| Drive By Management.
|
| Instead of explaining the history of ergonomics, the
| philosophy of ethnography, and our reams of data from
| usability testing, I'd just point at Apple's Human
| Interface Guidelines.
|
| Like name dropping Aristotle in debate class.
|
| More serious actors will try harder, lean in.
| Daishiman wrote:
| Back in the day in Unix desktop land there were 4 or 5
| different UI toolkits and they looked behaved in a
| _massively_ different way. X looked like ass. QT looked
| less like ass but had totally overloaded UIs. The
| differences were even starker on lower-res displays.
|
| Also back then browser apps were a novelty instead of how
| most people interact with computers most of the time, and
| thus anything that wasn't using a native toolkit stood
| out pretty bad. A few apps like MP3 players used it for
| their advantage, but I remember those as being mostly a
| confusing mess.
|
| More importantly, font rendering has improved incredibly
| and most rendering looks the same across toolkits in the
| same desktop environment. Back then some toolkits
| supported antialiasing, some did not, some had godawful
| rendering that looked like crap, some couldn't render
| certain symbols correctly, some didn't have good hinting
| for LCDs, etc.
|
| The reality is that very slowly most UI paradigms have
| converged into a few well-established patterns (no more
| multiple-window apps, no more focus-follows-mouse, no
| more deep right-clicked context menus, etc). So now the
| styling differences are more apparent but most UIs are
| functionally the same nowadays. The same could not be
| said 15 years.
|
| We have come a long way; despite the different looks, the
| feel is much more uniform, and there's a better
| understanding of what makes for good UIs.
|
| As I write this, I'm frankly quite thankful that we have
| reached this state of good-enoughness. Spending hours
| looking into GTK themes and different fonts was fun, but
| in a frustrating way in which no exact font-icon-theme
| combination was entirely satisfactory.
| twic wrote:
| I don't think X ever had a toolkit of its own, but i
| would guess you are thinking of Motif, because your
| description is spot on:
|
| http://www.ist.co.uk/motif/books/vol6A/ch-3.fm.html
| Daishiman wrote:
| Indeed. It was about the closest you'd get to a standard
| X toolkit.
| fulafel wrote:
| In addition to Swing also Qt and Gtk spent a lot of
| effort on this. Not to mention browsers reimplementing
| look and feel of native controls (not sure if they're
| still doing it). So it was wider than HN definitely.
| Other toolkits took the native route from the other
| direction (eg wxWdigets I think embeds the actual native
| widgets?).
| mikelevins wrote:
| There are a few reasons to prefer a native look and feel.
|
| One is that if the look and feel of an app is native to
| the platform then it can lean on a design language that
| users of the platform assume, which makes it easier for
| those users to understand how to use the UI. Affordances
| look and act the way they expect, which reduces the time
| and effort it takes them to learn a UI.
|
| Another reason to prefer it is that a UI that doesn't
| look native stands out as different. Noticeable
| differences are information. If something in a UI gets
| your attention, it should be because it's telling you
| something meaningful. Gratuitous differences from the
| platform's UI standard are not telling you anything
| meaningful, so they're just noise.
|
| A third reason is that native platforms provide their
| native looks and feels through standard frameworks that
| also provide substantial whole-system features beyond
| just making things look alike. For example, Mac users can
| rely on a common set of keystrokes to do the same things
| across almost all applications (and the exceptions are
| badly behaved). UIs built without the platform frameworks
| must either recapitulate all of these platform-wide
| conventions or just ignore them. Commonly, they just
| ignore them, which means that conventions that users take
| for granted stop working in some apps for no good reason.
| ClumsyPilot wrote:
| It's a fantasy problem. Hold on before you downvote folks
| and count the number of 'native' applications that were
| written since year 2010.
|
| Most consumer applications are now webapps or electron
| apps. From accounting software to music players, they are
| not native.
|
| If someone botheres to make a desktop app, you either
| have proffeshionals tools or resource intensive
| applications like Adobe Photoshop, Blender3D, 3Dmax,
| IntelliJ IDE's and Games. None of them look native
| either!
|
| Almost noone bothers to develop platform spesific apps,
| and native applications are dying. If we don't stop
| squabbling about native look and feel, we will get no
| native applications at all.
| specialist wrote:
| Agreed.
|
| I guess what I'm alluding to is something like CSS for
| desktop apps. I tried to tweak stock L&F a few times (not
| my choice) and I mostly failed.
|
| Back in the day, there was a guy, Sven?, that crafted
| amazing L&Fs. I dimly recall he had one that was easily
| customized.
| tpxl wrote:
| > I guess what I'm alluding to is something like CSS for
| desktop apps.
|
| JavaFX supports CSS styling.
| specialist wrote:
| Right you are. Wiki says since 1.2. It looks pretty good.
|
| I just spotted JavaFX Script. Huh. This is _almost_
| directionally correct. So of course it got killed.
|
| If you're curious what The Correct Answer(tm) is, imagine
| VRML-97 reimplemented using JavaFX Script like syntax.
|
| Its wiki has a link to the Curl (programming language).
| That syntax is also directionally correct. But is also
| missing most of VRML's semantics.
|
| There's also a link to the F3 programming language, aka
| "form fits function". Great slogan. Alas. Looks like a
| misunderstanding of Conal Elliot's Fran functional
| reactive programming language.
|
| Oh well.
|
| Thanks for the tip. JavaFX's Script w/ CSS was about 1/2
| the solution. Maybe someday someone will loop back and
| harvest the good bits.
| ptx wrote:
| Didn't they introduce something like that with the Synth
| look and feel[1] in Java 7? Although with more XML.
|
| [1] https://docs.oracle.com/javase/tutorial/uiswing/looka
| ndfeel/...
| cmiles74 wrote:
| I remember Karsten Lentzch working in this space on the
| JGoodies project. I used some of his custom look-and-
| feels in a couple of projects... I think the had some
| tools to make layout easier as well.
|
| http://www.jgoodies.com/home/about/
| specialist wrote:
| Bingo! Thank you.
| sgt wrote:
| Skia works really well for Flutter so I think basing it on that
| is a brilliant choice. Will follow this project.
| oscargrouch wrote:
| Flutter is what it is because of the quality of the engineering
| team behind the Dart language.
|
| My point being that, Skia is great but is not the most
| important ingredient at play for Flutter achievements.
|
| Also being a good choice will not pay for the bad choice that
| is choosing JVM as a primary platform for this which targets UI
| application consumers.
| fotad wrote:
| Is there any benchmark between Graphics2D vs Skia?
| viach wrote:
| When one wants to implement a new desktop UI framework there is
| an elephant in the room - the rich text editor. You can implement
| your own layout engine, styling, fonts rendering but production
| quality feature-rich text editor is another level of complexity.
| rmorey wrote:
| evidenced by Raph Levien running out of steam on xi :(
|
| https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
| vamega wrote:
| I don't believe xi was a rich text editor. Just a regular
| text editor, with some interesting design decisions.
| uDontKnowMe wrote:
| I'm continually impressed by the stuff that comes out of the
| Clojure community. They really seem to punch above their weight
| in terms of useful output, novel ideas, interesting
| projects/products. Much more so than say Scala or Kotlin which
| enjoy a lot more industry adoption.
| gosukiwi wrote:
| I don't normally comment on the website design but my god, that
| yellow background burned my eyes. I literally couldn't finish
| reading the article.
| tasuki wrote:
| Is it burning your eyes more than a white background would? Can
| you explain how?
|
| I like yellow, and I like this website: it is simple and to the
| point.
| acomjean wrote:
| If you are running firefox, there is a little icon at the right
| side of the url bar "reader mode?" that fixes it.
|
| Though did anyone else notice the little "sun" slider at the
| top of the page for the spotlight in html? Useless but fun.
| suyash wrote:
| interesting, I found it refreshing and with enough padding, the
| focus was right on the content (text).
| unnouinceput wrote:
| Thank Mozilla for Firefox reader mode. This site is horrible to
| look at. And because of that, dear Nikita, I haven't looked at
| your repository. Remember the rule "first impression matters"?
| therealasdf wrote:
| Your loss
| unnouinceput wrote:
| Nah, I'm good. Java and its related technologies can die for
| all I care. I really hate Java. I use it every day because
| that's where my money come from, supporting legacy crap from
| 90's but I really hate it.
| vijaybritto wrote:
| Looks like some css issue. But the content was great
| [deleted]
| acomjean wrote:
| How does this compare with what the "processing" language does
| with a javalike language that seems to use JVM and a display
| layer?
|
| Its pretty fun. Also its javascript cousin p5.js
|
| https://processing.org
| smarx007 wrote:
| > Like any other JVM library, it's cross-platform. It runs on
| Windows, Linux and macOS. It's as simple to use as adding a JAR
| file.
|
| Well, not exactly. https://github.com/JetBrains/skija/ is 30% C++
| and of course requires native builds:
| https://packages.jetbrains.team/maven/p/skija/maven/org/jetb....
| If you are lucky, Maven simply hides it from you.
|
| UPD: no, it doesn't hide it. See
| https://github.com/JetBrains/skiko/blob/master/skiko/build.g...
| and search for 'lin'/'mac'/'win' and see for yourself.
|
| UPD2: @-moz-document domain("tonsky.me") {
| body { /* surovyi background color off */
| background-image: none; background-color: hsl(0, 0%,
| 85.9%); } }
| vbsteven wrote:
| Is this a problem? We're always going to need native blobs to
| interface with the OS. The JVM can package these native
| libraries within the jar so for the application developer it is
| indeed as simple as adding the jar file to your project.
| chrisseaton wrote:
| > We're always going to need native blobs to interface with
| the OS.
|
| Ideally we won't when the JVM gets an FFI built-in.
| shock wrote:
| https://en.m.wikipedia.org/wiki/Java_Native_Interface
| abollaert wrote:
| ... which is why we want to use FFI instead ;-) Now you
| already can using JNA though. JNI still requires you to
| write native code and compile it for your target
| platform, FFI eliminates that need.
| [deleted]
| chrisseaton wrote:
| I think you're possibly confused about what JNI is or
| what the discussion is about.
|
| JNI needs binary blobs. The new FFI won't. So we will not
| need binary bobs when we get the new FFI.
|
| See?
| smarx007 wrote:
| Not at all! Desktop apps require platform-specific
| executables and installers so this is unavoidable. But the
| author made it sound like a piece of cake for developers used
| to making JAX-RS services.
| speps wrote:
| Instead of Skia bindings, probably the effort of building a C++
| UI toolkit that has the features he needs and THEN do Java
| bindings for it would prove more useful for the community instead
| of tying the UI toolkit to Java. That's kind of what's missing in
| my opinion, something that does the hard part of UI, integration
| with native OS controls (eg. open dialogs, etc.), accessibility
| even with custom UI drawn using 2D primitives, etc. and that
| would be a great project that would also benefit the author as
| long as it has Java bindings.
| ajuc wrote:
| I just want qt on java working as well as pyqt.
| cromwellian wrote:
| > WASM implies Rust or C++
|
| Nope, there are lots of languages that compile to WASM. In fact,
| Kotlin compiles to WASM, and you get the best of both worlds,
| able to interop with the JVM, and compile to WASM (and C++/ObjC,
| and JS)
| oscargrouch wrote:
| Your comment makes me think how WASM will go through this hype
| phase where people will think is a panacea to build things for
| the browser.. Hype gold rush all over again, but applications
| built on native or even javascript ones in the web or Electron
| will perform better in most cases. Of course companies will
| think its great for them to have only one codebase for every
| platform, but applications built with Javascript or Typescript
| for the web, with eventual WASM module here and there will be a
| better fit, so it will be risky to try to cut expenses and
| development there.
|
| WASM will be awesome to bring great tech that is only available
| in native platform to the web, like FFMPEG, or to accelerate
| some code that uses a lot of math. But i think that people that
| are going way down into this WASM rabbit hole will have a wake-
| up call pretty soon.
|
| WASM will open some blue-seas for sure, but they are limited to
| some niche scenarios and using WASM for application development
| for the web, desktop and mobile wont be one of them.
| cromwellian wrote:
| I don't think of WASM as web specific, I think of it as a
| portable compiler IR format, and from an untrusted third
| party code, isolation standpoint, running code in WASM has
| nice security properties.
|
| This is why you see it starting to be used for "serverless"
| deployments.
| suyash wrote:
| sounds pretty bold, I'd love to try, how about integrating with
| openGL, is that a possibility, specially running GL/SL shaders ?
| MaxBarraclough wrote:
| > They were so significant that only one company managed to build
| a decent-looking app in Swing [IntelliJ IDEA]
|
| Also NetBeans.
|
| I'm not convinced that JavaFX is too slow for use in real-world
| GUIs. The article doesn't really back up this claim. It also
| ignores the SWT toolkit, used by Eclipse.
| usrusr wrote:
| The omission of SWT made it very hard to read for me. It's
| really only relevant for the introduction (on the low level
| that a skia binding is, SWT is surely just going through AWT),
| but echoes of the omission still bounced around in my head in
| the later bits, distracting me. A quick dismissal (good or not)
| would have made the rest much easier to read.
|
| Unfortunately I find the last part a bit confusing: is this the
| lower level of the stack that beneath Compose Desktop? How is
| skiko related, or is it unrelated? Apparently Compose Desktop
| is built on Skijo (the github readme is much less confusing).
| Apparently the skiko build is also consuming skija as a
| dependency (in some very interesting ways, apparently planet
| kotlin still does enough java to lombok it), but the
| presentation on the blog would benefit a lot from a healthy
| dose of clear "that uses this" bragging.
|
| All in all as a slowly greying java guy, it's amazing to see
| this entirely unexpected breath of fresh air for the JVM. In
| this age of new desktop apps having been given up completely to
| electron and the like, desktop JVM could see a surprising
| renaissance as a lesser evil.
| MaxBarraclough wrote:
| > SWT is surely just going through AWT
|
| Not so, SWT uses its own bindings to the OS's native GUI
| toolkit, using JNI.
|
| > desktop JVM could see a surprising renaissance as a lesser
| evil
|
| I'm not convinced that a whole new toolkit is the solution,
| with all the challenges that brings (lots of widgets to
| create, internationalisation, accessibility, multiple
| platforms to test on, etc). I figure the better move would be
| to work on improving JavaFX. As far as I can tell it's a
| pretty solid GUI toolkit, albeit one with little adoption.
|
| _edit_ Also, I suspect one of the things holding back Java
| desktop GUIs might be that they 're often clumsy to
| distribute. Expecting the user to install the JVM isn't good
| enough, the application should bundle a JVM, or use ahead-of-
| time compilation. The user should never be made aware of what
| language you built the program in. As I understand it,
| OpenJDK has been making solid progress on the latter option.
| (And Excelsior JET no longer exists.)
| jspaetzel wrote:
| JavaFX might turn out to be a winner but it's still partly
| proprietary and is still transitioning from Oracle to the
| OpenJDK community. There's good reasons for it having
| little adoption.
| usrusr wrote:
| And about your edit, it's true of course, this is an issue.
| If you bundle the JRE feels wasteful and if you don't it
| feels uncaring for the less technical. Didn't JavaFX,
| beside being "Swing 2", consist of some native launcher
| component that would connect with an installed JRE if
| available (and sufficiently modern) and guide the user
| through download/installation if not? Memories are faint.
|
| Many similar approaches have been done, but none became a
| conveniently dominant go-to solution. Perhaps AOT
| compilation will finally bring a JRE bootstrapper component
| that is sufficiently "java" to find a wide footing in the
| java dev community and sufficiently friendly to end-users
| to end all "but maybe that other tool is even better" that
| kept all existing approaches niche.
| usrusr wrote:
| > Not so, SWT uses its own bindings to the OS's native GUI
| toolkit, using JNI.
|
| A right, I forgot that, thanks. What's the SWT approach to
| use cases where you basically want a pixel canvas? Falling
| back to AWT on a surface allocated from the native API or
| its own facade for native APIs?
|
| In any case this property of SWT kind of explains the
| omission, SWT happens on a level that is two layers away
| from skija in the stack Jetbrains are building for Compose
| Desktop.
| MaxBarraclough wrote:
| > What's the SWT approach to use cases where you
| basically want a pixel canvas? Falling back to AWT on a
| surface allocated from the native API or its own facade
| for native APIs?
|
| I don't think SWT makes any use of AWT, I believe it does
| the latter.
|
| > SWT happens on a level that is two layers away from
| skija in the stack Jetbrains are building for Compose
| Desktop
|
| The article is making the case for a whole new GUI
| toolkit for Java, without making a persuasive case
| against JavaFX (I'm not convinced that its performance is
| a problem), and without mentioning SWT, the foremost
| 'unofficial' desktop GUI toolkit for Java. Skija may have
| its merits as a platform for 2D graphics, but that's not
| the point.
|
| Incidentally, the article's title is misleading. It's
| about GUI toolkits, not graphics libraries.
| usrusr wrote:
| The whole new GUI toolkit in question is Compose Native
| and that's not entirely new (only the desktop part is).
| Literally millions of Android devs would already feel
| more at home with it than with any other desktop UI
| toolkit.
|
| Maybe it's a bit dishonest to present Skija as if it was
| made for any other reason than to enable Compose Desktop,
| but it's very laudable to have the ambition to be more
| than an enabling component of that.
| ksec wrote:
| >Also, I suspect one of the things holding back Java
| desktop GUIs might be that they're often clumsy to
| distribute.
|
| I just download Netbeans, this is 10+ years since I touch a
| Swing / Java apps. And nothing has changed, it still looks
| Java. It is still heavy, although start up speed are now
| better. But generally speaking an Electron Apps ( VS Code )
| looks and works better than that.
|
| Eclipse is still better look wise, as it was 10+ years ago.
| That was basically the reason why I choose SWT back then.
| But it is still not perfect.
|
| So I decide to check out another consumer Desktop App from
| similar era, Vuze, or used to be called Azureus. And it is
| the same, Desktop Java Apps. And yes that was the reason
| why no many were using Consumer Desktop Java Apps. They
| dont look good, heavy on resources, need JDK etc....
|
| As if nothing has changed in the past 15 years. I remember
| I was trying to use GCJ and SWT for Desktop Apps then, it
| was just too hard. I gave up. And it seems no one cares
| about decent, java desktop apps.
| MaxBarraclough wrote:
| > it still looks Java
|
| I think the _Nimbus_ look is ok. [0]
|
| > It is still heavy, although start up speed are now
| better.
|
| It's certainly heavy. iirc NetBeans spins up over 20
| threads even if you're not doing anything. As for startup
| times, is this on the same hardware? I imagine SSDs must
| help with NetBeans startup.
|
| > trying to use GCJ and SWT for Desktop Apps then, it was
| just too hard.
|
| There was a proprietary payware alternative to GCJ called
| _Excelsior JET_ but it was discontinued 2 years ago. [1]
|
| [0] http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbu
| s_Scree...
|
| [1] https://en.wikipedia.org/wiki/Excelsior_JET
| floriol wrote:
| Not my project but this video seems to imply that it has no
| problem with performance whatsoever:
|
| https://www.youtube.com/watch?v=7Hai7cavmUY
| Cthulhu_ wrote:
| > I'm not convinced that JavaFX is too slow for use in real-
| world GUIs.
|
| I would like to have an opinion on this myself but I've yet to
| find a JavaFX application in the wild.
| [deleted]
| radomir_cernoch wrote:
| We do use JavaFX in an app for our customer. The application
| is not public, however.
|
| There are many aspects to UI performance. Unlike IntelliJ,
| our app has only tens of widgets displayed at once - I can't
| compare in this regard.
|
| However, we have very big models, namely tables with >100000
| of rows. Scrolling is smooth and initialization as well. From
| my experience, JavaFX allows you to write elegant code which
| still caches a lot of components. This is a strong
| performance benefit.
|
| My issue with JavaFX is a very well thought-out philosophy,
| translated into an API which is far from perfect. Once you go
| beyond "hello world" examples, you e.g. have to start type-
| casting. I'd love to see JavaFX v3 where these things would
| be sorted.
| ta988 wrote:
| My experience as well. JavaFX proved to be really fast for
| us (internal tools as well). Used to control equipment
| (live) or do calculations. And we distribute in a <200MB
| package jre included (modular builds), installs on a fresh
| windows or linux with no other download. For people that
| already have a jdk installed, i think we are around 100MB.
| There has been a lot of work on making "small"
| distributable java apps in the recent JDKs.
| geokon wrote:
| I wrote a JavaFX application in Clojure using CLJFX. It's
| fantastic and native-speed when you do things right
|
| https://github.com/geokon-gh/corascope/
|
| I even managed to make a little SVG backend for it
|
| That said - this seems to be more of a " graphics library "
| while JavaFX is more of a " user interface library ". I'm
| sure there is a ton of overlap - but I wouldn't be making
| funky creative coding displays directly in JavaFX
|
| My minor annoyance is that it's nearly impossible to make
| something that runs on Android out of that - which seems like
| a giant shame given it's all JVM
| jb1991 wrote:
| The end of the article points out how this graphics library
| is getting used as part of a UI kit. The article goes full
| circle, it talks about the three different components of UI
| technology up front, and then shows the other two
| components near the end.
| frou_dh wrote:
| I tried JavaFX recently and within seconds all I could notice
| was jacked up font rendering.
|
| By this point, it should be table-stakes that any GUI
| framework must always be tapped into identical font rendering
| to native apps on the host platform.
| shock wrote:
| Different JVMs have different font rendering settings. Try
| Zulu.
| chucky wrote:
| > The second is the DOM. It is a horrible collection of hacks
| that make simple things hard and hard things impossible. I have
| thought many times "if only was I drawing this control/layout
| directly, I would've finished hours ago."
|
| I think this betrays a lack of understanding on the part of the
| author of how to write good web components. Yes, the DOM is
| tricky at first, but that's because it's trying to support things
| like resizing windows to arbitrary sizes.
|
| I don't even understand what he tries to say with "draw the
| control directly". In component-based library, this is exactly
| how you would work. Put your component where it needs to be, and
| boom, you're finished (just like in all frameworks this is a lie,
| you probably still need to tweak).
|
| I don't in general buy the argument that the DOM is low-
| performant and low-quality. Lots of great and performant UIs have
| been built on the web platform.
| dmitriid wrote:
| > I think this betrays a lack of understanding on the part of
| the author of how to write good web components. Yes, the DOM is
| tricky at first, but that's because it's trying to support
| things like resizing windows to arbitrary sizes.
|
| This statement betrays the commenter's lack of understanding
| understanding of both limitations of the Web model and the
| freedom afforded by almost every single one of UI libs and
| frameworks.
|
| > I don't even understand what he tries to say with "draw the
| control directly".
|
| Aaand here it is: "I don't understand".
|
| In a GUI framework/lib you usually have the ability to skip the
| provided primitives and draw whatever you want directly. A
| framework/library doesn't provide a control you need? You just
| draw it yourself.
|
| So, instead of re-inventing, poorly, a virtual list, or a
| calendar, or a customisable drop-down with a few thousand divs,
| z-index issues and layout thrashing, you can (relatively)
| easily implement those controls yourself. At easy 60 or 120
| fps.
|
| > I don't in general buy the argument that the DOM is low-
| performant and low-quality. Lots of great and performant UIs
| have been built on the web platform.
|
| Name a few, please. And when you look into those "performant
| UIs", you'll see on or more of:
|
| - skipping the DOM entirely and building everything on top of
| canvas or webgl
|
| - going through great pains to: avoid mutating DOM, avoid
| repaint/reflow (which can happen by simply querying the DOM
| [1]), reducing the already laughably small amount of updates
| even further to prevent DOM updates, layout thrashing, JS GC
| pauses etc. etc.
|
| And this will still not come even close to, lets say,
| displaying a million objects on screen at 120fps (any modern
| game engine), or any significantly complex UI layout (any
| professional app).
|
| [1] https://csstriggers.com and
| https://gist.github.com/paulirish/5d52fb081b3570c81e3a
| fctorial wrote:
| > In a GUI framework/lib you usually have the ability to skip
| the provided primitives and draw whatever you want directly.
|
| HTML5 canvas?
| iovrthoughtthis wrote:
| I don't think you're wrong just that the discussion warrant
| more nuance and less ego. On the the comment...
|
| > You just draw it yourself.
|
| This is disingenuous. It might be ok in Games not to have
| decent interop with the OS but for productivity tools, it is
| a requirement.
|
| Which means you need to implement OS native interop (for
| multiple DE's in linux perhaps), accessibility for screen
| readers and you need to be smart with your rendering because
| having a function called 60+ times a second is a surprisingly
| big foot gun. All this across 2-3 very different (and
| currently diverging) operating systems.
| dmitriid wrote:
| > Which means you need to implement OS native interop (for
| multiple DE's in linux perhaps), accessibility for screen
| readers and you need to be smart with your rendering
| because having a function called 60+ times a second is a
| surprisingly big foot gun. All this across 2-3 very
| different (and currently diverging) operating systems.
|
| Yes, you have to do all of that, and I never said it was an
| easy task. That is, it's relatively easy compared to the
| web. This task is close to impossible on the web,
| especially if you want decent performance.
| lasagnaphil wrote:
| Rendering something natively in OpenGL (or using a lightly-
| wrapped framework around it) is usually much more
| performant than fiddling with canvas elements or CSS, so I
| don't think it's a footgun. (And OpenGL is quite cross-
| platform if you stick with older versions.) And since
| browsers these days also have all sorts of incompatibility
| issues, the merit of "write JS once" seems to be dwindling
| a bit... (although that's becoming less of a problem when
| Chrome is becoming the de-facto browser)
| AnIdiotOnTheNet wrote:
| > Lots of great and performant UIs have been built on the web
| platform.
|
| This must be some strange usage of the word 'performant' I
| wasn't previously aware of.
| simion314 wrote:
| Let me give you an example, the DOM is missing a decent
| dropdown component. Some will say that they can make a cool
| dropdown in 2 minutes with 20 divs and some js and css, the
| issue is this 2 minutes components have lot of bugs and missing
| features (accessibility, keyboard supports, missing events) and
| then if you need the same dropdown in other section but you
| need to add 1 small thing you duplicate it again.
|
| For comparison in GUI toolkits you use the existing feature
| complete dropdown. And if you need more customization you
| extend the dropdown and override it's render/paint function and
| you can painted as you want. What I liked about this powerfull
| GUI toolits is that most of the time you used the built in
| stuff so all application look consistent and only special apps
| would create custom stuff.
|
| I wish browser makers would focus on improving the existing DOM
| elements and adding a few more so we could use native ones
| instead of having to implement custom shit because the designer
| wants the component to look in a specific way but you can't CSS
| the native element to get the result.
| t0astbread wrote:
| If you override the render/paint function somewhere, would
| you not have to do extra work to improve accessibility again?
| thu2111 wrote:
| No, desktop accessibility APIs are basically about
| exporting a labelled semantic tree to screen readers. As
| long as your dropdown is still semantically a dropdown with
| items, etc, and responds to basic commands, it doesn't
| matter what it looks like.
| simion314 wrote:
| It depends. Say there is a Label that should show some text
| and a crazy designer asks me to have the text rotating and
| jumping and also be super light gray and ahrd to read, the
| component could still report back to accessibility
| framework the actual text and you could have a better
| experience then a regular user.
|
| Custom rendering is not most of the time painting on a
| canvas. A simple example , you have a Dropdown, each item
| is rendered with a simple component that is something like
|
| <text>item.text</text>
|
| and you might want to change the render function to be
|
| <icon>item.icon</icon><text>item.text</text>
|
| I think ATM you still can't use the HTML select to have a
| dropdown with the countries and the flags or a dropdown
| with the fonts and each font it is painted with it's own
| font family, or customize the numeric spinner arrows or
| scroll bars colors.
|
| Again , I prefer using native widgets, but I am forced to
| implement designs and I have to replace a native component
| with a pile of netsted divs,js and css.
| t0astbread wrote:
| Oh, I see what you mean. I was thinking about the case
| where you're painting something completely different than
| the semantic information but I guess that's rare.
|
| You're right, in HTML you have to fall back to elements
| without accessibility features pretty quickly if you
| wanna customize a native component. There are some
| features that one can use to restore accessibility like
| ARIA but yeah, it's not great.
| lmm wrote:
| Not if you're just making it look different, because the
| component already hooks into the right APIs to expose
| itself to screenreaders etc.. Of course if you're doing
| something completely radical you need to implement
| accessibility yourself, but there's more flexibility to
| customise existing components as little or as much as you
| like.
| nxrabl wrote:
| It's good that you mention accessibility, because TFA does
| not. Nor does the Skaija repo, and nor does the repo for
| Jetpack Compose for Desktop [0], JetBrains' higher-level UI
| kit based on it. I think it's a mistake to suggest that
| "native UI toolkit" implies "feature complete".
|
| [0]: https://github.com/JetBrains/compose-jb
| Phrodo_00 wrote:
| Skaija wouldn't really be the place for accessibility
| features (except for maybe provide access to color-blind
| filters?). It's an important feature, though, and I hope
| Jetpack Compose gets better at it.
| vips7L wrote:
| Desktop Compose is in alpha. I don't think it's appropriate
| to use that as evidence of feature completeness.
| pier25 wrote:
| > _then if you need the same dropdown in other section but
| you need to add 1 small thing you duplicate it again_
|
| Not really. That's the point of making components in
| React/Vue/Svelte/etc, you can create reusable modular parts.
| simion314 wrote:
| Can you today make a component, use it in 10 places in your
| project and now if you need to add one extra thing for the
| 11th place can you "extend" the existing component so if
| you fix a bug or add some new event in the old component
| the extended one inherits it? I know in OOP toolkits you
| can override any public and protected functions and add
| your little stuff on top but I am not sure if you can do it
| in React without cloning the code and modifying it.
|
| As an example you say have a DataGridView , a giant
| component with a lot of features and you need to modify
| something, can you do it in React using inheritance like
| functionality and not risking breaking anything where the
| component is already used ?
| pier25 wrote:
| Instead of using inheritance you'd use composition, but
| yeah you can do exactly what you're describing.
|
| Just right now I'm building a component that abstracts
| filtering and sorting for lists of items in Svelte.
| simion314 wrote:
| If a designer gives you 2 images to use for a radio
| button can you do a correct radio button in 1 minute (no
| third party libs?)
|
| By extending a RadioButton and overriding the paint
| method I can do it in 1 minute. The component would still
| be a radiobutton, same interface, same events,same
| keyboard shortcuts, same accessibility, focus/tab-order
| behaviour.
|
| In React you would start with a div, put 2 img inside it
| and implement the toggle logic, After that you need to
| add the events, the keyboard shortcuts, the tab ordering,
| focusing, accessibility.
| funcDropShadow wrote:
| I think the point was: Chrome has as much lines of code as
| Linux with all its drivers and still has no decent dropdown
| built in. Not that it cannot be built.
| galaxyLogic wrote:
| Another example is trying to implement a text-editor in the
| browser. Yes it can be done, but the standard component for
| text-editors is TextArea which is not much to write home
| about.
|
| An example big issue I faced creating my own editor was
| getting the caret follow my mouse-clicks and key-presses.
| Then trying to highlight matching parenthesis. I know it is
| doable because I did it but I had to spend a lot of time on
| it and I'm not quite happy with the end-result. A standard
| high-quality text-editor component should be part of the web-
| platform but is not.
| simion314 wrote:
| Yes, I had to do something similar using the
| contenteditable, a giant issue is that the browsers differ
| a lot(I had a lot of issue with the selections/ranges
| differing a lot)
| ta34545734 wrote:
| > Some will say that they can make a cool dropdown in 2
| minutes with 20 divs and some js and css
|
| Isn't there already JS libraries to do that? If so, doesn't
| it boil down to the same issue as traditional OO UI toolkit,
| where the abstraction must be extremely precise to allow for
| any sort of customization?
|
| > For comparison in GUI toolkits you use the existing feature
| complete dropdown.
|
| Aren't you making the assumption here that GUI toolkits
| necessarily bundle a perfect implementation of this widget?
| Why would that be only possible for native GUI and not for
| Web UI?
| simion314 wrote:
| The problem with existing libraries that give you a
| dropdown is that you have not one but many such libraries
| and some will not be compatible with what your project
| uses, some are missing the feature you need, some are
| bugged. As an example the Search input in YouTube has a
| dropdown with suggestion, that dropdown got stuck on for me
| a few times , clicking outside it did not make it hidden, I
| had to reload the page. So google developers are incapable
| of creating a basic dropdown that has the feature where you
| can type and shows you some options. If there was a built
| in powerful enough dropdown then YouTube could have used
| that and not invent it's own broken version. My point is
| give us native components as powerful as Qt,Flex,WPF ,
| React, Agnular and others could use those or if they want
| can use DIVs or canvas , I don't want to remove you the
| option to use React or whatever.
|
| The existing toolkits are not as limited as you think
| because you can most of the time override them and do
| whatever change you want , most of the time though you have
| enough built in customization that you don't need to do
| advanced overrides (I do not mean only visual
| customization, for example a dropdown can give you the
| option on how many items would be visible on the dropdown
| at once, a DataGrid can give you option about what columns
| are resizable, sortable and you can specify if you want a
| sort function for a column. And about DataGridView
| components, the native ones are implemented smart and can
| hold a million rows and have no performance hit because are
| smart enough not to create million GUI elements.
|
| >Aren't you making the assumption here that GUI toolkits
| necessarily bundle a perfect implementation of this widget?
| Why would that be only possible for native GUI and not for
| Web UI?
|
| Desktop toolkits are not perfect so if your designer asks
| you for super extra fancy stuff you can either extend and
| existing one or you can create it from scratch but for
| visual stuff just changing the paint/render function would
| be enough.
|
| For WebUI, let's say I need a good dropdown, calendar, and
| DataGrid where do I go and get this components? If you say
| bootstrap those are too basic, if you say some React stuff
| maybe I am not suing react, if you link me to some Angular
| version N stuff maybe I am using N-1 version etc.
|
| I think if you ask 3 developers to go and find me an X
| component for my framework Y I would get back at least 3
| different results.
|
| Other issue with non native components is that if you do
| not read the code you might not notice bad quality,
| components that do not clean after themselves or that run
| code each time you move your mouse around the page.
| [deleted]
| millerm wrote:
| I will just say I agree in my own words "the DOM sucks for user
| interface development". I don't know why people are always so
| quick to defend it, or insist on being ardent apologists for
| it. It's a crap foundation for what we've been building on it
| for decades. It was never intended for this.
|
| Yes, I am forced to use is, as we all are. But, I tell you, I
| miss Swing and actual GUI component libraries that were
| designed, and implemented, from the ground up to be used as
| GUI.
|
| I could rant until the end of my career for this mistake of a
| path we all took in the 90s. HTML/Hypertext was a game changer.
| But, bastardizing this implementation into what we have to deal
| with today was a total and utter mistake.
| mtrovo wrote:
| Could you give some examples of what are the problems with
| DOM and how do alternatives look like?
|
| It's been some years that I don't do anything web so I'm not
| sure if I'm familiar with its problems.
| dathinab wrote:
| I wouldn't say it's a crap foundation but it's the wrong
| foundation.
|
| DOM, CSS and the way they interact with JS where designed for
| mostly immutable "documents" with mostly but to complex
| design.
|
| Then it was bend and extended to somewhat extend somewhat
| more complex designs and more interaction.
|
| That step was repeated again and again until now where is
| used for application graphical user interface instead of just
| displaying documents with some forms in them.
|
| The foundation is fundamentally unsuited for the task it's
| used for by now.
|
| CSS might seem simple but has crazy amounts of hidden
| complexity and until recently lacked trivial/simple ways to
| do some layouts common for GUIs but unnecessary (and bad) for
| displaying documents.
|
| In recent years thinks have gotten better, e.g. CSS grid
| makes GUI layouts SO much simpler, but still the foundation
| is broken.
|
| As consequence many of the promises the foundation gives are
| in practice often broken, too (like accessibility, like free
| resizing and zooming which often doesn't work correct, like
| cross platform as web apps are often designed for chrome
| relying accidentally on chrome specific behavior especially
| wrt. CORS, ...)
| jcelerier wrote:
| > Lots of great and performant UIs have been built on the web
| platform.
|
| still waiting to see them, at least for performance levels
| comparable to 2007 desktop apps
| iovrthoughtthis wrote:
| Yeah, the whole of the bottom of the post strikes me as off
| base.
|
| I think the author is trying to get to a wonderful future but
| their heading in totally the wrong direction.
| [deleted]
| oblio wrote:
| With the DOM, can you extend the default text input component
| while keeping the default behaviors, like when
| inheriting/subclassing a component for normal GUI toolkits? For
| example accessibility.
|
| Also, does the DOM have a ListView/TreeView?
| MaxBarraclough wrote:
| > Lots of great and performant UIs have been built on the web
| platform.
|
| At the risk of simply mirroring dmitriid's comment, and without
| wishing to come across as snarky: which ones?
|
| I don't think I've ever seen an Electron app that couldn't have
| been implemented in C++ to run appreciably faster and use at
| most a quarter of the memory.
| marktangotango wrote:
| The author totally misses the real problem with jvm desktop apps,
| deployment. Either the jvm is bundled with the app or some other
| (platform dependent) hack has to be employed to ensure a correct
| version of jre is on the machine. Microsoft manages this nicely
| with .net btw.
| _old_dude_ wrote:
| The author is an employee of JetBrain. I believe JetBrian is
| using jlink [1], a tool that let you embed the modules of the
| JDK you need with your application, for all their products
| since they have migrated to JDK 11.
|
| [1] https://docs.oracle.com/en/java/javase/11/tools/jlink.html
| hderms wrote:
| Is bundling the JVM with the app really such a huge deal on
| desktops? I know it would add a bunch to the binary size but
| what are the other issues?
| krzyk wrote:
| It is the recommended way since Java 11 (no JRE there) -
| using jlink can build smaller packages and app developer
| doesn't depend on the JDK/JRE on the system.
| diegof79 wrote:
| The article doesn't mention SWT :(
|
| I used SWT to create desktop UI prototypes. The biggest issue of
| SWT is the distribution channel: to use the usual Maven repo you
| need a non-official package (this was around 2017). But other
| than that is a decent UI lib: it uses native widgets, it supports
| HiDPI, the layout using attachments are easier than Swing.
|
| I wonder why SWT is not popular in the JVM (my guess is the
| decision to distribute it using Eclipse p2 by default, and the
| lack of visibility outside Eclipse)
| znpy wrote:
| There used to be qt Jambi...
| geokon wrote:
| Errr, is there some example I can compile both into a Desktop app
| as well as Android app easily? I never got why we never got
| convergent Java apps that run everywhere... It's seemingly almost
| easier to do that with Qt than with Java
|
| If I could get an example written in Clojure that'd be even
| cooler :)
|
| I noticed they have this:
| https://github.com/JetBrains/skija/blob/master/shared/src/ma...
|
| Is rendering SVG in the pipeline? It seems within the scope of a
| graphics library.. or maybe not?
| saagarjha wrote:
| Ok, so this starts off as "Graphics for the JVM" which sounded
| promising, but then the first line starts talking about desktop
| apps and warning bells start going off. If you read the post,
| it's totally fine...if you are trying to do fast drawing or
| something. But no, we're making desktop apps, with circles and
| triangles and squares. This just isn't how it works, and the
| reason is the same as it always has been: a drawing toolkit is
| not a GUI toolkit.
|
| If you want people to make good apps, you need to give them
| buttons and checkboxes and text fields. If you don't, we'll,
| they're going to do it wrong. Time and time again people have
| tried doing this and the best we've gotten out of it are game UIs
| and Flutter, which are a solid "mediocre" in the UI department.
| The former probably gets a pass because it's allowed to be
| quirky, but the latter is literally run by a megacorp and it's
| still struggling to get basic things right.
|
| Heck, even Swing and HTML are better than this; at least they
| give you components that someone actually spent time on
| implementing and making half-decent. Maybe they suck, but they
| suck _together_ in a consistent way that is at least partially
| battle-tested, a must for any GUI toolkit. They've gotten to the
| point where they're no longer just a middle finger to people with
| accessibility needs.
|
| Look, I don't want to rain in this author's work. If you're going
| to treat it as an accelerated Graphics2D, go right ahead, this
| seems like it would be an excellent solution for you. JVM
| bindings to Skia seem _awesome_. Just don't, like, draw something
| that looks like a GUI in it.
|
| (I could go longer about the characterization of mobile apps as
| constantly being purged from RAM and losing your work and
| IntelliJ being a good Java UI, but that would probably make this
| divisive comment longer than it already is.)
| smarx007 wrote:
| Ehmmm, did you actually explore any links?
|
| https://www.jetbrains.com/lp/compose/ shows a code editor
| prototype.
| saagarjha wrote:
| I know Compose exists, and it's exactly the concern I have:
| look at the example apps, and compare them with true native
| desktop apps. Can you really call the result a good desktop
| UI? Is it not just a mobile UI that was blown up? Actually,
| it's difficult to even call it a good mobile UI, because at
| the moment it certainly falls on the side of "bunch of shapes
| put together" rather than "UI toolkit". Of course, while UI
| is just a bunch of shapes on the screen, it needs to be
| cohesive, and familiar, and accessible; not to mention the
| many, many behaviors under-the-hood that don't show up in a
| screenshot.
| dmitriid wrote:
| > I know Compose exists, and it's exactly the concern I
| have: look at the example apps, and compare them with true
| native desktop apps. Can you really call the result a good
| desktop UI? Is it not just a mobile UI that was blown up?
|
| Because the project is in alpha? And it says so on the
| page?
|
| To quote from the article on skia:
|
| --- start quote ---
|
| We are so used to things we can hack together in a week,
| nobody is thinking in terms of years. And good UI requires
| years of work. It's a big commitment.
|
| The road to high-quality UI on JVM is a long one. We'll
| need:
|
| - a graphics library,
|
| - a window/OS integration library,
|
| - a UI toolkit.
|
| --- start quote ---
| sooheon wrote:
| Is your central complaint that a "graphics for the JVM"
| library is not a full featured "UI toolkit for the JVM"
| library?
| thu2111 wrote:
| A bit of context may help.
|
| The author of the blog post works for JetBrains (I
| think). JetBrains are interested in moving away from
| Swing for their product line. Their intended replacement
| is a port of JetPack Compose to the desktop, perhaps
| because it's a Kotlin-centric framework and Kotlin is
| their baby, perhaps because Google is funding Compose and
| they hope that it'll have more money invested in it than
| Swing/JavaFX did.
|
| Compose renders with the Skia graphics library. Hence,
| Skija and Skiko, bindings to Java and Kotlin
| respectively. And hence their Compose for Desktop effort.
|
| The grandparent comment is questioning whether a mobile
| toolkit ported to desktop is really going to become
| competitive with Swing anytime soon, given that although
| Swing is admittedly by now a very old API, it's been
| continuously developed for 20+ years and is thus by now
| one of the most battle tested and matured frameworks in
| the world.
|
| Now you might ask, but aren't Skia bindings useful in and
| of themselves? Well sure, maybe, but bear in mind Java
| has had a Skia equivalent for a very long time via Java2D
| as used in Swing, and JavaFX also has a Skia-type
| subsystem where you can issue drawing commands and they
| get hardware accelerated. So to understand the value of
| this new library you very much need to be able to do an
| in depth comparison of Skia vs Java2D vs the JavaFX
| Graphics subsystem. Very, very few people have the
| expertise to do this and the blog post doesn't really
| try.
|
| I've actually looked at this topic in the past few months
| for various obscure reasons. I'll say that:
|
| * Skia is the core of Chrome so it's actively maintained,
| which is good. On the other hand so is Java 2D.
|
| * Skia seems to have some support for playing animations
| exported by a visual animation builder called Lottie,
| which is nice. Java 2D doesn't have that.
|
| * You can partly embed Skia in a web page via
| WebAssembly, which I guess is neat. You can embed Java2D
| in a web page via stuff like TeaVM too though.
|
| * There are no benchmarks comparing these libraries, as
| least not as far as I know.
|
| * They are both hardware accelerated via OpenGL /
| Direct3D. Skia also has experimental support for Vulkan.
|
| * Skia is a C++ lib that therefore requires manual
| bindings to other languages. Java2D/JFX are JVM APIs that
| can be automatically bound to a wide variety of
| languages, e.g. JavaScript, Python, Ruby, etc.
|
| * Skia's documentation is rubbish. Check out this excuse
| for a website: https://skia.org/ - a 2D graphics lib is a
| complex thing. Where are the docs? E.g. click on the main
| API objects and you get a handful of semi-random examples
| with one line of explanation for each.
|
| Basically, Skia is a component of Chrome that happens to
| have its own website. There is some vague attempt to make
| it into a real, production quality API but when internal
| docs for Skia developers drastically outnumber API docs
| for users, you know what you're dealing with. Java2D and
| JavaFX are designed to be APIs consumed by lots of
| developers, in a large variety of languages.
| sooheon wrote:
| You're right, that does help, alot.
|
| Sounds like in principle, Skija is an attempt to take the
| benefits of Skia and bring the shortcomings (for this use
| case) up to par. What's taken for granted is 1. Skia is
| better/more/performant/nicer than javaland status quo,
| and 2. Jetbrains has the resources/experience to "hand-
| craft" a nice Java API over it. And then on to all the
| other steps.
|
| > So to understand the value of this new library you very
| much need to be able to do an in depth comparison of Skia
| vs Java2D vs the JavaFX Graphics subsystem. Very, very
| few people have the expertise to do this and the blog
| post doesn't really try.
|
| This is the main point, which I can only assume JB have
| answered internally. They are probably the biggest Java
| GUI shop in terms of users and revenue (at least that I
| know of), so I'm not too too skeptical when one of their
| developers with some clout says "AWT, Swing, and JavaFX
| came with a lot of quality and performance drawbacks"
| chrisseaton wrote:
| > Just don't, like, draw something that looks like a GUI in it.
|
| I think you've got the wrong end of the stick. The author isn't
| suggesting anyone do this.
|
| But most apps need to do some drawing of their own - if they're
| a charts library, or a CAD program, for example. Then you need
| a library like this.
| saagarjha wrote:
| No, I read the post, the author mentions that this isn't a
| GUI toolkit. But the reason I made the comment is that like
| 90% of the post is "we need desktop apps and Swing sucks and
| let's not use Electron" so I think regardless of what it says
| in the middle it really seems like it's selling "use this to
| make your desktop app" rather than "this is a general-purpose
| graphics library".
| pwdisswordfish0 wrote:
| The author is exhibiting heavy denialism. The first indicator
| was gesturing towards IntelliJ IDEA as an example of a good
| desktop app. And whaddaya know, it turns out the author is
| affiliated. This isn't to say there's any intentional deception
| here--it's somewhere between self-deception and simply being
| unaware of one's own blindspots.
|
| Without going through the effort of installing and running it,
| it's easy to see that IDEA looks just as good as it did 5 years
| ago--which is to say not great. And without any evidence saying
| otherwise, it's reasonable to assume that it hasn't gotten any
| more lightweight or nimble since then, either.
|
| People writing JVM apps who tout their quality never seem to
| understand that their firsthand experience does not translate
| to other machine/system configurations that other people are
| running. It very well may be the case that those apps look and
| feel _worse_ than an Electron app. (And one doesn 't have to be
| a fan of Electron apps to admit this.)
| thu2111 wrote:
| It has actually. It starts a lot faster, and has a "lite"
| mode where it's more like a text editor.
|
| As for how it looks, well, it's an IDE. It looks fine to me.
| There's a dark mode if you want it, the look is modern yet
| dense: sparsity being a common issue with web apps. Plenty of
| people use and like it.
| sooheon wrote:
| The point about information density cannot be stressed
| enough for a "pro" tool.
|
| Its keyboard friendliness is also highly underrated due to
| being a GUI -- I found it's rivaled only by emacs/vim in
| that I can go an entire work day without clicking around
| with a mouse.
| pwdisswordfish0 wrote:
| It has nothing to do with dark mode. Dark mode screenshots
| are the first thing you'll see when you go looking for how
| IDEA looks today. It looks like a dark version of the UI
| from 5 years ago, unsurprisingly. Which means it still
| looks about as out of place as any Electron app. Although
| one would hope they've dealt with the bad antialiasing by
| now. Hard to say without downloading and running it, but
| the continued lack of polish and past propensity to pass
| the buck makes one question, "why bother?"
|
| > As for how it looks, well, it's an IDE.
|
| Not sure what this is supposed to mean. There are good
| looking IDEs. There's not something inherent to them that
| makes one look the way IDEA looks. It's the aforementioned
| blindspots and the "I don't see anything wrong with it"
| attitude that causes that.
| johnnycerberus wrote:
| I think you misinterpreted what the author aims to do. He
| states in the beginning that the main reason for why we don't
| have a good UI toolkit on the JVM is because every existing
| solution is bringing its own drawing library and with it their
| very own limitations. He advocates for a drawing library that
| will be supported community-wide, something like Spring is.
|
| React Hooks, SwiftUI and Flutter are modern choices that
| popularized the declarative approach and the author expresses
| its frustration that until now there was no interest in
| developing one for the JVM, which has all the pluses that it
| needs to create an ecosystem around one. Java, Kotlin, Scala
| and Clojure will all benefit from it. I think he is right,
| there is no modern graphics API on the JVM right now to do an
| UI toolkit or 2D/3D visualisations.
| hutzlibu wrote:
| From the article:
|
| "The road to high-quality UI on JVM is a long one. We'll need:
|
| a graphics library, a window/OS integration library, a UI
| toolkit. Today I am happy to announce the first part of this
| epic quest: the graphics library"
|
| Maybe you misread a bit? I do not see him suggesting, to use
| his first step for the UI. The idea is to build the UI kit on
| top of it.
| saagarjha wrote:
| I get that, it's just that this is being presented as
| something that will kill Swing and Electron, which obviously
| makes it so that many will take away "I should use this to
| draw my buttons" from it. I'm advocating caution before
| throwing away Swing right now.
| mmm_grayons wrote:
| This is a blog post, not a product launch. It's intended to
| be a foundation on which a "real" GUI library can be
| written. The author mentions that it is one of several
| steps that should allow the Java community to coalesce
| around a better toolkit in the long term.
| hutzlibu wrote:
| Well, his intention is to create something that will
| eventually kill Swing (and Electron), so he probably got
| carried away wih his words a bit, but I do not see him
| missrepresenting.
| geokon wrote:
| I think it's confusingly worded b/c they compare to Swing and
| JavaFX in the first lines - so it sounds like this is aiming
| to replaces those. But in-effect this is just a first step
| towards that larger goal. Why the graphics library needs to
| be rewritten from scratch and they couldn't implement a
| better UI toolkit on top of what already exists is left
| unanswered - and that's confusing. All it says is "Java UI
| progress was blocked by the poor-performing Graphics2D"
| jb1991 wrote:
| See the end, the section: What's with the rest of the puzzle?
| saagarjha wrote:
| I assure you that I've read the whole thing, and since I've
| already answered this question a couple times in this thread,
| I'll direct you to my responses there.
| vbsteven wrote:
| This post is only about the Skia JVM bindings and that is
| indeed only the graphics layer. What you are looking for is
| Jetbrains Compose which is built on top of these bindings and
| provides the GUI toolkit.
| saagarjha wrote:
| The particular issue I have is that when you look at a
| library like this, and especially how it's being sold, we're
| just going to have people go "Wait, I can just draw my own UI
| toolkit! This is easy!" and they'll end up with something
| worse than Swing because they don't realize the work that
| went into Swing even though I'll be the first to admit it's
| not the best. So I guess what I hope this becomes is that a
| group of people who actually understand desktop UI come
| together and take this to make a good toolkit, and I'm trying
| to caution people who want to just dive in without fully
| understanding what this would offer them. An analogy might be
| a blog post announcing LLVM IR, and I advising caution
| against just going and writing your homebrew language against
| it and then shipping your software on that. This is just a
| part of a good UI toolkit, and I think the blog post is
| looking too far into the future.
| jb1991 wrote:
| This is directly addressed inside the article, in the last
| sections.
| saagarjha wrote:
| Ok, so claiming I didn't read the article is actually
| against the guidelines, and you've done so twice so I'm
| not particularly in the mood to really entertain it
| anymore. Like, if you read the comment you just replied
| to, you'll see why I made the first comment even though
| the thing it mentions gets a line in the article. But
| arguing about who read what is not fun so I'd rather we
| actually talk about the article itself.
| jb1991 wrote:
| Sorry if I got the wrong impression. It's an easy
| impression to make when you keep complaining in multiple
| comments that the article is omitting key things that are
| actually discussed in the article.
|
| Perhaps it's just the way you were communicating your
| opinion that is misleading. It's not just me, I can see
| at least three or four people here who are trying to
| point out things in the article that you seem to have
| missed.
| vonmoltke wrote:
| > Ok, so claiming I didn't read the article is actually
| against the guidelines, and you've done so twice so I'm
| not particularly in the mood to really entertain it
| anymore.
|
| First off, you are responding to two different posters.
| Second, neither vbsteven nor jb1991 said you didn't read
| the article, they pointed out things that were addressed
| in the article. The phrasing they used is explicitly
| called out as acceptable in the guidelines:
|
| > Please don't comment on whether someone read an
| article. "Did you even read the article? It mentions
| that" can be shortened to "The article mentions that."
|
| https://news.ycombinator.com/newsguidelines.html
| exabrial wrote:
| What would make a great Java UI toolkit is CDI integration.
| Things like event busses and injection would really simplify
| things and be very powerful.
| galaxyLogic wrote:
| I would like to have a JavaScript version of JavaFX, that runs in
| the browser. Is there such a thing?
| nahuel0x wrote:
| So we will see something like Flutter but from JetBrains and
| Kotlin (native/jvm) based?
| jillesvangurp wrote:
| We're currently in an era where UI mostly means doing react type
| stuff or IOS/Android native, for whatever very loose definition
| of native you wish to use.
|
| A trend that is interesting here is jetpack compose and swift UI,
| which are both inspired by react but better in the sense that
| they make full use of their respective type systems to make
| things like data bindings a lot less painful than they are in
| react. At least that being painful must be a reason why they keep
| changing how that works in every major release.
|
| Add internal DSLs to the mix and you are basically looking at a
| nicer way to do UIs. That's only covering mobile currently
| unfortunately. However, Jetbrains just announced Compose Desktop
| which brings this to the desktop as well. If they figure out how
| to target web and IOS with this, they could very well have a
| winner.
|
| For the web there is currently something called Fritz2, which
| runs via kotlin-js and basically adds very similar style bindings
| to a react like component framework. It's fully written in Kotlin
| and I've been meaning to give it a try so I can use my multi
| platform kotlin libraries there as well without having to figure
| out react and how to make that play nice with things like co-
| routines, data classes, etc.
|
| For me the trend here is new UI frameworks originating outside of
| the javascript world gaining traction and eventually ending up
| running in a browser as well. IMHO it's that that is ripe for
| disruption.
| PaulDavisThe1st wrote:
| From TFA:
|
| --------
|
| Is desktop still relevant?
|
| I believe it is!
|
| I watched an interview recently, between an Android developer
| and an iOS developer. One was asking:
|
| "Does someone still writes desktop apps?"
|
| To which the other answered:
|
| "I have no idea... Maybe?"
|
| Both of them were recording it on a desktop, in a desktop
| application, while having a call over another desktop
| application. Multiple other desktop apps were probably used for
| post-production. None of those were written by magic elves or
| left to us by a mighty ancient civilization. The desktop might
| be less trendy, but only because it's harder to sell useless
| crap here.
|
| -----------
|
| "react type stuff" and iOS/Android do not cover this, but you
| probably knew that.
| didibus wrote:
| I've found apps made with JUCE https://juce.com/ always look
| great and have really good responsiveness.
|
| Now on the JVM front, I think one problem it has for desktop apps
| is the memory usage of the JVM is just terrible for desktop apps.
| It's clearly optimized for backend services assuming they are the
| only app running trying to squeeze all performance out. But a
| desktop app needs to be lean, and currently I'm not sure the JVM
| is tuned to those use cases, and Java is missing a few features
| for lightweight objects that could help as well with memory
| usage.
| dethos wrote:
| > The desktop might be less trendy, but only because it's harder
| to sell useless crap here.
|
| There is some truth in this sentence.
| joseluisq wrote:
| and also that one:
|
| >Why not Electron?
|
| > The first reason is performance. JS is a great language for
| building UI, but it is much slower than JVM. Wasm can be fast
| but implies C++ or Rust.
|
| > The second is the DOM. It is a horrible collection of hacks
| that make simple things hard and hard things impossible. I have
| thought many times "if only was I drawing this control/layout
| directly, I would've finished hours ago."
|
| > That means there's a very low ceiling, performance-wise and
| quality-wise, of what a web app can do. I believe we can, and
| should, do better.
|
| > Electron taught us two good things, though:
|
| > People crave for native apps. Nobody wants to work from the
| browser. People don't care if apps don't look native to the
| platform as long as they look good.
|
| Regarding Electron, I think we "should" start to talking about
| more like "Browser Apps for Desktop" instead of just "Desktop
| Apps" which is broad term.
| bjarneh wrote:
| > with a lot of quality and performance drawbacks. They were so
| significant that only one company managed to build a decent-
| looking app in Swing [Link to JetBrains].
|
| Until I found the J-editor, I sort of agreed. I never understood
| why that project didn't get any traction; very well made IMO, and
| it looks good too.
|
| https://github.com/gnooth/j
| didibus wrote:
| Maybe because the repo doesn't even have a readme to tell you
| what it is?
| brunoluiz wrote:
| I wonder where Qt sits today as a desktop framework. I remember
| it was quite cool to use it and be able to run it in multiple OS.
___________________________________________________________________
(page generated 2020-11-17 23:01 UTC)