I agree. They can only build things that have incredibly well defined surface contracts[0], where every tasteful decision has already been made, tested, and scaled.
And putting out a 50% solution counts as 'enough', even though the hard work was always in the last 50% (qa, deployment, docs, bug-fixing, etc.). And they get to effectively state 'we wrote X in Y', which makes for a great blog post, but terrible software.
Is it worthwhile for some abstract benefit of theory-crafting and experimentation? Sure–but it ultimately is more noise than signal.
Note that the bun-rust conversion blog post took an extra month or two to come out, because it wasn't just a theoretical marketing piece.
It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture.
Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.
I do this. The awkward thing is when I am in person or on the phone and have to explain that my customer email address is [their_business_name]@my_weird_domain.tld
But the people usually just nod along.
The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience.
It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most high-level websites could net-benefit from the ideas behind RSCs. I don't find it to be quite as much of a footgun as most people would suggest, but if you don't understand both server and client in a deep manner it is, of course, confusing.
Happy to dig in deeper for anyone who wants to have an honest discussion about the benefits and drawbacks without dropping into FUD. Even if you decide it's not for you, all web developers could glean something from their model.
It's also always worth noting that RSCs don't require a server, and still bring value without one.
It's a shame that VCs have corrupted a $200MM/year business into the perception as a failure. Who cares if the VCs didn't get a large return, or if the outsized impact of the software didn't quite fully capture the value created. $200MM/yr without aggressive R&D or operational costs could be an incredibly healthy business.
Maybe we should stop trying to build so many billion dollar/year businesses and work on more sustainable models.
It's really up to the artists. Many are surprisingly cool with it, though there are a few notable exceptions (i.e. Prince). Sounds like the artist in this particlar case gave their blessing.
Many bands (like GD and Phish) specifically note in their rider that venues must allow and provide space for tapers to bring their rigs in.
A sibling comment in this thread pointed out my project Relisten[0], which now has over 4,000 bands who have given explicit permission for people to tape, record, and share their concerts non-commercially. We've been operating our FOSS platform for 12 years, and most of the audio is hosted by Archive.org. I can't tell you how many bands have begged us to add them to our platform.
We landed an update on mobile last week that brought all 4,000 artists with a "collection" onto Relisten. That'll be coming to the web and sonos shortly as well.
We've been discussing the Aadam Jacob's collection with the archivists for some time. It comes with its own unique UX[0] and data constraints so we've been iterating on that and waiting for a critical mass of uploads before tackling it. We're getting closer though.
I agree with most of the sentiment in these comments. Archive and share non-comercially all the things!
[0] it's not "one" artist so it requires some custom UI, it should be unified through a single Aadam Jacob's collection, and it has a unique data path/structure on Archive.org relative to other collections
I run Firefox latest so it should work. There's always a risk when going from HTML5->Web Audio. There's an occasional blip that's impossible to avoid (or at least, I have never found a solution). It doesn't happen every time though. Try going from track 2 to track 3 in the second tab of the demo (if both are "READY" as web audio).
The problem with exclusively using the web audio API is that the entire track must be loaded into memory before playing it, whereas HTML5 loads progressively. So we use both to balance the techniques.
In prior versions of the library, we'd load the track in parallel to HTML5 and make the switch mid-track so it's actually far less noticeable even if it does blip. I'm considering adding that to the new version.
Another alternative is building a custom buffer using RANGE requests to exclusively drive it via the web audio API. But obviously that is a far more complex undertaking (and requires the server to support RANGE requests). I'm open to implementing it, though.
Gapless 5 was actually the precursor to this library over a decade ago, so Rego deserves full credit. They built the first example of gapless playback on the web and I took inspiration from their techniques.
Gapless 5 has a built in UI and style. Our library is headless: you bring your own UI and controls. It just depends on what your use-case is.
RSC by design does not ship everything to the client. That's one of its basic premises. It ships markup, composed in client interactivity, but you can shed a lot of the code required curate that markup.
This is pretty fascinating and comes with some complicated AI-world incentives that I've been ruminating on lately. The better you document your work, the stronger contracts you define, the easier it is for someone to clone your work. I wouldn't be surprised if we end up seeing open source commercial work bend towards the SQLite model (open core, private tests). There's no way Cloudflare could have pulled this off without next's very own tests.
Speaking more about the framework itself, the only real conclusion I have here is that I feel server components are a misunderstood and under-utilized pattern and anyone attempting to simplify their DX is a win in my book.
Next is very complex, largely because it has incrementally grown and kept somewhat backwards compatible. A framework that starts from the current API surface and grows can be more malleable and make some tough decisions here at the outset.
Crazy to see it's already being run on a .gov domain[0]. TTFGOV as a new adoption metric?
Yup! We’re just one link in the chain (bands, tapers, archivists, & the listeners), but I appreciate the sentiment. Alec and I have been running Relisten for over a decade and we’ve put a lot of work into it these past few years.
https://saewitz.com (email: [email protected])