[EnKopVand]

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

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.

This way we can leave our cloud vendor at any time. Not without figuring out a suitable replacement but far easier than this article, and maintaining almost all of its advantages.

Interesting read, and if you’re certain AWS is a good home for the next five years from your most recently deployed service, then I don’t see too much of an issue with vendor lock-in.

[tomatowurst]

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

[EnKopVand]

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

[tomatowurst]

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?

[winrid]

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

[3np]

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

[winrid]

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

[AlchemistCamp]

I haven’t been super impressed with Typescript, to be honest. It’s fairly verbose, and it’s a gigantic language with a complex type system that still isn’t really type safe.

I’d lean towards either something dynamic and quicker to develop with, like Elixir, or else use Rust for the parts where stronger compiler guarantees are absolutely vital.

[lmarcos]

I was once working at a place which was heavily invested in CoffeeScript (at that time, the syntax and the handy sintactic sugar were awesome compared to what JS had to offer). A few years later after I left the company, I had a chat with an excolleague of mine and asked they if they have migrated to JS + babel transpilation. They didn't. As of today they are still working with CoffeeScript. It's a huge codebase.

I see TS just like CoffeeScript.

[FractalHQ]

Typescript is amazing. I didn’t get it until I built a large project with it. Now I can’t imagine working without it. Every-time I join a vanilla JS codebase, I can’t help but notice the multitude of bugs and setbacks we run into that would have been avoided entirely had they used TS. And the productivity gains scale exponentially with the size of the project- just as the harm scales in vanilla.

Doing justice to the advantages TS provides would take a proper blog post though.

[tasuki]

Is there a problem with CoffeeScript? I'd used it once and enjoyed it.