switz

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

Can someone explain to me if EU card transactions are capped, why Stripe charges me (US) the full ride on my EU customer's cards? In fact, I get charged even more for EU cards – perhaps as much as 2.5% extra.

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

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.

Please do not wash your authentic writing through an LLM.

Workers runtime is open source and permissively licensed fwiw

https://github.com/cloudflare/workerd

Though this would be mildly annoying for the earnest case (selling a ticket to a friend), it would be the actual solve to the problem.

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.

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.

[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)

Oh hey, it's me! Happy to answer any questions

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

4 1's == 4/1

could just be a coincidence

really appreciate you building and maintaining it! state machines are the truth!

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.

Thanks! Please do share if you choose to implement it (you can open a Github issue). I'd be glad to add any projects using it to the README.

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?

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

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.

Had to give the Dead a little nod here

TIL about ambiguous width unicode characters. Turns out some locales render these chars as double width. I'm attempting to work out a solution.

Seems like maybe there are some universal half-width characters that can be used.

https://www.unicode.org/reports/tr11/

Fair point. I added basic mermaid parsing to the library so you can do that here too.

    $ echo 'flowchart LR
        web([Frontend])
        subgraph platform [Cloud Platform]
          api([API Server])
          db[(Database)]
          api --> db
        end
        web -->|HTTPS| api' | npx box-of-rain --mermaid

                           ╔══ Cloud Platform ════════════════════╗
                           ║                                      ║
    ╭──────────╮           ║  ╭────────────╮      ╔════════════╗  ║
    │          │           ║  │            │      ║            ║  ║
    │ Frontend │ ─── HTTPS ──▶│ API Server │ ────▶║  Database  ║  ║
    │          │           ║  │            │      ║            ║  ║
    ╰──────────╯           ║  ╰────────────╯      ╚════════════╝  ║
                           ╚══════════════════════════════════════╝

I agree with you that we should care more about resource usage, but it's a false comparison. Backend devs control where their code runs, frontend devs don't.

You can make more precise decisions when you have complete control over the environment. When you don't, you have to make trade-offs. In this case, universality (electron and javascript) for higher RAM usage. It doesn't seem to have slowed Discord's adoption rate.

Even if they built their desktops apps in native code and UI, they'd have to build a JS website in parallel.

If we get to the point that AI can run a complete business unencumbered then the world looks very different. At this time, I have very little confidence that AI today can operate my business untouched while OOO. Nor would I want it to. I enjoy my work and I don't trust AI to run amuck with the valuable asset that is my business.

But it certainly has helped me gain velocity working alone. My business is very hands off after ten years of automating most things and cleaning up the hot paths. Things break, but usually due to external factors that have nothing to do with me. A few support emails and hands-off monitoring is hardly a deal-breaker for me on vacation. I'm not entirely sure why zero-effort is a goal, when you can genuinely attain a 5-hour work week today.

AI is really just a tool and there's a lot of incremental room between "helpful" and "totally autonomous". This calculus could all change one day, but it's not a personal desire of mine.

Yup, I always say – the hardest part of my job is that if I don't do it, nothing gets done. That copy error on the website. That minor bug. We take for granted the velocity we get by having colleagues. If I get lazy, everything grinds to a halt. And those little nits add up. But I strongly agree it's all worth it.

It really depends on what you want to do. By the nature of being self-directed, you elect what roles you want to play. I personally don't love the marketing and sales cycles, so my current business is B2C and I don't do any marketing.

Almost all growth was done via word of mouth. There are business models whose network effects lean in this direction. In order to use my product, you must bring along peers so it's inherently 'viral'. I fell into this by accident rather than by some grand design, but it became obvious to me after I saw it happen. Design a business in which the flywheel can spin without you, if you don't want to spend your time marketing.

My next business that I'm working on is B2B, so I'll have to have a much stronger handle on marketing and sales. But I'm more ready for that now, after a decade of running a B2C business.

Thanks for being so transparent. As a fellow solo bootstrapper, I think the thing people most often misunderstand is the relative inconsistency (income, "wins", the camaraderie, etc.) so it's nice for you to bare all.

That being said, you do get the consistency of independence and autonomy. As I watch my peers deal with crappy work environments, losing their jobs, and other bullshit, I just keep chugging along: self-directed and happy to not have to answer to anyone.

I've found it tough to talk about being a solo bootstrapper though. People don't seem all that interested in it until you catch them in the right light or perspective. Mostly they just care to know how much money you make (which to me ends up being rather shallow), or they can't relate to the process since it's so divorced from the traditional path. I mostly just keep my head down and keep working, since that's what I enjoy the most.

I was evaluating it recently but it's not FOSS, so buyer beware. I'm totally fine with commercialization, but I hesitate to build on top of data stores with no escape hatches or maintenance plans–especially when they're venture backed. It is self-hostable, but not OSS.

I’ve had a lot of success rendering svg charts via Airbnb’s visx on top of React Server Components, then sprinkling in interactivity with client components. Worth looking into if you want that balance.

It’s more low level than a full charting library, but most of it can run natively on the server with zero config.

I’ve always found performance to be kind of a drag with server side dom implementations.

Around a hundred per second at peak. Even though my server can handle it just fine, it muddies up the logs and observability for something I genuinely do not care about at all. I only care about seeing real users' experience. It's just noise.

If you have a lot of pages, AI bots will scrape every single one on a loop - wiki's generally don't have anywhere near the number of pages as an incremented entity primary id. I have a few million pages on a tiny website and it gets hammered by AI bots all day long. I can handle it, but it's a nuisance and they're basically just scraping garbage (statistics pages of historical matches or user pages that have essentially no content).

Many of them don't even self-identify and end up scraping with shrouded user-agents or via bot-farms. I've had to block entire ASNs just to tone it down. It also hurts good-faith actors who genuinely want to build on top of our APIs because I have to block some cloud providers.

I would guess that I'm getting anywhere from 10-25 AI bot requests (maybe more) per real user request - and at scale that ends up being quite a lot. I route bot traffic to separate pods just so it doesn't hinder my real users' experience[0]. Keep in mind that they're hitting deeply cold links so caching doesn't do a whole lot here.

[0] this was more of a fun experiment than anything explicitly necessary, but it's proven useful in ways I didn't anticipate

I don’t understand this conclusion. Why shouldn’t it be a business? Doesn’t it create value? Hasn’t the nature of being a business led to far more maturity and growth in a FOSS offering than if it had been a side project? Just because it can’t afford 8 full time salaries now doesn’t declare it a failure. Your conclusion is that value should be created without any capture.

It wasn’t venture scale and never intended to be venture scale. By any metric you have, it’s a very successful business and has made its creators independent and wealthy as you pointed out.

I agree this is your worldview warping your perception. But I’d argue we need far more tailwinds and far less whatever else is going on. It captured millions in value - but it generated tens, or hundreds of millions, or more. And essentially gave it away for free.

I think a better conclusion is that it’s a flawed business model. In which case, I’d agree - this didn’t come out of nowhere. The product created (TailwindUI) was divorced from the value created (tailwindcss). Perhaps there was a better way to align the two. But they should be celebrated for not squeezing the ecosystem, not vilified. Our society has somewhat perverse incentives.