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 just checked and I get charged ~8% in fees on a 10 euro transaction on Stripe. Of course some of that is the low transaction amount (flat 0.30), but it's brutal for a small business like myself.

    2.9% + 1.5% (intl card) + 1% (currency conversion) + 0.30

    Payment amount (€1.00 EUR = $1.15253 USD)
 
    €10.00 EUR -> $11.53 USD

    Fees

    Total:    - $0.93 USD

    Stripe currency conversion fee 
    - $0.12 USD

    Stripe processing fees
    - $0.81 USD

    Net amount
    $10.60 USD

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.

Maybe we should stop trying to build so many billion dollar/year businesses and work on more sustainable models.

https://github.com/cloudflare/workerd

The parent's suggestion still creates artificial scarcity, which is the real issue: people buying tickets they have no intention of using.

The problem is that the artists, venues, and ticketing companies benefit from this artificial scarcity. So we'll never see it change.

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.

[0] https://relisten.net (https://github.com/RelistenNet)

(The 4,000 number will be coming to web soon - it's available today on our mobile apps)

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

could just be a coincidence

Comments URL: https://news.ycombinator.com/item?id=47392479

Points: 10

# Comments: 3

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 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.

I just released v4 of my gapless playback library that I first built in 2017 for https://relisten.net. We stream concert recordings, where gapless playback is paramount.

It's built from scratch, backed by a rigid state machine (the sole dependency is xstate) and is already running in production over at Relisten.

The way it works is by preloading future tracks as raw buffers and scheduling them via the web audio API. It seamlessly transitions between HTML5 and web audio. We've used this technique for the last 9 years and it works fairly well. Occasionally it will blip slightly from HTML5->web audio, but there's not much to be done to avoid that (just when to do it - lotta nuance here). Once you get on web audio, everything should be clean.

Unfortunately web audio support still lacks on mobile, in which case you can just disable web audio and it'll fallback to full HTML5 playback (sans gapless). But if you drive a largely desktop experience, this is fine. On mobile, most people use our native app.

You can view a demo of the project at https://gapless.saewitz.com - just click on "Scarlet Begonias", seek halfway in the track (as it won't preload until >15s) and wait for "decoding" on "Fire on the Mountain" to switch to "ready". Then tap "skip to -2s and hear the buttery smooth segue.

Comments URL: https://news.ycombinator.com/item?id=47222271

Points: 35

# Comments: 11

Comments URL: https://news.ycombinator.com/item?id=47151545

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47150417

Points: 7

# Comments: 0

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?

[0] https://www.cio.gov/