Comment by tomatowurst | Hacker News Reader

Comment by tomatowurst | Hacker News Reader

Parent Full thread

> full stack typescript because it’s incredibly powerful resource (as in money) wise to have the same environment across everything in non-tech enterprise.

but with typescript are you not ending up writing more code? curious to know more about this and are you seeing tangible benefit from not having to switch between backend and frontend? im somehow skeptical of this and im always curious to hear from others who might prove otherwise.

we are using python on the backend (aws chalice) and just react javascript. don't really find much issue switching back and forth. and post 3.5 there is now runtime type hinting too so I didn't really see the appeal of using typescript.

now if there was only a way to write frontend applications in python that would be a dream :)

> We also do a lot of “serverless” but the way we do it seems far less vendor dependent than this. Basically what we do is layer out the “node” part of our “serverless” application and let our cloud provide act as what is essentially the role of what expressJS or similar might have done for you 5-10 years ago. We’re also handling a lot the federated security through a combination of ORMs, OPA, AD and direct DB access control for the very rare BI application that needs it.

hmmm I guess we are locked to AWS sort of (since we use AWS chalice) but I mean it could easily be ported to a python Flask server since the syntax is almost identical and we could absolutely run this on a VPS server if we choose to.

> but with typescript are you not ending up writing more code?

I think that depends on who you are and where you work. I actually come from a decades worth of C# and Python experience before starting at this place. I even wrote my first five “serverless” services in Python here, before switching to Typescript around December 2021. It wasn’t love at first sight, let me tell you that, but the control Typescript gives you once you decide upon some standards and enforce them, just makes things easier to manage. Basically what we do is write functional services that utilise interfaces (bad name) as a form or data-object Types and it sort of gives you this magical environment that has the best of both Python and C# mixed together.

You could probably achieve the same with Python, but we couldn’t. ;)

As far as speed, I’m talking about how we can reuse our internal packages. I wrote a NPM package to handle Odata API calls with the ability to add generics so that you can auto-complete anything in the query. I wrote it for our react clients (we use typescript for those) and then when I was writing a “serverless” function to do some heavy lifting in C# or Python it annoyed me that I couldn’t just consume the same library/package. Which is basically how I was converted to Typescript. I mean, there were other compelling arguments, but that’s what really did me in.

I’m not a fanatic though. I’m sure I’ll write more C# and Python and probably something else when it’s going to make sense to do so. But our Python “serverless” applications are frankly build the same way our Node applications are. It’s a little different with C# because the thing I haven’t yet named is Azure, but ideally, they too should be decoupled.

hmm interesting I will give it a try this weekend, I am trying to learn SolidJS so typescript will be needed anyhow.

Is there any issue with working with non-typescript npm modules?

By writing more code in this case, I think you're just referring to using a type system.

Yes, you type a little more, and your code is easier to refactor and change in the mid/long term. So you save time, and sanity.

Not mentioning the cost of using a slower runtime with Python... I've seen serverless bills of 100k+ a month with NodeJS. If something twice as slow was used, and Python is more than twice as slow on average, then we'd be talking 200k+...

Python can be faster than nodejs in many (but far from all) cases. It depends a lot on the workloads and environment. No general benchmark will tell the whole story.

Here Python came out on top:

https://scribe.rip/filia-aleks/aws-lambda-battle-2021-perfor...

https://scribe.rip/ville-karkkainen/python-is-slow-wait-its-...

In our case they were long lived lamdas consuming from a queue, so a JIT and good memory management mattered more.

Reply on news.ycombinator.com