[HN Gopher] Psst: Fast Spotify client with native GUI, without E...
___________________________________________________________________
Psst: Fast Spotify client with native GUI, without Electron, built
in Rust
Author : tim--
Score : 1040 points
Date : 2021-08-16 22:17 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jakecopp wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| reacharavindh wrote:
| 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 wrote:
| 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.
| maybe_pablo wrote:
| This is awesome. I wish something like this existed for Slack!
|
| edit: it does[0]!
|
| [0]: https://news.ycombinator.com/item?id=28205333
| tomduncalf wrote:
| 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
| pacifika wrote:
| 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 wrote:
| 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 wrote:
| 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).
| Vespasian wrote:
| 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
| bob1029 wrote:
| 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 wrote:
| 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 wrote:
| Archive.org still has copies.
| fabianhjr wrote:
| > source quality
|
| Spotify does at most MP3 320kbps, source quality would
| imply something like lossless FLAC/AAC
| tim-- wrote:
| I thought that the audio from Spotify was all ogg?
| vladvasiliu wrote:
| 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.
| dawnerd wrote:
| Rdio had an api that let you playback songs with a valid user
| token. It was really sweet.
| Qub3d wrote:
| 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 wrote:
| 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 wrote:
| This app does, too. It uses aspotify[0], which is just a
| rust spotify API wrapper.
|
| https://github.com/KaiJewson/aspotify
| Vespasian wrote:
| It also breaks the drm. Search for "decrypt" in the repo
| for psst.
| bluepizza wrote:
| They do not exist in a legal grey zone. Spotify has open APIs.
| Using them is allowed.
| nfd wrote:
| 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.
| thebean11 wrote:
| > This is too user facing and too easy to modify for DRM
| circumvention (if it isn't already doing that)
|
| How?
| Brian_K_White wrote:
| Google "pianobarfly"
| Brian_K_White wrote:
| I've been using pianobar and pithos and pandoroid for my paid
| Pandora account for over 10 years.
| stjohnswarts wrote:
| You realize there are other unofficial spotify clients and have
| been for years don't you?
| codetrotter wrote:
| > 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.
| GOATS- wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| This is a great point. It's truly no different than a third
| party manufacturer writing some device firmware to connect
| with Spotify.
| vladvasiliu wrote:
| 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.
| jeroenhd wrote:
| 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).
| skavi wrote:
| 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 wrote:
| 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.
| skavi wrote:
| I have not had to do that.
| asdff wrote:
| Your organization probably does not use secure sign on
| then.
| anonymousab wrote:
| > 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.
| 1vuio0pswjnm7 wrote:
| 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 wrote:
| > 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 wrote:
| "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 wrote:
| 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.
| tiew9Vii wrote:
| 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 wrote:
| 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.
| raphlinus wrote:
| 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.
| jpochyla wrote:
| 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
| mkj wrote:
| 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.
| globular-toast wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| If it's just for tracking, why not ship a JS runtime and run
| the tracking in a separate thread. No electron needed.
| stjohnswarts wrote:
| but electron does have a JS runtime included?
| pritambaral wrote:
| 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.
| tomc1985 wrote:
| Oh, don't forget the legions of cheap javascript newbs fresh
| out of boot camp that they can hire!
| [deleted]
| artursapek wrote:
| 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 wrote:
| love cryptowatch desktop! :) very performant.
| artursapek wrote:
| Thanks!
| toothbrush wrote:
| 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
| PascLeRasc wrote:
| I love this! Thanks for making it.
| dorian-graph wrote:
| I like this! Thanks for (re)posting it.
| raymondgh wrote:
| Add private listening by default and I'll forget many other
| features
| numlock86 wrote:
| > 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.
|
| -\\_(tsu)_/-
|
| 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.
| bluepizza wrote:
| Spotify API is open. He is not breaking any ToS.
| Vespasian wrote:
| The DRM decrypting stuff is breaking the ToS.
| tim-- wrote:
| 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.
| ubercow13 wrote:
| 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.
| codetrotter wrote:
| 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?
| miki725 wrote:
| This is amazing! Anybody knows anything similar for other music
| services like YouTube Music?
| dehrmann wrote:
| Nit: Spotify isn't electron-based.
|
| https://www.quora.com/How-is-JavaScript-used-within-the-Spot...
| laserbeam wrote:
| "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 wrote:
| And when people say "iPhone" they don't really care if it's
| an actual iPhone or just any smart phone?
| soheilpro wrote:
| 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.
| tiborsaas wrote:
| Also, they can lock out out overnight and good luck appealing
| to the legal team.
| CamperBob2 wrote:
| How does the nature of the API determine the number of users?
| soheilpro wrote:
| I meant rate limits. Edited my original comment.
| tim-- wrote:
| The trick would be to have each user register their own API
| key.
| ShroudedNight wrote:
| This seems like such an obvious answer, why isn't it
| significantly more common?
| kzrdude wrote:
| Because that will also self-select the audience to be
| really small.
| tim-- wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The Spotify API doesn't support private API keys, so you
| need to create your own OAuth App and then authorize it for
| yourself.
| exciteabletom wrote:
| I've been using Spot[0], which is another Rust Spotify client
| using GTK.
|
| [0]: https://github.com/xou816/spot
| boudin wrote:
| And for those wanting a ncurse client, there is ncspot [0]
| which is quite stable and complete.
|
| [0] https://github.com/hrkfdn/ncspot
| nicolaslem wrote:
| 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 voila 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 wrote:
| Instantly installed and wow - this is outstanding. Thanks for
| the recommendation, had never heard of it.
| stjohnswarts wrote:
| 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 wrote:
| 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.
| golondon wrote:
| 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 wrote:
| 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 wrote:
| Thanks for the answer!
| jreese wrote:
| 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.
| swiley wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| _Algernon_ wrote:
| 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.
| joshstrange wrote:
| 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 wrote:
| 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.
| rogy wrote:
| 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
| joshstrange wrote:
| 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 wrote:
| Roughly how long have you had your Airpod Pros?
| joshstrange wrote:
| 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.
| JohnWhigham wrote:
| 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.
| YetAnotherNick wrote:
| 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.
| eurasiantiger wrote:
| 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 wrote:
| 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 wrote:
| 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.
| swiley wrote:
| Between their screw ups and Pine64's successes that
| hopefully won't happen.
| rubiquity wrote:
| 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 wrote:
| 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.
| matthewfcarlson wrote:
| 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?
| yupper32 wrote:
| 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.
| josephg wrote:
| 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.
| vxNsr wrote:
| 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 wrote:
| 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.
| fossuser wrote:
| 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 wrote:
| Yeah there's currently a war on to be the YouTube of
| podcasts and Spotify is currently in the best position.
| briish wrote:
| I was really surprised that Podcasts on Spotify became
| that popular. Thats what exclusives can do, iI guesd
| fossuser wrote:
| 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).
| pornel wrote:
| 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.
| tyre wrote:
| 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.
| jazzyjackson wrote:
| 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 wrote:
| 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 wrote:
| That makes sense, thanks. I remember now I was using
| Tidal which did have this option.
| bleachedsleet wrote:
| 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/
| fossuser wrote:
| 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.
| geraneum wrote:
| 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 wrote:
| 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.
| gizdan wrote:
| 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...
| mackrevinack wrote:
| 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
| dangravell wrote:
| 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.
| jfrunyon wrote:
| 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.
| throwaway1777 wrote:
| 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 wrote:
| On iphone I can't seem to actually choose the bluetooth
| device to play to from the app itself. iOS limitation?
| modernerd wrote:
| 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.
| cik wrote:
| 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.
| lwansbrough wrote:
| 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 wrote:
| It works similar on Linux with pipewire/alsa/pulse, there
| are several guis for such.
| konart wrote:
| I'd rather use https://staticz.com/soundcontrol/ (which I do
| use actually) than rely on an app like Spotify to be honest.
| vladvasiliu wrote:
| 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.
| jazzyjackson wrote:
| 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?
| sbuttgereit wrote:
| 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 wrote:
| 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
| ivolimmen wrote:
| 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).
| mcjiggerlog wrote:
| 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
| jeroenhd wrote:
| 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 wrote:
| >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 wrote:
| This is not really the case, you need a Premium account for
| Psst to work.
| mimimi31 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| ho_schi wrote:
| 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/
| merrvk wrote:
| This is excellent, just what I use spotify for, music.
| arendtio wrote:
| 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?
| pcf wrote:
| YouTube Music - what do you guys think is the best client for
| this? Because YTM doesn't have its own app. Thanks!
| literallyaduck wrote:
| 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 wrote:
| I believe this is the goal of mopidy
| literallyaduck wrote:
| Close, but that looks like a server, I guess a client front
| end for it could be written in a native GUI.
| sdfjkl wrote:
| I expect it will soon run into the troubles that NewPipe/SkyTube
| or even Barinsta suffer from.
| qudat wrote:
| And like moths to a flame, any mention of electron on HN spurs
| complaints only this community cares about.
| forrestthewoods wrote:
| 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 wrote:
| fast enough is good enough. All the words you used to
| describe a good experience are subjective and relative.
| quaintdev wrote:
| 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 wrote:
| 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.
| dtagames wrote:
| 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.
| avh02 wrote:
| > 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 wrote:
| Yeah your necessities don't match Spotify's. If they took
| this path, the web version is probably important for them.
| TchoBeer wrote:
| I use the browser pretty frequently, I don't even have
| Spotify desktop on my work computer
| jbverschoor wrote:
| 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.
| S0und wrote:
| > 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...
| MonoidWitness wrote:
| 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.
| SkyMarshal wrote:
| 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.
| riskable wrote:
| 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
| maccam94 wrote:
| I wonder if that executable is stripped, often that saves a
| decent chunk of memory.
| mkj wrote:
| 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.
| xyst wrote:
| I wonder what the footprint will look like once the author
| writes in all of the missing features
| lostmsu wrote:
| According to this:
| https://forums.overclockers.com.au/threads/winamp-memory-usa...
|
| Winamp 2.72 only used about 8 megs of RAM.
| dotancohen wrote:
| Eight Megs And Counting.
|
| Wow, eight megs was once so much memory that we would laugh
| about applications that even approached it.
| TchoBeer wrote:
| 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.
| rvz wrote:
| 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.
| jpochyla wrote:
| 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).
| userbinator wrote:
| 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.)
| madeofpalk wrote:
| > Spotify client with _native GUI_ , without Electron, built in
| Rust
|
| Does this use system UI control bindings? What makes a UI
| "native"?
| rob-olmos wrote:
| Related to the Spotify desktop client, I still don't understand
| why I have to restart the app when my internet connection is
| interrupted.
| glogla wrote:
| Nice!
|
| I also suspect that this one doesn't destroy ssds by running
| OPTIMIZE or whatnot on its internal sqlite, unlike the official
| client?
| EastSmith wrote:
| 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.
| jcq3 wrote:
| No ad blocking feature?
| looperhacks wrote:
| Since this client (like all third party clients) requires a
| spotify premium account, ad blocking shouldn't be necessary.
| andrewmcwatters wrote:
| 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.
| BoxOfRain wrote:
| 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!
| jazzyjackson wrote:
| Nothing illegal about it, Spotify has a well documented API and
| supports third party clients
| sunshineforever wrote:
| So does this version not have advertisements or something?
| laserbeam wrote:
| 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.
| laserbeam wrote:
| 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 wrote:
| Hmm it was years ago but I remember now my chatbot was
| controlling the playback session in a browser, you're
| right.
| gjs278 wrote:
| 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.
| TheRealNGenius wrote:
| The play button in the image looks off-center. Probably a case of
| centering horizontally as opposed to the centroid.
| robertwt7 wrote:
| 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.
| fleddr wrote:
| 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 wrote:
| MS Office is React now? Wow. Does not surprise me though.
| gruez wrote:
| That statement's horribly misleading. The desktop versions
| (eg. windows or mac) aren't, but the web versions are.
| fleddr wrote:
| 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 wrote:
| > 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 wrote:
| 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
| :)
| yawaworht1978 wrote:
| So how do I download and run this on mobile phones? Would like
| both on Android and apple, is this possible?
| dt2m wrote:
| 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.
| sirsinsalot wrote:
| 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.
| cik wrote:
| 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.
| pleb_nz wrote:
| I would love to see something like this adapted for YT music?
| mythz wrote:
| 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.
| ap-andersson wrote:
| 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...
| mythz wrote:
| 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 uTorrent 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.
| jayjader wrote:
| > 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.
| fps_doug wrote:
| 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 uTorrent in College, you name it...
| mikeyjk wrote:
| 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 wrote:
| 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.
| vsnf wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sincerely wrote:
| >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.
| scns wrote:
| Studies showed that people who download more, spend more
| money on music than those who don't.
| drdec wrote:
| 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.
| brianzelip wrote:
| > 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 wrote:
| Money tends to change people.
| Nevermark wrote:
| 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 wrote:
| 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?
| slumpt_ wrote:
| 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?
| mythz wrote:
| 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.
| slumpt_ wrote:
| 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.
| ducktective wrote:
| 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_ wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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.
| mythz wrote:
| 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_ wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| > 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_ wrote:
| 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.
| blub wrote:
| 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 wrote:
| > 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.
| handrous wrote:
| Off and on Android (and iOS) developer here: no, not
| really, unless you throw top-end hardware at it.
| GekkePrutser wrote:
| 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.
| Kiro wrote:
| 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 wrote:
| > _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.
| ducktective wrote:
| 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 wrote:
| 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
| iCarrot wrote:
| 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 wrote:
| 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.
| kristiandupont wrote:
| In my experience, my VSCode setup responds just as fast as
| my fully extended VIM does.
| inter_netuser wrote:
| 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 wrote:
| Somethings wrong with your vim setup then.
| cjblomqvist wrote:
| 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 wrote:
| 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_ wrote:
| 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_ wrote:
| 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 wrote:
| Can it send e-mails?
| twobitshifter wrote:
| 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.
| huhtenberg wrote:
| > _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
| cronix wrote:
| > 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
| judge2020 wrote:
| 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.
| shp0ngle wrote:
| 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.
| open-source-ux wrote:
| 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://b
| log.kowalczyk.info/article/2f72237a4230410a888acbfc...
| Shacklz wrote:
| > 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.
| handrous wrote:
| My wife doesn't know WTF Electron is, but definitely notices
| when a pile of Electron "apps" are slowing her computer to a
| crawl.
| ipv6ipv4 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| thesuitonym wrote:
| > 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.
| southerntofu wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| systemvoltage wrote:
| 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_ wrote:
| trashcan, butterfly keyboard, bending displays, less
| intuitive user interface in post of similar style whit ios?
| systemvoltage wrote:
| 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.
| inter_netuser wrote:
| 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.
| panda88888 wrote:
| 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
| gsich wrote:
| They do care if they have a comparison.
| nicoburns wrote:
| 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 wrote:
| > 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.
| legulere wrote:
| 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)
| snek_case wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| jgb1984 wrote:
| 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 wrote:
| > _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 wrote:
| 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 wrote:
| > _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 wrote:
| >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.
| westoncb wrote:
| 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.
| runawaybottle wrote:
| 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.
| SilverRed wrote:
| 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.
| westoncb wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| westoncb wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| TeMPOraL wrote:
| 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 wrote:
| > 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 wrote:
| I'd wager those devs will be told to use the official
| Slack client.
| TeMPOraL wrote:
| > _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 wrote:
| > ... 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 wrote:
| > _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.
| scns wrote:
| You can pick a modern framework that cares about
| performance, eg Svelte or Solid.
| westoncb wrote:
| > 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)
| bavell wrote:
| 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.
| blub wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| jack_pp wrote:
| 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.
| ryosuke wrote:
| 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.
| jamil7 wrote:
| The iOS client isn't much better, it seems as if they've
| given up on decent offline support all together.
| bradstewart wrote:
| 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.
| rightbyte wrote:
| > 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.
| vxNsr wrote:
| 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 wrote:
| 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 wrote:
| 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.
| blub wrote:
| 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 wrote:
| 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.
| spoonjim wrote:
| 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 wrote:
| Transferring playlists is pretty easy. There's a web app
| that connnects to most services and moves tracks between
| them
| specialist wrote:
| Probably. But I'd like to think fit & finish makes an app
| more sticky.
| jcelerier wrote:
| > Our QT/C++ client had decent performance but was noticeably
| heavier than Spotify's.
|
| Wasn't Spotify's client Qt too ?
| mythz wrote:
| 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/R
| esources/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 wrote:
| TIL, I only ever used it on Linux and assumed it was the
| same everywhere
| [deleted]
| djhworld wrote:
| 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.
| MasterYoda wrote:
| 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 wrote:
| 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.
| stayfrosty420 wrote:
| 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.
| miki123211 wrote:
| 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 wrote:
| Rdio's app was stunning compared to Spotify imo.
| montag wrote:
| 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.
| tjbiddle wrote:
| 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.
| matheusmoreira wrote:
| > unauthorized clones
|
| Are we really living in a world where we need "authorization"
| to replace some corporation's software with our own?
| spullara wrote:
| I really don't know what yall are going on about. I hit play on
| a song in spotify and it just plays instantly.
| ClawsOnPaws wrote:
| 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.
| jatone wrote:
| 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.
| blowski wrote:
| 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.
| mwcampbell wrote:
| > 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
| csmpltn wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Apple:
| https://machinelearning.apple.com/research/creating-
| accessib...
| dailyanchovy wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| mitemte wrote:
| 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/documenta
| tion/Ac... [1] https://developer.apple.com/documentation/
| applicationservice...
| jcelerier wrote:
| 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
| miki123211 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jpochyla wrote:
| 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
| dalmo3 wrote:
| 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.
| pkphilip wrote:
| Spotify should pay this guy to make their official native client
| or at least license the software from him.
| tim-- wrote:
| 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.
| brianmcc wrote:
| 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 wrote:
| Oh wow. I thought that was only a mobile thing, going to have
| to check the "desktop" app now...
| avh02 wrote:
| 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-- wrote:
| Sadly, this does not work on the newest version of their
| client.
| DynamicStatic wrote:
| True but you can use a old version and set the update
| folder to read only.
| avh02 wrote:
| 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 wrote:
| > 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-- wrote:
| 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.
| kuu wrote:
| 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 wrote:
| 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.
| gxqoz wrote:
| 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.
| milofeynman wrote:
| 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 wrote:
| Under the artist's page, select their Discography. Songs not
| released under albums should show up under 'Singles'
| tim-- wrote:
| 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.
| chx wrote:
| 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 wrote:
| > a forum on a now defunct tracker
|
| Years have passed. I still havent filled the gap left by
| whatcd...
| chx wrote:
| Nothing can, it seems. What wanton destruction. Oink's Pink
| Palace first, then what.cd
| 101011 wrote:
| Oink...talk about the glory days. If it existed, it was
| there.
| [deleted]
| IceHegel wrote:
| 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.
| noiv wrote:
| Check the workflow for artefacts, the macos build runs on m1.
| VirenM wrote:
| 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 wrote:
| Not yet, it's bottlenecking a lot of progress waiting to be
| made.
|
| https://github.com/actions/virtual-environments/issues/2187
| VirenM wrote:
| This link should help[0]!
|
| [0]
| https://github.com/jpochyla/psst/issues/87#issuecomment-9003...
| tabtab wrote:
| 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.
| mastax wrote:
| 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.
| jjice wrote:
| 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.
| jhatemyjob wrote:
| What a rookie mistake, making this open source. Hopefully the
| author wises up.
| modshatereality wrote:
| A vote for open source is a vote for minified javascript.
___________________________________________________________________
(page generated 2021-08-17 23:02 UTC)