I actually find that Spotify is super buggy. If I switch devices it doesn't work (I have to select the new device at least five times), when I go underground with my phone it's super slow to realise that I've lost connection, and I usually have to restart the app for it to continue playing music.
My major issue with Spotify is that they keep changing the UX on me every week. I hate being part of some terrible a/b testing that I didn't consent too. They already have my money, why do they feel the need to tamper with my experience more? It's extremely infuriating.
I remember something was posted to HN a while ago about exporting your playlists from Spotify. That's my current hurdle to leaving the platform, if I can do that and whichever service allows me to import these playlists I'll be leaving.
For me switching playback device is quick and reliable if the device is a PC or phone. Whenever I try to select a connected Google speaker... it takes like 3-5 tries. I've found it is more reliable to use voice commands to get the speaker to play Spotify then I can use a phone/PC to select the song/playlist/podcast/etc. but it's kind of frustrating it just doesn't work well to begin with.
Big tech UIs are never made to satisfy the user. They are made to balance you between annoyance and acceptance. Just enough that you wont leave, but still getting frustrated by the aweful mechanics. In a way its also a good thing. Gives room to create a better variant
I think the point is that "all modern software" has all kinds of delays and buffering before playing, in contrast to this site where the audio just plays instantly and reliably.
It’s important to be mindful that the engineering is a minority slice of all the decisions that go into a product’s development.
The reason why some engineers need to be managed by Product and Project is that they don’t think hard about all the constraints, such as the cost of developing multiple native apps vs. the benefit that would provide.
This is often due to a failure of empathy: many engineers envision the common user being like them, when really the common user doesn’t know, notice, or care about whatever this “Electron” thing is.
I’ve seen, time and time again, developers having loud opinions about how choosing X over Y is because people are dumb, or cheap, or inexperienced. Those are all possible, but not nearly as common as they think. They’re easy explanations. But I rarely see developers do the engineering part where they quantify the issue and make a case for picking X over Y.
If developers hate Electron so much, the answer is to develop the skill set for making an informed argument that isn’t limited to just things like RAM and latency and file size. These often aren’t compelling business reasons. They’ll either learn more about why Electron gets picked, or they’ll have a solid case to make for why not to pick it.
I'm on a four-person team building a React Native app. RN is awful, I'll admit, but it would be impossible to work at the pace we do if we were maintaining fully parallel Android and iOS codebases.
Besides, it's the hardware's job to optimize for the capabilities of the SDK.
I was with you for the first paragraph. But that's just despicable thinking:
> Besides, it's the hardware's job to optimize for the capabilities of the SDK.
You can't possibly blame the hardware manufacturers for how poorly React Native runs. Even if the CPU engineers wanted to target React specifically and make it run better somehow (and you seem to think they should), where would they begin? React sits on top of 35 layers of software abstraction and runs in 2-3 virtual machines, how could they target RN?
Assuming they could add magical instructions that benefit React somehow, who's going to patch the 34 lower layers for React to benefit from it? The manufacturers? The React team? You?
I don't have any performance issues with React Native[0], so as far as I'm aware the status quo is fine with regards to how well the hardware is optimized for the SDK. The specific SDK I'm referring to is JSCore, obviously everything on top of that is third-party.
[0] My main beef with React Native is the total lack of useful stack traces. Also, when running on a device, when you tap Debug before manually setting your dev machine's IP, the app is bricked and you have to delete and reinstall it.
This is why you need to become king. In many places, it is the only way to truly deal with this nonsense. Top-down.
If you want a big org to defenestrate electron, your #1 mission is to generate a very scary narrative that electron is a 'legacy' technology and that your competition is already 2 steps ahead. You could spin little lies like "I overheard a member of KPMG discussing our competition's use of SSR and native local apps to deliver leading-edge UX while at lunch last week".
The super shitty thing about electron is that it does, arguably, reduce the overall complexity of delivering an end solution (regardless of the UX). My traditional arguments that complexity is at the heart of all evil do seem to go hard against this idea that I can code an app one time and deploy it everywhere. Clearly, this is not how it works out in practice, but the savings are definitely somewhere in the middle and detectable.
What does HN think about the complexity argument for using electron?
