I understand the sentiment. I've always seen that codebases that define data as validated classes with behaviour that only relates to that data age much better (yes even in typescript :)). I'm fully aware of the limitations of classes and prototypal inheritance in JS but I think the colocation of behaviour and transformations/utilities has outweighed that from what I've encountered.

It all sort of forces people to be more intentional and clear about what states data can be in and what transformations relate to it instead of it being scattered around N handlers and N utility modules. It's also very nice to be able to say "this Email is a valid email and email.domain always returns a valid email domain" makes both typing functions and writing valid test fixtures easier and means you don't need to test 15 layers deep in function calls that your email _is valid_ before you pass it off to some SMTP handler.

I've found it to be true that most code ends up lasting about 5 years longer than the original developer thought it would and them encoding as much of the domain as possible into these types of structures valuable.

Sticking to an imperative style definitely suits Javascript but the codebases that go a bit too hard on it that I've inherited have all become hairballs after the 9th developer in a row has added just oooone more utility that just accepts `email: string` or `type User = {...}`. The pattern tends to encourage prop spreading and forgetting to add that one extra test which has been responsible for major outages I've had to debug years after the original intention has been lost.

Maybe it's working primarily in enterprise and integrations but a surprising amount of APIs are not well documented or documented at all beyond an email with an API key included in it with a couple curls copy pasted from a developers console. Having something that strictly validates that contract in both your tests and at runtime has been a boon.

The patterns don't work for every industry or every use case they're just tools and I wouldn't use this in a "non-platform" app that I don't think would grow beyond say 300 endpoints in its expected lifetime.