Psst: Fast Spotify client with native GUI, without Electron, built in Rust
github.com
github.com
Few Apps ever had that wow factor the first time I used it, it was so much lighter and more responsive than anything else of the day. I remember being perplexed at how I could search and skip to any part of a song quicker than iTunes could looking at a local library. Everything was latency-free and instantaneous.
We were building a Music Startup at the time, so we investigated how it worked. We we’re very surprised we couldn’t find any evidence of an established UI toolkit. It looked as though they had built their own custom UI renderer and optimized TCP protocol which sent back its metadata in XML. Their traffic looked like it was initially seeded from their own (or CDN) servers (for best latency) and then overtime we would see some P2P traffic on the wire.
Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. I was disappointed to see their native client eventually be abandoned and succumb to become yet another Chromium wrapper. I expect it fell to the pressures of a growing startup adding 100s of developers (without the skill of their original CTO/devs) where a native UI couldn't be updated and re-iterated as fast as a Web App. I wish they maintained 2 desktop clients, and left their native client alone to just be an audio player and push all their new social features to their new flagship CEF app.
It's unfortunate the skill and desire of building fast native UIs are being lost to Electron and CEF wrappers. Seems the larger the organization the more likely they are to build new Web rendered Desktop Apps and we have to rely on unauthorized Indie efforts like this for fast, responsive native UIs.
Imagine the frustration of someone who, for example, did work on sound insulation for cooling systems: they sit out on a patio for dinner with friends and the sound of an inexpertly designed air conditioner appears to them as intolerably intrusive; meanwhile, no one else at the meal notices until it's pointed out.
I’d let the guy that tinkers on performance keep tinkering.
Spotify is already better than the alternatives.
That said, I think it's good to remain as objective as possible about the actual impact of optimizing for performance in different domains.
So for instance, the impact of attention paid to performance in the codecs used by a music/video player, or the v8 runtime, or rendering or networking subsystems in e.g. macOS or Chromium is huge.
However, should we expect the impact of optimizing to be similar in application-level code for consumer apps? I would argue no (granting that exceptions exist). At this layer the computations are for business and display logic, and calling into highly performant subsystems. Additionally, they are typically 'leaves,' not dependencies of other systems (which would cause their performance choices to ramify).
This is not to say consumer apps are able to ignore performance concerns: you can still make garbage that way. But you'd be deep into the region of diminishing returns if you poured as many resources into performance for application-level code on something like Spotify as you did on e.g. codecs it uses or low-level rendering code it depends on.
And that's the reason tech like Electron is so often selected by folks whose bottom line is massively affective by their ability to be objective about these issues.
I've written long rants about this in the past, so let me draw a picture instead:
codecs,
chrome old spotify slack, teams,
renderer | current spotify
| | |
|--v----------v----x----------v--------|
FAST | SLOW
slow enough
to notice during
casual use
\________/\________/\________/\________/
| | | |
overkill | bad UX |
| you're just being
good UX mean to users
(your app should be here)First is that this is fundamentally a question of tradeoffs, which means a single axis diagram like this is fundamentally misleading.
For instance, we have the conclusion about 'being mean to users' toward the slow end of the scale. But if the tradeoff means the app costs more, or has fewer accessibility or language features, or doesn't run on the user's chosen OS—which is more mean?
Second, this topic is contentious not because Spotify is slow but because many readers believe that building on Electron implies your app will be slow and is a basically negligent technology decision, a blight on the field of software engineering, and so on and so on... So, while I agree with your placement of Teams (though not Spotify incidentally), saying that because a couple Electron apps are not optimally snappy in this context reinforces the (imo) mistaken attribution of non-snappiness to Electron: afaict, of the major Electron apps out, there are at least as many that are snappy, and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack or Teams; Spotify otoh, maybe it is really bad for some people—not my experience, and the sample of 1 wouldn't prove much).
In any case, I like the diagram and largely agree with its assertions in isolation.
Edit: I'd be happy to take a look at one of your longer rants if you want to point me to one. I am genuinely interested in better understanding the situation if I've missed something.
literally developed by one person in Qt Widgets, covers both Slack and Discord, the installed size of the AppImage on linux is 30 megabytes
$ smem -k | grep ripcord
jcelerier ripcord 0 60.2M 63.6M 84.9M
That said, the issue with Ripcord and similar is that they're all living on borrowed time - and using them means risking your own account. It's only a matter of time before Slack and Discord start to ban people using alternate clients - and then poof, Ripcord is dead.
--
[0] - Fancy way of saying "bought a license when the dev finally enabled throwing some money towards them".
Pretty sure in the case of Slack that their business customers will have words when a bunch of their developers can't suddently communicate with the business...
(FWIW, I judged the risk was wort the effort in my case, and was a happy Ripcord user for the years I had to use Slack.)
That said, I think it's important to consider how much development time is spent on iterating as a new product's design is figured out. The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years—and I'm sure Slack's actual complete feature set eclipses Ripcords (most of the difference coming in via features not essential to most individual users, but key to the business).
The workspace and tab counts are also hard to read much meaning from since most of the memory usage is dependent on the media that's been loaded into the app. How many web page previews, videos, images, etc. are in those tabs?
In any case, at the end of the day our sample sizes here are just too small to draw the conclusions people on here so often do about Electron. We know you can move fast with it (development speed), and that apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)—but people can also build slow apps with it (no surprise), and there is a somewhat large constant factor for install size (~50mb base).
In my mind that does not stack up to merit the kind of complaints about Electron that can be found here every day.
> The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years
That's definitely true, especially in areas where they were innovating (or at least experimenting with features that were not common in the space). There's a cost to R&D, and I'll agree that preferring velocity is important to minimize that cost, which justifies the use of "nice for devs, bad for UX" tools[0].
> I'm sure Slack's actual complete feature set eclipses Ripcords
That's true. Ripcord doesn't replicate Slack 1:1, there were few "sparkly" that were cut (at least when I used it ~2 years ago), and of course a lot of the chrome that got removed could be considered features by some. But at least by metric of productivity, Ripcord's UX eclipses that of Slack.
> (most of the difference coming in via features not essential to most individual users, but key to the business)
In this particular case, I'd say it was 90% just removal of resource-intensive bloat. But that's a good observation in general: one of the reasons some users are dissatisfied with official apps is because of what they[2] deem as user-hostile features, existing to exploit the user instead of aiding them. Obviously, they're put there because they're the key to the business. Plenty of obviously bad UX can be easily explained when one looks at how the vendor actually makes money.
> How many web page previews, videos, images, etc. are in those tabs?
Ripcord either doesn't load those or is lazy about it. But when it does, you at least get the full picture, instead of having to click through some gallery-like popup interface :).
> apps built with [Electron] can be fast (e.g. VSCode, Github desktop client, Discord)
People will contest with you here because they're using a different reference point for "fast". VSCode is impressively fast... for an Electron app. Not so much in comparison to desktop-native apps implementing equivalent features. And that's the one well-known exception, a typical Electron application is noticeably slower and more resource-intensive than an equivalent desktop app.
> large constant factor for install size (~50mb base)
This is not something that people care about unless you're doing something silly, like an Electron TODO app that weighs 50MB and uses many times more of RAM, where the reference comparison is against a WinAPI app that would weigh 50 kilobytes and use not much more of memory.
This is also why people don't generally complain about VS Code being Electron - it actually makes good use of all the features its platform offers. But most Electron apps? Picking Electron saves developers a little bit of time, at the cost of heavy resource tax for all users. That's annoying. Especially if you have experience with native software that gives you reference points to compare.
--
[0] - I'm definitely guilty of this myself. At my previous job, I developed a prototype for 2.0 version of the company's flagship product in two weeks, in... ObservableHQ[1]. The actual work to reimplement those features in our product took almost a year. I did joke we should probably ship the prototype in the meantime (especially given that our main competitor was an Excel plugin), but we never seriously considered that.
[1] - https://observablehq.com/
[2] - And when I say "they", I also mean myself in most such discussions.
I can't speak to the other two, but there is no way I would describe Discord's client as "fast". Starting the application takes 8-10 seconds during which it pops up several different windows on top. Switching between channels has a delay of about 1 second or so. If that channel isn't in cache, then it adds another 3-6 seconds of delay.
Switching between views isn't a new task, and isn't an infrequent one. If I think back to pidgin 20 years ago, the startup time was much faster, and switching between tabs had no perceptible delay. Discord has the advantage of 6 years of Dennard scaling followed by another 14 years of Moore's Law, so it has zero excuse for not being able to perform those same tasks to the same standard.
They got my €18 immediately after I managed to change font sizes and typefaces to the ones I like.
Agreed on the tradeoffs, and the diagram is a projection of complex parameter space onto a single axis.
> But if the tradeoff means the app costs more, or has fewer accessibility or language features, or doesn't run on the user's chosen OS—which is more mean?
That's a very tricky question, because relationship between performance and those other factors is not straightforward. For example, the cost of making an app in a typical startup has zero relation to what the users pay - development is funded from investor money, and user-facing price is set by whatever shenanigans the business is doing at the moment - e.g. $0 to corner the market or maximize growth, or $10 as a calculated point that maximizes money extraction from a growing user base, etc.
(One would think there's no free lunch, and eventually the price has to come close to costs - but that's not how startups economy works. If you get to the point of having to turn actual profit, you've already missed your exit.)
Related to this is a second point: in a winner-takes-all market, the most successful app will suck the oxygen out of the room, preventing others from doing better work. Success typically isn't determined by the app itself - the app is usually backed by a service, which makes it not commodizable. If you need Teams because of network effects, you won't switch to Slack even though the app is better. You won't dump Spotify for a competitor that doesn't have an equivalent musical catalog. Etc.
The point I'm trying to make is: the trade-offs are often arbitrary choices. Would it be possible for an app to successfully compete with Spotify while having fast, native clients for every platform and full accessibility? Definitely. But it's not happening because it's not possible for that app to break into that market in the first place. Our would-be app can't compete on being a better music streaming player - it has to first reproduce the entire value-offering, including the streaming service, the library, and countless of deals negotiated with labels and musicians. This isn't happening, and so Spotify isn't getting any feedback from the market about their godawful garbage apps.
> because many readers believe that building on Electron implies your app will be slow and is a basically negligent technology decision, a blight on the field of software engineering, and so on and so on...
I'm partial to this view. The way I see it, picking Electron by default lands you smack in the middle of what I labeled as "bad UX" zone. It takes hard work - the kind of work you've described as trading against accessibility or existence - to move it into the "good UX" zone. That work isn't usually done - you don't pick Electron if you want to make a snappy app, you pick it because you care about velocity, cornering your little part of the market. So Electron apps tend to move towards the "now you're being mean" zone - which is where this common view of "Electron = bloat" comes from.
These aspects of where the money comes from are orthogonal to the tradeoffs problem though: at the end of the day you have some quantity of money and spending it on A means you don't spend it on B. If performance was sacrificed, you can't look at that in isolation: whether it was a good decision or not depends on what it was traded for.
> But it's not happening because it's not possible for that app to break into that market in the first place.
That whole situation is unfortunate, but tech like Electron that allows companies to take advantage of it also enables independent developers to build things they wouldn't otherwise have time for. It's purely an increase in power and individuals can use it for good or evil.
> It takes hard work - ... - to move it into the "good UX" zone.
This isn't true. If you are to the point of having noticeable performance problems using the DOM/Chromium to render the kind of desktop application UI you might build with QT—you have seriously fucked up (imo). Out of the box this should be blazingly fast; there is nothing extra you need to do to make it fast. Just like don't run expensive computations on the render thread and don't be sloppy lol.
Where the situation complicates is once 'web development culture' is brought into the picture—and I think that's an interesting topic in itself—but it's separate from attributes inherent in Electron.
Fair enough. Myself, I mentally conflate the two - and I suppose so are most of the people criticizing Electron. This position is not without its merit, though: one of the main selling points of Electron is that you can leverage all the libraries developed for the Web.
It's the same thing as with regular web apps - modern browsers are amazingly fast, and you can create snappy experiences with vanilla JS and enough elbow grease. But people naturally reach for modern frameworks - and that very decision is what usually kills snappiness at the spot.
I think there is still a misconception here though: A) no elbow grease is required, and B) just using a popular framework (React, Vue) is not going to slow things down.
RE A, I would recommend just giving this a shot if you haven't: try building a desktop application-like UI with html/css/js executed by Chromium. My expectation of what you would find: it is snappy by default, and it's not even clear how you would write UI code bad enough to create a sluggish experience like e.g. Teams. IMO the explanation probably lies within some organizational structure at Microsoft, not the tech they're building on. (One exception to the rule of things being fast by default: with animations it's fairly easy to shoot yourself in the foot, but it doesn't typically take more effort for performant animations, just basic knowledge of what is quick and what is resource intensive.)
RE B, similar situation here: I think if you try building something with React/Vue you will see that they are also fast by default, and that no extra work is required to make them fast. That said, they (have the potential to) do a lot under the hood, so the potential for triggering something that would cause slowness is higher than without.
After writing this it seems like our disagreement may come down to this: my point is that the tech isn't inherently slow and that a disciplined/experienced programmer can use them to rapidly build high quality software; but maybe from your perspective the more significant thing is that in practice many developers using the technology do end up making sluggish/bloated software, so: that the tech allows people to make slow things fairly easily is more important than its equal potential to make fast things. I.e. the problem is that there are no guardrails + it is the tech of choice of a huge community of developers, many of whom would benefit by the guardrails? (I don't main to blame devs here so much, it's probably more that fault of businesses' priorities than anything)
On the contrary, I have the impression that people snubbing performance while claiming that user satisfaction or business goals are the only things that matter do not care about performance or dare I say technical brilliance at all.
This is a very confusing comment to me since "cares a lot about performance" is probably one of the most consistent attributes of the HN readership—or they are at least a highly vocal subset of the community.
Personally, I respect technical brilliance, but believe it comes in many varieties, of which performance tuning is just one and not on any kind of higher plane.
This thread is about how Spotify seemed like magic in the early days. The original iPhone seemed like magic. Netflix seems like magic in how fast it can stream. Similarly, early google and amazon were always fast.
I believe our subconscious values speed as an indication of quality far more than our product owners know how to measure for.
Songs would play immediately. It was faster than iTunes. I believe Spotify is still faster than Apple Music.
This was at a time when I had no expectation that my smartphone's internet was fast enough to do much of anything. It was so impressive, that I became a paying customer and have been a paying Spotify customer for 10 years.
And Spotify pulls a lot of annoying bullshit. They have a habit of treating their users like shit in various ways - you pay and don't get ads in between songs, but they still spam pop ups and try to direct your behavior in various ways. It feels like their attitude towards you as a user is very much influenced by the "free tier" even if you're a paying customer.
Their various app UIs have suffered greatly over the years (current incarnation is mostly tolerable)
But the base thing they do - play music faster than any other service is what has kept me. I also don't think it is ethical that Apple can offer a competing service, while forcing Spotify to give up a significant cut of its revenue. I think it should be illegal, so I likely would never pay for Apple Music because of that.
You might be guessing from intuition that 10-100ms latency doesn't matter, but I suspect that it does. You can feel the philsophy of the company when you use their products and they feel wonderful. It's a culmination of attention to detail in every aspect of development. I love Sublime Text precisely because of how fast it is.
And they would expect you to have an assistant to work the software for you. ;P
A lot more “luxury” apps compared to android, and priced accordingly.
e.g. $50 for a todo list app, etc.
For speed good enough is just very far away from good (factor 10-1000)
IMO, Spotify is neglecting its core features, and that will ultimately hurt the platform. However, there is such a thing as network effect, and they may have the broadest selection of music. That will keep the platform growing, up to a point. Eventually, the growth numbers may peak and slow down. It's just that there's a lot of inertia right now, and the growth is still going upwards, but eventually, gravity might catch up.
It seems to me that this happens on a per-user basis as recommendations are overfitted to the recommendations they've already listened to. They overfit so much that if you put a playlist of 1000 tracks you like on shuffle, it will only play the hundred or so tracks the algorithm has decided you "really like", and it will play almost the same selection if you put it on shuffle the next day.
YouTube music (music on YouTube, not YouTube Music) works the same way but less subtly. I had a great few months discovering music through their recommendations, until literally every song I listened to would be followed on autoplay by "Sergio Mendes feat. Black Eyed Peas - Mas Que Nada" or "Funky Destination - The Inside Man (Soopasoul remix)".
It became a bit of an in-joke with us but yeah the youtube recommendation algorithm is dreadful.
Search is just so basic, you can not have any typos whatsoever.
There is no proper history function. Say you start a radio, it only remembers that you started a radio but if you come back to it you probably will not have the same songs.
Connectivity is piss poor. If you lost connection you will have to restart the app otherwise you won't be able to use search.
While this is about the native desktop client, I assume it has similar problems so the argument that it is only a couple milliseconds of latency doesn't hold up. Their UX is the worst I've ever had to deal with in a music app.
I’m guessing someone in Spotify’s marketing dept or user retention came up with an algo that determined the features/bugs that would make the service just bad enough that it’s still usable (and thus worth paying for) but too annoying to use too often.
I'd rather have queries for exactly what I type then Google's irrelevant "never gonna let you down" answers.
The thing that keeps me on Spotify is that I’ve invested a lot (but not insane) time in curating my playlists. If I was guaranteed a high quality experience with a competitor I would make the switch but I’m not going to make the switch just to find out that the competitor also sucks.
How pleasant an app is to use does affect a user’s perception of an app and product even if they can’t articulate it. Fit, finish and polish do matter.
On my first iPad, gestures seemed to actually move the screen like paper. Now you perform the gesture and the screen does it’s animation. It doesn’t feel alive. And the animation gets in the way, because you need to wait for it.
Yes, rusty creaking lambos are the best. The rustier and creakier the better.
Still, for certain things 100ms is too much. Android famously had a round-trip audio latency of a bit above 100ms which made it a poor choice for music apps - in contrast to iOS. They now require 20ms in the Android Compatibility Definition Document and admit that musicians require 10ms [2].
In addition to that, hitting the 100ms threshold doesn't mean that lag is not noticeable or not annoying. There was an article about keyboard lag posted on HN a while ago, and the top comment was likewise interesting: https://news.ycombinator.com/item?id=15486494.
[1]: https://www.nngroup.com/articles/response-times-3-important-...
[2]: https://developer.android.com/ndk/guides/audio/audio-latency
Once per 100ms means 10 times per second. A game running at 10FPS would be considered unplayable, not just because of choppy rendering, but also because of input lag.
The NNGroup has done studies with users to gather reactions to slow websites in 1997 and 2010. They remain relevant in 2021 to both apps and websites: "Users really care about speed in interaction design" [1]
A few weeks ago someone on HN shared the reflections of the developer of SumatraPDF - a native Windows PDF reader that is small, lightweight and performant (all the things that Adobe Acrobat Reader is not).
From the developer Krzysztof Kowalczyk: "I believe being small and seemingly fast was a big reason for adoption...there will never be a time when users want bloated and slow apps, so being small and fast is a permanent advantage." [2]
[1] Website Response Times (2010): https://www.nngroup.com/articles/website-response-times/
[2] Lessons learned from 15 years of SumatraPDF : https://blog.kowalczyk.info/article/2f72237a4230410a888acbfc...
If you neglect your core features in exchange for pointless trinkets you're setting yourself up for failure.
The first alternative to show up with an equally vast catalog, but a light and fast interface is going to win a lot of customers in no time.
Remember this is streaming: there is no friction for me to switch. I export/import my playlists and it's done.
This is exactly why Spotify can decay so badly and still succeed. This is why most widely-used apps are so bloated and offer such ridiculously bad UX. It's because the whole point of the business behind them is to ensure there will be no alternative.
Slack, Teams, Discord, et al. live off network effects. You'll go where the community is. At work, you'll use what your employer picks for you, and your employer has a huge list of concerns[0] that are more important to them than user experience. Spotify survives because of the catalog - making a streaming app is relatively trivial; reproducing all the deals with labels and individual artists is an insurmountable barrier. Netflix was untouchable up until their distribution deals expired, at which point the owners of the content all spun up their own streaming services - but a random entrepreneur can't possibly break into that market.
--
[0] - Ranging from "does it tick the right cybersecurity questionnaire checkboxes", through "does it integrate with our SSO", "does it work with our SharePoint", to "was the golfing with the salesperson fun".
They have an insurmountable barrier to entry built out of their deals with labels and artists. They just don't care - caring cost money that could be used elsewhere in the business.
The thing is, that for many people Spotify wasn't competing with other platforms. Spotify was more convenient than downloading music. And at some point of decay, it no longer is.
I have one of the fastest laptops (Apple M1 MacBook Pro) and now I opened Spotify and it was just a black screen for about 1 minute before it showed anything. Then it started.
It is usable. But not good.
I probably wouldn't care about it too much if they didn't mess up the rest of their apps into the dogturd that they currently are. Doing bad UX is one thing, making UX consistently worse with pretty much every update another. And that's what Spotify has been doing for years now - if I could go back to a client-version from a few years ago, I would, immediately, without thinking twice.
The fun part? My company jumped on the SAFe-train a while ago, and Spotify was heralded as the "prime example" of where agile and all that works out really well.
I have no idea what they are doing, but whatever it is - if they continue like this, I'll go back to pirating music, because they're getting really close to having just-as-bad of an experience as that. And I really don't mind paying 20 bucks for my family account; experience is all I care about.
TLDR: up to 100ms latency is fine, but alongside higher RAM usage, and when applied to all programs across your machine (not just a single app), hell breaks loose.
I entirely agree with this statement. However, most people don't have a high-end machine like the developers test on, and actual difference in latency between an electron app and a web app may be over an order of magnitude larger.
The problem is in many parts of the world (including in poorer communities of the global north) people rely on second-hand hardware which even in 2021 typically has 1-4GB of RAM, so a single application taking hundreds of megabytes when not over a gigabyte of RAM will quickly lead to you swap hell and render your entire machine slower.
Despite being an ardent GNU/Linux user, I believe the linux kernel OOM is close to the worst that can be done in this matter (although there are certain progresses with eg. earlyoom), but MacOS and Windows are certainly not immune from it. You'd be surprised just how much people avoid using their computer altogether when they don't absolutely need it, just because it's slow as hell, just because developers in their ~ivory towers~ offices didn't do testing on reasonable second-hand hardware.
Many modern JS/Electron apps are in fact network bound for UI updates which is the worst possible thing you can do... just try to use element.io in a Tor Browser on a normal xDSL connection and you'll see what i mean (unless it's improved recently). So on this scale of the absurdity of modern software engineering, 100ms latency for user interaction is not all that bad... although my GUI/CLI tools in the 90s were much snappier than that and we have in fact greatly regressed as a field.
made my blood boil every time I had to use them. Even the poster child for a good Electron app, VS code, while packed with cool features, feels so sluggish next to Qt Creator that it distracts me from my work constantly when I use it.
Thankfully, on my Linux desktop, the actual number of such apps I actually need is precisely zero, everything has at least one (much snappier) Qt or GTK alternative.
> just try to use element.io in a Tor Browser on a normal xDSL connection and you'll see what i mean (unless it's improved recently).
I just tried without Tor and counted 5-6 seconds between the time where I clicked on "Open in your browser" and the page actually showing up here: https://element.io/get-started, so I'll happily pass
I think here it's more accurate to say, "the business' impression of the end-user's perceived value".
Because a snappy user experience DOES have real value; in web we are very conscious that milliseconds cost viewers in load and response times. It's well documented that brand positivity is connected to load and response times.
But users don't know to tell you that until the performance gets REALLY bad. Consequently it's hard to get this value from a user survey, and hard to communicate internally as a value prop. Capabilities are much more business process friendly.
You can tell this is true because people keep complaining about it, and developers keep reminding us that we don't actually care about how slow apps are.
Edit:
Upset downvoters care to elaborate? Or just huffing into the void?
So we end up where we were, with VsCode as singular example, and in turn, with the distinctive suspicion that the inability of anyone to point to even one decently performing Electron app may just simply be because Electron is not very good.
The downvotes then probably arise from the fact that this argument has been replayed on HN hundreds of times.
I've yet to experience any Electron App that's close to the snappiness and UX of the original native Spotify client, I'd like to hear about good examples of Electron Apps comparable to it.
I don’t care to share details of my past employers but I have absolutely worked on web apps that ran 60 Hz on mobile and looked beautiful to boot.
It was a team of senior devs though, and it was a small shop. We didn’t suffer from the same organizational issues at the time but as we grew, sure enough - the web application slowed as the need to move quickly and cut corners arose.
The point is that the web offers you a vast array of performance footguns that anyone on a tight schedule is going to wind up firing off at one time or another. Electron isn’t to blame. It’s architecture and code practices.
But the web is easy to hate, and by association Electron is going to take a ton of flack.
When I open a software, I did so for a purpose, and I expect to actually do the thing as fast as possible and be done with UI...that's the reason why TUI apps are popular with power-users
I will say though that I’ve yet to work anywhere else that held themselves to a comparable performance standard.
I have yet to use a fast electron app that didn’t hog ram.
To the extent you understand the tech, though, you understand the problem was never the platform but really the hands it resides in. Nobody thinks its worth the extra work required to heavily optimize a web application.
One needn’t exist for me to be right, as unsatisfying as that may be to a group of folks unfamiliar with frontend perf on the web platform.
You’re being pedantic and are upset that you’re being called out.
The problem is not Electron. It’s far bigger than Electron. I realize this is a take that requires knowledge of the web platform and industry, however, and as such may simply be lost on folks without that context.
You’re being hard headed and am upset I don’t agree with you. Hope that helps
Atom is the Electron-based editor from GitHub. It's way slower than the others.
I can't think of any Electron apps that have low response latency. VScode's is noticeably much higher than, say, Emacs.
Having experienced the original Spotify App myself and having used many Electron Apps daily for years I'd posit that it's naive to claim the responsiveness and snappiness of the original Spotify App could ever be reimplemented in Electron. You're claiming it is, so lets hear about some examples we can actually use?
I’ve worked in the industry for something on the order of like 15 years and have worked on extremely snappy web apps that I don’t personally care to name given my association with them.
I’m sorry you are disappointed by the web. I actually find VSCode to be an impressive achievement with Electron, though, fwiw - which is probably not much given your obvious predisposition.
VS Code is a good general multi-purpose text editor that I use daily, but it's nowhere near the responsiveness and performance of a native editors like Sublime Text.
Opening a 1MB text file with no other VS Code windows open takes up 350MB, Sublime is 48MB. If I want to view a file quickly I'll use a native text editor. But please keep baselessly spouting how Electron produces the snappiest apps and how it's everyone elses fault for assuming just because every Electron App they've ever used is slow, it's not Electron's fault - which apparently when used in stealth internally produces just as fast and snappy UX's as native Apps.
I did not say Electron intrinsically produces snappy apps. I said that one CAN produce snappy Electron apps.
Which is indeed true, but as highlighted elsewhere by more reasonable individuals - the baseline for the web is slow. It requires expertise to do right, and in ways other platforms might not demand.
The benefit? Run it everywhere. The downside? $$$ and time. That’s why most just take their “run everywhere” benefit and accept the fact their app is going to be slow and/or a hog.
We’re discussing the platform’s potential, not the common case result of the platform’s broad userbase.
You're still asserting they CAN without being able to cite any that does. You've only highlighted everyone's favorite VS Code example whose performance and resource usage is definitely not comparable to native text editors.
Everyone already knows the obvious benefits of Electron and why it's popular, that's irrelevant to your baseless snappiness claims on a thread about the impressive UX and responsiveness of Spotify's original Desktop App which even they themselves was not able to recreate when they moved to their new Desktop's CEF/Web UI architecture.
Which explains everything.
Slowness is the natural state of web applications and creating a fast web application is much more difficult and requires a senior team with knowledge about browser implementation in order to avoid or work around the performance pitfalls.
I also have the feeling that such performance comparisons are done with the assumption that the apps under test are almost the only thing running on the machine. If every applications were to start 10 processes taking 1 GB of RAM things would get uncomfortably slow.
Is anything fast on Android? I have a 2017 Samsung and it's always been slow.
I don't upgrade often for financial and environmental reasons but we're not at the stage yet where smartphones are a commodity and performance is stable over the years. There's still performance gains every year and they add up.
That is, indeed, the argument, except without the "if" part.
People usually point to VSCode...If that is the epitome of a responsive, lag-free software then I claim Electron defenders haven't seen snappy application.
Do people even remember Winamp?
But I remember a few months ago I was developing a basic API and testing it through Insomnia. At first, I almost had a heart attack seeing the time it took to answer, between clicking "send" and getting a response back. All this running on localhost, on an old but fairly powerful box (i7-3930k, 64 GB ram). My first reaction was I must have had some sleep() lying around.
Then I looked at the details, and the actual time taken handling the call, etc, as reported by Insomnia was a few ms, all the rest was... I don't know what.
But I do agree than other than that, when interacting with the app itself (switch requests, type, etc) it feels snappy enough. I usually use it alongside IntelliJ, which while fairly fast, isn't terminal-level instantaneous.
I see no other rational explanation here
https://github.com/whyboris/Video-Hub-App
Electron is overkill for a todo app that you want users to open/close many times per day. But if it's an app that's used for 90% while it's open and is used a few times per week, who cares if it takes 2 seconds to start?
I don't understand what everyone is moaning about with Electron. My app uses 130mb of RAM -- is that too much to ask for, for a dedicated video browser?
ps - here's also a file renamer I built with Electron: https://github.com/whyboris/Simplest-File-Renamer
I'll often play from my phone and connect it to my Echo speaker group. This used to work so seamlessly - it was beautiful.
But now - it takes 10 seconds for the initial connect. If I hit play/pause there's a 5-second delay to the point where I'll tap it twice, which is also delayed, and then it'll stutter and jump around. And worst of all: I'll hit pause, come back to it in a few minutes, and it's completely disconnected.
Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we...
> "Not to go into too much detail here, but at the time, most of the internet was made up of “thin clients,” like web pages or Flash-based clients that ran in-browser, and used more traditional, standardized protocols like HTTPS. Seeing the limitations of that, Ludde and a team of engineers ran in the exact opposite direction, creating a stand-alone “fat client,” building entirely new protocols and hybridizing client-server and P2P technology to suit their own ends. (Check out Episode 01, “How do you steal from a pirate?”, to hear more of that nitty-gritty stuff about persistent TCP connections and how our P2P implementation saved us bandwidth cost.) It was only by rethinking every layer of our infrastructure that we were able to pull Spotify off, to create that magic moment of double-clicking on a new song and having it instantly play. And speaking of magic …"
Having been an early user of the beta I presumed it had to be driven by people with this mindset from rethinking everything from bottom up to provide the best UX possible, would really love to read more about the technology used in the original Desktop client?
EDIT: Currently listening to “How do you steal from a pirate?” which is providing a more detailed backstory on the origins of Spotify:
https://open.spotify.com/episode/1jHRUXkeiUh44CK4KZQb0h?si=d...
Sounds like Ludde Strigeus, the creator of µTorrent was the key hire to make the original Desktop Client UX possible whose Desktop & P2P expertise was able to convince the rest of dev team to go down the path they did. Some interesting insights, they used Ogg Vorbis instead of mp3 using a custom designed TCP protocol because they were better able to strip packet bits down to transport just the audio bits required for playback.
> Michelle: The thing that happened that was kind of pure magic in that meeting was that [Daniel] did a comparison. He started playing a song on the software, and the song played so quick, so instant … I mean, I don’t know if people remember, but playback was slow back then. Even if you had an MP3 on your computer, and you played it via, you know, Winamp, iTunes, this was faster. And we were like, “You have the files on your computer, right?” And he was like, “No, it’s in the cloud.”
I had the same initial experience where I was blown away at how instant and responsive it was, at first I didn't believe it and thought it was doing some sort of pre-caching magic where it'd start downloading before selecting each song. So ran lots of tests where I did first time searches and immediately scroll to songs down the list of search results (to bypass any caches) and could see that it was indeed pulling traffic in real-time, the time from click/scrubbing to audio playing was just unbelievably fast.
This Electron crap is really a race to the bottom, so you can hire the cheapest college drop-outs to cobble together some JavaScript to add feature number 1001.
On another note, this ludde guy is one of the few rock stars in IT to me. Had a lot of fun on ScummVM, played OpenTTD to death, used µTorrent in College, you name it...
I definitely miss native apps, but I understand why they're less common now.
This reminds me of a conference that John Carmack gave (in 2019?) where he goes over how [the occulus team] got input latency down to a manageable amount on modern hardware.
It's an interesting data point that both these efforts to produce "magic" required an in-depth "rethinking" of many of the underlying stack layers.
They spend some time interviewing Lars Ulrich of Metallica in the context of of the Napster lawsuit. He comes across in this interview as still upset at Napster for what they did, and he is at turns indignant and also emotionally wounded at the fact that they are perceived as the villains in the story. In particular he cannot seem to reconcile his belief that they, and I quote "are the most fan friendly band on this planet" with suing Napster for $100k per download in damages, a ludicrous and arrogant sum. I am not a Metallica fan and do not listen to their music (out of disinterest, not antifandom. Metal isn't my genre), but it is striking to me to see how 20 years on they still don't get it.
A close friend gave me insight on why success changes people, after I hit a milestone that mattered to me. He told me, "You are still going to have problems, they are just going to be different problems."
Each of our moral outlooks, stability, suitability for state of life, relatability, etc., is heavily dependent on our relationship with our survival environment. And success radically changes that relationship qualitatively, when it changes it much quantitatively.
Did you read about the "what survival means to us" somewhere, or was that just convos with friends?
Slayers' drummer Dave Lombardo said about his colleague Kerry King: "He is the dumbest person i know."
You don't have to be smart, your ego problems figured out or a likeable personality to make great music.
Narcissim plays its part too. I think actually is okay to want to be admired by others by accomplishing great things. I think it is a biological urge to attract a mate. Doseage makes the poison though.
A lot of musicians still think this way, "I should be able to make a living from my craft and thus piracy is theft." But that's a misunderstanding, I believe -- people would still pay money for music, just like they pay money to creators on YouTube and the likes even if most of the content is freely available.
No offense but this is wishful thinking, they're one of the best selling bands of all time.
Here's a great clip (from the amazingly deep diving podcast What Had Happened Was) with El-P from Run the Jewels, et al, about why RTJ gives away their albums, https://www.youtube.com/watch?v=TdtLTw7Xsj8.
If you want to use a native GUI framework because of accessibility, check if it's as native as it claims.
Re. command-line Spotify clients, there is ncspot[1] and spotify-tui[2], and if you use Linux, Spot[3] looks like a nice GTK experience.
[1] https://github.com/hrkfdn/ncspot
Seems rather like comparing someone's homemade bottle rocket to a Saturn V...
Perhaps a better analogy would be whether you want a fast but fragile kit car missing some features, or a well-built but slower caravan.
I'm intrigued by this client, but I'll wait for a beta before trying it out.
The reality is that we can't expect every single hobby project to support every single use-case from day one. Painfully for all - the current state of things in this space is such that building accessibility into your product is not trivial and hence it gets postponed "for later".
Now, on to a completely honest question: why don't we have screen readers that can consistently translate the "visual" version to a version people with visibility impairments can understand in a more generic manner, without requiring every single piece of software to adjust itself to every single flavor of a screen reader? I'm honestly asking why can't we solve the whole problem by offloading it to the screen reader itself. Can we solve this by simply offering a text-only command-line like version of every product? (ie. as opposed to building "beautiful"/"designed" experiences that get downsampled by the screen-reader anyways)? Sort of like building a sitemap.xml file that lets the user with a screen reader do everything a user with the full-blown GUI can. Sounds like an opportunity to create a cross-industry standard?
Edit: getting downvoted for comments like this is why I'm honestly considering just closing my account and not participating in any more such conversations going forward.
Your last paragraph for a magic screen reader is that it simply doesn't exist, so in its absence you need to use a GUI FX that supports accessibility for it to be accessible. If all the screen reader can see is a rendered bitmap they're not going to be able to identify what's a UI control or how to interact with it, which group of pixels is decorative and which is functional or how it will be able to determine the difference between a real App and a screenshot of it? With the recent real-time AI powering "copy text from image" maybe a generic reader is going to be more advanced than what's historically been possible.
But I don't really know how screen readers work, I'm assuming they need to work in tandem with GUI FX's which is able to describe the purpose and roles of its different UI elements, so if you use native OS controls it's going to be able to know how to inspect different controls of running Apps and how to send events to them.
This has been the status quo for decades of computing, but it seems quaint in this age of instant ML-driven image recognition. Anybody doing anything in the accessibility space with ML?
I don't know much about the accessibility business, but my impression is that the screenreaders are all very expensive. Maybe providing a universal interface as described would level the playing field, maybe that's not desired (by the big brands).
False. I have a print-related disability and I rely on screenreaders.
I use Orca on Ubuntu. However, the default voices for Orca are deplorable (by default eSpeak text to speech engine).
Most people do not know this, but https://oralux.org sells machine learning high quality voices (NeoSpeech engine) for $35 per voice at most which work directly with Orca. Here are the English text to speech voices: https://www.oralux.org/voice.php#english_american_english
You can also accomplish UI scripting via C/ObjC/Swift using the Application Services framework [1].
[0] https://developer.apple.com/library/archive/documentation/Ac... [1] https://developer.apple.com/documentation/applicationservice...
We should decouple the core of the application from the UI. Have a standardized interface which exposes all available functionality to the screen reader and allows it to talk to the core directly, bypassing the UI.
Stop doing what everybody does today: stop having screen reader depend on the UI (ie. aria-labels, etc). This problem can't be solved by adding "decorations" to existing UI components. It's best solved by exposing an entirely separate interface which lets screen readers (and other hardware) interact with the core of the application directly.
This sounds like a spec, a set of language frameworks and a design pattern waiting to be written.
it'd take awhile to perfect but i think it'd ease the burden tremendously for software developers and those who need accessibility.
Legislation is not really the answer, or we'd already have great accessibility.
In other areas, we've automated and outsourced it - CI/CD, security, infrastructure. Think how hard it was to manage an RDBMS cluster or version control repository 20 years ago, and now even a junior developer is able to have both within minutes. We have frameworks like React.
In that time, accessibility has actually got harder, because of more devices, technologies, network connections, and more people with a wider range of accessibility needs.
I'm not sure what it would look like. Maybe a new way of rendering content, maybe a new framework that puts accessibility as a first-class concept.
Some of us can't wait. That's why I, for one, continue to advocate for developers to make their applications accessible with the currently available tools. It's also why I'm trying, with my AccessKit [1] project (which admittedly is taking time to get off the ground), to make it easier for GUI toolkits to implement the current baroque platform accessibility APIs.
I'm also reluctant to concede that we're doomed to reconstruct UI content and semantics probabilistically from pixels, when that information is already there somewhere in the app. But it may be the best long-term solution to the social problem of trying to get everyone to implement accessibility.
Wasn't Spotify's client Qt too ?
> Qt is only used on Linux. The native parts is built with our own custom toolkit on top of a canvas- and window-abstraction layer. The canvas/window stuff is implemented with Qt on Linux, but with native stuff on win/mac. Then we have the HTML5 views, which use Chromium Embedded Framework.
https://www.quora.com/What-is-spotify-Windows-Mac-GUI-app-bu...
> Proprietary technology written in C++, C and a tad of assembler. A list of third party technology used can be read by going to Help → Show Licenses in Spotify, or by opening file://localhost/Applications/Spotify.app/Contents/Resources/licenses.xhtml (if you're on Mac OS).
https://www.quora.com/How-did-Spotify-make-a-multiplatform-l...
The list of deps is insightful looks like they used WTL for their Windows UI, no idea how they made it work on Mac as well:
Boost, Expat, FastDelegate, giflib, libjpeg, libogg, libvorbis, Mersenne Twister, zlib, NSIS (Windows only), Windows Template Library (Windows only), Growl (Max OS X only), Lua
When Spotify came along it felt like a breath of fresh air, light, nimble, instant playback. Obviously the streaming approach was a departure from the older way, but it just felt so much better to use.
Such a shame they seem to have lost their way with the browser based thing.
As a screen reader user, I couldn't use Spotify at all before the Chromium client was released, first in beta and then in stable.
Spotify's desktop accessibility was... passable, but far from great. It improved massively with the most recent UI redesign, which is almost universally hated by sighted folks.
This is a pattern I see pretty often, Reddit is another great example. Old Reddit is almost unusable to me, the new one is a massive improvement.
Ludvig Strigeus is a skilled developer and have got many awards, like the Polhem Prize which is a Swedish award for a high-level technological innovation or an ingenious solution to a technical problem. If I recall correctly, he is very good at writing very small and optimized c++ programs, but the code is very hard for others to understand and maintain. So I guess when Spotify become bigger and more developer needed to work with the code they needed a more "main stream" solution and had to abandon the first client.
Are we really living in a world where we need "authorization" to replace some corporation's software with our own?
Very much expected - back then the main Spotify developer was Ludde, an author of another little marvel - uTorrent.
I think time is a large contributing factor. A lot of things start off simple and elegant. Then you have to come up with new features year after year after year (how old is the product?) in order to not appear stagnant and keep customers happy. "Oh, this other app got x feature, I want this in the app I use too!!!"
Here's kind of a video to illustrate the point, where Rick talks about iTunes. How it used to be, and how it evolved and is now. iTunes once ruled the world. It was simple, and elegant.
It's also small changes that are extremely annoying. Pressing "New Playlist" used to come up with a dialog box asking what the playlist should be named. Now it just gets called "New Playlist". Clicking the playlist name to rename it does not automatically select the textbox to give it a name, meaning that to create a new named playlist - an action that used to take one click, is at least three clicks and two keyboard presses... I mean, come on Spotify!
The search bar used to always be visible. Now I need to click search first, then click the search bar.
To me, Spotify was the epitome of software completion five years ago. The client worked. It was perfect. It seems like every single update since they released the "Daily Mixes" has both downgraded the performance of the app, and made discoverability harder. I want Spotify how it was 18 months ago.
Spotify on my machine sometimes chews up 2GB of RAM. Reached out to support, and the best that they can give is "try restarting the app". That helps, until 12 hours later you need to do it again. A music player should not have 10% CPU usage on a modern MacBook.
Finding Psst has been a life changer.
I'd pay handsomely for an app that did discovery on tracks and not artists. Last.fm kind of but not really does it. It took me many years to get from Sirenia: Seven Sirens And A Silver Tear to the Midnight Sonata (I can't remember alas who did it -- was it reddit or a forum on a now defunct tracker? all the great trackers are dead) and from there I was able to branch out. But this shouldn't be so hard..? We already have several music matching apps, surely closeness is a solvable problem.
Years have passed. I still havent filled the gap left by whatcd...
Now? A blank text box. "Let's ignore the artist and album this user's basing a playlist on and make them type the whole thing from memory". I just don't bother any more, which seems petty but it's just so cumbersome, from mobile especially.
tl;dr I think albums have more significance than you do.
I think Spotify (at least for me and I think for many others) is great because of lists: I'm the one choosing what and when to listen the songs, and I'm able to group them. I have lists made out of albums where I respect the order that you mention, with the same implications. But some other lists I have hours of songs that don't fit under the concept of album.
I agree and understand your point, but I think in the past Spotify's UI had both options: the songs were sorted by album, but also allowed me to access all of them and cherry-pick the ones I wanted easily from that same view.
They also see much more upside in podcasts and thus are pushing people there.
But any client without support for Spotify Connect might as well be dead to me. Controlling my wifi speakers from my phone, or playing music on my desktop Mac from my laptop or gaming PC is critical functionality at this point.
I hate it. If any spotify PMs are listening:
- If spotify wants me to listen to podcasts, let me do it from my existing podcast app. I'm sure the developer of Overcast (and other apps) would happily add a spotify login button for a song if you ask nicely and offered to pay.
- Let users disable podcasts entirely in the spotify app.
- In the spotify app, give podcasts a consistent visual differentiator so I can easily visually separate them from music. Nobody wants to be tricked into listening to a podcast instead of music. Maybe make the "album cover" for podcasts a rectangle instead of a square. Or change the background color for all podcast related content to blue so I can find podcasts visually (or filter them out visually) while scrolling.
Their strategy is to take the open protocol of podcasts and pay the hosts to turn that into centralized tracks on Spotify to force you as the user to use Spotify to listen to it.
It’s about control intentionally - that’s the strategy.
What I wanted though was just the ability to add podcasts via the open protocol url for them (how every other podcast app works) or for them to allow hosts to upload tracks.
Spotify instead saw an aggregation play - they could pay hosts for exclusivity and take those podcasts away from their open distribution into a distribution entirely controlled by Spotify. This is a hostile move to end users (and ultimately most content creators too in the end).
If spotify's podcasts are available in my preferred podcast app after I've logged in to my spotify account, they still get paid. And I'll listen to & appreciate way more of their podcasts that way. And they can use it as another funnel for potential customers.
Its win-win.
Can't comment on anything else, though.
Spotify promotes podcasts and buys exclusives so desperately, because their plan is to grow their audience to a too-big-to-fail size, so they start dictating their own terms. Every remaining use of RSS is a business opportunity.
Or the pain of switching between paired devices.
At least no more cables getting ripped out of my ears by the door knob.
So to answer your question I’ve had them for around 20 months.
And for price, $250AUD every 5 years is well within what I am willing to pay for the convenience of the airpods. I use them daily, I have them in my pocket always. Being able to quickly put them on and take a call and it all just works instantly is worth it to me.
I also have just not ever had in ear headphones ever last that long either. The cable always breaks within a few years max of usage.
The Spotify UI has been pretty painful lately but I have a hard time living because the suggested music selection has been so good.
When my girlfriend and I moved in together, we got rid of her Alexa devices because privacy and use HomePods. But Spotify doesn’t work with AirPlay for reasons I cannot fathom, so I set her up with a program that will AirPlay specific applications on her Mac.
That said, there are open source libraries and clients for AirPlay so it shouldn’t be too difficult to get them supported. I have a Raspberry Pi for streaming to “dumb” speakers.
Apple Music is still mostly worse without discovery, but at least lossless makes up the quality difference that use to be there.
The correct solution is for the application to support Airplay, so that for instance Spotify can stream music to your Airplay device, while the Mac sounds still goes to the speakers of the laptop/iMac.
It’s also worth noting that Spotify can act as a remote for its own service across devices. So you can start a song playing on your phone and direct the output over AirPlay and then just interface with that session using the desktop client.
This is what I do on macOS. I press on the little megaphone icon (enable it in OS sound preferences) in menu bar and then I can choose my HomePod from the list, without any third party software. I am running Big Sur but in two previous versions I also did the same. Maybe I’m missing something here but I think it should work seamlessly.
This makes watching a "GIF" with audio (say browsing Reddit), opening a video, answering a slack call, etc. a very bad experience.
Spotify by itself supports its own protocol, whatever that may be, and chromecast. The iOS app should also support Airplay through the OS.
Personally I have a Spotify enabled receiver plugged to my audio system, it works really well.
Spotify is a marketing platform first and an audio player second.
I think I remember seeing this on desktop too but at that point why not use the OS sound mixer?
Sometimes I just want music through my speakers while I have something else piping into my headset. ¯\_(ツ)_/¯
For me this presents a native popover showing all Bluetooth devices and Apple TV.
I'm a Linux user and have multiple audio outputs. I've configured Spotify to always go to my amp / speakers. And it works great.
But then there's Teams, which is absolute sh*tshow. It always says "custom configuration" but you never know where it goes, and partially ignores the configuration in PulseAudio / PipeWire.
I understand why they do this, random users may find it more useful to have this choice directly in front of them, and I would agree... if it worked well! Zoom at least has the good taste to have an entry for "use system settings", which seems to mostly work.
I think that aside from "specialty" applications (like DAWs, etc) regular apps have no business messing around with the system audio settings.
Or... like audio players, maybe?
And it's not messing around with the system audio settings; it's selecting a audio device other than the system-wide default.
Heads up though, the original developer is MIA at the moment and the latest few versions of the client are incompatible. There's an effort by someone to fix the issues and there are other maintainers who mostly just seem to address PRs. Personally I just downgraded the client and it works perfectly.
[0] https://github.com/khanhas/spicetify-cli
[1] https://github.com/3raxton/spicetify-custom-apps-and-extensi...
For example - for people that prefer listening to albums. Or people that only care about political podcasts. Or something. I wonder if the global audience is enough to support indie products like this.
Significant platform risk though.
Where would the world be today without Napster? Maybe the same place, but provocative software is the definition of cool.
Regardless, I'm excited about this little project even if it goes against the ToS.
It shows you can write native cross-platform apps that are fast and have low system resource usage instead of the now default, packaging your app in a standalone resource-intensive web browser, aka Electron.
It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron.
This is a purposeful decision though. How else could they track a thousand different metrics about you without 20mb of Javascript?
1. Electron apps also have access to "your whole (userspace) system".
2. Electron has npm, which makes it ridiculously easy to add analytics code to your app. See, for example: https://www.npmjs.com/package/electron-analytics
I get that this is early days for this project, but the issues are general for all of these non-browser, non-native UI toolkits. Hopefully we get there though.
Obviously screen readers are an important step, but we hope to be working with AccessKit.
In any case, though I'm not trying to represent Druid as ready for production use, I love seeing stuff like this. I think it's a good sign of what's possible and where things are headed.
Picard is a good example of a PyQt app: https://picard.musicbrainz.org/
I suspect the real reason is that web developers are seen as a dime a dozen and GUI programmers more specialist and hard to find. This was the main reason my team chose to do an Electron app. We were already doing React on the website and nobody had any experience with Qt.
This is too user facing and too easy to modify for DRM circumvention (if it isn't already doing that)
Whether it dies through a DMCA takedown or harder DRM measures remains to be seen.
I'm always sad to see people investing lots of time into creating great software that exists in a legal dark grey zone and will inevitably be nuked.
And yes I'm also not happy with the standard Spotify client
If it weren't for all the legal agreements with copyright holders, I feel like spotify would already have an open playback API.
But if you could get the original file from Spotify's servers and decrypt it yourself, you could automate downloading your entire library, offline forever at source quality DRM free. Unfortunately, that is illegal and Spotify is going to dick them with lawyers. Pretty sure that's what happened to this project: https://news.ycombinator.com/item?id=25017167
History: after the developer decided to pivot from only being a tool to scrape the encryption keys needed to decrypt an individual song, the developer decided it would be a good idea to build in automating the downloading and also decryption of those files, instead of letting people develop that as a separate tool.
Developer and project has disappeared shortly after that decision.
Spotify does at most MP3 320kbps, source quality would imply something like lossless FLAC/AAC
> This app uses the Web API from Spotify, which doesn't handle streaming itself. So you'll need either an official Spotify client open or a lighter weight alternative such as spotifyd.
Is that even possible for Spotify at this point?
The OP project is speaking to Spotify servers through the same means that official clients are, but the official clients are not just on iOS, Android, macOS and Windows.
There’s official Spotify clients on almost every platform imaginable. Everything from PS4 to built into TVs. And even a lot of stereo systems have Spotify Connect built into them.
Spotify Connect works by having these other devices streaming and playing the media, and your computer or phone acting as a “remote” for choosing the songs to be played. See https://www.spotify.com/us/connect/
Basically they’d have to break a lot of official clients, many of which probably cannot be updated, if they were to change their DRM scheme. How do you update a receiver for example? Well, you might be able to flash a new firmware with a USB stick. But for regular people, they are not going to do that. And the DRM scheme, at least as of yet, would be defeated by the reverse engineers as DRM always is. And hopefully continues to be.
So at least as of yet I think they would hurt people with official clients more than they would hurt anyone using an unofficial client.
And even people using unofficial clients are probably paying customers.
Besides what’s the point anyways, everyone knows that if you really really want to rip audio you don’t need to circumvent any DRM at all. You can play the song on your computer or your phone and take the analog signal that is going to the speakers and digitize it again and make an imperfect but still good copy of any audio. Admittedly it doesn’t scale anywhere near as good as automatically stripping DRM though.
I've looked it up a few years ago, so this may have changed, but at the time you couldn't just ask Spotify for the SDK / docs to build your own Connect client. I don't remember the details, but you'd have to jump through some hoops, at which point I stopped looking since I wasn't about to build anything industrial. I expect some terms would be that you'd at least try to protect the keys.
In order for Spotify to have any decent user experience, they need to nip any DRM bypass as scale in the bud before the publishers find out, through cease and desist or worse. If better DRM becomes the only solution, everyone loses.
The difference between official and unofficial clients is that Spotify can have some (contractual) power over the official clients, like demand that music is cached encrypted, demand a certain limit for cached music, etc. Unofficial clients aren't bound by any contract, so the developers could easily do something they shouldn't be doing according to the terms and conditions Spotify lays out (or the terms and conditions of the copyright holders that Spotify must uphold).
Spotify are using Widevine on their web client, which is considerably more annoying to deal with than the encryption method used in the files fetched by Psst.
Nothing is stopping them from only serving files from the endpoint that serves Widevine protected files.
Then again, Widevine L3 has been broken[0], Google just keeps rotating the private keys used in the content decryption module.
Spotify is built on bringing your music library with you everywhere. If your car or five year old stereo stops being able to play spotify songs, why would you still pay for a Premium account? 2% loss doesn't sound like much, but at Spotify's scale, that would mean loosing 2 million paying customers. If they pay $5 /month, that's not pocket change.
What's more, media-oriented devices like smart tvs or game consoles usually have those requirements.
How?
I wonder what's faster: The new GUI, linked user accounts getting suspended or the project getting legal issues with the result of being taken down.
¯\_(ツ)_/¯
No, seriously. I support projects like this. But they pretty much always end the same. It's always sad to see so much effort go into waste. I get the motivation but I think there are a lot of other things to spend this kind of work on other than somethings that breaks a service's TOS from just reading the title.
Apple Music also has an official and maintained API for building third party clients.
As in, zero latency, or no observable latency. Instant performance. Honestly, it sickens me how spectacular advances in hardware translate into performance being worse than before.
Even the Office client apps are now web (React). And you can tell. Sluggish and glitchy.
As for the Spotify app, I have little love for it. Overengineered garbage where the simplest actions leave you searching. Internally, they have created this massively complex structure of squads and tribes each taking care of just one tiny part of the experience. This may explain why Spotify is so disconnected and makes no sense.
All of this engineering effort, I imagine there to be at least a few hundred working on it, ultimately add up to an experience less usable than bloody Windows Media Player from the 90s.
Specifically, React Native for Windows. https://github.com/Microsoft/react-native-windows
For things like background services, they still use C/C++.
Is there a source for this? I searched around and can only find rumors from 2018, and announcements that the mobile apps are using react.
This is the best I can find, with the Microsoft MVP clarifying the situation:
https://mspoweruser.com/no-microsoft-is-not-rewriting-office...
Specific point of interest:
"Office 365’s UI, a lot of it, but definitely not all of it, are pieces that are built using React Native (Windows). API’s and Services are still going to be powered by C++, C#, or whatever is the most appropriate for that team. Nothing is converting to “all/completely” JavaScript/TypeScript."
To me, this confirms that at least the UI is React. Anecdotally, it feels very "web" as I use it daily. Sluggish, missing paint cycles when switching between apps, and the typical main thread freezes.
I'll let you decide if this is convincing enough evidence :)
It's so damned efficient it barely registers in my CPU monitor. Check out the memory utilization too!
https://i.imgur.com/Fa3Dnnb.png
Now compare it with the semi-official Spotify client:
Winamp 2.72 only used about 8 megs of RAM.
Wow, eight megs was once so much memory that we would laugh about applications that even approached it.
Also, Electron apps do not scale and it wastes CPU time, eats RAM up and fills up HDD space. On laptops, it drains the battery faster.
A quadruple negative to the user.
I can't judge the main application but just the settings screen makes me feel like the UI library powering this isn't quite ready for prime time yet. I consider shortcuts and basic text handling like ctrl+a to select all text in a textbox to be basic features for any UI toolkit; the lack of such ease of use features really makes the GUI toolkit feel less native than the Electron cruft that's overtaking our desktops.
As for the legality, the DMCA sucks but this client is definitely in violation of it. Breaking the TOS isn't necessarily illegal so the tool is fine to use (at the risk of getting your account banned) but development can be quite risky. Hopefully, Spotify takes an interest and uses (a fork of) this project to write a faster player for their desktop clients instead of cease-and-desisting it to hell.
How is it definitely in violation of the DMCA? (Not a lawyer and not a USA resident, would appreciate legal clarification)
I agree, although it looks like you only have to change a single line of code to make it work without a premium account. Might as well go all the way if you're already breaking the TOS anyway I guess.
Frankly, it's awesome. It's literally every single thing I dislike about Spotify fixed. There are no podcasts, I can search, there's no social senselessness anymore.. I'm thrilled.
The only problem I have is that eventually it just gobbles CPU. Having it open and doing nothing seems to take ~4% of my CPU, and while playing a constant 7.2%. Frankly, I assume this is decoding, but I haven't traced yet. Eventually it spun out of control and pegged one CPU at ~90%, which a quick restart fixed. All of this is to say it's an incredible project - I'm not going back to the old client.
My project https://volt.fm has 100k+ users now and I'm really struggling with the Spotify API.
Then if they go over their allocated amount of calls, or they have been a user for X days/weeks/months, you give them a guided walkthrough on how to register their own API key.
I ended up writing a small library that does that locally cross-platform by using the metadata from the app.[3] The approach is probably not as robust as the API, but much faster and works well.
[1] https://github.com/SwagLyrics/SwagLyrics-For-Spotify
Makes me worry they’ll remove the feature from their app one day (they allude to it being a bit of a mess in the database) which would be the push I’d need to move away to either another service or a local collection only…
https://www.quora.com/How-is-JavaScript-used-within-the-Spot...
I remember when Spotify had Lyrics, which is an obvious choice of feature for a music service. It was off my a line or two, but it worked pretty well and I used it all the time. It was the best way to hear the music and see the lyrics that I knew of. Then, one day, I open the client and see that clicking the lyrics button showed a message that the lyrics feature was being enhanced and it'd be back soon. Then one day the button disappeared.
The only reason I use spottily over local music at this point is discovery, because they really do a great job at that.
But this is perfect:
- search for the name of an album, press enter and voilà it plays the album in order like I expect
- Playback takes 1% CPU and 0.1% of RAM
- vim-ish bindings
- It even works with physical play/pause/next... keys on my keyboard
Thank you!
It would give up control and it's an admission of failure; a slap in the face to some project lead, some designer, some exec, showing that their brilliant ideas were not in fact the superior option for everyone forevermore.
Either of those are unacceptable enough to lock the system down. But both? Never in a million years.
"Shareware is coming back, baby."
This is quite amusing. Further down:
"How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Shareware sometimes used to provide a way to check for updates, and sometimes allowed for this to be done automatically. But it generally did not try to make network connections without any permission from the user.
Shareware often used to provide contact information for the author so that users could show their appreciation. Authors invited voluntary feedback.
Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Anyway, his answer is:
"Set the environment variable RIPCORD_ALLOW_UPDATES=0"
How about starting the program while offline, i.e., network interface down.
Lots of shareware did and does that. It's normal. It's just an update check. It doesn't self-update. It doesn't transmit any information. No logs are collected. It just displays a "update is available" message if it finds that an update is available, with a link to the website to download the new version.
> Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Ripcord doesn't send any information about the client when it checks for updates. No information is logged on the server. It just fetches from this URL: https://cancel.fm/ripcord/updates/v1
Ripcord does not have any kind of telemetry or analysis system in it. It doesn't even report which OS you're using to the static file HTTP server — the update info URL returns the information for every OS at once.
> How about starting the program while offline, i.e., network interface down.
It works fine if you do that.
> "How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
This is provided as a way for users who extra paranoid to turn it off outside of using the normal preferences in Ripcord, since that requires launching Ripcord at least once. It's not the only way to do it. (It'a also useful for package managers on Linux who don't want "update is available" notifications to show up for their users.)
The normal preferences window in Ripcord has a clearly labeled checkbox on the first page for turning update checking off or on. I don't know what alternative there is. If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions. I don't know any software that does this.
What evidence do you have to support this idea? Is there somewhere we can view the feedback from this majority of users who believe they are being "tricked" into using "outdated" versions. I have observed that developers are the ones who are desperate to push "updates", to automatically install new code on the user's computer with no user interaction required. Users who bother to give feedback about software often complain about newer versions being not as good as the old ones. They often question the nature of supposed "improvements".
One of the things some shareware used to do, and software "installers" used to do in general, was to ask the user a series of questions to configure the settings before the first run of the program. I am not suggesting that I prefer that approach, but the idea that someone would purport to believe that setting automatic update checks by default and acceptance of ongoing remotely controlled software installation by default is "the norm" just shows how today's software authors make assumptions, and indeed engage in "trickery" through manipulation of defaults via "dark patterns", that software authors in the past generally did not make.
Thats why a reference to "shareware is coming back" is, IMO, quite funny. Today we have someone claiming he does not consider having an option off by default, and letting the user make the choice, as an alternative: "I do not know what alternative there is." The alternative is to let users turn things on instead of forcing them to turn things off. The "opt out" idea is an "alternative", one adopted by online advertising and the reason the web is such a mess. "Opt out" settings have a purpose and that purpose is not primarily for the users' benefit.
appreciate the work here.
Would be such a shame to put in all this work only for Spotify to kill it.
It's certainly against the ToS and probably illegal in some jurisdictions
The reason Electron is popular is because you can have a single codebase for ALL the targets.
Spotify even has a pretty detailed post on this:
https://engineering.atspotify.com/2021/04/07/building-the-fu...
Anecdata: I have used this functionality literally once in ~5 years. Safe to retire it and build a real client. I suspect most people don't use the browser.
These apps are identical to native. Not one person could tell you the difference. The complaints about speed are nonsense, too. People don't benchmark apps. They use them! These Electron and other web-wrapper apps are absolutely the future of all client-side app development.
If native apps are the railroad, web apps (w/ or without a wrapper, makes no difference), are the airplane.
BTW, there are many complaints about the Spotify UI, but does anyone ever complain that it's a web-based UI? Who has ever said, "Wow, I like Spotify but, ya know, it's got a UI built with HTML and CSS and JS, so I don't wanna use it."
That's not real. Proprietary app wrappers are proprietary because the companies that make them benefit from lockdown. They will always promote their locked-down platforms, and many enterprises have millions of dollars of sunk costs in these siloed application environments. The way out of prison is through web-based apps that run anywhere without the user even knowing or caring how that happens.
My pet complaint is Google Chat, which is now a web app or a PWA. Seriously, I don't believe that Google can't afford to have three Mac developers assigned to Chat and create an awesome native application, rather than shipping that piece of junk PWA. Similarly I don't buy that Slack, Facebook and Microsoft can't hire or train the most bad-ass Mac or Windows developers to work on native versions of their products.
I remember seeing some demos of the UI library Druid in the past but I didn’t realize it was at the stage where complete applications like this could be built.
Is there any plans for iOS support?
Didn't know Druid was even at this stage yet so that's nice to see. It's definitely living up to the goal of 60fps smooth resizing.
However, on mobile it is a completely different story. The Spotify app requires so many resources that it takes forever to start (like a minute) and sometimes even causes my phone to reboot. For something like a MP3 player that is hilarious...
Does someone know if there is a good alternative mobile app?
Thus, rather than reinvent the GUI adapter wheel for each and every programming language, let's form a dynamic GUI markup standard based on existing open-source kits to avoid starting from scratch (Typically Tk, Qt, or WinForms. WinForm's base is OSS, believe it or not.)
Then languages can read and write markup (XML or JSON text) to have GUI's instead of glue on some screwy binary addon.
``` Compiling sized-chunks v0.6.5 error[E0658]: `if` is not allowed in a `const fn` --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:119:5 | 119 | / if element_size == 0 { 120 | | usize::MAX 121 | | } else if element_align <= container_align && host_size > header_size { 122 | | (host_size - header_size) / element_size 123 | | } else { 124 | | 0 // larger alignment can't be guaranteed, so it'd be unsafe to store any elements 125 | | } | |_____^ | = note: for more information, see https://github.com/rust-lang/rust/issues/49146
error[E0658]: `if` is not allowed in a `const fn` --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:121:12 | 121 | } else if element_align <= container_align && host_size > header_size { | ____________^ 122 | | (host_size - header_size) / element_size 123 | | } else { 124 | | 0 // larger alignment can't be guaranteed, so it'd be unsafe to store any elements 125 | | } | |_____^ | = note: for more information, see https://github.com/rust-lang/rust/issues/49146
error[E0599]: no associated item named `MAX` found for type `usize` in the current scope --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:120:16 | 120 | usize::MAX | ^^^ associated item not found in `usize` | help: you are looking for the module in `std`, not the primitive type | 120 | std::usize::MAX |
error: aborting due to 3 previous errors
Some errors have detailed explanations: E0599, E0658. For more information about an error, try `rustc --explain E0599`. error: could not compile `sized-chunks`. warning: build failed, waiting for other jobs to finish... error: build failed ```
In the future, one will be able to give a nice error when this happen (https://github.com/rust-lang/rust/issues/65262) But now it's true that it can be hard to know what the problem is.
Any rust devs have second? I think its the miniaudio dependency that's broken.
Does Github Workflow currently support M1 (arm 64 based). Am I missing something?
[0] https://github.com/jpochyla/psst/issues/87#issuecomment-9003...
Would be nice to have a growing ecosystem of high-performance, rock solid, cross-platform native app frameworks.
The part I don't understand is how do you find the motivation to write such time taking things? Outside work? At work? I guess you don't know whether this would be profitable or not, how do you stay motivated?
Does this use system UI control bindings? What makes a UI "native"?
I also suspect that this one doesn't destroy ssds by running OPTIMIZE or whatnot on its internal sqlite, unlike the official client?
I wish there is one for apple music.. Since switching to apply music it has been a pain to open iTunes in my PC.
edit: it does[0]!
Is 20fps fast enough for a video game? 30? 60? 90? 120? 240?
It’s subjective and relative. That doesn’t mean it isn’t important or meaningful.