8 ms·

> For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtual

> For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS Is there any Typescript backend framework as mature as Django? > Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly. So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.

spiderice 5y ago
You are interpreting GP’s comment very uncharitably, to the point that it actually becomes a completely incorrect interpretation. GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.” There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.
- creshal 5y ago
  > GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.” Because he considers it a "barrier" to have to switch between languages to do backend-only changes. Which is a completely different use case than the one you're describing. For an SPA where you're essentially doing frontend on both ends, yes, that's obviously easier when you're only doing it once. But that's not the general case, and I'd argue that transitioning between different mental contexts for components you're not regularly touching is always going to be a hurdle to developers, regardless of the language used. Blaming it on the language is an useless red herring.
  - wonnage 5y ago
    It's definitely a barrier to have to switch languages. You might be super familiar with Chrome's debugger UI (which is excellent, btw), and feel lost when suddenly getting dropped into IntelliJ's. Also, what if you just have frontend developers who straight up don't know Java or vice versa? I don't see how having a shared language could ever be a bad thing.
  - Jarwain 5y ago
    I feel like switching languages adds extra friction too. Switching contexts is still a hurdle, but using the same language can make the hurdle shorter.
  - aranchelk 5y ago
    Having to write the same logic twice in two languages, and then making sure both implementations behave the same way. I don’t know if I’d use the word “barrier”, it’s certainly a significant pain in the ass. The classic example is of course validation, but plenty of other places it can come up.
  - onei 5y ago
    Perhaps I'm overthinking things and HTML does this naturally, but is there something for rendering that is what Swagger/OpenAPI is to APIs? Some way of specifying HTML that can be both rendered (and read back for inputs) by multiple implementations.
    - creshal 5y ago
      In theory, that's what template languages like jinja, liquid and twig are for. But as you can see, there's n+1 standards for it, and in practice none of them has a Javascript implementation good enough for productive use. So it's more a "what if?" scenario, had Angular/React/Vue not taken off.
austincheney 5y ago
Learning is great. It expands horizons, potential, and current capabilities. Learning is not producing though. Learning is a cost center. If you want to increase productivity start by minimizing required learning. That exchange is called usability.
- gentleman11 5y ago
  Interesting phrasing, I like it. But you can also reduce the cost by making learning easier, whether with good interfaces or naming, or just good docs
- creshal 5y ago
  > Learning is not producing though. Learning is a cost center. Spoken like a true MBA. > If you want to increase productivity start by minimizing required learning. Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. Is your employee churn so bad that you can't afford even this little familiarisation?
  - austincheney 5y ago
    There are two fundamental practical problems with your thinking. 1. Employers don’t train on languages/frameworks. In most circumstances employees are expected to learn on their own or from a prior employer before applying for a job. Worse, the last place I interviewed only asked about learning from the current employer while never asking about self learning outside the office. 2. Employees, in many cases, believe they can cheat learning by using a tool or framework. That is largely due to a lack of boundaries and experience in a given environment or platform resulting in low trust of peers and the technology. If you want to require learning then provide sufficient learning material expecting a predefined structured outcome.
    - creshal 5y ago
      We are training our employees. Learning the ropes of a new language/framework enough to make easy changes is trivial, so why wouldn't we? Much better than crippling our choices in software stacks we can use.
dfabulich 5y ago
> Is there any Typescript backend framework as mature as Django? No TS framework is as old as Django, and if you're looking for "Django for TS" you won't find exactly that, but Next.js is the current reigning champion for server-side frameworks right now, according to the popular "State of JavaScript" survey https://2020.stateofjs.com/en-US/technologies/back-end-frameworks/ https://2020.stateofjs.com/en-US/technologies/back-end-frame... Next is a "both-side" framework, allowing it to do stuff you just can't do in Django. If you want something much thinner than Next (and thus much thinner than Django), there's Express. > yet it cannot possibly be expected that frontend people learn more than a single language? The problem isn't learning two languages, it's interop between two languages.
- creshal 5y ago
  > No TS framework is as old as Django, and if you're looking for "Django for TS" you won't find exactly that, but Next.js is the current reigning champion for server-side frameworks right now, according to the popular "State of JavaScript" survey https://2020.stateofjs.com/en-US/technologies/back-end-frame https://2020.stateofjs.com/en-US/technologies/back-end-frame... So by that graph, it has a good chance of being entirely deprecated and/or abandoned in the next 3 years, what a wonderful foundation for a backend. And it doesn't even have any support for an ORM? Neither does Express? Having to hand-write every single query and migration like it's 1999 again is hardly the cutting edge of IT stacks… > The problem isn't learning two languages, it's interop between two languages. How so?
  - btgeekboy 5y ago
    Regarding ORM, it's typically paired with Sequelize or Prisma. (I'm personally using the latter.) I've built Django apps in the past (it's actually how I learned Python in the 2.5 days), but what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components. For example, while I mentioned the ORMs above, you can even go one step further and use a backend headless CMS like Strapi, which will get you the ORM + admin interface that you'd get from Django models.
    - 5y ago
hn_throwaway_99 5y ago
Our backend is Apollo GraphQL in TS, and it is has provided us numerous benefits: 1. The strong typing of GraphQL is a huge boon for correctness and security. 2. Easy to autogen TS types from GraphQL schema, so we can use the same types throughout our codebase, frontend and backend. 3. Apollo has lots of features that make it easy to scale projects.
- creshal 5y ago
  And yet – Apollo advertises its easy Python interoperatibility right on the front page, as one of the features that makes scaling easier.¹ GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers. ¹ https://www.apollographql.com/blog/graphql-python-api-complete-guide/ https://www.apollographql.com/blog/graphql-python-api-comple...
  - hn_throwaway_99 5y ago
    OK, let's unwrap that: > And yet – Apollo advertises its easy Python interoperatibility right on the front page Yes, absolutely, there is great support for GraphQL in many different languages. > , as one of the features that makes scaling easier.¹ To be clear, that is your own commentary and I didn't see anything in the Apollo site that said implementing in Python makes scaling easier. I.e you seem to be implying that somehow implementing in Python is better for scaling, but there is no background to support that. > GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers. Yes, I totally agree with that. If you are, say, providing an API to other developers GraphQL is a great choice for a number of reasons, one of which is that there is great language support across pretty much all languages. But if you are starting a project within a company, and have the luxury of choosing technologies, having the same ecosystem on the front and back ends makes it much easier for people on either team to go across that "boundary" if necessary. This is not just me hypothesizing. For the majority of career, which really started right when web apps started taking off, there was a separate language on the backend (Java for the majority of my career, but also sizable stints where Ruby and Python were the backend languages). Yes, most backend folks understood JS and CSS, and most frontend folks could understand the backend languages, but it was still a huge barrier to people being able to contribute across teams such that it rarely happened. It's only in the past couple of years where I've been in a "TypeScript everywhere" org where I've seen the gigantic change in the team dynamic that this allows.
mxkvl 5y ago
idk why people mentioned Next.js which is more Front End framework than Back End, but no one mentioned Nest.js. It is not old as Django but I think Nest is nearest framework to RoR/Django in Node.js
- williamdclt 5y ago
  Definitely. NextJS isn't a "backend framework", it's a server-side rendering framework that has some backend abilities to handle simple use-cases. NestJS is the most full-featured Node framework, but it's lightyears behind Django. Yet I'd still use it given the choice between both, because I prefer Typescript so much better than Python and having a single language through the stack is a game changer, enough that I'm willing to compromise on the frameworak.
8note 5y ago
Express? https://www.npmjs.com/package/@types/express https://www.npmjs.com/package/@types/express

spiderice 5y ago

You are interpreting GP’s comment very uncharitably, to the point that it actually becomes a completely incorrect interpretation. GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.” There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.

creshal 5y ago
> GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.” Because he considers it a "barrier" to have to switch between languages to do backend-only changes. Which is a completely different use case than the one you're describing. For an SPA where you're essentially doing frontend on both ends, yes, that's obviously easier when you're only doing it once. But that's not the general case, and I'd argue that transitioning between different mental contexts for components you're not regularly touching is always going to be a hurdle to developers, regardless of the language used. Blaming it on the language is an useless red herring.
- wonnage 5y ago
  It's definitely a barrier to have to switch languages. You might be super familiar with Chrome's debugger UI (which is excellent, btw), and feel lost when suddenly getting dropped into IntelliJ's. Also, what if you just have frontend developers who straight up don't know Java or vice versa? I don't see how having a shared language could ever be a bad thing.
- Jarwain 5y ago
  I feel like switching languages adds extra friction too. Switching contexts is still a hurdle, but using the same language can make the hurdle shorter.
- aranchelk 5y ago
  Having to write the same logic twice in two languages, and then making sure both implementations behave the same way. I don’t know if I’d use the word “barrier”, it’s certainly a significant pain in the ass. The classic example is of course validation, but plenty of other places it can come up.
- onei 5y ago
  Perhaps I'm overthinking things and HTML does this naturally, but is there something for rendering that is what Swagger/OpenAPI is to APIs? Some way of specifying HTML that can be both rendered (and read back for inputs) by multiple implementations.
  - creshal 5y ago
    In theory, that's what template languages like jinja, liquid and twig are for. But as you can see, there's n+1 standards for it, and in practice none of them has a Javascript implementation good enough for productive use. So it's more a "what if?" scenario, had Angular/React/Vue not taken off.

austincheney 5y ago

Learning is great. It expands horizons, potential, and current capabilities. Learning is not producing though. Learning is a cost center. If you want to increase productivity start by minimizing required learning. That exchange is called usability.

gentleman11 5y ago
Interesting phrasing, I like it. But you can also reduce the cost by making learning easier, whether with good interfaces or naming, or just good docs
creshal 5y ago
> Learning is not producing though. Learning is a cost center. Spoken like a true MBA. > If you want to increase productivity start by minimizing required learning. Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. Is your employee churn so bad that you can't afford even this little familiarisation?
- austincheney 5y ago
  There are two fundamental practical problems with your thinking. 1. Employers don’t train on languages/frameworks. In most circumstances employees are expected to learn on their own or from a prior employer before applying for a job. Worse, the last place I interviewed only asked about learning from the current employer while never asking about self learning outside the office. 2. Employees, in many cases, believe they can cheat learning by using a tool or framework. That is largely due to a lack of boundaries and experience in a given environment or platform resulting in low trust of peers and the technology. If you want to require learning then provide sufficient learning material expecting a predefined structured outcome.
  - creshal 5y ago
    We are training our employees. Learning the ropes of a new language/framework enough to make easy changes is trivial, so why wouldn't we? Much better than crippling our choices in software stacks we can use.

dfabulich 5y ago

> Is there any Typescript backend framework as mature as Django? No TS framework is as old as Django, and if you're looking for "Django for TS" you won't find exactly that, but Next.js is the current reigning champion for server-side frameworks right now, according to the popular "State of JavaScript" survey https://2020.stateofjs.com/en-US/technologies/back-end-frameworks/ https://2020.stateofjs.com/en-US/technologies/back-end-frame... Next is a "both-side" framework, allowing it to do stuff you just can't do in Django. If you want something much thinner than Next (and thus much thinner than Django), there's Express. > yet it cannot possibly be expected that frontend people learn more than a single language? The problem isn't learning two languages, it's interop between two languages.

creshal 5y ago
> No TS framework is as old as Django, and if you're looking for "Django for TS" you won't find exactly that, but Next.js is the current reigning champion for server-side frameworks right now, according to the popular "State of JavaScript" survey https://2020.stateofjs.com/en-US/technologies/back-end-frame https://2020.stateofjs.com/en-US/technologies/back-end-frame... So by that graph, it has a good chance of being entirely deprecated and/or abandoned in the next 3 years, what a wonderful foundation for a backend. And it doesn't even have any support for an ORM? Neither does Express? Having to hand-write every single query and migration like it's 1999 again is hardly the cutting edge of IT stacks… > The problem isn't learning two languages, it's interop between two languages. How so?
- btgeekboy 5y ago
  Regarding ORM, it's typically paired with Sequelize or Prisma. (I'm personally using the latter.) I've built Django apps in the past (it's actually how I learned Python in the 2.5 days), but what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components. For example, while I mentioned the ORMs above, you can even go one step further and use a backend headless CMS like Strapi, which will get you the ORM + admin interface that you'd get from Django models.
  - 5y ago

hn_throwaway_99 5y ago

Our backend is Apollo GraphQL in TS, and it is has provided us numerous benefits: 1. The strong typing of GraphQL is a huge boon for correctness and security. 2. Easy to autogen TS types from GraphQL schema, so we can use the same types throughout our codebase, frontend and backend. 3. Apollo has lots of features that make it easy to scale projects.

creshal 5y ago
And yet – Apollo advertises its easy Python interoperatibility right on the front page, as one of the features that makes scaling easier.¹ GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers. ¹ https://www.apollographql.com/blog/graphql-python-api-complete-guide/ https://www.apollographql.com/blog/graphql-python-api-comple...
- hn_throwaway_99 5y ago
  OK, let's unwrap that: > And yet – Apollo advertises its easy Python interoperatibility right on the front page Yes, absolutely, there is great support for GraphQL in many different languages. > , as one of the features that makes scaling easier.¹ To be clear, that is your own commentary and I didn't see anything in the Apollo site that said implementing in Python makes scaling easier. I.e you seem to be implying that somehow implementing in Python is better for scaling, but there is no background to support that. > GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers. Yes, I totally agree with that. If you are, say, providing an API to other developers GraphQL is a great choice for a number of reasons, one of which is that there is great language support across pretty much all languages. But if you are starting a project within a company, and have the luxury of choosing technologies, having the same ecosystem on the front and back ends makes it much easier for people on either team to go across that "boundary" if necessary. This is not just me hypothesizing. For the majority of career, which really started right when web apps started taking off, there was a separate language on the backend (Java for the majority of my career, but also sizable stints where Ruby and Python were the backend languages). Yes, most backend folks understood JS and CSS, and most frontend folks could understand the backend languages, but it was still a huge barrier to people being able to contribute across teams such that it rarely happened. It's only in the past couple of years where I've been in a "TypeScript everywhere" org where I've seen the gigantic change in the team dynamic that this allows.

mxkvl 5y ago

idk why people mentioned Next.js which is more Front End framework than Back End, but no one mentioned Nest.js. It is not old as Django but I think Nest is nearest framework to RoR/Django in Node.js

williamdclt 5y ago
Definitely. NextJS isn't a "backend framework", it's a server-side rendering framework that has some backend abilities to handle simple use-cases. NestJS is the most full-featured Node framework, but it's lightyears behind Django. Yet I'd still use it given the choice between both, because I prefer Typescript so much better than Python and having a single language through the stack is a game changer, enough that I'm willing to compromise on the frameworak.

8note 5y ago

Express? https://www.npmjs.com/package/@types/express https://www.npmjs.com/package/@types/express