5 ms·

Are you expecting another Visual Studio or IntelliJ? I think Electron is a very cost efficient dev environment. Can't really think of writing all this up in pl

Are you expecting another Visual Studio or IntelliJ? 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.)

krageon 9y ago
The whole idea of electron is that it is built on top of a deeply flawed framework. I can't speak for anyone else, but I cannot see the appeal to writing for something that is broken by design.
- thanksgiving 9y ago
  The problem is that, just like Java, electron wins at the end of the day in terms of market share. If we're in the business of helping people, we can do more "good" by making an inferior technology slightly more bearable. Of course, that is just one perspective (not mine but one that I'm trying to understand as well). Edit spelling
  - snarfy 9y ago
    It reduces software development costs, allowing more software to be written. There is plenty of software that needs to be written that doesn't exist today. Reducing costs helps with that need. 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.
  - izacus 9y ago
    > The problem is that, just like Java, electron wins at the end of the day in terms of market share. 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.
  - cmiles74 9y ago
    I don't think Java ever "won" in the cross-platform GUI application space. Sun tried hard and Swing was successful in terms of being able to produce a reliable, cross-platform experience that was reasonable. But in terms of developer mind-share and actual applications on the desktop, I'd say it's success was pretty meager. Aside from IntelliJ and NetBeans and Eclipse (yep, I know, SWT) I'm hard pressed to think of other popular Java GUI applications.
- marrs 9y ago
  The deeply flawed framework being HTML/CSS, JS, Node.js, or all of the above?
- tracker1 9y ago
  I really like the idea of React Native... similar JS engine constructs, but a leaner UI layer... though, really need a bit more unity in UI controls across platforms. 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.
dkersten 9y ago
> Once upon a time there was Qt, but now it's also doing qml+js.. 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.
- v-yadli 9y ago
  I'd agree with you on the basic idea, but practically from my experience, the qml+js subsystem seems like an isolated piece of "glueware" upon a legacy platform and they do not interpolate very well. Once I did a knowledge graph representation with the css-like qml goodies. I felt good about it because I cranked it up really fast. But later when I want to implement a force-based layout algorithm I found myself forced to implement it in Javascript, because the interop is both slow and cumbersome. So it's not like we have the javascript host and a bunch of native extensions, but rather, a floating js runtime, plugged into the great Qt4 legacy, with the two sides communicating through narrow gates...
  - dkersten 9y ago
    QtQucik isn't a legacy platform, its been developed from ground up and only shares the data structures (QObject, QVariant, QVector etc... but it works pretty well with C++ Standard Library too) with the legacy QWidgets stuff. > 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!
rootlocus 9y ago
> I think Electron is a very cost efficient dev environment. 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.
- Filligree 9y ago
  For which reason I refuse to run Electron applications. My battery life is poor enough as it is.
snarfy 9y ago
The users matter, not the contributors. > 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.
- marrs 9y ago
  You're both right. The best thing for the Oni dev to do now (presuming your performance comments apply directly to it) is to go back and identify/fix the cause of the performance issues. If the performance improvements can be done in the Electron code itself then we get the best of both worlds.
- v-yadli 9y ago
  I think there's misunderstanding here, because I don't think that electron is the only way to go. Like the author of oni wrote here, we can make this frontend happen on any web-friendly runtime. 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.
extr0py 9y ago
Author here - thanks for the kind words! Yes, your comment hits the nail on the head and echoes my thoughts exactly. Electron happens to be a great way to test out some of the thoughts and I ideas in an economical way - especially since my time to work on Oni is limited at the moment. 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.
- v-yadli 9y ago
  For 1) and 2), I have an idea that it would probably be better if we can have an "Electron factory" running in the background and serve all these apps. This turns the OS task manager into tabs of a browser, and any optimization done by a browser to speed up tab opening and page loading, still applies here. :)

krageon 9y ago

The whole idea of electron is that it is built on top of a deeply flawed framework. I can't speak for anyone else, but I cannot see the appeal to writing for something that is broken by design.

thanksgiving 9y ago
The problem is that, just like Java, electron wins at the end of the day in terms of market share. If we're in the business of helping people, we can do more "good" by making an inferior technology slightly more bearable. Of course, that is just one perspective (not mine but one that I'm trying to understand as well). Edit spelling
- snarfy 9y ago
  It reduces software development costs, allowing more software to be written. There is plenty of software that needs to be written that doesn't exist today. Reducing costs helps with that need. 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.
- izacus 9y ago
  > The problem is that, just like Java, electron wins at the end of the day in terms of market share. 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.
- cmiles74 9y ago
  I don't think Java ever "won" in the cross-platform GUI application space. Sun tried hard and Swing was successful in terms of being able to produce a reliable, cross-platform experience that was reasonable. But in terms of developer mind-share and actual applications on the desktop, I'd say it's success was pretty meager. Aside from IntelliJ and NetBeans and Eclipse (yep, I know, SWT) I'm hard pressed to think of other popular Java GUI applications.
marrs 9y ago
The deeply flawed framework being HTML/CSS, JS, Node.js, or all of the above?
tracker1 9y ago
I really like the idea of React Native... similar JS engine constructs, but a leaner UI layer... though, really need a bit more unity in UI controls across platforms. 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.

dkersten 9y ago

> Once upon a time there was Qt, but now it's also doing qml+js.. 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.

v-yadli 9y ago
I'd agree with you on the basic idea, but practically from my experience, the qml+js subsystem seems like an isolated piece of "glueware" upon a legacy platform and they do not interpolate very well. Once I did a knowledge graph representation with the css-like qml goodies. I felt good about it because I cranked it up really fast. But later when I want to implement a force-based layout algorithm I found myself forced to implement it in Javascript, because the interop is both slow and cumbersome. So it's not like we have the javascript host and a bunch of native extensions, but rather, a floating js runtime, plugged into the great Qt4 legacy, with the two sides communicating through narrow gates...
- dkersten 9y ago
  QtQucik isn't a legacy platform, its been developed from ground up and only shares the data structures (QObject, QVariant, QVector etc... but it works pretty well with C++ Standard Library too) with the legacy QWidgets stuff. > 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!

rootlocus 9y ago

> I think Electron is a very cost efficient dev environment. 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.

Filligree 9y ago
For which reason I refuse to run Electron applications. My battery life is poor enough as it is.

snarfy 9y ago

The users matter, not the contributors. > 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.

marrs 9y ago
You're both right. The best thing for the Oni dev to do now (presuming your performance comments apply directly to it) is to go back and identify/fix the cause of the performance issues. If the performance improvements can be done in the Electron code itself then we get the best of both worlds.
v-yadli 9y ago
I think there's misunderstanding here, because I don't think that electron is the only way to go. Like the author of oni wrote here, we can make this frontend happen on any web-friendly runtime. 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.

extr0py 9y ago

Author here - thanks for the kind words! Yes, your comment hits the nail on the head and echoes my thoughts exactly. Electron happens to be a great way to test out some of the thoughts and I ideas in an economical way - especially since my time to work on Oni is limited at the moment. 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.

v-yadli 9y ago
For 1) and 2), I have an idea that it would probably be better if we can have an "Electron factory" running in the background and serve all these apps. This turns the OS task manager into tabs of a browser, and any optimization done by a browser to speed up tab opening and page loading, still applies here. :)