Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.

The answer to the above question will reveal if someone an engineer or a electrician/plumber/code monkey.

In virtually every other engineering discipline engineers have a very prominent seat at the table, and the opposite is only true in very corrupt situations.

The product quality was just insane.

I have also worked with people in power who believed they were doing the same, but actually just had weird taste in interfaces and ended up screwing up the product.

So YMMV.

In my experience, when the team doesn't squash, this will reflect the messiest members of the team.

The top committer on the repository I maintain has 8x more commits than the second one. They were fired before I joined and nobody even remembers what they did. Git itself says: not much, just changing the same few files over and over.

Of course if nobody is making a mess in their own commits, this is not an issue. But if they are, squash can be quite more truthful.

It’s like a children or a puppy. People get impressed and go “how cute” at anything it does.

I see designers and PMs vibe coding shit that they would complain for days if it was delivered by a developer. I see C-Levels delivering reports that would make them eviscerate some intern.

In the past SEO blogspam was done by cheap freelancers, and there were several agencies selling the service.

Experts identify blogspam quite easily, but laypeople eat it up and use as reference in conversations and to make decisions.

Google has known about it, has been in contact with such agencies and companies, and has been refusing to do anything about it for the longest time.

What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".

React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.

This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.

> Here, we leverage the “quantum” feature to get exact pulse timings without resorting to cycle-counting

This is just a hard-real-time constraint that already exists in today’s computers and other devices.

For example: Audio playback and processing are a day-to-day operations where hard-real-time guarantees are necessary for uninterrupted playback, and every digital audio device already conforms to it. If the buffer is too slow you get playback errors.

Build systems (especially Babel and Webpack) were the first big culprits in terms of dependency bloat, and it was very rare to see React without them.

What people are criticizing is the approach in pushing this philosophy into the ecosystem for allegedly personal gain.

The fact that this philosophy has been pushed by a small number of individuals shows this is not a widespread belief in the ecosystem. That they are getting money out of the situation demonstrates that there is probably more to the philosophy than the technical merits of it.

This is a discussion that needs to happen.

If you're using third-party NPM packages to do "Vanilla", you're will probably run into the same problem.

If you import React directly from a CDN, you won't.

Atomic packages brings more money to the creators.

If you have two useful packages it's hard to ask for money, even if they're used by Babel or some popular React dependency.

If you have 900 packages that are transitive dependencies the same couple deps above, it's way easier to get sponsorship. This is a way to advertise themselves: "I maintain 1000 packages".

The first guy that did this in a not-nice way was a marketing/salesperson and has mentioned that they did on purpose to launch their dev career.

TLDR: This is just some weird ass pyramid thing to get Github sponsors or clout.

I had a PM that was unable to work without AI. Everything he did had to include AI somehow.

His magnum opus was 30 extremely large tickets that had the exact same text minus two or three places with slight variations. He wanted us to create 30 website pages with the content.

The ticket went into details such as using a CDN, following the current design, writing a scalable backend, test coverage, about 3-4 pages per ticket, plus VERY DETAILED instructions for the QA. Yep: all in the same task.

In the end it was just about adding each of the 30 items to an array.

I don’t know if he knows, but in the end it was this specific AI slop that got him fired.

Copying the visible behavior but not doing the actual part that matters.

Also incredibly common in corporate.

I recently had to clean up a mess and after days asking what’s in use and what’s not, turns out nothing is really needed, and 80 tracking pixels were added “because that’s how we do it”.