425 karma · joined June 17, 2022
Thanks for the feedback though, I'll delay the location request to later in the flow + add a popover which explains why it's needed when we get to beta.
These people killed people and hid their mess. Plain and simple.
If it's the former: React
If it's the latter: Svelte (Especially with Svelte 5 around the corner)
I've kept it thus far because I believe in the mission but man... I get why other promising search engines have fallen to Google.
Svelte's pattern for data binding (with the exception of the $: reactivity) is exceptionally idiomatic and as close to standard web as 2-way reactivity will ever be. Easy to get to grips with as a newbie and a breath of fresh air for someone with years of fe experience under their belt.
Svelte embodies the KISS principle and long may that last.
They should really be using the existing <script context="module"> syntax to have a context="server" portion instead of splitting the file out.
Heck, it could even just be an import for a server.ts file in the same root directory if people really liked the +whatever style of having the server code separated.
It feels especially redundant when you're building a static app or SPA. The sort of overly opinionated nonsense that put me off React and on to Svelte in the first place.
I've decided against making the switch to SvelteKit and instead rely on good old Svelte because I can have a /pages/Whatever.svelte encapsulates the structure and core logic of each view/page. It's clean, it's HTML-like, it works and more importantly, I can immediately wrap my head around it when coming back to the project after a period away.
I deeply love the guy, but I really think Rich should walk back this decision and default to the "whats the cleanest pattern that people can easily wrap their head around" approach.
You can also follow updates on Reddit -> https://www.reddit.com/r/RadiantApp/
Long term I'm going to go with something self-hosted using Tortoise TTS etc but I also want to break away from Google's Cloud Speech as that can cost me hundreds a month when the user base has a peak so this looks great, thank you!
Obviously, I'd expand this with more full-fledged shows if people liked the format. You could even configure it with "I listen to my podcasts in the morning / after noon / when I'm driving" etc in settings and Rad would factor that in when choosing when to play em.
I did it because I don't have the time to maintain for 3 platforms in parallel without one falling behind and I'm not a fan of React native personally. I spent a good chunk of time testing with much older hardware as a target to make sure performance wouldn't be a noticeable distraction for users and I'm happy with how it turned out :)
But we moved to be compliant with their guidelines after that and I carried it on as a labour of love.
Now I'm actively looking at moving away from Spotify and on to my own data set and APIs that can match what Spotify has. I've built something like it before using the Cover Art Archive for the artwork, Acoustic/MusicBrainz for the metadata and custom logic built atop so I know it's possible.
Once I've done that I can start looking for sponsors.
There is always the possibility that if the userbase really scales up, Spotify would grant me a commercial license and allow me to commoditise the platform but I don't need that to happen really.