In my experience Java GUIs are consistently even more laggy and unresponsive than Electron apps. They may be lighter in terms of memory, but they never feel lighter. Even IntelliJ and family - supposedly the state of the art in Java apps - feel like mud on a brand-new 16" Macbook Pro.

Lighter in terms of memory? No way. Intellij is always at a few gb per instance. They are indeed laggy as hell. With the latest Mac os intellij products specifically bring down the entire os for ten to twenty minutes at a time requiring a hard reboot without which the cycle starts again. Except it's not java or intellij, it's the os. I only wish they were electron apps. That way I wouldn't have to return a $4400 brand new 16" mbpro because of its constant crashing due to horrible native apps. All apps can be shitty. At least electron ones are cross platform, work, and generally do not bring the whole system to a standstill followed by a hard crash. While using about the same resources as electron apps.

Interestingly they seem to run exactly the same on horribly low spec machines. I blame the jvm's love for boxing and unboxing everything in IL land. Of course by now I'd hope it's less wasteful - last I spent serious time in Java was 2015.

I've definitely noticed the same on IntelliJ but weirdly enough Eclipse feels just fine. IIRC both are written in Java, so maybe it comes down to the design of IntelliJ moreso than the limitations of the JVM?

I used Eclipse for a while before switching to IntelliJ around ~2015 and it actually seemed like a vast improvement, not just in terms of features but in terms of performance. It still wasn't "snappy", but I figured I was doing heavy work so that was just how it was.

Fast-forward 5 years and I've been doing JS in VSCode for a while. My current company offered to pay for Webstorm so I gave it a try. Lo and behold it was still sludgy, but now unbearable to me because I've gotten used to VSCode.

The one other major Java app I've used is DBeaver, which has the same problem to an even greater degree. Luckily I don't have to use it super often.

Eclipse interestingly uses native controls which it hooks up to Java, while IntelliJ draws everything essentially.

I work daily in a codebase with 20M lines and RubyMine can still search near-instantly compared to say VS Code. One thing that's still true is that there are sometimes long pauses, presumably garbage collection, or I suspect more likely bugs as changing window/input focus can sometimes snap out of it.

If that's the case regarding IntelliJ then you probably haven't changed the jvm heap size, which is defaulted to something very small (2GB maybe) by IntelliJ.

QT is excellent, but C++ is quite a tough pill to swallow for many. Especially as QT layers a macro system on top. I predict that native desktop apps will make a comeback when there's QT-quality cross-platform framework in a more approachable language (Rust, nim, or similar).

There are a few options.

https://github.com/revery-ui/revery

https://github.com/briskml/brisk

Why not use Qt bindings for $YOUR_LANGUAGE_OF_CHOICE? https://wiki.qt.io/Language_Bindings

It's rather clunky and often requires writing like C++ in whatever language of choice you're using, the worst of both worlds.

I wonder what an API with both only C (or some other low level) bindings and designed to be easy to use externally might look like.

Your subdomain http://forum.ossia.io/ lacks an ssl certificate for the login mask.

You can get wildcard ssl certificates for your domain and all subdomains from Letsencrypt.

Thanks for the info, gonna check.. we already have a cert, no clue what's missing precisely in the config, how can I try ?

Configure your HTTP server to serve that subdomain from HTTPS. Here's an example using nginx:

https://linuxize.com/post/redirect-http-to-https-in-nginx/

...or just use CloudFlare, which will automatically take care of it.

Do you count Qt apps as native, but not count web apps as native? Why?

Qt may not 'look' native, but it has native performance, whereas Electron really doesn't.

The difference between "Qt native" and "native native" (e.g. Win32 or Cocoa) is still noticeable if you pay attention, although it's not quite as obvious as between Electron and the former.

(Likewise, applications using the JVM may also look very convincingly like native ones, but you will feel it as soon as you start interacting with them.)

Is it really even worth highlighting though? I use Telegram Desktop (Qt) daily and it is always, 100% of the time completely responsive. It launches basically instantly the second I click the icon and the UI never hangs or lags behind input to a noticeable degree. If we transitioned to a world where everyone was writing Qt instead of Electron apps we would already have a huge win.

If you're using KDE, Qt is "native native".

You're fundamentally mistaken about where Qt sits in the stack - it effectively sits in the same place as USER32/WinForms in Windows or NS/Cocoa GUI widgets of OSX. It is reasonable to think of it as an alternative native GUI library in that sense. If it is slower, it's because an implementation of something is slower, not because of where it lives or an abstraction cost.

Qt pretty much draws using low-level drawing APIs on the respective platform. And although Qt itself is not written in the most performance sensitive C++, it is still orders of magnitude faster than most (and it's not like Chrome doesn't pay overhead) - people rag on vtable dispatch speed but jeez its still orders of magnitude faster than something like ObjC which served Apple quite well for years.

The performance of a Qt app is more likely a function of the app itself and how the app developers wrote it.

But no, you're not noticing any micro-seconds differences in C++ overhead for Qt over "native native" - and you're basically comparing the GUI code of the platform - since Qt does it's own rendering. Win32 is mostly pretty good, NS is a mixed bag, and Gtk+ is basically a slug. In all cases there is some kind of dynamic dispatch going on, because that is a fundamental pattern of most GUI libraries. But dynamic dispatch is almost never a factor in GUI render performance. Things like recalculating sizes for 1 million items in a table on every repaint are the things that get people into trouble, and that is regardless of GUI library.

VSCode is indistinguishable from native, so not sure its Electron that's at fault here.

This gets said a lot, and granted VSCode is certainly one of the best performing Electron apps, but it definitely is not indistinguishable from native apps. Sublime, Notepad++, or TextAdept all fly compared to VSCode in terms of performance and RAM efficiency.

On Mac, VSCode does a better job than many apps at emulating the Cocoa text input systems but, like every electron app, it misses some of the obscure corners of cocoa text input system that I use frequently.

If we’re going to use JavaScript to write native apps, I’d really like to see things like React Native take off: with a good set of components implemented, it would be a first class environment.

No. I like VS Code but it's a hog.

I still use Macvim or even Sublime Text a lot for speed reasons, especially on large files.

If your native apps are indistinguishable from VSCode, they're doing something wrong.

Start Notepad++ or https://github.com/rxi/lite and then compare the startup speed with VSCode.

I use VS Code daily (because it seems to be the only full-featured editor that Just Works(TM) with WSL), but it can get pretty sluggish, especially with the Vim plugin.

Try to use AppleScript or Accessibility. It's like VS Code doesn't even exists.

If I recall correctly, Microsoft forked their own version of electron to make vs code feel more snappy. Because normal electron runs like slack.

I don't think so, Microsoft wanted to fork electron in the past to replace Chromium with edgeHTML, but it didn't happen. VSCode is powered by Monaco Editor github.com/microsoft/monaco-editor, and VSCode feels snappier than let's say Atom, probably because of Typescript.

Try opening a moderately large (even 2MB) .json file in VSCode, and then do the same in sublime.

VSCode very quickly freezes because it cannot handle a file that size. Sublime not only opens it but syntax highlights immediately.

This is something with your configuration. OOB VSCode will immediately show you the file but disable tokenization and certain other features. I regularly open JSON files upto 10 MB in size without any problem. You probably have plugins which impede this process.

Isn’t that more of an Electron issue?

I mean, is anyone clamouring for VS Code, for example, to be rewritten in native toolkits?

When you say web platform do you mean a browser? Using a browser is the mosted optimised and performant over installing an application on your desktop?

Curious what desktop do you run your browser under?

I would give you an example of a simple video split application. A web platform requires uploading, downloading and slow processing. A local app would be hours quicker as the data is local.

No reason a video splitting app couldn't be written with client-side JS.

That sounds like it’d probably be slow.

So please do.

a few reasons :

- Qt is actually the native toolkit of multiple operating systems (Jolla for instance and KDE Plasma) - you just need to have a Linux kernel running and it handles the rest. It also does the effort of going to look for the user theme for widgets to mix in with the rest of the platform, while web apps completely disregard that.

- Windows has at least 4 different UI toolkits now which all render kinda differently (win32, winforms, wpf, the upcoming winui, whatever is using Office) - only Win32 is the native one in the original sense of the term (that is, rendering of some stuff was originally done in-kernel for more performance). So it does not really matter on that platform I believe. Mac sure is more consistent, but even then ... most of the apps I use on a mac aren't cocoa apps.

- The useful distinction for me (more than native and non-native) is, if you handle a mouse event, how many layers of deciphering and translation has it to go through, and are these layers in native code (eg. compiled to asm). As it reliably means that user interaction will have much less latency than if you have to go through interpreted code, GC, ...

Of course you can make Qt look deliberately non-native if you want, but by default it tries its best - see https://code.woboq.org/qt5/qtbase/src/plugins/platforms/coco... and code such as https://code.woboq.org/qt5/qtbase/src/plugins/platforms/wind...

Knowing what I know about Qt and what I've done with it in my day job, it's basically the best kept secret on hn. What they're doing with 6+licensing... I'm not sure how I feel, but from a pure multi-platform framework it really is the bees knees.

I've taken c++ qt desktop apps that never had any intention of running on a phone, built them, ran them, everything "just worked. I was impressed.

I just wish it weren't stuck, anisotropically, ~10 years in the past. Maybe Qt6 will be better, but more likely it will be more and more QML.

Since QML uses Javascript it may be their best bet to attract new developers.

Yes, well, QML also uses JavaScript.

This is not really accurate. Qt relies on a lower level windowing system (X Window, Wayland, Cocoa, win32 etc. etc.).

Also worth noting that many creation-centric applications for the desktop (graphics, audio, video etc. etc.) don't look "native" even when they actually are. In one case (Logic Pro, from Apple), the "platform leading app from the platform creator" doesn't even look native!

> This is not really accurate. Qt relies on a lower level windowing system (X Window, Wayland, Cocoa, win32 etc. etc.).

Qt also supports rendering directly on the GPU (or with software rendering on the framebuffer) without any windowing system such as X11 or Wayland - that's likely how it is most commonly used in the wild, as that's one of the main way to use it on embedded devices.

I'd like to see it do that on macOS ...

You're seriously suggesting that the common use of Qt on Linux systems is direct rendering without the windowing system?

Not parent, but yes, sort of.

Arguably it's use in embedded contexts is much larger than desktop. It's quite popular for in-car computers, defense systems, etc.

For desktop linux, yes, it uses the windowing system.

Well, yes. I can't tell too much because of NDAs but if you go buy a recent car there is a good chance that all the screens are rendered with Qt on Linux or a RTOS - there is likely more of those than desktop linux users as much as this saddens me

On macOS Qt doesn’t really use Cocoa, it use Quartz/CoreGraphics (the drawing rather than the application layer). Note that Apple’s pro apps are native controls with a UI theme: they usually behave like their unthemed counterparts.

I had meant to write Quartz, not Cocoa.

I know how Qt works at that level. I did a bunch of work in the mid-naughts on the equivalent stuff in GTK.

> Qt relies on a lower level windowing system

That's true of QtWidgets, but not QML / Qt Quick (the newer tool), correct? (I found this hard to determine online).

Kinda - QML is a programming language, Qt Quick is an UI scene graph (with the main way to use it being through QML) which also "renders everything" and makes by default less effort than widgets to look like the OS.

But :

- QML can be used with other graphics stack - for instance Qt Widgets like with https://www.kdab.com/declarative-widgets/ or alternatives to the official Qt Quick controls with https://github.com/uwerat/qskinny or with completely custom rendering like here with NanoVG : https://github.com/QUItCoding/qnanopainter

- QtQuick Controls can be made to use the same style hints than the desktop with https://github.com/KDE/qqc2-desktop-style

What does “native” even mean?

Put a <button/> in an HTML page and you get a platform-provided UI widget.

It's not platform-provided in my experience, but browser provided. The result of <button/> when viewed in a browser on macOS has no relation to the Cocoa API in any meaningful sense.

I'm pretty sure that when you render just a <button> in at least Safari, the browser will render a native Cocoa button control. If you set a CSS property like background colour or change the border, then it will "fall back" to a custom rendered control that isn't from the OS UI.

I did a small bit of research into this, and found plenty of "anecdotal" evidence, but nothing confirming for sure. I'm looking and interacting with the controls and they seem pretty native - if they're a recreation than that's pretty impressive :)

The drawing is native and the interaction is handled by the browser.

I'd also love for Mac and Windows to make it really easy to get a vendor blessed version of QT installed.

Imagine if when trying to run a QT app on Windows a dialog box could popup saying. "Program X is missing the Y, install from the Windows Store (for free): Yes / No"

Ossia looks pretty sweet! I'll be checking that out for sure.

thanks ! it's still kinda in alpha but making progress :)

Bitwig has been ported to Android ? Or IOS ?

I don't think it makes sense to use it on even small laptops screen to be honest so I don't really see the point. You'd have to redo the UI and whole paradigm entirely anyways for it to be meaningful on small devices. But there is certainly not any obstacle to porting - from my own experience with ossia & Qt, it is fairly easy to make iOS and Android builds, the difficulty is in finding a proper iOS and Android UX.

In particular C++ code works on every machine that can drive a screen without too much trouble - if the app is built in C++ you can at least make the code run on the device... just have to make something pretty out of it afterwards.

I still can't believe bitwig is java. I'm a bitwig user. It even runs on linux.

Only small part, the core is C++ and assembly.

https://www.reddit.com/r/Bitwig/comments/4c2zoh/what_program...

Wasn’t that Java’s original selling point, it runs anywhere (there’s a JVM)?

Yes, today you can use JavaFx to build cross platform desktop apps.

Sounds like that’s the Java Swing replacement for the same thing you could do over a decade ago?

Only part of it will be Java, probably the UI logic layer

Because you NEVER have to do that with browsers, right?

You don't have to sign and deploy your web app six times.

You have to do it anyway if you're using Electron

That's not a web app then.

Isn't it? The UI is rendered using web technologies inside a specialized browser and it's written in a web-specific language. I might consider an electron app an hybrid app (that leans heavily towards the web side), but for sure not a native app

CI/CD + uh... doing your job? I build one app (same codebase) on 4 different platforms often, it isn't terribly hard.

I don’t know, I think they did mean that.

You write an app for the Mac... how do you ship on Windows as well?