When to Use TypeScript – A Detailed Guide Through Common Scenarios • Hacker News Board

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

#181

Post by 52-6F-62 » Mon, Apr 08, 2019, 2:05 AM UTC

lewisl9029 wrote: post #123

52-6F-62 wrote: post #121

Earlier quoted context omitted.

My experience is exactly the opposite of yours. Babel has always caused me headaches. Setting up Babel-based build systems is troubling—the same setup will work sometimes and not others even on the same machine. TypeScript vastly simplified working with modern JS for me. It’s consistent, requires far fewer dependencies, and is much more succinct. YMMV, of course...

I don't know if what you've described is an _opposite_ experience. I think TypeScript would work fine for me too if I never needed anything compilation-wise outside of what tsc is already capable of. But as soon as you do, the lack of extensibility of tsc compared to babel becomes painfully obvious.

I think it is the opposite. Even without TypeScript Babel has grown to be overly complex.

If you’re talking about front end libraries like React you’re better off ditching Babel altogether and going with something like Parcel. It just works.

The TS developer experience ya sim proved working with JS enormously for me when I have to do it, and nudged me toward simpler, smarter development environment setups.

I can’t speak for you or anyone else. Just adding my two cents.

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

#182

Post by weberc2 » Mon, Apr 08, 2019, 2:05 AM UTC

danmaz74 wrote: post #108

marcosdumay wrote: post #55

Earlier quoted context omitted.

Well, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation. I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.

What you described is the waterfall approach, which brings so many problems in most real world software development scenarios.

The opposite of waterfall is not “no planning whatsoever”.

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

#183

Post by weberc2 » Mon, Apr 08, 2019, 2:07 AM UTC

Jare wrote: post #110

josteink wrote: post #48

Earlier quoted context omitted.

> It doesn't slow down development I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.

I find that the first 50 lines are faster / more immediate without types. By 500 lines it's largely even. By 5000 you will have to pry types off my cold dead hands. I wish I could be convinced by the likes of Rich Hickey that types don't actually help, because he's so smart and charming and eloquent, but my experience screams the opposite.

Yeah, I haven’t used lisp enough, but I want to believe that there is something inherent in its simplicity that makes it categorically different from all of the other dynamically types languages I’ve tried which all would benefit from static types.

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

#184

Post by phiresky » Mon, Apr 08, 2019, 2:09 AM UTC

lewisl9029 wrote: post #127

lewisl9029 wrote: post #116

This doesn't seem like a common occurrence, judging from all the praise of TypeScript sung on this thread and elsewhere, but I've had an overall negative experience working with TypeScript so far. Here's some thoughts on what has contributed to that so far: 1. TypeScript pushes you towards its own build pipeline (based on tsc) that doesn't play nicely all the time with mainstream JS build pipelines (usually based on…

2. TypeScript's type checker, at least in its current state, has been downright painful to work with for functional programming with functional composition and higher order functions in general, with errors that are incredibly opaque and unhelpful, and its poor inference introduces so much seemingly avoidable type-related verbosity that it completely distorts the signal to noise ratio in our code. A prime example for…

You realize that your problems with Rambda were mostly fixed in TS3.4?

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

#185

Post by sieabahlpark » Mon, Apr 08, 2019, 2:09 AM UTC

ajxs wrote: post #178

bloomca wrote: post #173

Earlier quoted context omitted.

> 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 no…

I think most people think async/await gives them all the previous benefits of async but doesn't

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

#186

Post by phiresky » Mon, Apr 08, 2019, 2:11 AM UTC

lewisl9029 wrote: post #134

lewisl9029 wrote: post #127

Earlier quoted context omitted.

2. TypeScript's type checker, at least in its current state, has been downright painful to work with for functional programming with functional composition and higher order functions in general, with errors that are incredibly opaque and unhelpful, and its poor inference introduces so much seemingly avoidable type-related verbosity that it completely distorts the signal to noise ratio in our code. A prime example for…

3. TypeScript only supports positional generic parameters (i.e. you can't give them names). It's well known that positional semantics don't scale when it comes to argument lists, because when changing the API of something with a positional argument list, adding an argument in an arbitrary position becomes a breaking change that requires all usages to be updated. Unfortunately, part of the fallout from point 2 means w…

You can kind of give generics names by declaring them in an interface and passing T extends Interface as the generic parameter

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

#187

Post by [deleted] » Mon, Apr 08, 2019, 2:11 AM UTC

seanmcdirmid wrote: post #109

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…

Though you have a point, writing down type annotations can seriously slow you down when you are doing exploratory (prototyping) programming. It can also make your code less readable as the annotations can get in the way of the logic you really care about (easily fixed in an IDE, but people want to still use notepad to edit/read code). Then there is figuring out what the annotation should be in the first place, again…

[deleted]

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

#188

Post by fxfan » Mon, Apr 08, 2019, 2:20 AM UTC

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…

That's why there are compile-to-Js languages that see widespread adoption.

Elm, bucklescript, Scala.js to name a few.

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

#189

Post by fxfan » Mon, Apr 08, 2019, 2:22 AM UTC

crooked-v wrote: post #144

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…

What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?

While your parent clarifies that he meant for backend- ill suggest trying one off bucklescript, Scala.js or elm. They are all very well done and have wide adoption actually

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

#190

Post by hombre_fatal » Mon, Apr 08, 2019, 2:24 AM UTC

Jare wrote: post #110

josteink wrote: post #48

Earlier quoted context omitted.

> It doesn't slow down development I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.

I find that the first 50 lines are faster / more immediate without types. By 500 lines it's largely even. By 5000 you will have to pry types off my cold dead hands. I wish I could be convinced by the likes of Rich Hickey that types don't actually help, because he's so smart and charming and eloquent, but my experience screams the opposite.

Yeah, exactly. I think people add way too many zeros to those figures when they try to come up with advantages for dynamic-typing. There certainly are some, but I don't think agility is in dynamic-typing's favor.

The usual saying is that faster development is more important because your business probably won't get users anyways. As if Ruby is going to give you a two year head start before any chickens come home to roost.

I don't know about that. Maybe you will get a half-day head start on me if I'm using a statically-typed language I haven't used before and I'm digging through old projects to remember how to write my .gradle hello world.