I think basic or even complex stuff is fine in vanilla js.

The problems show up as you scale the team and code base. You can do a large project in vanilla js but you’re going to have to solve a lot of the same problems frameworks/libraries have already solved. Maybe it’s worth it, maybe it’s not.

Wat?

I asked AI to summarize the article since it’s paywalled. It didn’t say anything about lying, should I trust it?

Not saying anything about good or bad, but trunk-based development doesn’t work when the business requires you to have multiple releases under development concurrently.

I know of 2 projects that wanted to migrate from Oracle to Postgres, one of which was successful. Both migrations were driven by cost savings–Oracle can get exceedingly expensive.

In both cases there was up front analysis of Oracle specific features being used. A lot of that could be rewritten into standard SQL but some required code logic changes to compensate. Vendor lock-in is insidious and will show up in native queries, triggers, functions that use Oracle packages, etc.

Changing a project’s underlying database is rare, but not as rare as it used to be.

Take your example of adding a field to an entity. Just because you’ve made that code change doesn’t mean other code should be using it. Who should be using it and how is determined by the business rules.

Also your interest in ensuring it is “properly” used is impossible to enforce. What’s considered proper even for existing code can change over time.

Hmm I think you’re looking for a technical solution to a non-technical problem.

If you update your tests to reflect proper usage of the new field then you can catch potential errors.