While McDonalds is somewhat benign, most people simply don't understand that this data can be (technically at least, legally is a different question) permanently stored. See the surprise in the article that it is now easy to store every app open. Almost certainly with associated location data. So McDonalds selling/sharing that is a concern, particularly with the extraordinarily lax US approach to data privacy. Data like that cleanly bound to true identity is very unhealthy. McDonalds is highly likely syncing that into facebook as well, which is generally done both via email and phone.

And if McDonalds is doing this, imagine what more natively sensitive apps/websites are storing about you. Medical sites, period / pregnancy trackers (particularly in light of the US bans on medical treatment of pregnant or possibly pregnant women), a whole host of health-related information; political opinions, etc.

The downside is it does less than react. You will mostly have to keep the reactivity dependency tree in your head. Huge win for most b2b apps; A+ for internal admin pages; solid A for config pages in almost all apps; not a great fit for (parts of) highly reactive b2c apps.

The system is called Turbo. A turbo_frame is just a custom html element. You can largely use it instead of a div.

Turbo's js watches for navigation events (link clicks, form submits) that originate inside one of these elements, and instead of letting the browser do a full navigation, it:

1 - makes the request itself, against the usual rails routes. It uses your normal routing, sessions, cookies, etc.

2 - Intercepts the html response and looks for a that matches the id of the frame that triggered the request

3 - Swaps just that element's contents into the page.

more concretely: suppose I have a list of people in a flex table. I wrap the people table in a turbo_frame so I can prepend to it, and wrap each person in a turbo_frame so I can update it. My page can look as so:

    turbo_frame "people", class: "person-table flex flex-row" <-- the overall list
      turbo_frame person_1, class: "person-row flex flex-col"
        the row for person 1
      turbo_frame person_17, class: "person-row flex flex-col"
        the row for person 17
      turbo_frame person_12345, class: "person-row flex flex-col"
        the row for person 12345

If the user edits a form for person 12345, that is wrapped in turbo_frame person_12345.

The browser makes the request itself, grabs the response, pulls out the contents of turbo_frame person_12345 (and NB: the response can be a whole page or just this fragment), then swaps that in for the existing person_12345.

It's designed so you can make your normal MPA with page navigations and reloads for editing a table row or whatever, make a small set of updates to the html, and have this work almost entirely for free. It sounds too good to be true but I've been using it for years and it often really is that easy.

edit: for server-initiated updates, I can broadcast to select listeners:

1 - replace a turbo_frame (person_12345 was updated externally, and I want to just swap out) 2 - prepend (eg for a css table, put my new person_12345 row in front of other rows; 3 - append (same, but at bottom)

A common use case: eg in Rails, a user has a table open. you can stream new records to the top of that table as they are created in ~5 lines of ruby (a broadcast on the model, and put the table rows in a turbo_frame with a turbo_stream_from somewhere on the page).

There are real limits to this -- you have to hold the update dependency graph in your head -- but the benefits are huge for small to medium amounts of responsiveness.

My experience has been great with Rails/Turbo and htmx.

This is Percona's business model. They employ core pg/mysql developers and you can buy a support package from them. Same for enterprisedb. Pretty reasonably priced packages (like maybe $10k-ish/core IIRC) get you 24x7 support. I've only had to escalate issues once but inside 10 hours we got a pg core committer to debug some very strange vacuum behavior.

Whether that comes to pass depends on sprite uptake and so forth, but I believe it to be a lot more likely than I did a month ago. So, like I said, bummed, because fly is genuinely nice and I dislike using aws.

> [...] Sprites, and focusing the company on [Sprites] and the problem they solve.

Then later

> first path [the thing I like/advocate/use] and [Sprites] ... We do one thing or the other. We don’t limp in on both. And if we fail, we fail with our full asses.

Hard to interpret that as anything but the thing I like being backburnered. Which is how it goes, but sucks.

Private emails regularly lead to awful customer service interactions because people cannot tell us the email they used to register. Fastmail at least is off the beaten path enough that people probably can understand. Apple, especially using sign in with Apple, is horrid. And not just people unable to tell us the email; they then create multiple accounts; try to sign in on web and use their actual email and then have 2 accounts and flip shit that their stuff is gone; etc. Oh, and regularly blame us for their confusion.

Apple was not the problem for rcs; the carriers are and were.

That doesn't necessarily mean it's a bad idea from a competition point of view, but good ideas can be discussed w/ an honest view of the quite real downsides.

Applying standard financial metrics (do they make money? Will they ever? What valuation does that justify?) to certain companies.

People are encouraged by package managers to treat any bit of code someone tosses onto a package manager as equivalent in reliability to the core language and sdk.

And 1/100th the feature footprint.

But again, accidental complexity. The web platform is utterly rotten. So the people we should blame are chrome et al for not providing a standard lib or anything approaching a reasonable UI framework, which forces people to reimplement what a competent platform provides.

Electron is an artifact of the richest companies in the world prioritizing their platform monopolies and trying to increase their stranglehold on businesses by forcing them to write platform specific code, which is hysterically expensive to build and maintain. When I'm confronted with writing for web then reimplementing for mac and win... the answer is electron. I don't think anybody likes building in Electron; it's just it's that or +200% (or more) eng headcount to build 3 apps, one per platform.