Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When to Use TypeScript – A Detailed Guide Through Common Scenarios

khalilstemmler.com

Post reply on HN
Print view View original

171–180 of 244 posts

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#171

Post by sandGorgon »

ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

True, because you cannot avoid JavaScript. If you are building a new web startup, most likely you are going to write a LOT of React/frontend code.

So it makes absolute sense to write the backend in the same language...if you can. Typescript goes a long way in making this pleasant.

Nothing is stopping you from writing the backend in different language...but as an organization, you lose the advantage of shared thinking in one stack.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#172

Post by weberc2 »

nurettin wrote: post #86
Retozi wrote: post #72

Earlier quoted context omitted.

I have never understood why typed languages make you slower at any point in time (early, late etc.). Because you have to hit more keystrokes to write your program? That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystroke…

It is not the typing per se. Anecdotally, I started adding types to my python code and it is somewhat useful. That usefulness is diminished when you are fighting the type system instead of getting things done. Like when you have to make exceptions in typescript by using Any. Like when an interface for a js library is missing and you don't want to do all that work. Or when an API returns a field with a different type…

Python’s type system is a particularly bad example. It’s not ergonomic and the type checking is immature.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#173

Post by bloomca »

ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

> Promise-fatigue

JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice.

> poor ecosystem

Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages.

> For the extra tax you pay in terms of build pipeline

This pipeline is norm in the frontend development, so in case you have people proficient in tooling, it is not that high (of course, it is hard if you have Java developers).

> Typescript vs Javascript as if these are the only two possible options for web development

They are not, but the nice thing about it is that you can have almost the same tooling as on your frontend, if you have some sort of complex application. So that increases speed of development, and TypeScript gives you some sense of scalability.

Last part is that TypeScript can be adopted incrementally, while another languages will require complete rewrite (and different deployment, etc).

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#174

Post by bgorman »

bloomca wrote: post #173
ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

> Promise-fatigue JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice. > poor ecosystem Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages. > For the extra tax you pay in terms of b…

Other langauges can be adopted incrementally as well e.g. ReasonML and Clojurescript. I am not sure how you concluded that other languages need a different deployment. On the front end everything gets delivered to the browser...

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#175

Post by cmiles74 »

ajxs wrote: post #162
voidreaper wrote: post #147

Earlier quoted context omitted.

Other than Ruby and PHP, I've only really worked with JS/TS on the backend. Which strongly-typed programming language would you recommend on the backend?

Depending on what it is you're doing, I feel that .net and Java are far superior choices. Obviously these are pretty heavy languages, so obviously decide for yourself whether the size of your app justifies using a language like this. My thoughts run along the lines of: "If people are justifying using Typescript because their projects are large and critical, they're probably large and critical enough to use a language…

I would like to second this. This idea that everything will move more quickly if the same language is used on the client and server sides is compelling. But .Net or Java have been on the server side a long time, there are projects for which they are well suited.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#176

Post by jaequery »

Some people love js for it’s functional approach. Mainly because they hated the whole OOP paradigms and the design pattern baggage that came with it.

But now js is adding classes and there’s typescript , now it’s like Java all over again.

Welcome to programming, where the fads go back and forth in cycles.

I also read a commment here saying people love React because now they can add code all over their view file.

Well adding code in view file is ugly and there’s a reason why we tried to get away from doing that.

Sounds to me people want to just go back to the 90s-00s!

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#177

Post by slaymaker1907 »

ajxs wrote: post #158
dhab wrote: post #150

Earlier quoted context omitted.

I am not sure about other languages, but I have been programming in Java for many years, and Typescript does what Java does (minus performance on a long running VM on CPU bound computations) at a rate that I assume should be sufficient for most (business) apps, without any bloat. Can you elaborate on promise fatigue. In our setup we use async/await and the latest ES (although most of us prefer not using decorators if…

I've had too many terrible experiences having to maintain and work with buggy and poorly designed Node/Typescript packages. I'm especially thinking of the terrible choice of ORMs available for Node, Typescript in particular. TypeORM seems the de-facto standard and my experiences with it have been horrific. It looks like Hibernate but works like a dumpster fire. There isn't anything as robust as ORMs like EF or Hibern…

The ORM was your first mistake. They almost always get in the way and are way more complex than the relatively simple language (SQL) they are intended to abstract over.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#178

Post by ajxs »

bloomca wrote: post #173
ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

> Promise-fatigue JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice. > poor ecosystem Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages. > For the extra tax you pay in terms of b…

I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#179

Post by hombre_fatal »

sonnyblarney wrote: post #151
ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

" Issues like Promise-fatigue" Actually, async-await is a nice feature of the JS paradigm that simplifies things and that I miss in the threaded world of Java. But yes - use TS where you would have used JS, but TS up against other, more classical languages may not be the right choice for a lot of non-web projects.

Yeah, it's a strength in my book. Node makes it trivial to sequence asynchronous tasks, stuff you may be juggling in a server route.

You can start this promise early, await two parallel DB request + one API request, branch off some more async work depending on a response, await that initial promise that had a head-start because now you actually need it, and then run 10 tasks with no more than 3 in-flight at a given moment. And the code would look exactly how I just described it. And it's ubiquitous.

It's a good tool in the belt and imo the most trivial async implementation out there.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#180

Post by virtualwhys »

a-saleh wrote: post #62

I wonder if some of the people here, that like Typescript just fine, would consider less main-stream typed-js solution. I.e. Elm, ReasonML/ocaml/bucklescript, Purescript, Haskell with ghcjs, Rust with web-assembly compilation, or even wasm from Go? I am somebody who really likes to dabble, but is not a fronted person, so I am thinking, what would make you consider switching?

> I wonder if some of the people here, that like Typescript just fine, would consider less main-stream typed-js solution.

Would love to but TypeScript integrates so seamlessly with JavaScript the language, and the ecosystem, that it's difficult to justify using my preferred language (Scala/Scala.js).

Another thing to note is that working TypeScript with JavaScript feels idiomatic; I can't say that for any other typed-to-js language I've seen or worked with.

Finally, the ecosystem, this is the deal breaker. With TypeScript it's similar to languages on the JVM, you get a huge ecosystem for free. The alternative is manually writing wrappers/interfaces for JavaScript libraries, or, if you're lucky, interface generators are available, but even then there are often caveats/tweaks required to get things working as expected.

Post reply on HN