Automatic desktop integrated webapps via Electron
github.com
github.com
That said: I think we should. Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible.
Still - at some point if you want to build an app that has a UI users interact with, connects to the internet to get data via HTTP requests, and then stores some data in a database: at some point you should just be able to write that no matter where the end delivery will be.
I'm not sure how we're going to get there, but it seems like things like Electron and React Native will at least be part of the path. Eventually they'll hit a critical mass of performance and will become the default, then we'll have to deal with that from there.
In the short-medium term Electron apps will probably hit that ole VisualBasic sort of sweet spot: for learners to write xcopy-distributable (I'd hope?!) "apps" to share with peers, and for day-to-day hackers writing the "messy no-performance-required" one-off tools that need a tad more visualization than can be effected with quick custom CLI println tools.
I too fail to see "a programmer's text editor" as the "killer app" for Electron of course ;)
And of course in the early 00s the VB crowd largely moved to the, at first, much more resource-intensive (all-in) .NET..
Electron apps certainly seem quite wasteful and probably should be short-running one-off tools for now, rather than long-running major LoB or productivity apps.. config editors or media tweak things or such. Of course if it takes 500MB out of my 32GB RAM that's not cool (but kinda in range with ~1/64MB), but if I run it and close it after 10 mins it's also not the end of the world if it performed a job that needed doing.
What the embedded browser provides is of course both a GUI toolkit and a runtime framework, so just in-place-of a .NET or a JVM or some custom combo of (C++ std shared objects + Gtk/Qt/Etc libs). YES: this sort of "browser as runtime framework" isn't currently optimized for the Electron use case. But if efforts were invested in such optimizations, it would probably benefit browsers as well. And though it is unlikely, it is slightly likelier as the younguns adopt Electron for much/most of their hackery.
Consider: I think there's countless native app developers who sometimes yearn for the great design freedoms afforded by the infinitely mallable HTML+CSS. It is only for efficiency reasons that native still wins. That being the case, if Electron etc (embedded html/css renderer and runtime via JS) approaches were as fast-as-.net/jvm-bytecode, it would easily become the prime choice. So maybe it's just too early to discount entirely.
Is this intrinsic to Electron architecture --- or just the current realities of the sort of JS people tend to write, thrown at the JS engine that Electron wraps?
What I mean, if the final executable is actually some sort of embedded Python interpreter and "Electron" is a bunch of shoddy Python scripts messing with WebKit and Gtk/Tk/Qt/whatever then I'd steer clear. But if the non-3rd-party parts are solidly high-perf-engineered, I'll remain interested..
In raw performance: Vim > Emacs* > Sublime > VS Code > Atom
In UI performance:; Sublime > VS Code > Atom > Vim > Emacs*
*I don't use Emacs regularly, so not entirely certain of this
Honestly, download Sublime and try to use it for a day or two (if your workflow can bear it) and then switch back to VS Code. You'll notice all sorts of small delays that, while not breaking, are certainly annoying.
NeoComplete -> Async autocomplete for both NeoVim and Vim 8 NeoMake -> Async linting and make for both Neovim and Vim 8
Those are the only two I can think of that really benefit from async. Vim-airline, Easymotion, Ctrl-P, UndoTree etc. all don't need async, and you can just lazily load them on start if you use Vim-plug.
Have you tried the open-source Brave browser?
Its GUI is created with Muon (which is a fork of Electron). The browser doesn't seem very slow, at least to me.
Also, Firefox have used XUL for a long time to create its interface. XUL is not much different from what Electron is: XML-like markup to design your interface and JS to manipulate it.
Yes, and XUL is terrible too. Firefox is very resource-intensive and quite slow, and I'm a Firefox user. I wish we could get the values of Firefox with the performance of Chrome...
I can tell an Electron app when I see it because it clobbers other windows on my Windows 7 VM: https://github.com/electron/electron/issues/1821 . I really wish they'd fix this since it makes VS Code much less usable.
I wanted to create a self-contained package of a webapp [1] (from source) so I could easily share it with less technically inclined friends. I was sure something to do this automatically must exist, but it looks like i will just have to create my own package out of a portable xampp or similar.
VS Code is pretty ok too - though there is a definite performance gap between that and something like sublime/notepad++
What I would like is a set of Desktop GUI tools that would work for something like Go or Rust