switz · HackerTrans

switz

4,505 カルマ登録 15 年前

FF6600 -> bbbbbb

https://saewitz.com (email: [email protected])

投稿

Cloudflare forked just-bash and they really, really should not have

twitter.com

10 ポイント投稿者 switz4 か月前3 コメント

Show HN: Gapless.js – gapless web audio playback

github.com

35 ポイント投稿者 switz5 か月前11 コメント

TLDraw plans to move their tests to a closed-source repo

github.com

6 ポイント投稿者 switz5 か月前1 コメント

Tests Are the New Moat

saewitz.com

7 ポイント投稿者 switz5 か月前0 コメント

Ukranian controls Home Assistant over LoRa radio when their power grid goes down

old.reddit.com

99 ポイント投稿者 switz5 か月前10 コメント

Turning Your Robot Vacuum into a Mesh VPN

saewitz.com

2 ポイント投稿者 switz5 か月前0 コメント

Show HN: Box of Rain - Auto-Layouted ASCII Diagrams

github.com

24 ポイント投稿者 switz5 か月前14 コメント

[untitled]

1 ポイント投稿者 switz8 か月前0 コメント

Parallel and Recursive Route Rendering

twofoldframework.com

3 ポイント投稿者 switz10 か月前0 コメント

Show HN: Variable Font Debugger

saewitz.com

2 ポイント投稿者 switz12 か月前0 コメント

React Cache: It's about consistency

twofoldframework.com

2 ポイント投稿者 switz12 か月前0 コメント

Agentic Coding Is a Fundamental Shift

saewitz.com

4 ポイント投稿者 switz昨年0 コメント

The State of React and the Community in 2025

blog.isquaredsoftware.com

2 ポイント投稿者 switz昨年0 コメント

Code Lifecycles

saewitz.com

1 ポイント投稿者 switz昨年0 コメント

Server Components Give You Optionality

saewitz.com

2 ポイント投稿者 switz昨年0 コメント

Lessons on Creative Work

saewitz.com

1 ポイント投稿者 switz昨年0 コメント

Hume and Ivey – Frames of Reference (1960) [video]

youtube.com

2 ポイント投稿者 switz2 年前0 コメント

[How Would You?] Spend the SETI Institute's $200M Gift

supercluster.com

1 ポイント投稿者 switz2 年前0 コメント

Show HN: driver – a TypeScript pkg for declaring finite states via boolean logic

github.com

1 ポイント投稿者 switz3 年前0 コメント

Andrew McCalip: "It might be a bust - we may be over"

twitter.com

27 ポイント投稿者 switz3 年前10 コメント

コメント

5 日前議論

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.

[0] (disclaimer: my blog post) https://saewitz.com/tests-are-the-new-moat

7 日前議論

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

3 か月前議論

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.

3 か月前議論

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.

3 か月前議論

Please do not wash your authentic writing through an LLM.

3 か月前議論

Workers runtime is open source and permissively licensed fwiw

https://github.com/cloudflare/workerd

3 か月前議論

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.

3 か月前議論

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)

3 か月前議論

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 か月前議論

4 1's == 4/1

could just be a coincidence

5 か月前議論

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

5 か月前議論

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.

5 か月前議論

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.

5 か月前議論

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.

5 か月前議論

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.

5 か月前議論

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/

5 か月前議論

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

5 か月前議論

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/

5 か月前議論

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  ║  ║
    │          │           ║  │            │      ║            ║  ║
    ╰──────────╯           ║  ╰────────────╯      ╚════════════╝  ║
                           ╚══════════════════════════════════════╝