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

211–220 of 244 posts

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

#211

Post by geewee »

chmln wrote: post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

Well, in React's case if you use PropTypes, the rewrite is mostly mechanical, and can be automated via things like https://github.com/lyft/react-javascript-to-typescript-trans...

But many tools, flow, Python, TS allow you to incrementally add types to an existing codebase. That way refactoring isn't some herculean effort, but something you can do for new features, or gradually over time.

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

#212

Post by fxfan »

nickbauman wrote: post #192
fxfan wrote: post #188

Earlier quoted context omitted.

That's why there are compile-to-Js languages that see widespread adoption. Elm, bucklescript, Scala.js to name a few.

... Clojurescript. A React app is 10x more complicated than a Reagent app. http://reagent-project.github.io/

In the following code segment, the `[:div` `[:p` et al- are the reagent or clojurescript?

```

  (defn simple-component []

    [:div

     [:p "I am a component!"]

     [:p.someclass

      "I have " [:strong "bold"]

      [:span {:style {:color "red"}} " and red "] "text."]])
```

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

#213

Post by vnorilo »

bengotow wrote: post #43
_bxg1 wrote: post #34

It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.

Yep I feel the same. TypeScript improves my workflow tremendously and I use it for everything now. Going back to regular javascript feels like driving without a seatbelt. Sure you can but why? Type-checking and smarter autocompletion mean I don't make mistakes as often and my productivity is higher. (No longer run the app, see I misspelled a function call, fix and run again, etc.) I also feel unit-level tests are les…

The major advantage of static types is replacing tests with proofs. Tests always have (limited) coverage, but type proofs are invariant. That said, it's very possible to misunderstand what a test or a type actually means.

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

#214

Post by fergie »

Yup- Typescript is mostly used in large-scale enterprise software development where rigorous unit tests are not in place.

I still suspect that a large part of Typescript adoption comes from developers who are used to working in an IDE (Visual Studio, Eclipse, etc), and are uncomfortable with javascript's natural "textfile->compiler->test" workflow.

Its also worth noting that support for typescript (that isn't Microsoft marketing) tends to come from outwith established tech environments. Using Typescript outwith MS environments can be challenging.

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

#215

Post by vnorilo »

Retozi wrote: post #72
mixmastamyk wrote: post #39

Earlier quoted context omitted.

> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.

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…

A well designed dynamic language like clojure can have explosive velocity. Stuff just fits together smoothly: a predicate can be a function or a set or a map or a regex, but most importantly, libraries are built of these mutually compatible blocks. Reminds me of (Sussman's?) description of lisp codebases as organic.. of course, "explosive" can be very literal when type mistakes propagate and the data model goes to bizarroworld. In clojure, you can defend yourself with spec, which catches these things at the site of the mistake. It's a tradeoff I often like (velocity vs. compile time checks). It all depends on the domain.

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

#216

Post by true_religion »

ht85 wrote: post #28
chmln wrote: post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

Rewriting vanilla JS to Typescript isn't that big of a deal though. It would be more like building a house on a budget, then adding some fancy paint, furniture and alarm system. In my experience, if you spend a few weeks in the "exploratory" phase writing ES6, rewriting to TS won't take more than one or two days. Nowadays I'm a lot better at Typescript and will use it from the get go, but for someone who is less skil…

Alternatively, you can write in Typescript from the get go with most of the strict checks disabled, then only enable a certain check when you see the need.

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

#217

Post by autoconfig »

ravenstine wrote: post #139

The amount of fanboyism in these comments is astounding. TypeScript is a great tool. At the same time, people have written apps with vanilla JavaScript for a very long time now, and it works just fine. If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing. It's not "dangerous" to use plain ol' JavaScript, an…

> If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing.

Speaking of software snobbery, what does this statement reek of? This attitude is just as condescending and utterly non-constructive as the fanboyism you're describing.

I'm currently building a fairly large application using TypeScript both on the front end and backend specifically because I "have a hard time writing an application without a compiler checking your types". It's working great but according to you this is a valid reason to reevaluate what I'm doing?

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

#218

Post by mschuetz »

ajxs wrote: post #195
hn_throwaway_99 wrote: post #191

Earlier quoted context omitted.

I completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java. As you put it, "Once you get into the controllers they tend to become en…

I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like: ``` Thing thing = await loadThing(); Thing other = await thing.doSomething(); thing = await saveThing(); // repeat x1000... ``` I see this over and over.

And what exactly is the problem with that?

"Thing thing = await loadThing(); ": Start loading thing, then await so the main thread can continue doing other stuff while thing is loaded.

"Thing other = await thing.doSomething();": Invoke some other function that does some stuff in the background, then await so the main thread can continue doing other stuff while thing does something.

"thing = await saveThing();": Saving can often be done in parallel so no need to block the App while something is saved. Invoke the save function, then await so the main thread can continue doing other stuff while thing is saved.

This gets you the advantages of async programming while still maintaining a legible coding style that looks similar to common synchronous code.

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

#219

Post by mschuetz »

sieabahlpark wrote: post #185
ajxs wrote: post #178

Earlier quoted context omitted.

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

What benefits don't we get with async/await?

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

#220

Post by arvinsim »

wrestlerman wrote: post #20
chmln wrote: post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

I don't know why people make such a big deal of types. They don't add that much time to typing the code. I also have noticed that if you write daily using some code style (for example using types) it takes time to switch to another style, for example without types. So you are better of using types, because you are used to it and you will code faster that way anyway.

For me, it is less about typing and more about being sidetracked with hard-to-debug Typescript issues.

I also use HOCs a lot and it's painful with Typescript.

Post reply on HN