4 ms·

> having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargant

by twic 5y ago

> having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains How so? Is it just about being able to use a single set of tools, libraries, habits, etc? Or are there particular things which are easier when the language is common? Are you sharing code between front-end and back-end. I do very lightweight front-end coding these days. It's usually some variation on populating and updating a table from a websocket, maybe with some simple filtering and toggling in response to user interaction. There, i can't think of any particular advantage to having both ends in the same language, but then mine is quite an unusual use case.

eyelidlessness 5y ago
There’s a lot of compelling reasons to share code particularly at network boundaries. Using something like io-ts/zod/etc gives you simple, declarative, type safe validation. Being able to share that behavior is an enormous productivity boost in and of itself.
- twic 5y ago
  Sharing validation for forms is definitely really nice. It feels like it should be possible to do that cross-language, generating some JS validation rules from Java annotations, say, but i have never seen it done.
  - eyelidlessness 5y ago
    The way it’s usually done is with a generalized language-agnostic spec like OpenAPI/JSON Schema. Because the definitions are standardized, you can effectively build tools in any language that should provide the same validation, to the extent they’re compliant and the spec is unambiguous. These approaches can of course be combined, where the sorts of validators I mentioned generate (or even build their primitives around) those more verbose standards.
hn_throwaway_99 5y ago
Mainly it has to do with teams. In most orgs there is something analogous to "a backend team" and "a frontend team", because the concerns and expertise are quite different. Oftentimes, however, a frontend dev may need some small extra bit of data or functionality from the backend, and vice versa. If the ecosystems are very different, then the amount of time it takes to set up that separate ecosystem, remind yourself of the relatively minor syntax difference e.g. between TS and Python, update your dependencies, etc. can be a big barrier, so often the answer is to just throw a ticket over to the team on the other side and wait. If, on the other hand, you can just quickly get into the other codebase, make a small PR and get it reviewed quickly, it can drastically improve the team's overall productivity.
- twic 5y ago
  I've always had front-end and back-end owned by the same team, and in the same repo, despite being in separate languages. The repo has a single build script which builds all parts of the project, whatever language they are in. Implementing almost any feature involves touching both front-end and back-end code, so people stay fresh. All of this seems like table stakes to me. Maybe some organisations have separate teams working on the two parts of an application, which honestly just seems stupid, but that's not a necessary consequence of using different languages.

by twic 5y ago

eyelidlessness 5y ago

There’s a lot of compelling reasons to share code particularly at network boundaries. Using something like io-ts/zod/etc gives you simple, declarative, type safe validation. Being able to share that behavior is an enormous productivity boost in and of itself.

twic 5y ago
Sharing validation for forms is definitely really nice. It feels like it should be possible to do that cross-language, generating some JS validation rules from Java annotations, say, but i have never seen it done.
- eyelidlessness 5y ago
  The way it’s usually done is with a generalized language-agnostic spec like OpenAPI/JSON Schema. Because the definitions are standardized, you can effectively build tools in any language that should provide the same validation, to the extent they’re compliant and the spec is unambiguous. These approaches can of course be combined, where the sorts of validators I mentioned generate (or even build their primitives around) those more verbose standards.

hn_throwaway_99 5y ago

Mainly it has to do with teams. In most orgs there is something analogous to "a backend team" and "a frontend team", because the concerns and expertise are quite different. Oftentimes, however, a frontend dev may need some small extra bit of data or functionality from the backend, and vice versa. If the ecosystems are very different, then the amount of time it takes to set up that separate ecosystem, remind yourself of the relatively minor syntax difference e.g. between TS and Python, update your dependencies, etc. can be a big barrier, so often the answer is to just throw a ticket over to the team on the other side and wait. If, on the other hand, you can just quickly get into the other codebase, make a small PR and get it reviewed quickly, it can drastically improve the team's overall productivity.

twic 5y ago
I've always had front-end and back-end owned by the same team, and in the same repo, despite being in separate languages. The repo has a single build script which builds all parts of the project, whatever language they are in. Implementing almost any feature involves touching both front-end and back-end code, so people stay fresh. All of this seems like table stakes to me. Maybe some organisations have separate teams working on the two parts of an application, which honestly just seems stupid, but that's not a necessary consequence of using different languages.