Rad.FM maker here. Thanks for at least trying it. A) the web app is still in alpha. B) Rad needs your location to make what it says to the listener relevant to where you are and your current time. Also, news & weather need your location.
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.
Have they alluded to what they're using for that voice? It's Bark/ElevenLabs levels of good. Please god, let them release this voice model at current pricing....
I've been a paying subscriber to Kagi for over a year and I'm sad to say it just gets in my way and I often find myself just wishing I was using Google.
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.
If you follow Youtubers like Jim Browning that tackle this sort of scam-based cybercrime operations then this will come as absolutely no surprise to you.
I just want to write Svelte and get native apps out the other end. I know we have SvelteNative but that's not great and is a big abstraction. React here is a bit of a bummer i'm not going to lie.
Recently re-discovered him due to a Business Wars podcast episode on him. The dude deserves his own movie. Not a nice way to go but he'll surely be remembered.
Apple Music has so few 3rd party apps in fairness. Spotify has basically shafted the developer community who built their platform and fan base for them (Soundwave, Greenroom, and all the other services that have been built on top of them that Spotify have cannibalised and killed) so they deserve a mass migration even of 3rd parties. Here's hoping this is it.
To my eye, this makes vanilla JS more like React rather than making vanilla JS reactive. I'm basically looking for an even lighter Svelte if I can get it. Maybe this just isn't for me!
With all the love in the world, that's probably down to the sunk-cost fallacy. You've invested a chunk of time into understanding the idiosyncrasies and non-standard methodologies that React has pushed at you over the years.
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.
The more I see it the more I'm certain that Rich and the team screwed the pooch with the whole '+page.server.ts' stuff.
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.