3 ms·
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 w
by 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 agoYou'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 agoI 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.