> Can't really think of writing all this up in plain C++, wiring up native calls...
Yes, it's more work and features will come slower, but the end result is a better application. Latency matters. It's extremely irritating that when I hold the delete key in an electron based application like visual studio code, that half my file continues to be deleted after I let go of the key. The application can't keep up with the key repeat speed, and it's running on a high end workstation! It's pathetically slow, even for all of the improvements that have been made over others like atom and brackets.
I'm excited by Oni, and it saddens me that the top comment is a negative comment complaining we should all just support electron.
What I mean is that we should put aside the cons brought by a piece of building block and appreciate the vision, and the ideas behind these "new old things" -- neovim, oni, etc., to which we have been on the same page. However, discussion about whether it's appropriate to use Electron in this thread, without technical explanation or a proposal for workarounds, are distractions in my opinion.
QML+JS is still primarily C++ in that the QML gets compiled into a scene graph that is then processed in C++ and OpenGL and your JS would typically only be setup and glue code. QML makes it super easy to write single objects in C++ and have them seamlessly communicate with QML/JS, so writing simple logic in JS and performance-sensitive code in C++ is easy to do. QML performs extremely well, while my brief experience with electron was less favourable.
> I found myself forced to implement it in Javascript, because the interop is both slow and cumbersome
I'm a bit confused by this because its different from my personal experience, where implementing custom QObjects was both developer-friendly (easy and quick to accomplish) and performant. I guess your experience was different. Would love to hear a bit more about your use case and why it didn't work for you.
> plugged into the great Qt4 legacy
Beyond the basic classes like QObject/QVariant/QVector and some of the addon libraries like QtConcurrent, when I used QtQuick/QML, I didn't have to use any of the Qt4 legacy stuff and had a pretty slick experience of developing UI in QML, glue in JS and any heavy lifting or platform interpo in C++ as custom QObjectf. Since C++11, its also been even slicker because they made most of the Qt Library classes interoperate with C++11 better (especially allowing you to connect lambda's directly to signals).
I wonder why you had such a different experience than I did? Although, to be fair, I haven't done any serious Qt work in ~2 years or perhaps a little more, so maybe my experience isn't representative (I used it to do the UI for a data analysis tool, it was performance sensitive but not THAAAAT much, so maybe if it had been more so it would have been problematic?)
Would love to hear more about what problems you faced!
Edit spelling
The other side of that is software that already exists, running in the background unnoticed. Things like your graphics driver. You wouldn't want that written in Java. If it were written in Java you might get a lot of features faster, but it sure would perform like crap. For core software like that, development costs are secondary. Performance matters first.
At the end of the day I think we need projects like neovim and oni. Editors are old technology and should be core software. Performance in my editor matters. I have five different IDEs installed and I still use vim.
The hell are you talking about, Electron still doesn't come near the marketshare when you look at acual apps using other cross-platform GUI toolkits.
Another bit seems to be some work in progress from the Xamarin guys at MS.
In the end, an XML based UI combined with a JS runtime engine seems to be a very powerful combination... getting similar points of integration with other languages could be equally nice.
Something resembling Material Design, or Bootstrap as a cross platform UI toolkit with an XML interface would be a great place to start. Electron really seems to be as close as it gets for the most part, with the least cross platform effort.
Because it's faster to develop? You're basically trading developer time with user time and battery life.
> Can't really think of writing all this up in plain C++
IntelliJ is written in Java.
And I think the fat headroom for improvements is important to call out - when people talk about "Electron Bloat", they usually refer to one of 5 things:
1) Footprint (space on disk) 2) Memory usage 3) CPU usage (corresponding to battery life) 4) Responsiveness (esp typing latency) 5) Startup time
As you mentioned, across the board, there's a bunch of room for improvements - especially with tech like WebAssembly on the horizon! #1 and #2 are the hardest, because Electron will always have a fixed overhead - but when comparing to an IDE like Visual Studio, it's not over the top.
For my workflow, #4, #5, and #3 are most important, and Oni still has plenty of low-hanging fruit to tackle for each of those. If I find there is a blocker to getting to acceptable typing latency and startup time, I'd consider making a switch (potentially to a react-native-on -desktop solution), but I'm optimistic that with WebAssembly, React 16, Chrome 61, along with optimizations on the Oni side, there's still plenty of opportunity to improve performance.
I think Electron is a very cost efficient dev environment. Can't really think of writing all this up in plain C++, wiring up native calls for various OSes, leveraging GPU, support rapid plugin dev/prototyping etc., etc. Once upon a time there was Qt, but now it's also doing qml+js..
Even if a NeoVim version of Eclipse (or whatever you think a 'more native IDE' is) is rolled up, by a small team comparable to oni's, are you going to _pay_ for it?
Oni: 17 contributors, one main dev. IntelliJ: 249 contributors, Github fails to load stats in one minute.
So why not stop complaining about the IDE and put efforts into optimizing electron-like platforms? There's still a fat headroom for improvements! (WebAssembly etc.)