No it reflects the reality that requirements and applications evolve over time. You sound like someone who's never supported an application for more than 5 minutes.
If your application requirements change every 5 minutes, then you prove my point - you suck at architecting and should honestly just give your job away to someone more competent.
I obviously don't know your specific use case, but in my experience having the database schema reflect throughout a project means its either very small or the design is going to run into problems.
It also sounds like a potential security nightmare. We have a policy of never sending domain objects across the wire so nothing accidentally gets sent. APIs must strictly whitelist data structures.
The way this can work in something like an Elixir or Clojure: you have gradual types in most of the core code, but you translate it just before you hit the view layer (e.g. templates).
The great thing about dynamically typed languages is you don't have to declare a new type for each view. You just select out the data you need and expose it for the view. In Clojure this is as simple as a select-keys.
Which is why you architect before-hand with a paradigm of your choice, like DDD (Domain Driven Design) using proper contexts (which Phoenix supports) beforehand. That is the sign of a mature developer, not the other way around.
If your datatype for a column evolves over time to completely different types, it's just an excuse for poor planning and architecture. Eg. A string turning into an integer. That just sounds like someone junior would do with MongoDb.
> You really sound like someone who only does CRUD services.
You throw this like an insult, but in reality most applications can be simplified to just CRUD services. Chat interfaces? CRUD. Social Media? CRUD. Banking? CRUD.
This lets you evolve each part independently and use the "native" types frontend vs backend, which happens surprisingly frequently as the app grows
You're not wrong and most other comments are responding this from some sort of UI library perspective, like React / Svelte. However, if you're using even the barebones scaffolded UI using LiveViews from Phoenix, you don't have to do any of these. Phoenix will wire up the form to the changesets by default. Which is what I'm referring to.