captbaritone

As part of building Webamp I did a side quest to enable rendering Windows animated cursor on the web. You can read about it here: https://jordaneldredge.com/rendering-animated-ani-cursors-in...

Interesting! I've only ever actively used subdomains of webampskins.org, however during early testing I set a hard coded IPV4 IP as the A name for the root domain. Now it looks like that IP has been handed off to someone else who is hosting a spammy site.

Thanks for flagging, I removed that A name record.

This is an idea that 3D artists have been playing with for years. I've collected 63 different artists imaginings of this here: https://jordaneldredge.com/physical-winamp/

Looks like that was a "modern" Winamp skin, which are unfortunately not displayed in the museum: https://winampheritage.com/skin/pimeer-v2-2-ultime/142664

Author of the Museum here. Agreed! That was true for "classic" Winamp skins which are what is shown here. I also took a stab at "modern" Winamp skins which were fully dynamic and scriptable and wasn't quite able to bring that to the browser. I did a writeup of that work here: https://jordaneldredge.com/webamp-modern/

Oh! Author of the project here, but not op. Happy to answer any questions.

The code for the Museum as well as the Webamp player that powers the interactive preview can be found here: https://github.com/captbaritone/webamp

You can also find a blog post I wrote about the project here: https://jordaneldredge.com/winamp-skin-musuem/

His goal was to get a faster oracle that encoded the behavior of Pokemon that he could use for a different training project. So this project provides that without needing to be maintainable or understandable itself.

Former classical singer here. Only theory I can come up with is that opera tends to have large casts where all the singers are credited individually which would inflate the absolute numbers of "artists" relative to other generes. I still struggle to imagine this accounting for bringing such a niche genera to the top here.

I recall hearing that SQLite actually had some significant issues with choosing public domain as their license and somewhat regret the decision. Apparently it’s not a concept which has broad understating internationally, and there’s less legal precedent in a software context which has made it harder for some teams to adopt due to concerns from legal departments.

Author here. I think we might actually be in agreement. My point is that in React you don't formally describe the transition table because (and I think this is where we agree) that's infeasible for an app of any reasonable size.

The observation I'm trying to capture in this post is that even though we don't define a formal transition table, we actually _do_ implicitly define the set of valid (user) transitions for each state via the event handlers we bind into the DOM when our React component tree renders that state.

Hey! I run the museum, and these stories of people finding things they created and thought had not survived, are so fun to read. Also, your skin is… incredible.

There were also “other” reasons to skip version number 4: https://jordaneldredge.com/notes/winamp-4-skin/

Full link with the skin preloaded for anyone curious: https://webamp.org/modern/?skin=https://kepano.s3.amazonaws....

Good point. I’ll update the post.

Possibly this one? https://skins.webamp.org/skin/8fab8401c9ed83068a677f8ec08842...

The closest I've seen is https://re-amp.ru. Not sure about codecs

Hey! That's my side project. So glad to hear people enjoy it.

Note that they don't actually say "open source" anywhere.

Grats author here. I agree, decorators would be preferable. However, decorators are a runtime construct and as such cannot be applied to type constructs. This means you can’t, for example, annotate an interface definition, or add a description to an argument (since arguments are declared using an object type literal).

You can read more about how I ended up settling on docblocks here: https://grats.capt.dev/docs/faq/why-use-comments

Grats and Relay (I work on both) can be combined to get this developer flow, and it’s pretty incredible. Would love to see it working with Strawberry as well.

https://x.com/captbaritone/status/1748020699263045659?s=46

Example project with this setup working can be found here: https://github.com/captbaritone/grats-relay-example

Grats author here: Strawberry was definitely (and continues to be) a big inspiration for Grats, I’m pleased to hear that you see the resemblance!

gql.tada is indeed very impressive and I think shares many of the same values as Grats. That said, I believe that today they only support the client path. Editor features and type generation for queries/mutations and fragments, although they do have interest in having a server story as well: https://github.com/0no-co/gql.tada/issues/10

This approach works fine for simple projects, but you also need to provide an implementation, and the two need to line up. This is what leads people to want solutions that either generate implementation types from the .graphql schema or (as Grats does) generate the .graphql schema from the implementation.

Grats author here. It's spiritually similar to type-graphql or typegql, except that it's able to see the TypeSCript types as well as the class/method names. So, there's less duplication, less overhead, and a less confusing API (specifying argument types and return in type-graphql for example is pretty confusing.

Unlike Pothos, this implementation-first approach is able to leverage simple type script names and types, whereas Pothos requires you to explicitly define all the names and types using their builder-pattern-for-graphql-SDL API.

More here on why Grats does not use decorators like type-graphql: https://grats.capt.dev/docs/faq/why-use-comments/

Grats author here. That's supported as well. You can simply write annotated wrapper functions/classes/types/interfaces around your GraphQL agnostic API.