atheken

You might have a look at “CONTRIBUTING.md” files in repos.

• Set quality standards (no giant PRs, follow documented coding style, include tests for changed functionality, etc).
• Establish a way to discuss contributing work before they do it. Generally, have them open an issue discussing the proposed change and get buy-in from the maintainer (you) before starting work.
• document any high-level goals and non-goals in the README.md for the repo, and refer to that when discussing changes. You can always amend it as you discover more about what should be built.

Initially, contributors can fork and send a pull request for you to review and merge. You do not need to give them any write access to the main repository. Be respectful of their time and review PRs promptly.

If multiple people want to collaborate on a branch, they can do that in their fork. In my experience, this is pretty rare, usually you don’t want multiple people committing to the same branch (except for merges to master/main/stable, etc).

If you have a few dedicated contributors that have a history of submitting good quality patches, and alignment with you on your project’s goals, you can invite them to have more control in the main repository, at which point there should be minimal concern about granular controls.

The problem with the article is that it’s confusing hard realtime and low latency requirements. Most UIs do not require hard realtime, even soft realtime is a nice to have and users will tolerate some latency.

I also think the author handwaves “too many blocking calls end up on the main thread.”

Hardly. This is like rule zero for building gui apps. Put any non-trivial or blocking work on a background thread. It was harder to do before mainstream languages got good green thread/async support, but it’s almost trivial now.

I agree that there are still calls that could have variable response times (such as virtual memory being paged in or out), but even low-end machines are RAM-rich and SSDs are damn fast. The kernel is likely also doing some optimization to page stuff in from disk for the foreground app.

It’s nice to think through the issue, but I don’t think it’s quite as dire as the author claims.

The thread you are in and my response made it clear that the headline is clickbait by including that irrelevant detail.

If they didn’t include that word in the post title, it would have no traction at all.

It literally doesn’t matter. You can remove the word and the nature of the problem being discussed is still the same. What platform is being targeted has nothing to do with the example problem. Roblox is only mentioned to sensationalize it and get clicks.

It’s misleading because it’s irrelevant and makes it sound like a platform breach.

Try replacing Roblox with “Foozsplatz” and the implication of severity is completely different, even though the nature of what is being reported is unchanged.

Also, as far as I can tell, they’re talking about devs that are building on the Roblox platform, not devs that are building the platform.

In other words, random devs of varying skill levels getting name-squatted.

It’s not good, but including Roblox in the title is definitely misleading/clickbait.

Your call, there are plenty of "define arbitrary entity" CMSes out there, and especially if you're mainly using this as a configurable data store (hence headless), the amount of UI customization should be limited. I'd definitely try to flesh out the actual customization you expect to do in the longer term vs. how stuff works out of the box.

Even as a dotnet person, my general experience is that the stuff that's built over NodeJS tends to get a lot more love and maintenance, and if you're eventually going to build web pages, you'll probably end up in Typescript/JavaScript pretty quickly, anyway.

I’m mostly a dotnet person, but another important factor in making this choice (and limiting your options to only dotnet), is how much customization you think you’ll do to the cms.

If you’re deploying it as a container and it’s backed by your preferred data store, you may not ever really do much with the headless CMS code.

I’d be looking at options written in go, or js/typescript.

https://jamstack.org is probably a good resource for surveying the options.

Probably the more important question is whether DHH is your boss.

It’s fine to look for people with real experience/opinions on the internet, but at the end of the day, you have to build your own product.

I also am going to just say that I’m betting the kinds of stuff rails does in JS doesn’t really need a lot of complex JS. My guess is a lot of it paints on behavior similarly to what htmx does now, which doesn’t really require a ton of js code anymore. I don’t much see the point removing TS for the vast majority of projects.

I think it’s a double negative: “against not using”

As in, use a bundler.

Sure, you can make it 10x faster by optimizing the complexity, but I can improve throughput by 1000x by putting it on 1000 machines.

In practice, it’s a bit of both. Paying attention to Big-O and understanding the gross relative cost of various operations goes a long way, but being able to run an arbitrarily large number of them can get you out of a lot of jams.

The absence of descent does not imply the presence of acceptance.

Sometimes people are busy and don’t have time to think about or discuss doing X thing, but they haven’t bought in on it.

A lead or senior person on the team needs to gather input and get a read from people individually, sometimes.

I also think there’s another good one when things are in a deadlock and nobody wants to force their position: “Disagree and decide.” - having some ruffled feathers and a resolution is way better than the illusion of harmony and no closure.