Hacker News Reader

Comment by tombert | Hacker News Reader

Electron has always kind of felt like a prototyping tool to me. It's great for rapidly developing desktop apps, but it feels like once you get a product you want to distribute, you should use a more performant GUI library like Qt.

View on HN

Unfortunately, it almost never works that way, because Electron is what allows people knowing only (and willing to only ever know) JavaScript to make "desktop" apps. At the point you should switch to something native, the prototype has so much JS code you'd have to por that it's not worth it anymore.

Oh, I figured that that was the case; it's easier to make desktop apps with Electron, so it's attractive to companies because they can hire JS developers, which are almost certainly cheaper than Cocoa/Qt/GTK+/Whatever-Windows-Uses-Now developers. They're able to deliver a good-enough product with Electron, and don't really see it as a prototyping tool.

React Native says otherwise: javascript talking to native components.

React native targeting QT or a similar desktop widget toolkit ... is that a thing? It seems like it should be a thing at least at the highly starred but otherwise vaporware github repo level?

Microsoft maintains react-native-windows that targets the UWP/XAML components

And then when you see how easy it is to make a Qt app (eg http://qmlbook.github.io/en/ch04/index.html) you start wondering why you didn't go this route sooner :p

Unless you need features that aren't staples of the Qt system, like editable diagrams connected by Bezier curves on an arbitrary size canvas.

Okay but you can do stuff like that in qt or qml just as easy as javascript (if you know how to use it of course)

Uh ? there are actually quite a bit of stuff like this, for instance I like this one: https://github.com/paceholder/nodeeditor

From the "roadmap" section for that project

> GUI: fix scrolling for scene view window scrolling

I need the scrolling to work out of the box. Some of the users' diagrams are going to be 10x the size of the examples shown for that framework (if not larger).

Also in the issues section:

* you can't put a custom context menu for the nodes

nw.js (and I assume Electron) provide this by default.

* Crash: Attempting to connect an input node into self output node

Sorry, that's a showstopper. The application I maintain proudly does not crash when the user tries to do this.

And then this one: * Implement QML frontend

So... if I'm not leveraging QML, what's my workflow with this framework? Am I coding it in C++?

If so, then the speed and ease of developing the frontend doesn't compare to HTML5.

Just noticed another showstopper:

* https://github.com/paceholder/nodeeditor/issues/63 (doesn't currently support HiDPI)

I need HiDPI support out of the box.

This may all seem secondary to my original statement, which was that Qt works fine until you want to draw certain types of diagrams. While I'm convinced it's possible (and looks to be getting easier in the future), the example you gave isn't fully baked, doesn't have a QML frontend, and doesn't look to be stable.

I have no doubt people can and will build more frameworks for Qt as it continues to improve. Meanwhile, however, with HTML5 I can use raw Javascript, or d3, or React, etc. all the way up the ladder to frameworks specifically designed for editing diagrams. All of those will result in diagrams of boxes connected by Bezier curves with performance that scales with the number of DOM elements. And every single one of those options have demos that work in the browsers we're staring at that merely require a keyboard shortcut to study and change the code.

I looked through the docs some and thought it looked quite nice, except that it appears you have to write the app in c++. I see that Qt Quick uses Javascript in some way, but it seems like you'd primarily be writing your application in c++ and then maybe doing some UI scripting with javascript—is that right?

I'm not particularly tied to javascript, but just have no interest in investing the time to learn c++ properly, so that would be a showstopper for me and probably lots of others who are considering going down the Electron route.

To re-iterate though, QML does look like a very nice system for specifying UIs...

> I looked through the docs some and thought it looked quite nice, except that it appears you have to write the app in c++.

No, you can write full apps in QML/JS (I personnally prefer going the C++ route for the stricter typing and better performance, but to each its own :p).

Most JS libs will work (except those that work on the HTML DOM since ... it's not HTML).

And then when you see how "uncanny valley" Qt apps still look due to its emulated widgets, you'd wonder when are we gonna get a proper cross platform UI solution...

wxWidgets

Chromium is a ridiculously optimized and extremely flexible runtime. Qt is ok for basic UIs, but once you need to do custom draw, "modern" animations (supported by CSS) - Chromium will be much more approachable and faster.

That's ridiculous. Qt has excellent support for custom UIs and one of the strengths of QML is animation.

Reply on news.ycombinator.com