Are you sure Java's UI issues are caused by threading and not just Swing being a glitchy pile of junk?
replyFor example, if you don't explicitly call the java.awt.Toolkit.sync() method after updating the UI state (which according to the docs "is useful for animation"), Swing will in my experience introduce seemingly random delays and UI lag because it just doesn't bother sending the UI updates to the window system.
You think IDEs are written in JS because of the performance benefits of the threading model?
replyI thought it was because they could copy chromium.
Why do you think they don’t struggle with input latency? Because the non blocking nature built into the browser model is so powerful and you cannot get that with threads.
replyI disagree with the premise. I cannot imagine a better latency experience than blocking loop IDEs like VS6.
replyWhich inputs are getting latency? The keyboard? The files?
> the non blocking nature
Are you sure that latency-sensitive parts are written in async JS instead of having a separate UI thread (pool)? I have no idea myself, but without knowing the details it's hard to argue. Note, that browsers themselves, are usually written in languages like C++ or Rust. They run JS, but aren't written in it
replyYes they are, the UI layer is mostly JS, outside the rendering and layout engines.
replyIf you implement threads and code that reacts to an input queue (e.g. PostMessage, queue_push, mq_send, ...), you've implemented (probably a bad version of) async threads. And yes, that's exactly what Windows 1.0 did and what made it great.
replyBut God help you if you have to change the code. Async threads are a way to organize it and make it workable for humans.
Maybe you remember performance of IDEs from 15 years ago because that definitely isn't my experience.
reply> that’s why JS text editors have reasonably acceptable performance
replyAbsolutely not