That is useful, but you can achieve a similar benefit if you manage to spec out your api with openapi, and then generate the typescript api client. A lot of web frameworks make it easy to generate openapi spec from code.
The maintenance burden shifts from hand syncing types, to setting up and maintaining the often quite complex codegen steps. Once you have it configured and working smoothly, it is a nice system and often worth it in my experience.
The biggest benefit is not the productivity increase when creating new types, but the overall reliability and ease of changing stuff around that already exists.
100% this.
I’ve been doing this for a long time and have never once “shared code between front end and back end” but sharing types between languages is the sweet spot.
In my other comment in this tree I mentioned that with TypeScript you can do even better. You don't need codegen if you can import types from the back-end. OpenAPI is fine, but I really hate having an intermediary like that.
Just define your API interface as a collection of types that pull from your API route function definitions. Have the API functions pull types from your model layer. Transform those types into their post-JSON deserialization form and now you're trickling up schema from the database right into the client. No client to compile. No watcher to run. It's always in sync and fast to evaluate.
You're right of course, it is better without an intermediary. But only if you already are, can or want to use typescript in the backend. If you have good reasons to not do so, then those usually outweigh the cost of having to go through an intermediary codegen step. The tooling is often good enough.
Plus, openapi can be useful for other things as well: generating api documentation for example, mock servers or clients in multiple programming languages.
I'm not disagreeing with you, what is best always depends on context and also on the professional judgement of the one who is making the trade-offs. A certain perspective or even taste always slips into these judgement calls as well, which isn't invalid.