5 ms·

Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small

Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small teams. I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in our case it was).

cianuro_ 2y ago
IME, the productivity promise falls short. I have found major gains following an integrated framework over multiple code bases with the same language. With the setup you described I just felt I had to write more, even if it was in the same language.
- hn_throwaway_99 2y ago
  I don't understand your comment. There are plenty of integrated frameworks that work well between Node and React. More importantly, though, you seem to be commenting from the perspective of an individual developer. The biggest productivity gains I've seen is that it makes it much easier for people on different areas of the team to understand and fix/modify parts of the code that they're least familiar. E.g. if I'm a developer that spends 99% of my time on the front end, but then I need some extra field that's not being returned by the backend, instead of having to do a full context switch, get an environment up and building that I may not have compiled in a long time, get my brain "switched over" to a different language, or worse, file a ticket and wait for the backend team to fix it, it's much easier if I can just go in quickly and add the field I need. I've seen this in spades on small/medium teams - it really "lowers the barrier to entry" for people being able to submit PRs in parts of the codebase that is not their primary day-to-day work.
  - re-thc 2y ago
    > it's much easier if I can just go in quickly and add the field I need This assumes that just because it's the "same language" it's all the same. It's especially true in Javascript land where the React setup is vastly different than the Node backend framework setup. You get bundler differences, ESM/CJS, different versions of Node (or even Bun / Deno), linters or things like decorators, etc... You can be doing "functions" with React and then head to classes and modules with NestJs all of a sudden. It pretends to be much easier. I've seen lots of real world assume-there's-a-shortcut method that just makes it worse.
- mplewis 2y ago
  Perhaps use an integrated framework with one codebase then? RedwoodJS is one of these.
dtquad 2y ago
Definitely. Although Go is the simplest language with sane/good concurrency support so it's a good fit for Node.js/TS and Python shops that have run into a use case where they feel limited by their main language or runtime and need a concurrent backend service to implement a feature.
- jilles 2y ago
  Kotlin also has amazing concurrency support. Plus you get the additional benefit of the entire Java ecosystem. I wish it got more love.
  - teg4n_ 2y ago
    Kotlin is not simple. it has like every language feature in existence
    - have-a-break 2y ago
      Why do people always mention kotlin, but not Scala? Scala is more similar to traditional Java while letting functional programming shine.
      - pclowes 2y ago
        Honestly, I think it is because the Scala community was/is/can be so pedantic and bickering and often combative and toxic that it lost all momentum and appeal. Nobody wants that culture in their workplace. Also the dysfunction is visible in the technical fragmentation of the ecosystem
      - valenterry 2y ago
        Scala is way superb for concurrency than what Go or Kotlin have to offer. But it is a complex language with a high learning curve.
      - re-thc 2y ago
        > Why do people always mention kotlin It's backed by $$$ that have promoted it that way - a "better" Java.
moron4hire 2y ago
I disagree. I don't think it's too much to ask of software developers to be the bare minimum of competent enough to wire up a basic web service in whatever language they are dealing. REST is not complex.
- onion2k 2y ago
  REST is not complex. REST isn't complex, but API design is still hard. Making a strategic choice not to design a service API but to ship the same code in two places is valid, and arguably the right one if that's what the teams skills lend themselves to.
- baq 2y ago
  Over the past two decades I’ve seen a well implemented RESTful API exactly once, in a relatively small project. The rest of REST apis are ad-hoc RPC over HTTP, I’d argue because it isn’t complex and complexity moves to the client.
TheCapeGreek 2y ago
At the least, tools that minimise the usage of certain languages (i.e. JS if you're not a JS shop) or general frontend boilerplate will also do this. See: Rails Hotwire, Laravel Livewire, Alpine.js
- Cyph0n 2y ago
  Or Elixir + Phoenix + LiveView.
temporallobe 2y ago
This is why Rails is a decent solution for many apps. It’s “Ruby everywhere” including the data layer.
brunoqc 2y ago
Gleam might be a good fit for that.
meandmycode 2y ago
This was my view once, but practically the languages have their own ecosystem strengths, now I think most of the major languages have similar concepts, async await, etc.. instead we now teach transfer your skills, and tbh I think it makes for a more interesting culture that's adoptive and excited by tech, and also learns better
- nesarkvechnep 2y ago
  It’s called being a software developer instead of being a JavaScript developer. If someone knows how to engineer software, their skills are transferable. Stitching libraries together is usually not software engineering.
  - 8note 2y ago
    software engineering is mostly a kludge of interacting with stuff people have made and will make, rather than physical limits of different materials and structures stitching libraries together is the essense of soctware engineering
deleted 2y ago
[deleted]
hansonkd 2y ago
Hard disagree. Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both. Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chances are if you just chose react and typescript you could pull things off the shelf and have almost an unlimited amount of resources and developers you could pull from compared to an esoteric LiveView or webassembly type framework, get the project done faster, ship and iterate as opposed to reinventing the wheel and satisfying the commonly felt NIH syndrome. Typescript for both frontend and backend is a bit better, but the backend story for me is still weaker than using Python or elixir, etc simply serving an API, because if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit. the only exception to the above is if you aren't building a company and instead working on a small personal or group project.
- Aeolun 2y ago
  > Almost never have a met a person who was equally good at both. Doesn’t that say more around your surroundings? I’ve definitely met people that were equally competent at both (and more competent than most). A lot of things that are important on the front-end are equally important on the back-end and vice versa. Lets add databases and infra while we are at it. The thing is, you need an actually senior engineer for that. Not some kid right out of college that is somehow called a principal.
  - runarberg 2y ago
    These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design. On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers to deliver a good UX. On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure, or work with your infrastructure engineer, you have to design databases and optimize your storage and delivery. You also need to deliver a good API for your frontend devlopers, otherwise they‘ll complain. I‘m a frontend developer so I bet there are tons of stuff backend developers do which I don‘t even know about.
have-a-break 2y ago
I think it's a safety concern, I'd like to explicitly know whats being ran on the client vs the server. And react introduces a host of dependencies which may be ill maintained. The only reason to bring this up in an online forum is because I'm tired of recruiters constantly asking for react and nodejs.
smarkov 2y ago
I get the potential appeal in having a single language do all things, but in practice the front-end and back-end have vastly different jobs and different capabilities, so I see no issue in them being different languages and letting them utilize their strengths. Not to mention the vast amount of complexity you need to involve at some point in order to bring a language to a side it wasn't meant to be in.
- 8note 2y ago
  moreso, you cant share promise chains or streams well across api boundaries, so it isnt seamless, even in the same language
rvz 2y ago
> I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in our case it was). Absolutely bad advice and totally disagree. So having a language such as TypeScript which is already built on top of an even more immature language such as Javascript in critical systems software or highly regulated settings is a good idea? Having it on the backend is also bad enough, but everywhere really an indication of not being able to adapt into using a properly designed language for the specific use-case and just being inflexible because you are 'used to the language'. This is not even talking about the entire TS/JS ecosystem which is has a sea of libraries which most of them are also immature and not production-grade at all.
- panstromek 2y ago
  Sounds like a straw man to me
- baq 2y ago
  The ecosystem is a bit insane, JavaScript is a disaster, but typescript itself is very, very good. IMO it’s better for complex backends than Python, and I’ve been doing Python since before Django 1.0. That said I’m patiently waiting for dotnet renaissance.
jmyeet 2y ago
No disrespect to you but I'm constantly reminded of this quote: "Consistency is the hobgoblin of little minds" -- Ralph Waldo Emerson It's this same idea that led Google down the garden path that was (is?) GWT: Java everywhere. It seems like a good idea but for every platform you add, you reduce the total the lowest common denominator between them. You add transliteration bugs and issues. Google also trie to do this with Protocol Buffers on Javascript front ends and the serialization methods were... suboptimal. Because obviously you can't do (or at least couldn't at the time) binary encoding and decoding on a browser. All this is why we've seen multiple attempts to, say, allow you to write an app that'll work on iOS and Android. React Native springs to mind. Now if you can come up with an end-to-end Typescript solution, that's great. But it's also a pretty severe constraint and one that doesn't, for example, solve the native mobile platform issue.
- panstromek 2y ago
  I have pretty positive experience with Capacitor, actually. Precisely because it doesn't try to be e2e solution that shields you away from the native platform. It doesn't stand in your way when you want to do something native, it's more of a toolkit to manage the bridge between WebView/Native land.
panstromek 2y ago
I guess this depends a bit on the project but pretty often yes. I currently maintain Typescript SPA with PHP backend and the split between languages is very frustrating, it induces a ton of pointless busywork. If the backend language was something stronger, than I'd be willing to accept that split to get those benefits, but having two different scripting languages seems quite pointless.

cianuro_ 2y ago

IME, the productivity promise falls short. I have found major gains following an integrated framework over multiple code bases with the same language. With the setup you described I just felt I had to write more, even if it was in the same language.

hn_throwaway_99 2y ago
I don't understand your comment. There are plenty of integrated frameworks that work well between Node and React. More importantly, though, you seem to be commenting from the perspective of an individual developer. The biggest productivity gains I've seen is that it makes it much easier for people on different areas of the team to understand and fix/modify parts of the code that they're least familiar. E.g. if I'm a developer that spends 99% of my time on the front end, but then I need some extra field that's not being returned by the backend, instead of having to do a full context switch, get an environment up and building that I may not have compiled in a long time, get my brain "switched over" to a different language, or worse, file a ticket and wait for the backend team to fix it, it's much easier if I can just go in quickly and add the field I need. I've seen this in spades on small/medium teams - it really "lowers the barrier to entry" for people being able to submit PRs in parts of the codebase that is not their primary day-to-day work.
- re-thc 2y ago
  > it's much easier if I can just go in quickly and add the field I need This assumes that just because it's the "same language" it's all the same. It's especially true in Javascript land where the React setup is vastly different than the Node backend framework setup. You get bundler differences, ESM/CJS, different versions of Node (or even Bun / Deno), linters or things like decorators, etc... You can be doing "functions" with React and then head to classes and modules with NestJs all of a sudden. It pretends to be much easier. I've seen lots of real world assume-there's-a-shortcut method that just makes it worse.
mplewis 2y ago
Perhaps use an integrated framework with one codebase then? RedwoodJS is one of these.

dtquad 2y ago

Definitely. Although Go is the simplest language with sane/good concurrency support so it's a good fit for Node.js/TS and Python shops that have run into a use case where they feel limited by their main language or runtime and need a concurrent backend service to implement a feature.

jilles 2y ago
Kotlin also has amazing concurrency support. Plus you get the additional benefit of the entire Java ecosystem. I wish it got more love.
- teg4n_ 2y ago
  Kotlin is not simple. it has like every language feature in existence
  - have-a-break 2y ago
    Why do people always mention kotlin, but not Scala? Scala is more similar to traditional Java while letting functional programming shine.
    - pclowes 2y ago
      Honestly, I think it is because the Scala community was/is/can be so pedantic and bickering and often combative and toxic that it lost all momentum and appeal. Nobody wants that culture in their workplace. Also the dysfunction is visible in the technical fragmentation of the ecosystem
    - valenterry 2y ago
      Scala is way superb for concurrency than what Go or Kotlin have to offer. But it is a complex language with a high learning curve.
    - re-thc 2y ago
      > Why do people always mention kotlin It's backed by $$$ that have promoted it that way - a "better" Java.

moron4hire 2y ago

I disagree. I don't think it's too much to ask of software developers to be the bare minimum of competent enough to wire up a basic web service in whatever language they are dealing. REST is not complex.

onion2k 2y ago
REST is not complex. REST isn't complex, but API design is still hard. Making a strategic choice not to design a service API but to ship the same code in two places is valid, and arguably the right one if that's what the teams skills lend themselves to.
baq 2y ago
Over the past two decades I’ve seen a well implemented RESTful API exactly once, in a relatively small project. The rest of REST apis are ad-hoc RPC over HTTP, I’d argue because it isn’t complex and complexity moves to the client.

TheCapeGreek 2y ago

At the least, tools that minimise the usage of certain languages (i.e. JS if you're not a JS shop) or general frontend boilerplate will also do this. See: Rails Hotwire, Laravel Livewire, Alpine.js

Cyph0n 2y ago
Or Elixir + Phoenix + LiveView.

temporallobe 2y ago

This is why Rails is a decent solution for many apps. It’s “Ruby everywhere” including the data layer.

brunoqc 2y ago

Gleam might be a good fit for that.

meandmycode 2y ago

This was my view once, but practically the languages have their own ecosystem strengths, now I think most of the major languages have similar concepts, async await, etc.. instead we now teach transfer your skills, and tbh I think it makes for a more interesting culture that's adoptive and excited by tech, and also learns better

nesarkvechnep 2y ago
It’s called being a software developer instead of being a JavaScript developer. If someone knows how to engineer software, their skills are transferable. Stitching libraries together is usually not software engineering.
- 8note 2y ago
  software engineering is mostly a kludge of interacting with stuff people have made and will make, rather than physical limits of different materials and structures stitching libraries together is the essense of soctware engineering

deleted 2y ago

[deleted]

hansonkd 2y ago

Hard disagree. Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both. Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chances are if you just chose react and typescript you could pull things off the shelf and have almost an unlimited amount of resources and developers you could pull from compared to an esoteric LiveView or webassembly type framework, get the project done faster, ship and iterate as opposed to reinventing the wheel and satisfying the commonly felt NIH syndrome. Typescript for both frontend and backend is a bit better, but the backend story for me is still weaker than using Python or elixir, etc simply serving an API, because if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit. the only exception to the above is if you aren't building a company and instead working on a small personal or group project.

Aeolun 2y ago
> Almost never have a met a person who was equally good at both. Doesn’t that say more around your surroundings? I’ve definitely met people that were equally competent at both (and more competent than most). A lot of things that are important on the front-end are equally important on the back-end and vice versa. Lets add databases and infra while we are at it. The thing is, you need an actually senior engineer for that. Not some kid right out of college that is somehow called a principal.
- runarberg 2y ago
  These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design. On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers to deliver a good UX. On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure, or work with your infrastructure engineer, you have to design databases and optimize your storage and delivery. You also need to deliver a good API for your frontend devlopers, otherwise they‘ll complain. I‘m a frontend developer so I bet there are tons of stuff backend developers do which I don‘t even know about.

have-a-break 2y ago

I think it's a safety concern, I'd like to explicitly know whats being ran on the client vs the server. And react introduces a host of dependencies which may be ill maintained. The only reason to bring this up in an online forum is because I'm tired of recruiters constantly asking for react and nodejs.

smarkov 2y ago

I get the potential appeal in having a single language do all things, but in practice the front-end and back-end have vastly different jobs and different capabilities, so I see no issue in them being different languages and letting them utilize their strengths. Not to mention the vast amount of complexity you need to involve at some point in order to bring a language to a side it wasn't meant to be in.

8note 2y ago
moreso, you cant share promise chains or streams well across api boundaries, so it isnt seamless, even in the same language

rvz 2y ago

> I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in our case it was). Absolutely bad advice and totally disagree. So having a language such as TypeScript which is already built on top of an even more immature language such as Javascript in critical systems software or highly regulated settings is a good idea? Having it on the backend is also bad enough, but everywhere really an indication of not being able to adapt into using a properly designed language for the specific use-case and just being inflexible because you are 'used to the language'. This is not even talking about the entire TS/JS ecosystem which is has a sea of libraries which most of them are also immature and not production-grade at all.

panstromek 2y ago
Sounds like a straw man to me
baq 2y ago
The ecosystem is a bit insane, JavaScript is a disaster, but typescript itself is very, very good. IMO it’s better for complex backends than Python, and I’ve been doing Python since before Django 1.0. That said I’m patiently waiting for dotnet renaissance.

jmyeet 2y ago

No disrespect to you but I'm constantly reminded of this quote: "Consistency is the hobgoblin of little minds" -- Ralph Waldo Emerson It's this same idea that led Google down the garden path that was (is?) GWT: Java everywhere. It seems like a good idea but for every platform you add, you reduce the total the lowest common denominator between them. You add transliteration bugs and issues. Google also trie to do this with Protocol Buffers on Javascript front ends and the serialization methods were... suboptimal. Because obviously you can't do (or at least couldn't at the time) binary encoding and decoding on a browser. All this is why we've seen multiple attempts to, say, allow you to write an app that'll work on iOS and Android. React Native springs to mind. Now if you can come up with an end-to-end Typescript solution, that's great. But it's also a pretty severe constraint and one that doesn't, for example, solve the native mobile platform issue.

panstromek 2y ago
I have pretty positive experience with Capacitor, actually. Precisely because it doesn't try to be e2e solution that shields you away from the native platform. It doesn't stand in your way when you want to do something native, it's more of a toolkit to manage the bridge between WebView/Native land.

panstromek 2y ago

I guess this depends a bit on the project but pretty often yes. I currently maintain Typescript SPA with PHP backend and the split between languages is very frustrating, it induces a ton of pointless busywork. If the backend language was something stronger, than I'd be willing to accept that split to get those benefits, but having two different scripting languages seems quite pointless.