4 ms·
Interesting exercise. It explores the upper bounds of what can be done this way and proves that forms and links don’t need to be an SPA monstrosity. But compar
by gherkinnn 3y ago
Interesting exercise. It explores the upper bounds of what can be done this way and proves that forms and links don’t need to be an SPA monstrosity.
But comparing this to the linked Astro version [0], Astro wins hands down. It feels faster, URL works, and behaves more predictably.
Turns out a music player is best built using SPA-y tech. And it is possible not to build a monstrosity along the way. These so-called island architectures are right on the money. It is server first, but breaking out of it and building some client side interaction is seamless when required.
0 - https://astro-records.pages.dev/ https://astro-records.pages.dev/
- hcks 3y agoCan we stop using expressions such as “SPA monstrosity” when this “unbloated HMTL” website breaks copying links, the back button, the address bar, don’t cache ressources properly, etc etc
- sitzkrieg 3y agoconsider it browserwreck feature complete /s
- zero_shift 3y agoGive it a couple of years, people will bemoan the "Frankenstein" of partial server rendering, pine for the "consistency" of SPAs instead.
- jadbox 3y agoThe Astro version feels just like a SPA to me.
- hrisng 3y agoI agree. They did a very cool exercise. But let be honest here, most of the users today would not put up with a UX like that. Even for a tech person who is used to some very hostile UX day in and day out, I would still not use that if I have the option.
- meiraleal 3y agoThe Astro one is indeed not a SPA. But the original one is a SPA composed of multiple iframes. It is like old AJAX hacks.
- benbristow 3y agoThose albums sound a bit different! :)