Would sharing help a lot though? DOM will still eat up a ton of memory and windows are each using a separate process. I have not done this for a while but a year or so ago communicating between two windows in an Electron application was insane.
The rendering engine in Windows is accessible. It has not been as advanced as V8 but it is getting better and that means you can, or will soon be able to, create an app with html+css+js and run it on Windows without downloading a full engine.
For the more common solutions I think computers already have enough memory to handle this. The boot time is a bit too long but if each app uses 200-300 MB does not mean _that_ much when the computers have 8 GB or more.
HTAs, or HTML applications, almost forgotten, have been available as far back as xp and possibly windows 98. They still work in windows 10, though they only support html4 and very limited JavaScript, and obviously aren't cross platform like electron.
Microsoft saw the potential in html for building apps way back in the late 90s. You used to be able to use html as a wallpaper back in windows 98, something I dearly miss.
It's also worth pointing out that uwp / windows store apps can be built in html/js, which are very small to distribute and use a global rendering engine
> Have you tried using 3 Electron apps simultaneously on 8GB machine?
I have done this, and it worked fine. In fact, I had three instances of vscode, slack, gitkraken, Spotify and headset all running concurrently on a windows machine and it didn't melt. I'm tired of this myth that electron takes 1gb per app
It's over half a GB for freshly opened messages app. Give it a full day and I'm sure it won't let you down. Compare that to the previous native version:
I'm typically the defender of electron on these threads. I think its a great way for devs to get an MVP out there quickly. But there is a time and a place for electron.
electron good
- IDEs, markdown editors, visual git clients, things that are front and center
electron bad
- music players, tray notifiers, app launchers, things that work in the background
On windows and mac I use foobar for music and greenshot for screen grabs because they use minimal resources.
The main reason I went with electron is that fantastic system tray integration. System tray integration with the native .Net is an unholy mess. The windows 10 UWP apps do not have a way to integrate with the taskbar. WPF requires interop with win32 code or a half baked 10 year old depreciated WinForms component.
And none of the native solutions allow me to shape and design the UI like I want to without compromises.
Electron may not the best in every aspect. But it was the only sensible and feasible choice for what I wanted my app to behave like.
For me, a small performance hit is justified for being able to make exactly what I want.
I have tried nighthawk, and though it shows promise it needs a little work. Settings is not an obvious place to add music from and when I did add my music folder it didn't seem to look in any subfolders I had.
I was quite surprised by the CPU and memory usage though. Surprisingly lean. I ran a bunch of music players along side it and it averaged the same memory and CPU as colibri, vlc, foobar, and swinsian. Clementine stood out from the pack as an absolute hog, burning up my desk with 33% cpu usage, where nighthawk and the others stayed below 1% most of the time.
UWP has access to the notification area, with badge and toasts to control interaction. The term systray has gone away, as Microsoft reaims developers to use that area differently.
That is mostly because as far as I know, other than ubuntu no distro supports tray icons. And even then it is basically a workaround. Gnome removed support in 3.20 and I don't know about other linux desktop environments.
But for windows, which i primarily use, it is better that what .Net gives me. And it apparently works flawlessly on mac.
Having used foobar2000 for many many years, I've loved its power and customizability, but I do wish that there was a modern way to customize its UI.
The basics are simple, but if you want to do styling tweaks or anything approaching a "custom" UI, you need to start hacking away at an obscure C++ SDK or an even weirder mishmash of GDI+ and old JavaScript.
If there was a modern and easily customizable frontend to foobar2000's core audio and media library engine, I'd be in love. Something like Zeit's Hyper, but for music. I'd be willing to trade off Electron resource usage if it meant I could set up the UI just how I like it.
I still use Foobar2000 on Windows (cmus on Linux), but i wonder why everyone want a Custom UI (Skins) in media player, Is it an old WinAmp feature everyone is nostalgic for ?
For me I think it's because music is a hobby I care a lot about, and I'd like the "option but not the obligation" to easily improve my experience. I've tried a bunch of other music players over the years (on the go, Plexamp seems the most promising in the "access and play all the weird formats in my music collection anywhere in the world, look nice, and get out of my way" category) but I keep coming back to foobar2000 for the sheer capability and flexibility to tweak how I manage and interact with my music every day.
Thats's why I've stopped using foobar2000 and changed to Musicbee instead. Not as flexibel, but much easier for me to get a good looking music player on Windows with all the functions I like.
Really? I was always wondering why people would care about the looks of a (otherwise very functional) music app. I actually almost never look at it, it simply runs in the background!
I am listening to full albums most of the time and don't like shuffle play at all. So I am looking over all artists / albums every time I want to listen to something different. A big plus for me is a beautiful list with all the album covers.
That looks like a great foobar replacement, why couldn't I find that when searching for mac music player, macos mp3 player, osx itunes alternative etc?
The WinAmp interface is fantastic, most other media players simply take up to much screen space. Everyone seems to build iTunes like clients and media library managers. My files are already managed just the way I like them, in folders, there's no need for additional management.
I like having a solid tagging scheme. I don't go deep into subgenres, re-release dates and all that jazz. But having an easy filter mechanism to select music that can have multiple tags for a particular category is very handy. That doesn't work so well with folders, unless you go mad with symlinks everywhere.
I see a lot of negative comments on these electron threads (rightfully so, especially if one cares about resources / performance). Question is: what other frameworks would you recommend for developing cross-platform desktop apps ?
I don’t have a good answer to the framework question, but I do have an opinion about cross-platform. Why make cross-platform a priority over efficiency and user experience? I bounce between Mac and Windows daily, and my least favorite apps are those that try to run on both. They are often resource hogs and provide a UI experience that feels worse than native apps. Electron apps have the least bad UI experience, but are resource hogs. One app I use for work, Mendeley, uses Qt for its UI I believe, and it’s garbage on both platforms- so I use the web interface instead. Give me a good native app instead of a suboptimal cross platform one.
I often think the issue isn’t cross platform though: it’s that there is a cohort of developers who know a toolchain (JS+web), and use frameworks that let them live in that instead of investing the time and effort to learn how to write an app well using a toolchain not built for those focused on web/browser models of programming.
Electron does not magically make your app work like shit - if you treat it like any other framework and actually invest resources into architecture and optimization it (surprise!) results in a good software, eg: vs code. Problem is it also allows to disregard all that and quickly prototype a solution that works good enough for some, and forget about all the optimization. That's real problem, but it's not tied in any way to electron. Same people would go and make a shitty app in qt if there was no electron, or just wouldn't make anything.
Since we're on the topic of music players, I'll comment here that the lack of foobar2000 on Linux is frustrating. I don't have the wherewithal to contribute to a port, the maintainer doesn't seem interested, and things like quodlibet and deadbeef just don't hold a candle.
That said, if foobar2000 had been made cross-platform initially, it may never have been very good. Who can say.
Yes, I am new to all of this so I see the electron hate because of the resource usage but then never see any meaningful discussion on what people would rather be used.
It seems to be this Qt thing which appears to have it's own tradeoffs (which are?) and then...is that it? So is it going to be a case of not having any cross platform desktop apps or having something that uses 2-300mb of RAM that developers won't give you street cred for?
Maybe the focus should be on making electron more performant. Sounds like MS has found a way to do it with VS Code so doesn't that sound like a better alternative than to not have any cross platform apps?
Electron is not "just" a webview like people seem to think - it's more like node in that it comes with a lot of features to integrate into the system, such as autoupdating, tray, power saving stuff or touchbar. If you just want to draw windows using js proton native and vuido work fine, otherwise not nearly the same category.
I'm very partial to Quod Libet. It is utterly flexible and has probably the most powerful tagging engine of any media player. Customizing it just right takes a little bit of work and is a little bit arcane, but once it's there, navigating a huge library of music is completely fluid and intuitive.
I don't play music from my Linux machine often, but when I do it's from deadbeef. Big view of the current playlist, tabs for others and keyboard shortcuts for playback control works for me.
I saw that too...How can something using Electron be highly efficient? Maybe they are talking about the interface and not the system resources the app uses.
Both interface and performance actually. I have a library of about 1000+ songs and it barely takes anymore than 130 mb of RAM for me. This is actually better than some native c# music players that I used before I made this. And CPU usage is very light.
Clementine doesn't use Electron and consumes more of my memory and UI is ugly. Before we start talking about resources maybe we should compare other music players on the market.
There isn't really one inherently; a music player like foobar2000 only takes a few MB of memory even with many plugins. That doesn't mean Clementine and Winamp haven't found ways to waste resources that aren't loading a full Chromium instance (after all, Chromium is pretty efficient considering what it actually brings to the table.)
As a matter of fact(but not scientifically accurate), chromium-based browsers were consuming twice as much RAM on Win than on Linux whenever I checked.
High quality on the web player should be 256kbps AAC, so it should have no audible issues. That said, I find the web player absolutely horrible to use.
The desktop Electron app may be a bit of a pig, but on the other hand it runs on Windows, mac OS and Linux with very few issues, so I'll accept that trade-off.
I don't have Spotify premium - so the quality is 128 kbps.
The app works pretty fine, but is absolutely slow on my (old and quite underpowered) living room PC. But on the other hand it is just a media player...
The quality was the deciding factor for me to use the Spotify app.
I hardly use Spotify. I just use it if I don't want to buy a whole album or if I want to check out some new band. There is an ad every 3 or 4 songs - this seems pretty reasonable for me. I don't know of any other limitations. As much as I've read most of the limitations are for people on the mobile app (didn't like it at all) or when using playlists (I don't use play lists).
However, I found out that for me tui is where it's at for music players. Using cmus combined with a drop down terminal such as tilda or a tiling windows manager is the most comfortable i've been with music players.
You can't throw folders with subfolders at it to make a playlist out of them. The music files have to be in the same folder. Where's the unobtrusive in that if I have to create my playlist first?
Thanks for pointing that out. I tend to curate my library as a playlist itself without sub-folders so I never gave a thought to it.
I am working on a playlist system after all the feedback i got. Will definitely look into the sub-folders way.
Oh, and unobtrusive is for the fact that the player stays completely in the background without a single notification or interruption to your work.
hey is anyone interested in building a modern frontend for Foobar2000?
edit:
I think from the Foobar2000 sdk alone, you'd see how advanced that thing is.. I mean, extension points everywhere, dsp plugin support, built-in query & library management, codecs, gapless processing, all of that written in a scalable & native architecture.
It truly lacks a proper UI toolkit though. The current options are quite outdated that I'd rather fall back to the default Win32 UI.
So, Electron frontend + C/S communication with Foobar2000? I'd totally buy into it.
Internally, both foobar2000 and Chrome/Electron use ffmpeg for audio processing and codec support. The web audio api allows for writing all sorts of equalizers and audio processing effects.
Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do.
Electron frontend communicating with foobar2000 sdk for every little interaction will lead to a huge mess of performance and latency issues. It's better to rebuild the whole thing in electron instead.
> both foobar2000 and Chrome/Electron use ffmpeg for audio processing and codec support
not quite true. for example, the ZXTune plugin brings support for a dozen of chiptune formats which is obviously out of scope of ffmpeg. It'll be possible to incorporate webaudio api for codec but that's a resource hog. Also if you're doing decoding work and the GC jitters, you're going to run out of audio buffer (stuttering). If we take one step back and rely on some audio playback API, then gapless play and other issues would be difficult to deal with.
> The web audio api allows for writing all sorts of equalizers and audio processing effects.
maybe, but that's reinventing the wheel. foobar2000 supports VST plugins, the professional tools used in the audio production industry. there are a few dsp components for webaudio but that's far from satisfactory.
> Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do.
Yes I agree. That way we can make a neat package manager for an audio system. Some Digital Audio Workstations(DAW) have already begun to move this way (Bitwig Studio etc.)
> for every little interaction will lead to a huge mess of performance and latency issues.
Not quite sure.. Think about how NeoVim is built. But my concern is that, foobar2000 is not built for tightly interacting with a frontend, so yeah, better rebuild a native audio core, and use a modern communication protocol (msgpack maybe?) to do the roundtripping. But again, that protocol could be implemented as a foobar2000 plugin...
The downside of using foobar2000 is also obvious. It's close sourced and Win32 dependent. So I'd think about this:
```
Electron frontend <-- msgpack --> Native audio core <--> JackAudio, RtAudio or alike, whatever that bypasses the middleware and directly access the hardware audio buffer
Is there a subsonic interface/client that integrates nicely natively? Having to have it in a browser tab and not having music hotkeys is kind of a bitch.
It currently only works with mp3, wma and ogg files. Flac had some codec issues when I checked it in the beginning. Might have changed as I recall chrome having done something in this regard.
Will definitely check if the new versions of electron support it. If it does support flac, I'll get it working on the next release.
As a user, I simply won’t accept it. Platform integration is suboptimal at best and resource usage is preposterous.
If this is the future of desktop software, and it seems like it is, we have got to find a better solution.
There has to be a way to share the rendering engine and Node process among the many Electron apps that are proliferating on the user’s machine.