I might be misremembering, but I swear when Spotify launched it was a big revelation at the time because the client was super fast and playback was almost instantaneous. This was a big deal as other music players like iTunes were bloated.
Obviously streaming was the big selling point, something that iTunes didn’t offer at the time, but I swear the client was written in some native UI framework, along with the C/C++ library.
Or was the spotify UI always just a browser engine skin and the perception of speed was from the playback engine?
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.
(The comment is from a 2021 post about another Rust-based Spotify client.)
Ludvig Strigeus https://en.wikipedia.org/wiki/Ludvig_Strigeus?wprov=sfti1 wrote the original client, and fast, lean, native clients was his modus operandi. OpenTTD and uTorrent were both built the same way. I’ve been wondering on and off over the years why Spotify abandoned it. My guess is that it was hard to scale that approach and that a hybrid browser client was easier to scale when there are many different engineering teams working on different parts of the client.
I worked with a few people (tech) that Spotify later hired. Sweden is kind of small.
The calibre went from extremely high to surprisingly average within a decade. Not bad, to be clear, but kinda mid. I think they scaled too quickly and hit the 'bozo effect'.
It was originally native, then native with some web-based bits, and then the web-based bits slowly ate the whole thing. It seems the ease of development with web-tech compared to C++ (also the better font rendering and screen reader support) was just too tempting.
Interestingly the Spotify client was never based on electron but instead arrived independently at the "chromium + web app" architecture at around the same time as Atom did.
This was a fantastic read thanks for putting it together. I'm always fascinated by binfmt_misc, I remember fooling around with steganography a few years ago and putting executables inside images that could then be executed using a wrapper tool + binfmt_misc.
I think this is awesome though, feels like a lot of things on OS's could just be represented by databases - where does it end?
Sadly the materials in the lack changed over time, the insides are basically just cardboard honeycomb with a thin veneer around it.
So if you want to follow the lack mods on the web, especially ones written in the 2010s, you need to make sure you strengthen the legs to accommodate the hardware
I always wonder what motivates people to write posts on LinkedIn. Even before AI slop, it’s been the same for years with the cringiest posts somehow getting traction (“and the whole room applauded!”) - do people make money from the posts or something or is it more just a validation thing.
It would be interesting to see the models work on a book it hasn't been trained on yet. I guess sadly that means any book released very recently.
Definitely impressive demo, I do wonder though if the countless artwork, films, images etc produced over many decades around Lord of the Rings somewhat influenced the outcome of this though.
I definitely resonate with the "my software-oriented brain feels almost incompatible with this world of designing a home"
I really struggle with visualising what things are going to look like. Even trivial stuff like choosing a colour to paint the wall. Sticking tiny paint swatches or painting sections from sample pots just doesn't work either, it's either all or nothing to me. I don't have that aphantasia thing either, quite a vivid imagination actually, but for stuff like home decor and I'm useless
I'm not really in the market for a vision pro or VR headset so my version of this is to take a picture of a space (say a wall) and feed it into on of the AI image generators with a colour - probably taken from a screenshot of a paint vendor, and tell it to generate me an image of what the wall would look like in <this colour>.
Obviously it's not perfect but it's definitely given me a better idea of what, in the ballpark, something would look like when painted on the whole wall.
I've also had some success with getting it to generate stuff with wall decor on as well, even pasting in product images (e.g. "what would this mirror look like") - even on the "painted" wall.
It's not quite clear from the video but it looks to me like you park up in the garage, and there's a garage door on the other side. So as you 'check in', I guess the 'human' side you drove in on, that door closes, and then the other side opens for the robots to collect the car which I'm guessing is also where the car storage is.
Sort of feels like those videos you see of high tech warehouses where the human workers really only operate on the outskirts of the building, and everything central is completely automated (picking, sorting, storing, inventory etc)
I doubt the robots have sufficient enough traction/mobility to navigate on any surface that isn't reasonably smooth like tarmac. Also I'd wager the car park the robots go to isn't that far away from the drop off location, most likely on the same land owned by the airport.
I always wonder with solutions like these how stuff like alarm systems on the car cope with the car being lifted, the vibrations encountered as its being towed.
Unless they tell you to switch the alarm system off I guess.
I don't think car alarms detect these kinds of vibrations. It's specifically tilt and more impactful stuff. Certainly, the alarm is never going off when I get my car back via the lifts that I've used. It's probably too smooth.
The problem will be aftermarket car alarms. There used to be a car that parked on the street near my apartment that would go off ever time a bus went by it.
Illegally parked Cars are regularly lifted up and put into the back of flatbed lorries or towed away on back two wheels so this is arguably more gentle!
I asked this once in the past, but...do car alarms actually stop any actual crime ever? My entire life, every time I've ever heard a car alarm go off, literally everyone around just rolls their eyes and ignores it. If I actually looked up at a car alarm and the person outside the car just said "I'm so sorry! You know how it is", I would probably just nod and move on without really taking the time to figure out if it was really their car (because even if they were breaking in I don't have any desire to risk an altercation with someone doing that, and even if I were inclined to call law enforcement, I'm pretty sure they wouldn't come do anything because some random car's alarm is going off).
I want to be open minded that I'm missing something, but I can't help but feel like car alarms are just security theater with a side of nose pollution.
Obviously streaming was the big selling point, something that iTunes didn’t offer at the time, but I swear the client was written in some native UI framework, along with the C/C++ library.
Or was the spotify UI always just a browser engine skin and the perception of speed was from the playback engine?
Anyway, cool to see projects like this
reply