3 ms·

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 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

TeMPOraL 8y ago
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.
- spricket 8y ago
  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.
bryanrasmussen 8y ago
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.
kangoo1707 8y ago
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 !
- spricket 8y ago
  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.

TeMPOraL 8y ago

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.

spricket 8y ago
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.

bryanrasmussen 8y ago

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.

kangoo1707 8y ago

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 !

spricket 8y ago
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.