This advantage is further multiplied with TypeScript, since you can easily share types between backend and frontend. Working with a single set of types that enforce contracts (and supply IDE autocompletion) across the entire stack is amazing. It provides a huge productivity boost and eliminates a whole class of extremely common bugs.

I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages.

I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem

It's not about RPC, it's about a way of DRYing code between the backend and frontend, using libraries as your copy-paste engine. You pull in the same library (or extract common code to a library) both on the page and on the server, and assume they're both identical.

I have mixed feelings about this. I don't feel comfortable with assuming that just because I use the same library in backend and frontend, I don't have to ensure consistency and behaviour. But then again, I've used this approach in one ClojureScript project (ClojureScript can transpile a lot of Clojure libraries to JS), and it is convenient.

Needing to copy code around is largely a JS thing IMO. Java has such good standard and third party library support that I don't see what would be that reusable between the front and backend. Except maybe validators, gRPC doesnt support even basic field validation its annoying.

sure that answers part of the isomorphic problem (but not all), but it still leaves me writing code in two languages that often have lots of similarities in how they look but funny little differences in how they behave that either slow me down or cause me to put in bugs because I'm tired because it's a small startup situation.

JS on both backend and frontend is all about reusability, less context switch and unified toolings.

And don't associate less proficient engineers with Javascript dude !

Sorry, it's a stereotype, but in my experience JS is a super common first language devs that know JS and nothing else are less experienced.

Other than form validation, I never wrote the same code for both sides.

And that is only when not using JSF, Spring, Forms, MVC, Liferay, Sitecore, which generate the JavaScript validators automatically from type annotations anyway.

For my projects, the Web layer is only the View part of MVC.

For a few things I've worked on Views can be rendered client side or server side.

Aside from form validation I find I might have a number of utility functions that are used on both layers.

I find there are a few other edge cases, but those are the most common situations where reuse is nice (on the other hand what I often do for personal projects is just build the server side and client side code from a gulp pipeline and not worry about needing 'isomorphic' code reuse, but often teams on paid for projects find this approach confusing)