exactly, react could not deal with mutable object so they decided to make immutability seem to be something that if you did not use before you did not understood programming.

React made immutability patterns more relevant which increased discussion of it. Some people did get preachy about it. Yet dismissing immutability entirely just because of that misses the entire point of why it's actually useful in managing complex state.

Have you ever thought about instead of having emotional reaction to obnoxious gatekeeping to learn about actual benefits of immutability?

I guess a lot of users do not want to deal with Git hence Overleaf is so successful.

with what tool was this article written?

thanks, that is helpful

React has a history of solid backwards compatibility. IMO one of the top reasons to choose React. You do not have to worry that much if the framework is still around in two years.

Also - as the article mentioned - everybody knows react.

This are two reasons why picking react is almost every time the right choice.

How the internal rendering works and if it is a little faster or slower is just an implementation detail.

Your's has to little upvotes. I think it is only detected as duplicate if it had made the front page in the last few months.

Hm, I've had my submissions deduped before, where the existing post also had few upvotes and was definitely not on the front page.

same

looking at the examples, it looks more like a Rails alternative?

Rails for Ruby is similar with the simplicity and structure (same idea here for TypeScript), but Modelence is more cloud-first focused and less of a pure framework.

I can not try it out without entering payment information?

I'm working on something similar. Check out MonsterWriter

BTW. Your domain authority is 0 but you claim your app ist trusted by teams from GitHub, AWS, MongoDB, ... Hard to believe.

I don't get this trust discussion. I don't trust myself not to do a mistake, why should I trust somebody else.

Also - while pair programming is great - it does not replace a code review. When you do pair programming you start working on the problem at the same time, you get tiered and annoyed of the problem at the same time. You want to go to lunch break at the same time. All reasons to slip in a sloppy solution and convince each other it is actually ok.

While doing code review you get a fresh perspective on the matter.