You could so easily build your own /schedule. This is hardly a feature driving lock-in

Yes, but once everything has been deployed through their web UI or the cli command, and fine-tuned over the weeks and months as kinks get ironed out, how do you port it all to your own?

Nothing insurmontable or even complex; just laborious. Friction. That’s all it takes to lock users in.

It’s useful for large PRs in large repos with many contributors. It reduces the burden for reviewers.

Still not sure this is the right solution. My problem is if one of your first stages gets rejected in review or requires significant changes, it invalidates so much work that comes after it. I've always when possible preferred to get small stuff merged in to production as it happens rather than build an entire feature and put it up for review.

> it invalidates so much work that comes after it.

No, not necessarily.

I work on a large repo and new features often involve changes to 3 different services: 2 from the backend, and the frontend UI. Sending a single PR with changes to all 3 services is really not ideal: the total diff size in a feature I added recently was maybe 600+ lines, and the reviewers for frontend and backend changes are different people. The changes in the 2 backend services can be thought of as business logic on one side and interactions with external platforms on the other. The business logic can't work without integrating calls to external APIs, and the UI can't work without the business logic.

These days I open 3 separate PRs and the software only works once all 3 are merged and built. It would be great to have all of them as a single package that's still testable and reviewable as 3 distinct parts. The UI reviewer can check out the whole stacked PR and see it running locally with a functional backend, something that's not possible without a lot of manual work when we have 3 PRs.

The LLVM community used this model for years with Phabricator before it was EOL'd and moving to GH and PRs was forced. It's a proven model and works very well in complex code bases, multiple components and dependencies that can have very different reviewer groups. E.g: 1) A foundational change to the IR is the baseline commit 2) Then some tweaks on top to lay the groundwork for uses of that change 3) Some implementation of a new feature that uses the new IR change 4) A final change that flips the feature flag on to enable by default.

Each of these changes are dependent on the last. Without stacked PRs you have o only one PR and reviewing this is huge. Maybe thousands of lines of complex code. Worse, some reviewers only need to see some parts of it and not the rest.

Stacked diffs were a godsend and the LLVM community's number one complaint about moving to GitHub was losing this feature.

This has a solved problem for a long time

Love it! Thanks for sharing!

It’s a design tool. Why communicate it with text?

Seriously though. And this is a design company?

If there were any semblance of liability for software engineering firms things like this wouldn’t happen

GC can be very slow. Relying on it for control flow is a bold move

I don't think the control flow relies on GC.

The control flow stops because statements after `await new Promise(() => {});` will never run.

GC is only relied upon to not create a memory leak, but you could argue it's the same for all other objects.

as long as there's no leak interrupting a promise should be good for performance overall, not necessarily for the front-end but for the whole chain.

They forgot the bit where Alice could barely make rent and ate trash for a year while she worked 70hr weeks for a poverty-line stipend. Bob had great sleeps and could hold a part time job waiting tables.

NYT occasionally uses fancy interactive articles. They have games, and other things that are better on the app. The NYT app is actually very good

For games I agree that an app makes sense (though I think at least the games I used to play were in a separate nyt games app). For interactive articles, I've not seen anything I couldn't use fine in my browser, but in theory I wouldn't mind covering up the interactive part with a "Open in the app for a better experience" button (similar to what YouTube does on the video portion of the page). Where I encounter this though is in standard, text-heavy articles that maybe include a photo or two.

I assume the reason they are pushing me to the app is that it benefits them not me (longer dwell times, maybe easier tracking for behavior/ads), and that is precisely why I want to stay in the browser. Covering up a good portion of the article and preventing me from scrolling until I click the tiny link to decline is hostile and is the only thing degrading the experience on the website for most articles I read.

Every time I end up trying an app for things like this, I end up missing tabs.

There is no reason they can’t have a native tab navigator. It kills me that Google maps app doesn’t have tabs.

Yeah true. Tabs, history, etc on the browser are unparalleled.