Psst: Fast Spotify client with native GUI, without Electron, built in Rust

mythz 2021-08-17 03:47:35 +0000 UTC [ - ]

What's funny about having to rely on unauthorized clones to provide a fast native UX was that Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.

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.

ClawsOnPaws 2021-08-17 07:59:21 +0000 UTC [ - ]

Something that Chromium apps do give you however, for free for the most part, is accessibility. I just tried the GUI version of this client and was not surprised to find out that I could not use it. The new Spotify UI released a few months ago is the most accessible Spotify has ever been. Landmarks, clear labels, headings, and even aria-trickery to automatically announce things using my screen reader. I remember being very frustrated with the old UI's to the point where I chose another service just because it was more accessible, even if it didn't have a desktop app. YouTube Music and Deezer had much better UI's from the get go. At this point, I'm almost happy to see an Electron app. It doesn't guarantee accessibility, but the likelyhood is so, so, so much higher than any modern cross-platform UI framework. I'd almost go as far as to not call these UI's native. Because if they were, if they used native controls, the accessibility would be there. The OS vendors spend a lot of time to make them usable and consistent. Sadly, these UI frameworks don't, or can't. Sure, psst has a CLI, but I only get panics. I can't do -h to find out what I can do with it, I can only call it with a spotify URL and get it to play and exit once it's done. It feels like the cli was included as a sort of testing tool to check the underlying libs and code, and not as a usable version of the app itself - but it's still very early in development so the GUI might be the same. I can't tell.

csmpltn 2021-08-17 12:17:34 +0000 UTC [ - ]

Here's how these things usually go: first, you start small. You build something you can show other people. You try to generate some traction and build interest around your idea, validating it at a very small scale (friends, family, "Show HN", etc). You gradually expand that cycle of people. You get into a routine of iterating on improvements, adding new features, and gradually scaling things up. You probably get a couple of people to join you on that journey, because the more popular your product becomes - the more asks you'll be getting, and the more work it takes to scale it out. Rinse and repeat.

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.

mythz 2021-08-17 12:46:44 +0000 UTC [ - ]

I upvoted you to combat your downvote because your initial paragraphs was a very reasonable description of the journey of a lot of hobby projects and its unreasonable to expect alpha apps (built using a GUI FX in active development) racing to get out an MVP is going to have accessibility nailed out of the gate.

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.

ericbarrett 2021-08-17 13:17:48 +0000 UTC [ - ]

> 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

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?

mwcampbell 2021-08-17 13:22:56 +0000 UTC [ - ]

Apple: https://machinelearning.apple.com/research/creating-accessib...

dailyanchovy 2021-08-17 12:49:35 +0000 UTC [ - ]

I read your comment and agree. Without thinking it through, it seems that if every program provided a full CLI and a sitemap like file, then a screenreader should be able to integrate with said program.

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).

disabled 2021-08-17 17:35:51 +0000 UTC [ - ]

> 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

eloisius 2021-08-17 13:29:22 +0000 UTC [ - ]

This is an interesting idea for app-interoperability in general. It brings to mind Apple Automator, which I have no idea how works, but can sometimes be used to make Apps interoperate. It'd be pretty cool if every app did have a sitemap-like API spec that that mapped out the core of the app, and the UI sat on top of that.

csmpltn 2021-08-17 15:20:17 +0000 UTC [ - ]

Exactly.

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.

autoexec 2021-08-18 02:24:29 +0000 UTC [ - ]

If it's done right and standardized it'd be worth it for everybody since even people who don't need accessibility features could then create their own interfaces to the programs they use customized for their preferences and workflow

mitemte 2021-08-17 13:58:04 +0000 UTC [ - ]

A lot of the UI scripting on macOS is accomplished via accessibility APIs. If you’re interested, check out Accessibility Inspector[0], which ships with Xcode. You can inspect macOS applications in a similar, albeit much more limited way to a web browser’s interactive inspect element function.

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...

jcelerier 2021-08-17 22:32:33 +0000 UTC [ - ]

These APIs have existed for like three or more decades for desktop apps. That's partly why most desktop UI toolkits are based on tree of widgets: Mac and Windows's native accessibility APIs expect a tree

mwcampbell 2021-08-18 00:14:41 +0000 UTC [ - ]

FWIW, the oldest accessibility API was Microsoft Active Accessibility (MSAA), which was added to Windows 95 in a service pack in 1997. Classic MacOS never had an accessibility API; the Outspoken screen reader for that OS had to rely exclusively on ugly hacks (e.g. patching Toolbox functions). OS X introduced accessibility APIs for Carbon and Cocoa in an early version; not sure which one. Unix-based desktop environments got an accessibility API, AT-SPI (thank you Sun), in the early 2000s.

jcelerier 2021-08-18 08:29:53 +0000 UTC [ - ]

well TIL, I believed accessibility to already be there by the late 80s, in NeXT workstations and the first windows versions but it looks like that was not the case.

jpochyla 2021-08-17 08:43:55 +0000 UTC [ - ]

Hi, the author here. Psst is definitely in alpha, and the CLI is indeed just an example (it's what I was using to test the core mechanisms). I'm sorry the accessibility is so bad now, but Druid, the GUI library, takes it very seriously -- which is not very common in custom GUI frameworks. So, fingers crossed, it should get better soon.

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

[2] https://github.com/Rigellute/spotify-tui

[3] https://github.com/xou816/spot

miki123211 2021-08-17 08:39:29 +0000 UTC [ - ]

This is, unfortunately, a very common occurrence when GUI frameworks are concerned. For some reason, framework authors like to mislead and say that their framework is native, when it looks native but actually isn't. WX and SWT are the two notable exceptions here, they do indeed use native OS controls.

If you want to use a native GUI framework because of accessibility, check if it's as native as it claims.

OOPMan 2021-08-17 11:15:24 +0000 UTC [ - ]

You're comparing a person's side project to years of work on this in Chromium.

Seems rather like comparing someone's homemade bottle rocket to a Saturn V...

blowski 2021-08-17 11:47:15 +0000 UTC [ - ]

Your analogy doesn't make sense since I'm paying the same amount either way - so of course I'll choose the 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.

bovermyer 2021-08-17 11:53:03 +0000 UTC [ - ]

To be fair, accessibility is not listed on psst's roadmap at all yet.

I'm intrigued by this client, but I'll wait for a beta before trying it out.

dalmo3 2021-08-17 11:54:15 +0000 UTC [ - ]

Fun fact about Spotify web's accessibility: Alt+left/right are used to both navigate pages AND go back/skip a song. It is truly an abomination.

jatone 2021-08-17 14:09:30 +0000 UTC [ - ]

I honestly think we need to rethink accessibility from the ground up. modern advances in OCR and machine learning should allow us to do accessibility entirely from the GPU output.

it'd take awhile to perfect but i think it'd ease the burden tremendously for software developers and those who need accessibility.

mwcampbell 2021-08-17 15:28:13 +0000 UTC [ - ]

> it'd take awhile to perfect

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.

[1]: https://github.com/AccessKit/accesskit

blowski 2021-08-17 15:04:51 +0000 UTC [ - ]

You're onto something here. As long as accessibility is the job of the developer, software accessibility will reamin "on the roadmap" for many projects. There's simply too much to learn, too many battles to fight, and accessibility tends to offer to little obvious and immediate value compared to other priorities.

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.

ap-andersson 2021-08-17 05:50:03 +0000 UTC [ - ]

If you are interested in their story how the original client and architecture came to be and then how it changed to what it is today they have a podcast you can listen to: "Spotify: A Product Story" - https://pca.st/cbo7khrm

Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we...

vsnf 2021-08-17 07:08:18 +0000 UTC [ - ]

Just finished listening to this, thanks for the recommendation.

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.

scns 2021-08-17 08:09:39 +0000 UTC [ - ]

I watched a documentary they made about themselves... Only went there because two band colleagues ask me if i wanna come. In one scene he stands in front of a 4mx4m painting he is going to auction off. Some colors smeared over black foundation, ugly as hell if you'd ask for my irrelevant opinion. Sipping a drink he says: "Sometimes i stand here and ask myself: 'What did the artist think when he made it?'"

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.

toxik 2021-08-17 08:21:05 +0000 UTC [ - ]

Ulrich took it personally, thinking it was somebody stealing from him. I'm convinced Metallica would have faded to irrelevance far earlier if people hadn't downloaded their music.

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.

scns 2021-08-17 10:16:28 +0000 UTC [ - ]

Studies showed that people who download more, spend more money on music than those who don't.

drdec 2021-08-17 10:27:39 +0000 UTC [ - ]

It strikes me as totally reasonable and predictable that the people who spend the most money on music would be the people who download the most music.

sincerely 2021-08-17 21:29:58 +0000 UTC [ - ]

>I'm convinced Metallica would have faded to irrelevance far earlier if people hadn't downloaded their music.

No offense but this is wishful thinking, they're one of the best selling bands of all time.

brianzelip 2021-08-17 14:40:10 +0000 UTC [ - ]

> 20 years on they still don't get it

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.

inter_netuser 2021-08-17 07:19:51 +0000 UTC [ - ]

Money tends to change people.

Nevermark 2021-08-17 09:15:24 +0000 UTC [ - ]

Anything that qualitatively changes what survival means to us, will change someone. For good, bad, indifferent. For most people a combination.

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.

inter_netuser 2021-08-17 09:50:05 +0000 UTC [ - ]

I think this is by far the best quantification of this phenomena.

Did you read about the "what survival means to us" somewhere, or was that just convos with friends?

mythz 2021-08-17 06:05:07 +0000 UTC [ - ]

Thanks! It's great to read the backstory of how the original Spotify client came to be:

> "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.

fps_doug 2021-08-17 08:37:35 +0000 UTC [ - ]

Yes, I miss this so much, I actually stopped using Spotify about 6 years ago. This might be nerdy, but the feeling of instant playback was just great.

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...

mikeyjk 2021-08-17 12:16:08 +0000 UTC [ - ]

I'm really not seeing the features raining down on the electron client anyway. Seems like it has been the same clunky experience as always.

disgruntledphd2 2021-08-17 17:05:29 +0000 UTC [ - ]

It's probably easier for various teams not to break things, and it provides a more widely known environment (the browser essentially) to ensure that new hires can be pretty productive.

I definitely miss native apps, but I understand why they're less common now.

jayjader 2021-08-17 10:25:03 +0000 UTC [ - ]

> 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 …

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.

MasterYoda 2021-08-17 09:12:38 +0000 UTC [ - ]

I guess much that did the first client light weight was because it was developed by Ludvig Strigeus. He devloped the very light and popular uTorrent client. Very early for Spotify they bought uTorrent AB, not for the uTorrent client, but because they wanted his skills and he was the person that developed the first Spotify client. A few month later Spotify sold the uTorrent client to Torrent Inc.

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.

zanderz 2021-08-17 19:17:19 +0000 UTC [ - ]

The early versions of uTorrent were on the order of 80KB in size, it really was amazing. BitTorrent the company re-skinned it as BitTorrent the software and offered both versions for a few years, differing only by icons and colors, but fans held to strong opinions about which was technically better. It is true that the code was hard to maintain and extend though.

judge2020 2021-08-17 04:11:07 +0000 UTC [ - ]

The problem (or rather value proposition) is that the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability. Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app, especially given they just want to listen to music, which the app does just fine. If people specifically don't like the social features, they'll be mad at the decision to implement those social features instead of 'what they used for the tech stack' since ultimately Spotify could have developed the same features in a native app with just a few extra weeks of sprint, if that.

westoncb 2021-08-17 04:41:05 +0000 UTC [ - ]

The outrage around these supposedly egregious performance issues is more understandable when you consider that developers who spend a lot of time tuning performance in their work would naturally develop a 'selective attention bias,' magnifying the significance of what to others are negligible if not imperceptible differences.

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.

blub 2021-08-17 06:09:07 +0000 UTC [ - ]

Judging by the dismissals of performance concerns seen in typical online discussion threads, I'm not sure that developers working on performance tuning in any meaningful way still post online.

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.

yomly 2021-08-17 09:42:34 +0000 UTC [ - ]

I'm starting to come to the conclusion that performance is much more important than we realise.

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.

dimmke 2021-08-17 14:00:56 +0000 UTC [ - ]

I can only share my experience. I used Spotify for the first time in 2011. It completely defied what I thought was possible with music streaming.

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.

Cederfjard 2021-08-17 08:25:42 +0000 UTC [ - ]

In terms of running a business, surely user satisfaction and business goals are much more directly relevant than performance in and of itself, except insofar it contributes to the former? So it's not surprising to me that you'd see a lot of that sentiment on a forum hosted by a startup accelerator, nor that it's what for-profit organizations optimize for. That doesn't mean that people can't also have an appreciation for well-performing or technically brilliant code.

westoncb 2021-08-17 07:59:36 +0000 UTC [ - ]

> I'm not sure that developers working on performance tuning in any meaningful way still post online

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.

runawaybottle 2021-08-17 05:49:35 +0000 UTC [ - ]

The imperceptible becomes perceptible when you make it noticeably more perceptible. A better point would be to not even show the user what they are missing out on, because then that will be the standard. The danger of the latter is it is very likely your competitor(s) will show it to users anyway.

I’d let the guy that tinkers on performance keep tinkering.

westoncb 2021-08-17 06:36:12 +0000 UTC [ - ]

Absolutely. Anyone building on top of performance critical systems should have a healthy bit of gratitude for the engineers who were interested to specialize there.

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.

TeMPOraL 2021-08-17 07:05:59 +0000 UTC [ - ]

There's a huge difference in the performance levels you're talking about, which creates a risk of unintentional equivocation.

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)

westoncb 2021-08-17 07:28:03 +0000 UTC [ - ]

A couple things 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.

jcelerier 2021-08-17 08:24:44 +0000 UTC [ - ]

> and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack

https://cancel.fm/ripcord/

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

with a dozen slack workspaces open and ~20 tabs

TeMPOraL 2021-08-17 09:21:56 +0000 UTC [ - ]

Ripcord is lovely, I'm a paying customer[0] and highly recommend it. I used it for years with Slack, and have only good things to say about the experience. It's also a living proof that all the bloat in Slack and similar apps is absolutely not necessary.

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".

antihero 2021-08-17 17:46:55 +0000 UTC [ - ]

> It's only a matter of time before Slack and Discord start to ban people using alternate clients

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...

void_mint 2021-08-17 20:13:09 +0000 UTC [ - ]

I'd wager those devs will be told to use the official Slack client.

antihero 2021-08-18 08:09:18 +0000 UTC [ - ]

So there’s no loss to using ripcord in the mean time.

TeMPOraL 2021-08-18 09:15:18 +0000 UTC [ - ]

There isn't, as long as you're willing to tolerate the risk of getting your account banned for blatant ToS violation. Companies like Slack tend to ban first, ask question never, and good luck reaching customer support if you aren't a paying business customer.

(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.)

westoncb 2021-08-17 09:48:31 +0000 UTC [ - ]

That's pretty awesome, hadn't heard of it before.

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.

MereInterest 2021-08-17 12:11:49 +0000 UTC [ - ]

> apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)

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.

TeMPOraL 2021-08-17 10:26:55 +0000 UTC [ - ]

You raise very good points, that together make the picture even more complex :).

> 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.

Const-me 2021-08-19 10:15:21 +0000 UTC [ - ]

Thanks so much for that link!

They got my €18 immediately after I managed to change font sizes and typefaces to the ones I like.

TeMPOraL 2021-08-17 09:17:28 +0000 UTC [ - ]

> First is that this is fundamentally a question of tradeoffs, which means a single axis diagram like this is fundamentally misleading.

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.

westoncb 2021-08-17 10:15:40 +0000 UTC [ - ]

> ... the cost of making an app in a typical startup has zero relation to what the users pay ...

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.

TeMPOraL 2021-08-17 10:31:10 +0000 UTC [ - ]

> 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.

bavell 2021-08-17 13:51:58 +0000 UTC [ - ]

Great thread and discussion. IMO, there's some overhead to using a framework but it's marginal compared to the data model/flow/architecture you've chosen to implement. I don't think reaching for a framework kills snappiness nearly as quickly as reaching for a convenient but inefficient data model.

westoncb 2021-08-17 22:43:56 +0000 UTC [ - ]

> 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)

scns 2021-08-17 12:03:16 +0000 UTC [ - ]

You can pick a modern framework that cares about performance, eg Svelte or Solid.

SilverRed 2021-08-17 06:01:09 +0000 UTC [ - ]

None of the competitors care about making the ui 20ms faster. Apple music just flat out didn't work for me, totally broken for the web version and not even an electron app.

Spotify is already better than the alternatives.

snek_case 2021-08-17 05:36:05 +0000 UTC [ - ]

The Spotify website and phone apps don't just have performance issues, they have awful bugs that have been left unfixed for months/years. When streaming to a Chromecast, the UI quickly gets out of sync, randomly disconnects, etc. I'm resorting to using a bluetooth receiver connected to my amplifier because that works better. The recommendations are also getting worse IMO, though that's more subjective, hard to quantify, but the amount of time I spend using Spotify has gone down a lot, just because I'm not discovering enough interesting tracks anymore.

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.

ouchjars 2021-08-17 07:24:48 +0000 UTC [ - ]

> The recommendations are also getting worse IMO

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)".

srmarm 2021-08-17 11:38:10 +0000 UTC [ - ]

During the first lockdown my girlfriend and I would put music videos on youtube on a Friday night. No matter where we started we'd end up funnelled to 'Len - Steal my Sunshine' and then a predictable list of likable but before long thoroughly overplayed songs.

It became a bit of an in-joke with us but yeah the youtube recommendation algorithm is dreadful.

Shacklz 2021-08-17 07:24:09 +0000 UTC [ - ]

> Most people don't care that it takes an extra 10-100 milliseconds

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.

blub 2021-08-17 06:34:07 +0000 UTC [ - ]

Generic statements such as "most people don't care [...] extra 10-100ms for the UI" need to be supported by evidence, especially since those 100ms are added to existing latency and 100ms is considered the threshold where operations feel instantaneous [1].

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

TeMPOraL 2021-08-17 07:15:32 +0000 UTC [ - ]

Yup. 100ms may be working as "instantaneous" in isolation. If you start chaining interactions, it absolutely isn't.

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.

open-source-ux 2021-08-17 06:41:23 +0000 UTC [ - ]

Users do notice speed issues in apps and websites.

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...

jack_pp 2021-08-17 05:37:29 +0000 UTC [ - ]

Spotify's Android app is of very poor quality.

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.

vxNsr 2021-08-17 06:26:49 +0000 UTC [ - ]

You know what’s fascinating, I find these same things so annoying and also use it less because of that… but crucially I still pay for it. So in essence I’m their best customer. I pay and I don’t use it. All streaming platforms operate like gyms, they want the most paying customers who forget they even pay for the service and don’t really use it.

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.

jack_pp 2021-08-17 07:26:07 +0000 UTC [ - ]

Yeah i still pay for it too even though I mostly use youtube music now which is much better in my opinion. I'll go ahead and cancel it because of this thread.

gmassman 2021-08-17 05:45:06 +0000 UTC [ - ]

It's true. I'm sad to see how far downhill Spotify's UX has slid on all fronts, but especially native. They are also suffering significantly on the customer service end. I asked for a data dump months ago and haven't gotten anything more than an automated "we're working on it" in May.

bradstewart 2021-08-17 14:35:59 +0000 UTC [ - ]

The most irritating thing to me is the constant shuffling of the menu. I'm sure they're running some sort of A/B test, but every update seems to randomly moving the menus around for no apparent reason.

ryosuke 2021-08-17 09:37:43 +0000 UTC [ - ]

I've had the same exact experience. You lose connection once and there's no way to get back to your music without restarting the app. The iOS version is better but still not amazing.

rightbyte 2021-08-17 09:55:48 +0000 UTC [ - ]

> Search is just so basic, you can not have any typos whatsoever.

I'd rather have queries for exactly what I type then Google's irrelevant "never gonna let you down" answers.

jamil7 2021-08-17 06:47:23 +0000 UTC [ - ]

The iOS client isn’t much better, it seems as if they’ve given up on decent offline support all together.

systemvoltage 2021-08-17 05:16:27 +0000 UTC [ - ]

If we followed similar arguments about hardware, we wouldn't have Apple today. The entire premise of Apple's hardware is that it is beautiful, well designed, with attention to details even in places where the user would never interact (motherboard layout and finish).

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.

imachine1980_ 2021-08-17 05:31:31 +0000 UTC [ - ]

trashcan, butterfly keyboard, bending displays, less intuitive user interface in post of similar style whit ios?

systemvoltage 2021-08-17 06:00:12 +0000 UTC [ - ]

Touche, we need some finest software equivalent of Rolls Royces. Luxury software industry doesn't exist, I wish it did. I'd gladly pay 2x for a piece of software that is well crafted.

panda88888 2021-08-17 06:09:18 +0000 UTC [ - ]

Rolls Royces equivalent software would cost at least 10x if the cost ratio is analogous to the vehicle prices.

And they would expect you to have an assistant to work the software for you. ;P

inter_netuser 2021-08-17 07:27:13 +0000 UTC [ - ]

Crudely put, luxury market is iOS.

A lot more “luxury” apps compared to android, and priced accordingly.

e.g. $50 for a todo list app, etc.

ipv6ipv4 2021-08-17 06:00:26 +0000 UTC [ - ]

I disagree with the assessment that an extra 10-100ms doesn’t matter.

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.

inter_netuser 2021-08-17 07:24:27 +0000 UTC [ - ]

Arguing app performance doesn’t matter sounds like extra polish and better fitting parts without gaps or creaks on luxury cars just do not matter.

Yes, rusty creaking lambos are the best. The rustier and creakier the better.

laurent92 2021-08-17 07:19:53 +0000 UTC [ - ]

This. 10ms matters.

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.

jgb1984 2021-08-17 07:12:45 +0000 UTC [ - ]

Myself and every (non-technical) user of Spotify I know complains about the horrible mobile and desktop apps. The android one is an absolute dog, even on mid to high end smartphones.

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.

TeMPOraL 2021-08-17 09:41:10 +0000 UTC [ - ]

> The first alternative to show up with an equally vast catalog (...)

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".

jgb1984 2021-08-17 10:09:50 +0000 UTC [ - ]

How many devs do they employ? How big is their cashflow? And still they fail to develop a glorified winamp that's not an exercise in frustration to use? The thing is bloated, slow and riddled with bugs that go years unfixed. Why take the risk of offering such a crap experience, just because you can afford it? Hubris? Incompetence? Both?

TeMPOraL 2021-08-17 10:28:53 +0000 UTC [ - ]

> Why take the risk of offering such a crap experience, just because you can afford it? Hubris? Incompetence? Both?

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.

hfsh 2021-08-17 11:02:51 +0000 UTC [ - ]

>This is exactly why Spotify can decay so badly and still succeed.

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.

thesuitonym 2021-08-17 14:52:42 +0000 UTC [ - ]

> Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app

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.

shp0ngle 2021-08-17 07:22:23 +0000 UTC [ - ]

I mean

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.

legulere 2021-08-17 05:35:14 +0000 UTC [ - ]

The problem is that the people with decision power over software are usually not the ones who actually use it and latency issues are more of a subconscious thing. Slow programs just feel less good to use until they reach a pretty high threshold where it feels unbearable.

For speed good enough is just very far away from good (factor 10-1000)

spoonjim 2021-08-17 05:43:38 +0000 UTC [ - ]

The stability of Spotify is awful, I use Spotify to entertain my kids in the daytime and put them to bed at night so I’m a heavy user. Connecting to external speakers through Connect is very unstable.

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.

bigfudge 2021-08-17 07:06:36 +0000 UTC [ - ]

Transferring playlists is pretty easy. There’s a web app that connnects to most services and moves tracks between them

handrous 2021-08-17 14:52:10 +0000 UTC [ - ]

My wife doesn't know WTF Electron is, but definitely notices when a pile of Electron "apps" are slowing her computer to a crawl.

nicoburns 2021-08-17 09:21:27 +0000 UTC [ - ]

The problem is it's only 10-100 milliseconds when my computer is otherwise unloaded. When my machine is under high load that turns into several seconds.

ohthehugemanate 2021-08-17 10:00:24 +0000 UTC [ - ]

> the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability.

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.

2021-08-17 23:50:34 +0000 UTC [ - ]

specialist 2021-08-17 05:45:08 +0000 UTC [ - ]

Probably. But I'd like to think fit & finish makes an app more sticky.

southerntofu 2021-08-17 08:19:31 +0000 UTC [ - ]

> Most people don't care that it takes an extra 10-100 milliseconds for the UI

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.

jcelerier 2021-08-17 08:26:49 +0000 UTC [ - ]

I don't understand in which universe 100ms latency is fine. It's an insane amount of time. Hell, when you're used to 140+hz refresh rate, apps that have hardcoded a 60fps GUI refresh loop, so 16ms between two frames, are terribly obvious (and really feel like a pain to use)

southerntofu 2021-08-17 08:58:52 +0000 UTC [ - ]

It's not good, but it's not the worst. Of course i prefer applications which feel instantaneous, but these are hard to come by nowadays. I don't have strong opinions for 140Hz refresh rate, because i don't think i ever had monitors with more than 60Hz.

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.

jcelerier 2021-08-17 09:54:21 +0000 UTC [ - ]

> Many modern JS/Electron apps

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

gsich 2021-08-17 11:04:33 +0000 UTC [ - ]

They do care if they have a comparison.

tjbiddle 2021-08-17 05:34:57 +0000 UTC [ - ]

Spotify has certainly degraded over time. My latest frustration: Controlling external devices via my computer or phone.

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.

miki123211 2021-08-17 08:34:16 +0000 UTC [ - ]

One of the big (for me) issues with the old, native client was accessibility, or the complete lack of it.

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.

amerine 2021-08-17 04:33:51 +0000 UTC [ - ]

Rdio's app was stunning compared to Spotify imo.

montag 2021-08-17 06:01:00 +0000 UTC [ - ]

Rdio was great, but it could not compete with Spotify’s performance. The funny thing is, those performance advantages (p2p streaming and a native C++ desktop client) are now ancient history. Rdio was ahead of its time.

djhworld 2021-08-17 08:20:22 +0000 UTC [ - ]

Additionally Spotify's original app came out at the time iTunes was (is?) a big bloated mess, especially on Windows.

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.

matheusmoreira 2021-08-17 16:27:51 +0000 UTC [ - ]

> unauthorized clones

Are we really living in a world where we need "authorization" to replace some corporation's software with our own?

cronix 2021-08-17 19:28:35 +0000 UTC [ - ]

> Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.

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.

https://www.youtube.com/watch?v=MKJjLwMUPJI

stayfrosty420 2021-08-17 09:17:48 +0000 UTC [ - ]

Spotify removed a lot of their great social features from that time, as well as Spotify apps. Almost everything about Spotify has gotten much worse except the reccomendation algorithm.

slumpt_ 2021-08-17 04:57:17 +0000 UTC [ - ]

You can build snappy UIs with Electron. It’s easy to conflate organizational bloat’s consequences with something intrinsic to Electron.

Edit:

Upset downvoters care to elaborate? Or just huffing into the void?

ducktective 2021-08-17 05:54:49 +0000 UTC [ - ]

Didn't downvote, but can you name a couple of Electron apps that are sna...,hell,.. not sluggish?

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?

yboris 2021-08-17 15:13:39 +0000 UTC [ - ]

I built an Electron app Video Hub App and it's fast:

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

kristiandupont 2021-08-17 06:35:46 +0000 UTC [ - ]

In my experience, my VSCode setup responds just as fast as my fully extended VIM does.

skydhash 2021-08-19 12:08:20 +0000 UTC [ - ]

I barely have released the return key after typing mvim and the macvim window is already there. Even Sublime is not that fast.

inter_netuser 2021-08-17 07:29:04 +0000 UTC [ - ]

Are you remoting into your vim on a satellite link or some really far away box somewhere?

I see no other rational explanation here

jamil7 2021-08-17 06:53:14 +0000 UTC [ - ]

Somethings wrong with your vim setup then.

iCarrot 2021-08-17 06:17:06 +0000 UTC [ - ]

Aside from the initial load that all Electron apps suffer from, Insomnia feels pretty snappy to me. Granted, I only have a few dozens of API that load 20KB of JSON max.

https://insomnia.rest/

vladvasiliu 2021-08-17 07:34:45 +0000 UTC [ - ]

I love Insomnia and usually recommend it to others.

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.

mythz 2021-08-17 05:48:37 +0000 UTC [ - ]

Maybe try elaborating yourself? The constant criticism of Electron Apps is that they're bloated and slow, you're claiming otherwise but missed the part providing any presumption of evidence to the contrary.

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.

Kiro 2021-08-17 06:32:07 +0000 UTC [ - ]

Electron adds no more overhead than Chrome does. Any snappy web app can be packaged as an Electron app and be equally snappy. So if there are no snappy Electron apps it's because of the web, not Electron.

TeMPOraL 2021-08-17 07:18:10 +0000 UTC [ - ]

> So if there are no snappy Electron apps it's because of the web, not Electron.

That is, indeed, the argument, except without the "if" part.

slumpt_ 2021-08-17 05:58:56 +0000 UTC [ - ]

The web is filled with bloated and slow web applications. This is nothing new. Electron is taking the fall for existing on a popular platform that lots of fast moving companies are using and unfortunately gumming up with feature creep and poor architectural design.

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.

mythz 2021-08-17 06:12:14 +0000 UTC [ - ]

Right, so still no evidence despite continuing to claim otherwise. Lets start off easy, what's the best example of a publicly downloadable Electron App that has the snappiest UX?

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?

slumpt_ 2021-08-17 06:28:18 +0000 UTC [ - ]

No evidence? I have no obligation to hold your hand.

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.

mythz 2021-08-17 07:06:56 +0000 UTC [ - ]

If you make a ludicrous claim the onus is on you to provide some resemblance of evidence to back it up, the extent and reasons you go into avoid doing so is obvious and transparent.

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.

slumpt_ 2021-08-17 08:38:25 +0000 UTC [ - ]

You’re misrepresenting my argument.

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.

mythz 2021-08-17 09:13:07 +0000 UTC [ - ]

> I said that one CAN produce snappy Electron apps.

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.

slumpt_ 2021-08-17 15:01:31 +0000 UTC [ - ]

One needn’t exist for my claim to be true. It’s based on how the actual platform works and having built performant web sites. I would agree nearly every mainstream Electron implementation is a mess, but so is nearly every mainstream website. It’s rare companies deem it important to build that level of performance because by and large customers don’t give enough of a shit. Except Hackernews posters, that is.

mythz 2021-08-17 23:46:05 +0000 UTC [ - ]

> One needn’t exist for my claim to be true.

Which explains everything.

ducktective 2021-08-17 06:06:23 +0000 UTC [ - ]

It doesn't matter if that rotating loading indicator icon is rendered at 120hz or how fancy the boot animation is presenting latest commodities of the company shop...

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

slumpt_ 2021-08-17 06:09:18 +0000 UTC [ - ]

That’s not what I mean when I say 60 Hz. I’m referring to performance navigating about the app. There was a small startup latency to populate the store but it was smooth sailing after that. Even that you could probably optimize out today with a talented team given all the new PWA tech.

I will say though that I’ve yet to work anywhere else that held themselves to a comparable performance standard.

vxNsr 2021-08-17 06:31:45 +0000 UTC [ - ]

You claim electron apps can be fast but don’t give examples. Native apps are fast and there are many examples.

I have yet to use a fast electron app that didn’t hog ram.

slumpt_ 2021-08-17 15:07:44 +0000 UTC [ - ]

Yep. I’m not familiar with a lot of great web apps anymore. The web has gotten really lazy, these days.

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.

vxNsr 2021-08-17 18:57:38 +0000 UTC [ - ]

Anything is possible. No one here is arguing it’s absolutely impossible for an electron app to be fast. But as you said the amount of work it would take is simply not worth it… with a lot less effort you could make a much more performant native app, so it’s never gonna happen.

You’re being pedantic and are upset that you’re being called out.

slumpt_ 2021-08-17 21:00:34 +0000 UTC [ - ]

Hardly. I think it’s extremely worth the investment to make performant web applications. It’s the true vision of write once run everywhere. That a lot of naive leadership teams don’t understand or care to invest in that is a mistake - or perhaps a forced hand due to the lockout of web apps from the phone app ecosystem - not a demonstration of infallible analysis on the utility of the web platform.

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

neolog 2021-08-17 06:33:30 +0000 UTC [ - ]

https://pavelfatin.com/typing-with-pleasure/#editor-benchmar...

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.

blub 2021-08-17 06:19:00 +0000 UTC [ - ]

Web technologies are default-slow while native (except Java on Android) is typically default-fast. One needs to go out of their way to create a slow native app, even if it's of course possible.

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.

neolog 2021-08-17 06:28:15 +0000 UTC [ - ]

> native (except Java on Android) is typically default-fast

Is anything fast on Android? I have a 2017 Samsung and it's always been slow.

GekkePrutser 2021-08-17 08:30:01 +0000 UTC [ - ]

Upgrade :) I just upgraded from my Samsung S8 to a OnePlus 8 and the difference is amazing. Apps install in a second again instead of 20 and everything feels snappy.

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.

handrous 2021-08-17 19:02:34 +0000 UTC [ - ]

Off and on Android (and iOS) developer here: no, not really, unless you throw top-end hardware at it.

cjblomqvist 2021-08-17 05:31:29 +0000 UTC [ - ]

Up-voted for the same reason as the edit - I'd love to hear some fact based arguments why this comment should be down voted (why it's not possible to build performant applications with Electron)

zwaps 2021-08-17 06:42:19 +0000 UTC [ - ]

Op did not provide a single example of an Electron app that competes with native performance. When pushed, they became indignant and said that they have personally worked on several snappy Electron apps, which, however are secret. Also, there are apparently no other examples of Electron apps readily at hand.

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.

slumpt_ 2021-08-17 08:39:42 +0000 UTC [ - ]

It’s nothing to do with Electron specifically and everything to do with the web as a platform and the requisite work to make performant apps.

slumpt_ 2021-08-17 05:35:29 +0000 UTC [ - ]

It’s certainly an easy fall-person for their performance issues, but it seems just as reasonable to blame an ever-expanding feature set, including advertisements and all of the analytics to go with, along with a great deal of just… age? Spotify isn’t a young company anymore, and they’ve been maintaining their shop for long enough that the kitchen sink is undoubtedly strapped to their app by now.

rzzzt 2021-08-17 05:52:49 +0000 UTC [ - ]

Can it send e-mails?

huhtenberg 2021-08-17 16:52:59 +0000 UTC [ - ]

> started out as beautifully light, custom rendered native client

Very much expected - back then the main Spotify developer was Ludde, an author of another little marvel - uTorrent.

[1] https://en.wikipedia.org/wiki/Ludvig_Strigeus

jcelerier 2021-08-17 08:20:15 +0000 UTC [ - ]

> Our QT/C++ client had decent performance but was noticeably heavier than Spotify's.

Wasn't Spotify's client Qt too ?

mythz 2021-08-17 08:59:29 +0000 UTC [ - ]

The original Windows and Mac clients didn't use Qt, it appears the Linux version released after did. Here's what I found scouting quora:

> 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

jcelerier 2021-08-17 09:51:01 +0000 UTC [ - ]

TIL, I only ever used it on Linux and assumed it was the same everywhere

2021-08-17 08:39:48 +0000 UTC [ - ]

ilrwbwrkhv 2021-08-18 04:56:17 +0000 UTC [ - ]

Even on the iPad app they don't follow basic things like swipe left on the edge to go back.

twobitshifter 2021-08-17 12:39:25 +0000 UTC [ - ]

Loading and rendering HTML can be extremely fast. The slowness we see with apps is a result of bloat, and it’s happened to our native apps too.

spullara 2021-08-17 07:58:53 +0000 UTC [ - ]

I really don't know what yall are going on about. I hit play on a song in spotify and it just plays instantly.

tim-- 2021-08-17 06:26:30 +0000 UTC [ - ]

One thing that has devastated me about recent Spotify updates is that now, when viewing an Artist, you do not get to see all of the albums (or at least the first 10 newest albums) for that artist straight away with all of the tracks listed. It's now much harder to find a song that you don't know the title of, but you know an artist has sung.

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.

chx 2021-08-17 06:30:40 +0000 UTC [ - ]

Discoverability...

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.

operatorius 2021-08-17 06:38:13 +0000 UTC [ - ]

> a forum on a now defunct tracker

Years have passed. I still havent filled the gap left by whatcd...

chx 2021-08-17 06:39:48 +0000 UTC [ - ]

Nothing can, it seems. What wanton destruction. Oink's Pink Palace first, then what.cd

101011 2021-08-17 13:53:57 +0000 UTC [ - ]

Oink...talk about the glory days. If it existed, it was there.

blehn 2021-08-18 13:54:42 +0000 UTC [ - ]

Try YouTube Music. There's a tab in the player that shows related tracks for each song you're listening to.

chx 2021-08-19 01:04:52 +0000 UTC [ - ]

Based on https://www.reddit.com/r/YoutubeMusic/search?q=related&restr... I will pass.

brianmcc 2021-08-17 11:21:36 +0000 UTC [ - ]

They really do make things worse and worse and worse. Related to your playlist example - saving an actual album I liked as a new playlist would give it a default title, "artist - album title" or something like that. Fine, 2 clicks: create the playlist, and accept the title.

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.

Teknoman117 2021-08-17 17:13:04 +0000 UTC [ - ]

Oh wow. I thought that was only a mobile thing, going to have to check the "desktop" app now...

milofeynman 2021-08-17 06:29:58 +0000 UTC [ - ]

I have also noticed this. There isn't even a way to see songs, you always have to go to each album. I don't remember the album! Or the name of the song!

norov 2021-08-17 08:11:20 +0000 UTC [ - ]

Under the artist's page, select their Discography. Songs not released under albums should show up under 'Singles'

tim-- 2021-08-17 08:13:41 +0000 UTC [ - ]

Again with the multiple clicks though. You need to select 'Singles & EPs' after clicking the drop down with the label 'Albums'. To see all the tracks, you first need to change the view from grid view to list.

antifa 2021-08-19 03:03:11 +0000 UTC [ - ]

Also it's rare that an album folder even has all the songs from the actual album. I wish they'd just have an "all songs by artist" list.

gxqoz 2021-08-17 17:24:57 +0000 UTC [ - ]

I wonder if some of these decisions are driven by their business model. My understanding is Spotify's agreement with record labels means they have very low margin on a typical song stream. I've heard that some of their playlists are very valuable for artists and that there's some payola going on there. It could make sense that they're nudging people in those directions.

They also see much more upside in podcasts and thus are pushing people there.

kuu 2021-08-17 12:24:57 +0000 UTC [ - ]

I'm on the same boat: finding a song now requires too many clicks. Albums make sense in a physical world, but not in the virtual one.

JasonFruit 2021-08-17 12:57:26 +0000 UTC [ - ]

An album is (ideally) carefully crafted to work as a coherent musical statement. Tracks in isolation don't have the same effect. It's even more so in classical music, where a work usually encompasses multiple tracks. One of my frustrations with Spotify is that it doesn't understand multi-movement works, so you get an single movement — sometimes even one that is connected to the preceding or following one — in isolation, and it's often really unsatisfying.

tl;dr I think albums have more significance than you do.

kuu 2021-08-19 06:34:21 +0000 UTC [ - ]

Let the user be the one choosing how to use the music.

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.

antifa 2021-08-19 03:04:31 +0000 UTC [ - ]

But none of that matters because most artists only upload a small number of songs from each album anyways.

efreak 2021-08-19 04:41:40 +0000 UTC [ - ]

Not sure how it works now, but back with GPM, you could get access to all the songs by purchasing the album on Google play. Some tracks just can't be played unless you pay for them.

avh02 2021-08-17 07:40:25 +0000 UTC [ - ]

dunno how long it will last for, but you can add `ui.experience_override="classic"` to your prefs file to hold out a little longer.

tim-- 2021-08-17 07:46:34 +0000 UTC [ - ]

Sadly, this does not work on the newest version of their client.

DynamicStatic 2021-08-17 18:18:40 +0000 UTC [ - ]

True but you can use a old version and set the update folder to read only.

avh02 2021-08-17 07:53:43 +0000 UTC [ - ]

oh? I'm on stable version from snap and it's still alive - time to find a way to keep an old version around just in case (apparently snaps don't make this easy.)

lucsky 2021-08-17 08:34:40 +0000 UTC [ - ]

> The search bar used to always be visible. Now I need to click search first, then click the search bar.

This is a lie. When you click "Search" in the side bar the search field gets focused automatically. It is still just one click.

tim-- 2021-08-17 08:45:16 +0000 UTC [ - ]

I just checked Spotify, and it seems like yes, it does now get focused automatically, not sure if it was always that way, or I just feel that I need to click the textbox after choosing the menu item on the left hand side.

That being said, it was still much friendlier to have a search box that you could click on straight away. From a UX perspective, you need to move your focus away from where you have clicked, because the textbox is in a different area of view.

Clicking back on the search menu clears the search that you were doing. It's fine, you can click the back button, but the old Spotify client (iirc!) would keep your previous search in the search box.

jreese 2021-08-17 00:59:24 +0000 UTC [ - ]

At this point, I'd be willing to pay for a Spotify client that works exactly the same, but just ignores the existence of podcasts entirely. I use a dedicated podcast client when I want to listen to podcasts, and they keep shoving them in my face and taking up precious UI real estate everywhere.

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.

gizdan 2021-08-17 06:16:07 +0000 UTC [ - ]

Check out spicetify cli[0]! It patches the Spotify (desktop) client and makes it better. It also adds support for extensions, one of which[1] disables the podcast features. I haven't used the extension so I'm not sure how well it works.

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...

jfrunyon 2021-08-17 02:36:29 +0000 UTC [ - ]

I'd be willing to pay for a Spotify client that allows you to select your audio output device. And yet here we are, 10 years later...

Spotify is a marketing platform first and an audio player second.

lwansbrough 2021-08-17 03:55:05 +0000 UTC [ - ]

If you’re on Windows, you can define audio input and output devices on a per app basis through Windows’ settings. Handy for any app that doesn’t support such configuration (though Spotify obviously should.)

stjohnswarts 2021-08-17 05:31:51 +0000 UTC [ - ]

It works similar on Linux with pipewire/alsa/pulse, there are several guis for such.

jfrunyon 2021-08-18 22:23:28 +0000 UTC [ - ]

TIL, thanks!

jazzyjackson 2021-08-17 03:16:45 +0000 UTC [ - ]

What platform do you mean? The iOS app lets me select output device. It’s a little icon next to play/pause, kind of half computer screen half bookshelf speaker (monitor/monitor :)

I think I remember seeing this on desktop too but at that point why not use the OS sound mixer?

jfrunyon 2021-08-18 22:25:21 +0000 UTC [ - ]

No, the app lets you select what system you're going to listen to Spotify on, not what audio device to use on your system.

Sometimes I just want music through my speakers while I have something else piping into my headset. ¯\_(ツ)_/¯

sbuttgereit 2021-08-17 03:29:18 +0000 UTC [ - ]

Android works pretty much the same way. I'm usually listening on my PC, but I don't try to control other devices from there so I can't remember if it's possible there.

poteznykrolik 2021-08-17 05:40:07 +0000 UTC [ - ]

this doesn't speak to that point but while we're talking android, the Spotify lite client is so nice for me and my 6 year old phone

konart 2021-08-17 05:39:48 +0000 UTC [ - ]

I'd rather use https://staticz.com/soundcontrol/ (which I do use actually) than rely on an app like Spotify to be honest.

vladvasiliu 2021-08-17 07:40:54 +0000 UTC [ - ]

This. I absolutely hate it when apps try to be smart and use their own audio routing.

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.

jfrunyon 2021-08-18 22:26:34 +0000 UTC [ - ]

> I think that aside from "specialty" applications (like DAWs, etc)

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.

cik 2021-08-17 05:35:34 +0000 UTC [ - ]

Can't you just do that outside of Spotify? It would be nicer if you could in app, but with pavucontrol I have Spotify send music where it belongs.

throwaway1777 2021-08-17 05:34:05 +0000 UTC [ - ]

They make it easy to play to any Bluetooth device or headphones. Covers my use case, but I can see it being annoying if it doesn’t support your setup.

savolai 2021-08-17 05:42:33 +0000 UTC [ - ]

On iphone I can’t seem to actually choose the bluetooth device to play to from the app itself. iOS limitation?

modernerd 2021-08-17 05:53:46 +0000 UTC [ - ]

Click the Bluetooth or Devices icon, then choose “AirPlay or Bluetooth” under “Other Devices”.

For me this presents a native popover showing all Bluetooth devices and Apple TV.

rubiquity 2021-08-17 02:12:43 +0000 UTC [ - ]

Came here to say this. It was hard enough losing Rdio and now Spotify has been on a rapid decline for the last 1-2 years. It used to be a place to listen to music you already knew and maybe find something new and now they do nothing but shove podcasts down your throat. Who that works there is looking at the current UI as an improvement?

bullfightonmars 2021-08-17 04:29:59 +0000 UTC [ - ]

I loved Rdio for the Ui. I subscribed for years. That said Spotify has introduced me to so much music that I missed growing up.

The Spotify UI has been pretty painful lately but I have a hard time living because the suggested music selection has been so good.

swiley 2021-08-17 02:09:16 +0000 UTC [ - ]

I love my 3.5mm cables for this reason. No negotiating with vendors (except Apple but it's well known that they really suck) just plug and play.

asdff 2021-08-17 02:35:30 +0000 UTC [ - ]

I can't wait to sit my grandchildren on my knee and tell them stories of the magic headphones that you never needed to charge and just worked instantly with practically any audio device ever made by mankind right up until the iPhone 7 was unleashed unto the world.

SilverRed 2021-08-17 06:05:09 +0000 UTC [ - ]

They would probably see it like we computers that had memory which did not wipe when powered down. The inconvenience is minor and the benefits large. They will never deal with huge hell balls of cables/headphones. The charging is pretty painless and the airpods pretty much do just work instantly with any Apple device (they can detect which one you are using at the time).

addandsubtract 2021-08-17 09:07:56 +0000 UTC [ - ]

Oh, I love a computer voice screaming into my ear "BATTERY! LOW! " every minute when my headphones reach 30%. Yeah, hearing loss is only a small price to pay for not dealing with tangled cables.

joshstrange 2021-08-17 15:22:37 +0000 UTC [ - ]

AirPods do not STT announce a low battery unless that's an accessibility setting. By default they just play a little tone to alert you that your battery is low. An argument can be made around the expensive of AirPods but not when it comes to usability, they are bar none. Watching my Android friends cycle though bluetooth headphones like changing outfits is always interesting to me. Every few months I hear about "check out these awesome headphones, they are so small and they have noise cancelling", yawn, I've been using the same AirPods Pro since they released and they've tried 3+ and still aren't happy. I didn't want to believe it and refused to buy AirPods when they first came out until I got them as a gift and reluctantly used them but after I lost them (or they were stolen, still not sure) it took less than 3 days before I had ordered more. They really are magic.

hundchenkatze 2021-08-17 16:27:38 +0000 UTC [ - ]

How is the battery holding up on the Pros? My 1st gen AirPods were dead (each bud only holds about 20 mins of charge) after a year. I then tried a pair of the SoundCore Air Liberty 2 (what a name...) with the same result after a year or so. I can't justify paying $200 every year, so I'm sticking with wired for now.

joshstrange 2021-08-17 17:01:43 +0000 UTC [ - ]

I mean, I've had the same Pros since launch and I haven't noticed a decrease in the battery. I mean, I'm sure there is a decrease but I listen for hours and hours at a time without issue. If I go longer than 4 hours I might get the low battery notification but they charge so fast that I can either take a break or do the "charge 1 at a time" trick so keep listening.

ayewo 2021-08-17 20:20:47 +0000 UTC [ - ]

Roughly how long have you had your Airpod Pros?

joshstrange 2021-08-17 20:29:57 +0000 UTC [ - ]

I just checked and actually got them for Christmas 2019 (so like 2 months after they released, my mistake, I thought I got them sooner). I use them almost every single day for 30min to 4+ hours depending on what I’m doing.

So to answer your question I’ve had them for around 20 months.

rogy 2021-08-17 21:08:29 +0000 UTC [ - ]

my original airpods were bought feb 2018 and mine still last hours on output only, they last maybe 90 minutes using the microphone on calls though

_Algernon_ 2021-08-17 13:12:30 +0000 UTC [ - ]

And the button that starts a glorified voice "assistant" that I've haven't pressed intentionally once.

Or the pain of switching between paired devices.

At least no more cables getting ripped out of my ears by the door knob.

YetAnotherNick 2021-08-17 10:34:31 +0000 UTC [ - ]

It's not just charging. You can pretty much connect it to any device in a second without waiting for a minute for bluetooth connection. Maybe airpod is good for single person use who has very limited devices which are all Apple, but I own multiple non Apple devices. Even though all have bluetooth, bluetooth is much more error prone than 3.5mm jack.

JohnWhigham 2021-08-17 18:49:41 +0000 UTC [ - ]

It's planned obsolescence. Analog headphones from 15 years will work whereas Airpods will be nigh-unusable after 5 years because the batteries will be spent.

SilverRed 2021-08-17 23:08:00 +0000 UTC [ - ]

This is completely true but I also just don't really care. The airpods are quite small and use minimal resources so the environmental impact of buying airpods every 5 years is minimal compared to other things. I already do not use a car or public transport so I am well below the average persons resource usage.

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.

swiley 2021-08-17 02:39:08 +0000 UTC [ - ]

Between their screw ups and Pine64's successes that hopefully won't happen.

eurasiantiger 2021-08-17 05:12:23 +0000 UTC [ - ]

Remember to throw in stories about impedance matching and the differences of A/B and T/D class amplifiers, as well as soundstage, acoustic compression and active correction.

rnestler 2021-08-17 07:38:24 +0000 UTC [ - ]

At least some of these things are kind of unrelated to how the audio signal arrives at the amplifier and are still an issue when connecting speakers to a bluetooth enabled amplifier.

eurasiantiger 2021-08-17 11:06:40 +0000 UTC [ - ]

Absolutely, but the thought that a 3,5mm jack makes everything always compatible is nonsense. Sure, it will work with most consumer products in some way, but it is not a given that it is working as intended.

matthewfcarlson 2021-08-17 01:46:21 +0000 UTC [ - ]

I'm with you 100%. If they had a decent podcast experience, I'd be happy to switch but it's terrible. Why can't I mark something as already played?

josephg 2021-08-17 02:29:45 +0000 UTC [ - ]

Yep; I'm a paying customer of spotify and I like some of the podcasts they have. But they don't have the gap removal + speed controls of Overcast (my fav podcast program on my phone). So I'm in this weird situation of never wanting to listen to any podcasts through the spotify app, which I'm paying for. And then when I want to listen to music (eg while coding) I have to wade through podcasts which are intentionally designed to blend in with music recommendations in spotify's apps.

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.

fossuser 2021-08-17 03:09:46 +0000 UTC [ - ]

I don’t think Spotify wants you to be able to use your favorite app.

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.

tootie 2021-08-17 05:10:29 +0000 UTC [ - ]

Yeah there's currently a war on to be the YouTube of podcasts and Spotify is currently in the best position.

briish 2021-08-17 06:09:53 +0000 UTC [ - ]

I was really surprised that Podcasts on Spotify became that popular. Thats what exclusives can do, iI guesd

fossuser 2021-08-17 16:03:38 +0000 UTC [ - ]

When I used Spotify I had wished my podcasts were able to be there since it would be convenient to just have the tracks in the same UI.

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).

vxNsr 2021-08-17 06:39:11 +0000 UTC [ - ]

Spotify has spent over half a billion dollars on acquisitions and investments into its podcasts division, there is zero chance they ever intentionally implement anything that might impede the returns on that spending.

josephg 2021-08-17 06:45:30 +0000 UTC [ - ]

They get ROI if people subscribe to spotify. Why would they care whether I listen to podcasts through their official app or through a 3rd party's app?

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.

pornel 2021-08-17 10:40:44 +0000 UTC [ - ]

If you care about Podcasts, don't listen to them on Spotify, ever. Spotify's plan is to build a walled garden around them.

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.

yupper32 2021-08-17 05:12:57 +0000 UTC [ - ]

You can. There's a "Mark as played" button in at least the Android Spotify app that I'm looking at right now.

Can't comment on anything else, though.

tyre 2021-08-17 02:26:39 +0000 UTC [ - ]

It’s insane that Spotify on Mac doesn’t support airplay.

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.

bleachedsleet 2021-08-17 03:42:16 +0000 UTC [ - ]

Airfoil [1] is worth every penny. The same could be said for pretty much everything Rogue Amoeba makes.

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.

[1] https://rogueamoeba.com/airfoil/mac/

geraneum 2021-08-17 05:32:28 +0000 UTC [ - ]

If I understood your problem correctly, you need to listen to Spotify through your HomePod which is on the same local network as your Mac.

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.

nonninz 2021-08-17 08:03:48 +0000 UTC [ - ]

That routes all the audio from the mac though, not only Spotify. And with a noticeable delay.

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.

jazzyjackson 2021-08-17 03:22:26 +0000 UTC [ - ]

I don’t understand, not a user of Airplay - your Mac doesn’t have a way to stream to airplay devices? Why does it come down to the app?

mrweasel 2021-08-17 08:04:16 +0000 UTC [ - ]

The Mac can use the Airplay device as an output device, but it's not ideal, because that will send ALL sound to the Airplay device.

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.

jazzyjackson 2021-08-17 08:22:45 +0000 UTC [ - ]

That makes sense, thanks. I remember now I was using Tidal which did have this option.

fossuser 2021-08-17 03:06:21 +0000 UTC [ - ]

I gave up on Spotify because of this - and because of their hostile moves to turn podcasts into another centralized service.

Apple Music is still mostly worse without discovery, but at least lossless makes up the quality difference that use to be there.

dangravell 2021-08-17 09:23:36 +0000 UTC [ - ]

Got me thinking. I wonder how much scope there is to build apps for platforms like Spotify which are built around a given use case.

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.

mackrevinack 2021-08-17 07:01:35 +0000 UTC [ - ]

i don't like this podcast stuff either. even just the homepage that displays artists (that i will never listen to) is enough to annoy me. i would really love an option to open directly into my playlists or something else. im building up a local music collection at the moment so its not going to be annoying me for too long more

andrewmcwatters 2021-08-17 01:08:17 +0000 UTC [ - ]

I love seeing software like this, even if it's not legal. Who cares? I remember being a teenager and trying out all sorts of cool underground, fundamentally illegal software, or stuff that worked around Terms of Service.

Where would the world be today without Napster? Maybe the same place, but provocative software is the definition of cool.

jazzyjackson 2021-08-17 03:15:11 +0000 UTC [ - ]

Nothing illegal about it, Spotify has a well documented API and supports third party clients

laserbeam 2021-08-17 03:31:25 +0000 UTC [ - ]

Eh. Ish. They only support playback within a browser and have deprecated native playback support years ago. Also their ToS technically doesn't let you do a looot of things you may want. Like caching. Srsly, you're not allowed to cache things. Many 3rd parties stopped supporting spotify because the dev ToS kept getting worse.

Regardless, I'm excited about this little project even if it goes against the ToS.

jazzyjackson 2021-08-17 04:56:23 +0000 UTC [ - ]

Hmm it was years ago but I remember now my chatbot was controlling the playback session in a browser, you’re right.

sunshineforever 2021-08-17 03:30:43 +0000 UTC [ - ]

So does this version not have advertisements or something?

laserbeam 2021-08-17 03:49:17 +0000 UTC [ - ]

You still need to log into spotify to use any 3rd party app and none of the playback apis will work without a premium account. Apps like this one are for people with premium accounts.

BoxOfRain 2021-08-17 09:02:19 +0000 UTC [ - ]

Things like Napster have a long tradition dating back to the 1960s, in the UK the response to the paternalistic and stuffy state monopoly on music broadcasting was for people to put studios and transmitters on ships parked just outside of British territorial waters. That’s really what fuelled the explosion in British music!

gjs278 2021-08-17 01:24:58 +0000 UTC [ - ]

people on here care about laws too much. it's a api/webscraping tool redisplayed a gtk window. nobody is going to go to jail. even if they dmca it someone should just host the sources on anything other than github and let it ride. people cheat at videogames all the time, they can cheat on a music client.

toothbrush 2021-08-17 05:52:22 +0000 UTC [ - ]

Running the risk of being a dirty reposter and.. reposting. My little Spotify client is for macOS only, mostly only built for my own use, and a lot more minimal, visually. It's also native Swift though, so it's got that nice macOS feel. It's also pretty much 100% keyboard-driven (Vim keys, if that's something you like) and supports regex filters. It's just an open-source thing: https://github.com/toothbrush/Spotiqueue

dorian-graph 2021-08-17 09:22:01 +0000 UTC [ - ]

I like this! Thanks for (re)posting it.

PascLeRasc 2021-08-17 14:02:41 +0000 UTC [ - ]

I love this! Thanks for making it.

tiew9Vii 2021-08-17 01:33:53 +0000 UTC [ - ]

This is good to see.

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.

dropofwill 2021-08-17 03:20:25 +0000 UTC [ - ]

Druid is still not ready for prime time though (https://www.areweguiyet.com/). Played with psst for a bit: no keyboard shortcuts, no screenreader support, scrollbar feels 'off', stuff that just works if you use a native toolkit or a browser.

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.

jpochyla 2021-08-17 09:02:29 +0000 UTC [ - ]

Hi, the author here. Keyboard navigation is definitely something I'd like to focus on soon, the app should be 100% usable without a mouse. And accessibility is definitely on the Druid roadmap! <3

raphlinus 2021-08-17 04:01:08 +0000 UTC [ - ]

Keyboard shortcuts should be doable, I don't think this is a limitation of the toolkit.

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.

mkj 2021-08-17 03:45:11 +0000 UTC [ - ]

Trying psst here on Linux I came away with the opposite impression - Druid's further along than I expected, it Just Worked at high DPI on Wayland better than most electron apps. I guess it'd feel worse on MacOS which already has a more consistent system UI.

artursapek 2021-08-17 05:44:11 +0000 UTC [ - ]

We are (I hope) helping solve this problem at Kraken. We sponsor development of the iced library, which we're using to build https://cryptowat.ch/desktop. It's supported on Windows, Mac, and Linux and has received a ton of positive feedback about how fast and light it is. I have hope for the future, and don't expect Electron to stay dominant forever. Native GUI apps are slowly coming back.

https://github.com/hecrj/iced

rewtraw 2021-08-17 16:13:18 +0000 UTC [ - ]

love cryptowatch desktop! :) very performant.

artursapek 2021-08-17 17:22:15 +0000 UTC [ - ]

Thanks!

globular-toast 2021-08-17 10:47:43 +0000 UTC [ - ]

Why do people keep forgetting this? You can use Qt to easily build a "fast" GUI that works on all platforms. And you can do it with Python via PyQt. No complicated C++ or Rust, unless you actually need it (which this almost certainly does not).

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.

ramesh31 2021-08-17 01:40:18 +0000 UTC [ - ]

>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?

brundolf 2021-08-17 02:47:59 +0000 UTC [ - ]

Why would an Electron frame allow them to track you more easily than a native desktop app that has access to your whole (userspace) system?

pritambaral 2021-08-17 05:40:32 +0000 UTC [ - ]

Not your parent. Just clarifying.

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

zingplex 2021-08-17 02:22:36 +0000 UTC [ - ]

If it's just for tracking, why not ship a JS runtime and run the tracking in a separate thread. No electron needed.

pritambaral 2021-08-17 05:42:49 +0000 UTC [ - ]

Too much work. With Electron, one can just `npm i electron-analytics` and done. Without Electron, libraries like that will have to be patched (at least) to be usable with the custom runtime.

stjohnswarts 2021-08-17 05:33:16 +0000 UTC [ - ]

but electron does have a JS runtime included?

tomc1985 2021-08-17 02:08:42 +0000 UTC [ - ]

Oh, don't forget the legions of cheap javascript newbs fresh out of boot camp that they can hire!

2021-08-17 11:44:10 +0000 UTC [ - ]

numlock86 2021-08-17 06:42:18 +0000 UTC [ - ]

> Psst: Fast Spotify client with native GUI, without Electron, built in Rust

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.

ubercow13 2021-08-17 07:52:46 +0000 UTC [ - ]

This uses the same API as libspotify, a library for accessing Spotify for playback that Spotify released themselves. It’s not been supported for a while so future support for this API is unclear, but it’s not clearly going to be shut down like you suggest.

Apple Music also has an official and maintained API for building third party clients.

bluepizza 2021-08-17 07:41:45 +0000 UTC [ - ]

Spotify API is open. He is not breaking any ToS.

Vespasian 2021-08-17 09:14:49 +0000 UTC [ - ]

The DRM decrypting stuff is breaking the ToS.

tim-- 2021-08-17 09:30:34 +0000 UTC [ - ]

But you are not decrypting the DRM. The software you are using is decrypting the audio stream in real time in a way that works similar to the official client. The logged in user is not breaking the TOS.

Vespasian 2021-08-17 00:49:02 +0000 UTC [ - ]

I'm going to give it less than a year now that it has been featured on HN.

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

codetrotter 2021-08-17 01:24:32 +0000 UTC [ - ]

> harder DRM measures

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.

jeroenhd 2021-08-17 01:53:02 +0000 UTC [ - ]

Music publishers could demand better DRM in their contracts, though. That would lock out any devices incapable of receiving DRM updates, but it's certainly a possibility. If Spotify would refuse to budge, their platform would lose access to a lot of songs. If they agree, their users would have a terrible experience, only being able to play some songs on some devices.

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).

GOATS- 2021-08-17 12:37:21 +0000 UTC [ - ]

> Is that even possible for Spotify at this point?

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.

[0]: https://github.com/Satsuoni/widevine-l3-guesser

BrokenDesktop 2021-08-17 12:49:44 +0000 UTC [ - ]

Something is stopping them: all the old devices that already know how to speak Spotify.

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.

OscarDC 2021-08-17 20:31:36 +0000 UTC [ - ]

One thing that could be done - and which is already what's being done by most video streaming companies - is to just propose really poor audio qualities to devices/softwares with less DRM capabilities and only unlock the better qualities when e.g. Widevine L1 or PlayReady SL3000 is available.

What's more, media-oriented devices like smart tvs or game consoles usually have those requirements.

ramesh31 2021-08-17 01:38:12 +0000 UTC [ - ]

This is a great point. It's truly no different than a third party manufacturer writing some device firmware to connect with Spotify.

vladvasiliu 2021-08-17 07:54:48 +0000 UTC [ - ]

But as a sibling has posted, this is a posture / plausible deniability thing.

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.

bob1029 2021-08-17 00:57:52 +0000 UTC [ - ]

DRM for audio is so laughable. Any bit of patience allows for even the most rookie of users to rip a track from spotify.

If it weren't for all the legal agreements with copyright holders, I feel like spotify would already have an open playback API.

56h4h4h 2021-08-17 01:46:45 +0000 UTC [ - ]

The name of the game is risk mitigation. In this case, there are lots of ways to rip a singular track. They are usually slow because you record the audio stream from Spotify.

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.

1vuio0pswjnm7 2021-08-17 02:50:11 +0000 UTC [ - ]

Archive.org still has copies.

fabianhjr 2021-08-17 03:32:41 +0000 UTC [ - ]

> source quality

Spotify does at most MP3 320kbps, source quality would imply something like lossless FLAC/AAC

vladvasiliu 2021-08-17 07:50:22 +0000 UTC [ - ]

They probably mean source as in "what you get from Spotify", as opposed to what you can record after Spotify has decoded it, which you'd have to re-encode.

tim-- 2021-08-17 05:05:44 +0000 UTC [ - ]

I thought that the audio from Spotify was all ogg?

dawnerd 2021-08-17 07:03:43 +0000 UTC [ - ]

Rdio had an api that let you playback songs with a valid user token. It was really sweet.

Qub3d 2021-08-17 00:58:50 +0000 UTC [ - ]

Anecdotally, the only other Spotify UI I've seen on HN is still going strong after 2 years: https://github.com/Rigellute/spotify-tui

Vespasian 2021-08-17 01:06:08 +0000 UTC [ - ]

They don't break the DRM and use the official WebAPI.

> 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.

Qub3d 2021-08-17 01:36:32 +0000 UTC [ - ]

This app does, too. It uses aspotify[0], which is just a rust spotify API wrapper.

https://github.com/KaiJewson/aspotify

Vespasian 2021-08-17 01:51:45 +0000 UTC [ - ]

It also breaks the drm. Search for "decrypt" in the repo for psst.

stjohnswarts 2021-08-17 05:34:05 +0000 UTC [ - ]

You realize there are other unofficial spotify clients and have been for years don't you?

Brian_K_White 2021-08-17 01:59:14 +0000 UTC [ - ]

I've been using pianobar and pithos and pandoroid for my paid Pandora account for over 10 years.

thebean11 2021-08-17 01:57:50 +0000 UTC [ - ]

> This is too user facing and too easy to modify for DRM circumvention (if it isn't already doing that)

How?

Brian_K_White 2021-08-17 02:00:11 +0000 UTC [ - ]

Google "pianobarfly"

bluepizza 2021-08-17 07:44:29 +0000 UTC [ - ]

They do not exist in a legal grey zone. Spotify has open APIs. Using them is allowed.

nfd 2021-08-17 16:50:16 +0000 UTC [ - ]

librespot is a reverse-engineered thin client (using the same api that e.g. your "smart speakers" would). It doesn't use official APIs, arguably violates DMCA, and you pretty much have to use it if you don't want to simultaneously run the full thick official client on the same device at the same time.

fleddr 2021-08-17 14:13:18 +0000 UTC [ - ]

I think the idea of desktop apps being web apps repackaged is now so ingrained that some people have never experienced true desktop app performance.

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.

shp0ngle 2021-08-17 15:30:27 +0000 UTC [ - ]

MS Office is React now? Wow. Does not surprise me though.

gruez 2021-08-17 19:18:25 +0000 UTC [ - ]

That statement's horribly misleading. The desktop versions (eg. windows or mac) aren't, but the web versions are.

fleddr 2021-08-17 20:07:06 +0000 UTC [ - ]

No, it's not misleading. The Office 365 desktop apps are written in React. As is Teams. As is Visual Studio Code.

Specifically, React Native for Windows. https://github.com/Microsoft/react-native-windows

For things like background services, they still use C/C++.

gruez 2021-08-17 20:16:10 +0000 UTC [ - ]

> No, it's not misleading. The Office 365 desktop apps are written in React. As is Teams. As is Visual Studio Code.

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.

fleddr 2021-08-17 21:40:09 +0000 UTC [ - ]

You're right that the main source is a 2018 original tweet, and then some articles building on that tweet, and then news dries up.

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 :)

riskable 2021-08-17 01:05:17 +0000 UTC [ - ]

Just downloaded this to try it out... This is now my new Spotify client!

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:

https://i.imgur.com/nNWFIj1.png

lostmsu 2021-08-17 01:43:12 +0000 UTC [ - ]

According to this: https://forums.overclockers.com.au/threads/winamp-memory-usa...

Winamp 2.72 only used about 8 megs of RAM.

dotancohen 2021-08-17 03:43:10 +0000 UTC [ - ]

Eight Megs And Counting.

Wow, eight megs was once so much memory that we would laugh about applications that even approached it.

TchoBeer 2021-08-17 13:27:40 +0000 UTC [ - ]

It's really crazy how quickly things have gotten bigger. I remember not too long ago my mid-high power computer had 1Gb of RAM, nowadays that would be laughably small.

jpochyla 2021-08-17 09:07:27 +0000 UTC [ - ]

Hi, I'm glad you like it! The performance is not _that_ good at the moment, mostly because of superfluous paints, but it's something I'd like to focus on (as it's one of the primary objectives).

rvz 2021-08-17 02:55:05 +0000 UTC [ - ]

So Electron is the problem. It gets worse if you have lots of tabs open in Chrome + running other electron apps as well. A visible and obvious improvement when compared with a native app.

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.

userbinator 2021-08-17 02:58:18 +0000 UTC [ - ]

The second one should be sorted by name to show that there are actually multiple spotify processes. (There's another one near the bottom of the list.)

xyst 2021-08-17 04:10:05 +0000 UTC [ - ]

I wonder what the footprint will look like once the author writes in all of the missing features

maccam94 2021-08-17 05:56:20 +0000 UTC [ - ]

I wonder if that executable is stripped, often that saves a decent chunk of memory.

mkj 2021-08-17 06:49:48 +0000 UTC [ - ]

It'll save disk space but not resident memory? Debug symbols etc shouldn't be paged in. The Linux binary goes from 20MB to 10MB stripped.

cik 2021-08-17 10:33:01 +0000 UTC [ - ]

I've been running this for the last 5 hours, since I saw the posting. Thankfully, in arch it's just part of the aur.

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.

jeroenhd 2021-08-17 01:43:37 +0000 UTC [ - ]

I've never given Spotify a try because of the crummy web/Electron player I saw everyone using. Wanted to try this out, but it only works with a premium account. That could've been mentioned more clearly, would've saved me the effort of compiling this thing.

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.

mimimi31 2021-08-17 06:55:32 +0000 UTC [ - ]

>it only works with a premium account. That could've been mentioned more clearly

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.

jpochyla 2021-08-17 09:08:44 +0000 UTC [ - ]

This is not really the case, you need a Premium account for Psst to work.

mimimi31 2021-08-17 18:52:12 +0000 UTC [ - ]

I tested it before making the claim. It is definitely possible. The only limitation is that you can't stream at the highest bitrate.

fabianhjr 2021-08-17 03:36:53 +0000 UTC [ - ]

> As for the legality, the DMCA sucks but this client is definitely in violation of it.

How is it definitely in violation of the DMCA? (Not a lawyer and not a USA resident, would appreciate legal clarification)

jeroenhd 2021-08-17 11:20:11 +0000 UTC [ - ]

Any circumvention of DRM, even simple DRM as long as it's not too trivial, is considered illegal under the DMCA. The decryption routines Spotify uses should definitely be considered non-trivial DRM.

kxrm 2021-08-17 05:01:02 +0000 UTC [ - ]

Not who you replied to, but if anything decrypts a DRM stream in an unauthorized way, it technically is breaching DMCA. I assume that is what they meant.

soheilpro 2021-08-17 04:08:20 +0000 UTC [ - ]

This is great, but the sad truth is that unofficial clients like this can never grow big and support more than a few thousand users, given how ridiculously low Spotify API's rate limits are.

My project https://volt.fm has 100k+ users now and I'm really struggling with the Spotify API.

tim-- 2021-08-17 05:07:25 +0000 UTC [ - ]

The trick would be to have each user register their own API key.

ShroudedNight 2021-08-17 06:05:35 +0000 UTC [ - ]

This seems like such an obvious answer, why isn't it significantly more common?

kzrdude 2021-08-17 06:18:15 +0000 UTC [ - ]

Because that will also self-select the audience to be really small.

tim-- 2021-08-17 06:30:15 +0000 UTC [ - ]

No, not at all. There are ways to implement this without making it a requirement to use the app. For example, you implement a counter for each user of the app, so they can only use a subset of the API requests allowed for your application.

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.

TchoBeer 2021-08-17 13:26:28 +0000 UTC [ - ]

I imagine for something like 90%+ of users, a popup that says "Your maximum number of API calls has been reached, click this link and register your own API key to continue using..." is an instant nope

clashmeifyoucan 2021-08-17 06:30:42 +0000 UTC [ - ]

this, I wanted to make a little utility for getting lyrics for whatever song is currently playing on spotify[1] and ran into the issue for getting the song name without using the API since that's just inconvenient for the end user. The most popular such project does go that way though.[2]

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

[2] https://github.com/johnwmillr/LyricsGenius

[3] https://github.com/SwagLyrics/SwSpotify

OhNoMyqueen 2021-08-17 10:42:53 +0000 UTC [ - ]

The Spotify API doesn't support private API keys, so you need to create your own OAuth App and then authorize it for yourself.

tiborsaas 2021-08-17 05:46:05 +0000 UTC [ - ]

Also, they can lock out out overnight and good luck appealing to the legal team.

CamperBob2 2021-08-17 04:10:46 +0000 UTC [ - ]

How does the nature of the API determine the number of users?

soheilpro 2021-08-17 04:33:19 +0000 UTC [ - ]

I meant rate limits. Edited my original comment.

tomduncalf 2021-08-17 07:21:04 +0000 UTC [ - ]

Slightly off topic, but it’s a shame Spotify’s web API doesn’t support (and they’ve said never will support [1]) playlist folders. I get that it’s a bit of a power user feature but it’s an essential one for me in any media player.

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…

[1] https://github.com/spotify/web-api/issues/38

dehrmann 2021-08-17 03:27:36 +0000 UTC [ - ]

Nit: Spotify isn't electron-based.

https://www.quora.com/How-is-JavaScript-used-within-the-Spot...

laserbeam 2021-08-17 03:36:04 +0000 UTC [ - ]

"Chromium Embeded Framework". When people say Electron based they don't really care if it's using Electron or any other browser. It's still a browser. And it's therefore at least 100x slower than it could be.

varajelle 2021-08-17 10:20:23 +0000 UTC [ - ]

And when people say "iPhone" they don't really care if it's an actual iPhone or just any smart phone?

jjice 2021-08-17 13:33:22 +0000 UTC [ - ]

Spotify regularly upsets me with change. Don't change a UI that looks good and works well just to hide something I need. It feels like it's just justification to have an entire team of client designers employed.

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.

exciteabletom 2021-08-17 06:00:29 +0000 UTC [ - ]

I've been using Spot[0], which is another Rust Spotify client using GTK.

[0]: https://github.com/xou816/spot

boudin 2021-08-17 07:21:50 +0000 UTC [ - ]

And for those wanting a ncurse client, there is ncspot [0] which is quite stable and complete.

[0] https://github.com/hrkfdn/ncspot

nicolaslem 2021-08-17 09:14:34 +0000 UTC [ - ]

I never really got into Spotify because I found the UI so confusing, clearly designed for "engagement" instead of usability.

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!

petepete 2021-08-17 08:10:26 +0000 UTC [ - ]

Instantly installed and wow - this is outstanding. Thanks for the recommendation, had never heard of it.

graynk 2021-08-18 05:28:51 +0000 UTC [ - ]

I actually liked this a bit more than Psst, thank you for the comment

skavi 2021-08-17 02:11:44 +0000 UTC [ - ]

people who are interested in this will also be interested in ripcord [0], a native client for discord and slack.

[0]: https://cancel.fm/ripcord/

asdff 2021-08-17 02:39:06 +0000 UTC [ - ]

Ripcord is excellent but you need to generate a new login token every few weeks. Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want.

anonymousab 2021-08-17 05:43:40 +0000 UTC [ - ]

> Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want

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.

skavi 2021-08-17 03:13:17 +0000 UTC [ - ]

I have not had to do that.

asdff 2021-08-17 03:25:22 +0000 UTC [ - ]

Your organization probably does not use secure sign on then.

1vuio0pswjnm7 2021-08-17 03:15:51 +0000 UTC [ - ]

From the Ripcord page:

"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.

tumult 2021-08-17 15:01:26 +0000 UTC [ - ]

> As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.

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.

1vuio0pswjnm7 2021-08-17 21:32:24 +0000 UTC [ - ]

"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."

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.

anonymousab 2021-08-17 05:41:00 +0000 UTC [ - ]

I have heard that discord is quite active in banning users of alternate clients and even slight CSS tweaks, when they can manage to detect them.

dt2m 2021-08-17 00:31:20 +0000 UTC [ - ]

looks very cool, might switch back to spotify just for this. the speed and feeling of pre-bloated iTunes is still the benchmark to which i hold any music app, and this might be the next best thing.

appreciate the work here.

jakecopp 2021-08-17 00:48:08 +0000 UTC [ - ]

I love the look and idea of this - are alternative clients against the Spotify ToS though?

Would be such a shame to put in all this work only for Spotify to kill it.

Vespasian 2021-08-17 01:00:03 +0000 UTC [ - ]

It uses private APIs to retrieve the decryption keys from the server and circumvent the DRM.

It's certainly against the ToS and probably illegal in some jurisdictions

conradev 2021-08-17 01:37:45 +0000 UTC [ - ]

Usually the way it works is that _using_ the software is illegal, but distributing its source code is not. Code is covered by the first amendment in the US.

dannyobrien 2021-08-17 03:24:55 +0000 UTC [ - ]

Unfortunately, the DMCA 1201 court decision that establishes once and for all has yet to occur. EFF continues to pursue it though: https://www.eff.org/cases/green-v-us-department-justice

rob-olmos 2021-08-17 01:49:12 +0000 UTC [ - ]

Related to the Spotify desktop client, I still don't understand why I have to restart the app when my internet connection is interrupted.

quaintdev 2021-08-17 04:20:36 +0000 UTC [ - ]

I hope this becomes popular enough that Spotify buys this and makes it default. I have not used this but anything is better than current Spotify memory hog. I miss those WinAmp days.

q-rews 2021-08-17 05:03:39 +0000 UTC [ - ]

Anyone thinking this is delusional. Spotify works in a browser and there’s no non-CSS-based framework that can do that.

The reason Electron is popular is because you can have a single codebase for ALL the targets.

S0und 2021-08-17 07:43:27 +0000 UTC [ - ]

> 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...

jbverschoor 2021-08-17 08:22:30 +0000 UTC [ - ]

Actually, you could just use use react (or vue or angular with nativescript) and have one codebase with a __native__ ui on desktop + css on the browser, but keep the app-logic and UI code the same.

avh02 2021-08-17 10:15:03 +0000 UTC [ - ]

> Spotify works in a browser

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.

q-rews 2021-08-17 13:23:34 +0000 UTC [ - ]

Yeah your necessities don’t match Spotify’s. If they took this path, the web version is probably important for them.

TchoBeer 2021-08-17 17:22:50 +0000 UTC [ - ]

I use the browser pretty frequently, I don't even have Spotify desktop on my work computer

dtagames 2021-08-17 15:10:22 +0000 UTC [ - ]

So right. As soon as you are the person paying for people and time to develop native apps, you start thinking, "Geez, I could make an identical UI with web technologies and skip all the platform stuff entirely!"

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.

reacharavindh 2021-08-17 07:20:37 +0000 UTC [ - ]

This feels like such a breath of fresh air. I wish there comes a wave of such native implementations of popular electron resource hogs - Slack, Teams, WhatsApp etc.

mrweasel 2021-08-17 08:10:39 +0000 UTC [ - ]

What I don't understand is: How many developers do you really need to create a native Spotify client?

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.

arendtio 2021-08-17 18:19:09 +0000 UTC [ - ]

On the desktop, I simply use a separate Firefox profile for Spotify with the web client. The only 'special' thing is that I had to disable ServiceWorkers because they somehow caused some trouble every few weeks (dom.serviceWorkers.enabled = false). In addition, I use KDocker for a system tray icon.

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?

ivolimmen 2021-08-17 06:06:18 +0000 UTC [ - ]

I am definitely going to check this out. I use the Spotify snap under Ubuntu as I never got Spotify client working when I upgraded to the lastest Ubuntu and they keep working on the main stable. I do not hate the UI of Spotify but having alternatives is really nice. I also have Spot installed. It is also a simple and native application to listen to your music. I am a very heavy Spotify user. We have a family subscription so my kids have their own premium. Last year I listened to 60K songs; I really like the yearly review BTW. Yesterday I was talking to my wife and we just swallowed the pill completely and we will be throwing out our CD collection to make room for a new cabinet (I currently own around 1000 CD's).

codetrotter 2021-08-17 00:54:37 +0000 UTC [ - ]

Looks really nice! I switched to Apple Music like a year ago but if this is good then I might switch back to Spotify.

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?

account42 2021-08-18 09:42:43 +0000 UTC [ - ]

Is it just me or does the play buttons triange in the screenshot look horribly uncentered. Seems like the like positioned based on minimum/maximum horizontal extend whereas aligning the "center of gravity" with the circle center might make more sense.

EastSmith 2021-08-17 08:28:17 +0000 UTC [ - ]

For the last couple of months I am using open.spotify.com (i.e. I uninstalled the native Windows app). Works great, not sure if I am not losing some audio quality, but if I do - I have not noticed.

pacifika 2021-08-17 09:34:41 +0000 UTC [ - ]

Didn't build on macos 11.5

``` 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 ```

varajelle 2021-08-17 10:09:24 +0000 UTC [ - ]

If I had to guess, I'd say you're using a too old versions of rust.

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.

dmit 2021-08-17 10:50:23 +0000 UTC [ - ]

Yep, the two missing features are `usize::MAX` (stabilized in Rust 1.43, April 2020), and control flow in const fns (stabilized in Rust 1.46, August 2020).

2021-08-17 05:34:35 +0000 UTC [ - ]

ho_schi 2021-08-17 11:33:58 +0000 UTC [ - ]

Good news. We need more native apps, which work autonomous and locally and optionally sync with servers. Examples are Git (yeah! --everything-is-local) or any decent Mail-Client. Especially what the industry usually does is not the best, but just the cheapest.

https://josephg.com/blog/electron-is-flash-for-the-desktop/

MonoidWitness 2021-08-17 05:16:37 +0000 UTC [ - ]

Wow! Could Rust return the desire to build fast native UIs? I sure hope it does. And also is there Apple Music native app? Because the standard client is such a mess of an app.

sirsinsalot 2021-08-17 11:08:10 +0000 UTC [ - ]

A project like this cant come fast enough. Spotify desktop on Linux is a bloated mess that regularly crashes and takes down the display server with it.

stjohnswarts 2021-08-17 05:04:07 +0000 UTC [ - ]

It's working just fine so far on Linux even it sounds like they're mostly using MacOS. I could see using this a lot if playlist support was added. It seems snappy. I'm kind of surprised that htop reports 165M and Cpu reporting 38-45% which seems a tad bit high for playing a sound file O_O . I know it's early days though, so I'll keep an eye on it for sure. Very clean interface.

jpochyla 2021-08-17 09:19:50 +0000 UTC [ - ]

Hi, thanks for being interested! There've been some regressions lately, sorry :| Performance is #1 priority for me, and a big focus now, after last round of refactorings.

SkyMarshal 2021-08-17 16:38:32 +0000 UTC [ - ]

I hope the team considers abstracting this codebase into a general framework after its reached a sufficient level of maturity.

Would be nice to have a growing ecosystem of high-performance, rock solid, cross-platform native app frameworks.

literallyaduck 2021-08-17 17:58:14 +0000 UTC [ - ]

Can you decouple the UI from Spotify and make a generic interface to plug in N streaming services? Then people could make a Spotify provider, a file provider, a Pandora provider, an Amazon music provider, etc.

dreamofkoholint 2021-08-17 18:01:30 +0000 UTC [ - ]

I believe this is the goal of mopidy

literallyaduck 2021-08-17 19:35:42 +0000 UTC [ - ]

Close, but that looks like a server, I guess a client front end for it could be written in a native GUI.

pkphilip 2021-08-17 04:35:03 +0000 UTC [ - ]

Spotify should pay this guy to make their official native client or at least license the software from him.

mastax 2021-08-17 04:44:24 +0000 UTC [ - ]

Just cloned and built this - was running within 3 minutes with no effort. On Windows. That's unusual for native GUI apps to say the least.

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.

mcjiggerlog 2021-08-17 09:04:05 +0000 UTC [ - ]

For linux there is a snap of the app available, which is a lot easier than building it from source: https://snapcraft.io/psst-gui

golondon 2021-08-17 08:15:28 +0000 UTC [ - ]

Great work!

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?

jpochyla 2021-08-17 09:15:03 +0000 UTC [ - ]

Thank you! I took some time off after finishing my last full-time commitment, and wanted to cut my teeth on Rust a little bit -- exploring how feasible building cross-platform native apps is right now. So I've started building something that I'm missing and would like to use. Combine this with the pandemic, and here we are.

golondon 2021-08-17 09:29:55 +0000 UTC [ - ]

Thanks for the answer!

IceHegel 2021-08-17 01:19:14 +0000 UTC [ - ]

Tried to build on M1/Apple Silicon, but hit some errors. Looks like one of the dependencies isn't playing nice with arm but would love to give this a try.

Any rust devs have second? I think its the miniaudio dependency that's broken.

VirenM 2021-08-17 14:20:20 +0000 UTC [ - ]

This link should help[0]!

[0] https://github.com/jpochyla/psst/issues/87#issuecomment-9003...

noiv 2021-08-17 03:49:20 +0000 UTC [ - ]

Check the workflow for artefacts, the macos build runs on m1.

VirenM 2021-08-17 04:43:37 +0000 UTC [ - ]

IIRC the workflow targets macOS-latest, which is macOS Catalina 10.15 and the default host is `x86_64-apple-darwin`.

Does Github Workflow currently support M1 (arm 64 based). Am I missing something?

artursapek 2021-08-17 05:47:55 +0000 UTC [ - ]

Not yet, it's bottlenecking a lot of progress waiting to be made.

https://github.com/actions/virtual-environments/issues/2187

pleb_nz 2021-08-17 06:23:41 +0000 UTC [ - ]

I would love to see something like this adapted for YT music?

madeofpalk 2021-08-17 10:25:30 +0000 UTC [ - ]

> Spotify client with native GUI, without Electron, built in Rust

Does this use system UI control bindings? What makes a UI "native"?

pcf 2021-08-17 11:35:56 +0000 UTC [ - ]

YouTube Music – what do you guys think is the best client for this? Because YTM doesn't have its own app. Thanks!

glogla 2021-08-17 08:28:00 +0000 UTC [ - ]

Nice!

I also suspect that this one doesn't destroy ssds by running OPTIMIZE or whatnot on its internal sqlite, unlike the official client?

TheRealNGenius 2021-08-17 07:00:28 +0000 UTC [ - ]

The play button in the image looks off-center. Probably a case of centering horizontally as opposed to the centroid.

robertwt7 2021-08-17 04:24:28 +0000 UTC [ - ]

Really great job.

I wish there is one for apple music.. Since switching to apply music it has been a pain to open iTunes in my PC.

sdfjkl 2021-08-17 08:24:57 +0000 UTC [ - ]

I expect it will soon run into the troubles that NewPipe/SkyTube or even Barinsta suffer from.

miki725 2021-08-17 05:02:08 +0000 UTC [ - ]

This is amazing! Anybody knows anything similar for other music services like YouTube Music?

raymondgh 2021-08-17 05:53:34 +0000 UTC [ - ]

Add private listening by default and I’ll forget many other features

merrvk 2021-08-17 09:48:33 +0000 UTC [ - ]

This is excellent, just what I use spotify for, music.

maybe_pablo 2021-08-17 02:43:33 +0000 UTC [ - ]

This is awesome. I wish something like this existed for Slack!

edit: it does[0]!

[0]: https://news.ycombinator.com/item?id=28205333

yawaworht1978 2021-08-17 10:28:34 +0000 UTC [ - ]

So how do I download and run this on mobile phones? Would like both on Android and apple, is this possible?

qudat 2021-08-17 06:10:28 +0000 UTC [ - ]

And like moths to a flame, any mention of electron on HN spurs complaints only this community cares about.

forrestthewoods 2021-08-17 06:15:31 +0000 UTC [ - ]

Everyone hates slow, laggy, shitty software. The average consumer just has no insight as to why their software experience is bad. But don’t be fooled. A snappy, smooth experience does matter to consumers. Even when they can’t even quantify why one app “feels good” and another “feels bad”.

qudat 2021-08-17 22:21:27 +0000 UTC [ - ]

fast enough is good enough. All the words you used to describe a good experience are subjective and relative.

forrestthewoods 2021-08-19 02:00:50 +0000 UTC [ - ]

And your point is?

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.

tabtab 2021-08-17 20:55:58 +0000 UTC [ - ]

Why the hell is there not a stateful GUI markup standard? Mice and desktops did not go away with the advent of mobile. They are still the bread and butter of business, for example.

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.

jcq3 2021-08-17 06:59:45 +0000 UTC [ - ]

No ad blocking feature?

looperhacks 2021-08-17 07:10:11 +0000 UTC [ - ]

Since this client (like all third party clients) requires a spotify premium account, ad blocking shouldn't be necessary.

jhatemyjob 2021-08-17 03:55:58 +0000 UTC [ - ]

What a rookie mistake, making this open source. Hopefully the author wises up.

modshatereality 2021-08-17 06:39:46 +0000 UTC [ - ]

A vote for open source is a vote for minified javascript.