I haven't found this to pay off in reality as much as I'd hoped… have you?

Me neither, for multiple reasons, especially if you are bundling your frontend. Very easy to accidentally include browser-incompatible code, becomes a bit of a cat and mouse game.

On types, I think the real value proposition is having a single source of truth for all domain types but because there's a serialisation layer in the way (http) it's rarely that simple. I've fallen back to typing my frontend explicitly where I need to, way simpler and not that much work.

(basically as soon as you have any kind of context-specific serialisation, maybe excluding or transforming a field, maybe you have "populated" options in your API for relations, etc - you end up writing type mapping code between the BE and FE that tends to become brittle fast)

It's useful for running things like Zod validators on both the client and server, since you can have realtime validation to changes that doesn't require pinging the server.

It's been very useful for specific things: unified, complicated domain logic that benefits from running faster than it would take to do a round trip to the server and back.

I've only rarely needed to do this. The two examples that stick in my mind are firstly event and calendar logic, and secondly implementing protocols that wrap webrtc.

Yes, incredible productivity gains from using a single language in frontend and backend.

That's Java's story.

A single language to rule them all: on the server, on the client, in the browser, in appliances. It truly was everywhere at some point.

Then people massively wish for something better and move to dedicated languages.

Put another way, for most shops the productivity gains and of having single languages are far from incredible, to being negatives in the most typical settings.

Java applets were never ubiquitous the same was JS is on the web though - there's literally a JS environment always available on every page unless the user explicitly disables it, which very few people do.

JS is here to stay as the main scripting language for the web which means there probably will be a place for node as a back end scripting language. A lot of back ends are relatively simple CRUD API stuff where using node is completely feasible and there are real benefits to being able to share type definitions etc across front end and back end

> there are real benefits to being able to share type definitions etc across front end and back end

There are benefits, but cons as well. As you point out, if the backend is only straight proxying the DB, any language will do so you might as well use the same as the frontend.

I think very few companies running for a few years still have backends that simple. At some point you'll want to hide or abstract things from the frontend. Your backend will do more and more processing, more validation, it will handle more and more domain specific logic (tax/money, auditing, scheduling etc). It becomes more and more of a beast on its own and you won't stay stuck with a language which's only real benefit is partially sharing types with the frontend.

Java never ran well on the desktop or in the browser (arguably it never truly ran in the browser at all), and it was an extremely low-productivity language in general in that era.

There is a significant gain from running a single language everywhere. Not enough to completely overwhelm everything else - using two good languages will still beat one bad language - but all else being equal, using a single language will do a lot better.

Yes, Java was never really good (I'd argue on any platform. Server side is fine, but not "really good" IMHO)

It made me think about the amount of work that went into JS to make it the powerhouse it is today.

Even in the browser, we're only able to do all these crazy things because of herculian efforts from Google, Apple and Firefox to optimize every corner and build runtimes that have basically the same complexity as the OS they run on, to the point we got Chrome OS as a side product.

From that POV, we could probably take any language, pour that much effort into it and make it a more than decently performing platform. Java could have been that, if we really wanted it hard enough. There just was no incentive to do so for any of the bigger players outside of Sun and Oracle.

> all else being equal, using a single language will do a lot better.

Yes, there will be specific cases where a dedicated server stack is more of a liability. I still haven't found many, tbh. In the most extreme cases, people will turn to platforms like Firebase, and throw money at the pb to completely abstract the server side.

I’ve used the ability to import back end types into the front end to get a zero-cost no-file-watcher API validator.

My blog post here isn’t as good as it should be, but hopefully it gets the point across

https://danangell.com/blog/posts/type-level-api-client/

But that's only really relevant in the last layer, the backend-for-frontend pattern; as an organization or domain expands, more layers can be added. e.g. in my current job, the back-end is a SAP system that has been around for a long time. The Typescript API layer has a heap of annotations and whatnots on each parameter, which means it's less useful to be directly used in the front-end. What happens instead is that an OpenAPI spec is generated based on the TS / annotations, and that is used to generate an API client or front-end/simplified TS types.

TL;DR, this value prop is limited.

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.