15 ms·

When to Use TypeScript – A Detailed Guide Through Common Scenarios

331 points by stemmlerjs 8y ago

externalreality 8y ago
I agree with this article. Good stuff. One minor gripe: > if you care about the code, you need to have unit tests for it. That's not really true. You can test at a differently granularity and still have the same confidence in your code. Scores of brittle unit tests crowding your productivity is not what you do to code you care about. I wish people would just stop propagating this detrimental rumor that is backed by zero evidence. I prefer to keep my unit test suite lite and sweet (try to test what is very sensitive at the unit level - easy to miss or algorithmic things) and then try to get the most out of my acceptance test suite. Sorry, but I just worked on too many systems where the unit tests suite breaks no matter what you touch and you spend more time updating the tests than actually getting shit done.
- a_wild_dandan 8y ago
  "Write tests. Not too many. Mostly integration."
- vp8989 8y ago
  +1, though this is an unpopular opinion. IMO appreciation for automated test ROI is a great litmus test for a "good programmer".
- leeoniya 8y ago
  agree. Acceptance Tests hit the sweet spot for me in terms of productivity and quickly catching causes of regressions (coupled with a well-groomed, atomic commit log).
- eranation 8y ago
  If you write a library, or expose a public interface, I do expect a lot of unit tests. Unit tests can run offline, fast, during build time. I don’t mind integ-unit tests that perhaps simulate a database in memory to avoid mocking the entire storage layer. I rather have tests that are technically integration tests as they include more than, well, a unit, as long as they are idempotent, test mainly one thing, and can run fast and offline. Not sure if there is a term for it but I call these integunit tests... (probably the worst name possible) But unit / unit++ tests are not just for you, they are for me, they give me confidence I can touch your code without inadvertently breaking something critical that you may have missed in your acceptance tests. It gives you peace of mind to be able to refactor. An acceptance test may tell you they something broke, but a good unit test will show you exactly where.
  - externalreality 8y ago
    > breaking something critical that you may have missed in your acceptance tests. So you can miss things in your acceptance tests but can't miss them in your unit tests? Why do you feel more confident with unit tests than with acceptance tests? Maybe because unit tests break more often so they are providing you with a false sense of security? Do you know that when a test fails for a reason other than the specified assertion its a called a false negative and the failure is meaningless? Do you know if your tests fail and no functional or non-functional requirements of the program has changed the failure is also meaningless (you are testing implementation)? Ask yourself how often does your group give you time to do these hypothetical large refactoring that give merit to large unit test suites? How many times, even, do you do small refactorings and find all the test have to go away or significantly change anyway because they made some implementation assumption that is no longer true? How many times have you gone into a test suite and have seen that its been patched up so many times that you can swear its testing something but you just don't know what? I know that Uncle Bob tells us about test for refactoring and this and that, but I just don't buy it any more. The emperor is naked god dammit. Uncle Bob and the like are very famous because people swallow their anecdote without due scrutiny.
    - discreteevent 8y ago
      One thing I can't find much evidence of is Uncle Bob's experience in delivering commercial software. I get the feeling he works mainly on toy examples which might explain some of the things he advocates that, like you, don't match my experience at all.
  - int_19h 8y ago
    If you write a library or expose a public interface, I expect functional tests that cover that interface. Unit testing would require going below that level, and test implementation details - which is exactly why those tests tend to be so brittle, and the overhead of maintaining them is so high.
- Spartan-S63 8y ago
  Biggest benefit of having a compiler in your toolchain is that it often serves as the majority of your integration testing layer. That said, you should proliferate unit tests for algorithmic logic. That can be a small subset of your code, but a large part of your domain (depending on richness). Integration testing can be written manually, or you can pick a compiled language that does a lot of the lifting by type checking and producing the binary. Acceptance tests guide the overall happy path and can protect against weird regressions.
- ufmace 8y ago
  I agree. I think it's important that your test suite gives you something useful with every test, instead of writing a bunch of pointless extra tests just to get to 100% coverage because you read somewhere that that's good. I feel like I ought to write more on this one of these days, but I have a few testing pet peeves, as far as tests you shouldn't write. Don't write tests that are a copy-paste of the code you're testing. Don't write tests to validate things that should be proven by your type system and lack of compile/parse errors. Beware of tests so tied to implementation details that they make your code harder to refactor. Don't write tests for things talking to external services - the only real test is that it correctly handles the actual service responses.
  - ChristianGeek 8y ago
    Tests should be testing behavior, not implementation (this was the original intent of unit testing but it got sidetracked over time).
- stemmlerjs 8y ago
  Thanks for reading the article. Perhaps I should have been more specific about what needs testing. In The Clean Coder by Uncle Bob, he says that your unit tests should approach the asymptote of 100% test coverage. Here's where I agree with his statement: On the backend, I agree that all of the domain-layer code should be tested. This is a hard requirement for me. It's also code that has 0 dependencies so it should be easy to test. TDD pairs really nicely with DDD. Unit tests give you the needed confidence in order to do refactoring. You can't refactor code without tests. If you do, there's a risk involved. Therefore, in order to safely improve the design of existing code, it needs to have tests. This "detrimental rumor backed by zero evidence" is one of the fundamental takeaways from Martin Fowler's book on "Refactoring" in addition to Uncle Bob's chapter in The Clean Coder on Unit Testing. Here's where I disagree with his statement on 100% test coverage. I used to spend a lot of time writing brittle tests by testing front-end UI code. I used tools like Selenium and Cypress. Because the front-end is the most susceptible part of a system to change, I found myself spending an equivalent amount of time maintaining these tests in addition to adding new code. This is a hard place to find a balance. In Angular, I merely ensure that I write tests for services. In React, I spend a lot less time writing Enzyme tests on rendering and a lot more time testing the redux operators. Uncle Bob clears this up in his book by saying USUALLY, it's not necessary to write UI tests. I'd say by UI tests, he means "rendering tests". His solution is to ensure that you have a way to run acceptance tests that work through the API, as it should be a lot less susceptible to constant regressions. This way, you're essentially testing the features that the API is executing. If you're using DTOs, the inputs and outputs of your system should remain relatively the same anyways, and you should spend less time changing old tests, and more time adding new ones.
  - externalreality 8y ago
    > You can't refactor code without tests See this is where the conversation goes south. You will use the phrase "unit tests" when it suits you, and then, like a magician using indirection, generalize to the word "tests" when it suits you. Why are you listening to Uncle Bob so much? I mean you can do as you like. However, the strong "Uncle Bob" style assertions should probably be left out of most articles in favor of a more humble "this is what worked for me/us" approach. Universal rules for any discipline are very hard to come by. Sharing what worked for you on your projects is great but it becomes somewhat obnoxious when you try to generalize it to universal rules that works in all environments for everyone. Also, I think that large unit test suites, where most of the tests are redundant, come about in competitive environments where if you try to make a commit without a test some other competitive coder will try to use it as a "I know better" stepping stone and call you out on the change - "Where is the test". After 3 years of this behavior what do you think your going to have. A nice clean suite of tests or a monstrous big ball of stubs, mocks, faked, copy pasta that resulted from defensive social coding. Honestly, write a light suite of tests that get to the point, and keep your ability to code swiftly and make changes quickly. As the code matures you'll find the trouble spots and focus testing on those areas. Don't blindly follow methodologies that are going to have you writing large test suite for version pre-alpha 0.0, and now your updating a large test suite for every micro-change just to make it to beta 1. Here is an old article by DHH where he rails against unit testing dogma. Ironically it was ideas from the Ruby community that formed a lot of the basis of the mad dog McCarthyan style unit test dogma. https://dhh.dk/2014/tdd-is-dead-long-live-testing.html https://dhh.dk/2014/tdd-is-dead-long-live-testing.html
chmln 8y ago
> 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.
- revskill 8y ago
  This. I always focus more on the "foundation" part, in this case, it's common React Hooks and its API for the components to use. The good part is, if some hooks are wrong, we can just write new one and replace old ones within old components without the need of taking care of the old wrong Hooks.
  - chrisweekly 8y ago
    Aren't Hooks too new for you to make claims about what you "always" do with them?
    - revskill 8y ago
      Before, it was HOC and RenderProps. This is just an example with Hooks, it's mostly how i approach the problem though.
      - chrisweekly 8y ago
        Right on, makes sense.
- a_wild_dandan 8y ago
  I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!" This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've never regretted that decision in the end. If people here want to use a 5 gallon bucket on an initial 5 gallon job, go for it. Best of luck to you. I'll be over here starting with a 10 gallon bucket and not sweating when the customer needs to add another gallon...
fxfan 8y ago
4 of the most popular language creators here https://www.youtube.com/watch?v=csL8DLXGNlU https://www.youtube.com/watch?v=csL8DLXGNlU agree that type systems are useful. I would suggest definitely not using Vanilla JS. There are excellent type systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with their pros and cons (I don't know what cons BuckleScript has though, maybe relatively smaller lib-ecosystem)
- melling 8y ago
  There are lots of alternatives to vanilla JavaScript. Why stop at types and encapsulation? http://bikeshed.fm/192 http://bikeshed.fm/192
- tyingq 8y ago
  Larry Wall is endorsing strong types? I'll have to watch that now. I guess you can use Perl 6 in a way that approximates it, but it's very optional.
  - Shoop 8y ago
    Does anyone have a timestamp for Larry Wall talking about types?
  - mst 8y ago
    I believe the idea is 'gradual typing', where you add types as you firm up an interface. Lots of the perl6 code I've seen types most stuff at least at interface boundaries.
- Hermitian909 8y ago
  I use bucklescript/reasonML extensively. The biggest con is definitely the smaller lib-ecosystem, creating bindings for functions is generally relatively painless but if you're using javascript libraries with large API surfaces that will be a large time sink. Otherwise it's been a joy to use.
- Illniyar 8y ago
  Not that I don't agree with their opinion, but being a language creator mostly like greatly biases you towards over estimating the usefulness of certain features. As such I wouldn't hold language creator's opinions on the value of certain language features over say the opinions of CTOs or VP engineering of large companies, especially as it relates to productivity, maintenance and onboarding.
parhamn 8y ago
Why does everyone treat TypeScript like a full language? Besides some features like generics 98% of it is just javascript with type annotations (sorta similar, including in syntax, to py3 with annotations). And in that view its probably foolish not to use it as the cost of these annotations is so low relative to the refactoring/safety/easy-of-use/code-completion/etc it offers. These type annotations are so easy to add! I can't even imagine writing JS without these annotations esp given all the odd behaviors of the language.
- a_wild_dandan 8y ago
  TypeScript is such an unbelievably powerful add-on that I simply refuse to use vanillaJS unless absolutely necessary. It eliminates entire classes of bugs, encourages me to write better code by thinking in JS about contracts (interfaces), and vastly improves my productivity with the aforementioned annotations. ("What was the signature for method X of class Y in library Z? Ah, that's it. Thanks, TS/VSCode!")
- bengotow 8y ago
  I know... when to use typescript = all the time? It's not a huge shift.
vore 8y ago
Regarding TypeScript, the benefit of catching way more errors at compile time greatly outweighs the amount of extra work for adding types. If you're starting a new JavaScript project, you should definitely think long and hard if you pledge not to use TypeScript.
- a_wild_dandan 8y ago
  And the best part is that TypeScript is just a superset of JS. If you're new to TS, you can use it like you've been using JS. Just by giving your variables the `any` type, or disabling null checking, and so on, you can write JS like you always have. No pressure. And, eventually, you'll be lulled into properly typing your variables, because damn it those type annotations are super handy! Oh, and you start defining your own interfaces because it makes your code more readable and easier to reason about. Oh, and...etc etc etc. If you start by gradually adopting the extra features that TS provides, you'll never want to go back.
- tills13 8y ago
  > greatly outweighs the amount of extra work for adding types this is such a bad excuse, imo - the "work" required to get your wheels off the ground in a JS -> TS transition is literally just changing the filename. 99% of syntax / TS errors that present themselves after that change are bugs that your code already had.
leeoniya 8y ago
i recently learned you can actually have typescript annotations without [imo] polluting the syntax or requiring the TS compiler: http://seg.phault.net/blog/2017/10/typescript-without-transpiling/ http://seg.phault.net/blog/2017/10/typescript-without-transp... does anyone know if there are limitations to this style?
- netghost 8y ago
  I suspect you can't do some of the fancier type contortions. For the simple case, I think it works just fine.
- orta 8y ago
  No limitations (only that it's a bit more verbose than just TS), this is canonical supported by the TypeScript powered tooling which VS Code provides by default on an JS project. https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
- breck 8y ago
  Cool, thanks. I generally love TS, but I have one project which I converted to TypeScript, and then reverted back to ES7, because the project is quite complex and the overhead of TS was not worth it. I wonder if by using this Jsdoc/ts strategy in critical sections I can get 80% of the benefit.
  - monkpit 8y ago
    > the overhead of TS Do you have any concrete examples? I would argue that a complex project that is already in TS benefits more from remaining in TS, so I’m curious what your reasoning was.
    - breck 8y ago
      1) Import/export syntax hell. This project is 148 Javascript files, 12k LOC. Everything runs in both Node and Browser environments. Without TypeScript I just use CommonJS syntax and rewrite the scripts on the fly via a server-side pass through for a browser environment. But because of the module hell (import/export/script modules/relative vs absolute paths/defaults) I couldn't find a good formula for write once, run everywhere for this large project. I needed to be outputting 2 different builds to 2 different places which led to all kinds of path problems. This is very much unique to this project though, which has unique runtime require requirements. 2) Compile time overhead when iterating. For many visual development tasks it just takes too long to change something, compile and see results in the browser. Without TS it's 0 latency. With TS it was a few seconds. Without TS I could make 10 changes with 2 seconds latency, and perhaps I make 1 type mistake costing me 20 seconds of debug time, for a total of 40 seconds. With TS I make 10 changes with 5 seconds latency and zero mistakes but now total overhead if 50 seconds. I want to be able to get the documentation and static type checking benefits without giving up that instant feedback.
humbleMouse 8y ago
Typescript is wonderful, especially as someone used to writing a lot of java/groovy. Typescript is like pouring cement around your javascript house of cards. It makes writing front end code painless and predictable. It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff.
- eitland 8y ago
  > It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff. ... and in the free Visual Studio Code, also crossplatform like IntelliJ. (Nothing against IntelliJ, JetBrains is a cool company with amazing products IMO, I just prefer VSCode myself.)
  - h1d 8y ago
    I think VS Code is almost like a little brother of IntelliJ now but better at a few places. (Especially rendering.)
- widerporst 8y ago
  >It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff. Yes, this makes writing Typescript actually faster for me than vanilla JS. The code completion in IntelliJ is really amazing.
  - h1d 8y ago
    I wonder what people are using to write code with for those that complain vanilla JS works fine. Vanilla vim?
devit 8y ago
Always, unless it's a very short script that uses packages that have no type definitions.
- SonicSoul 8y ago
  the issue I run into (and maybe there is a quick solution) but when I work on a TS React project and want to add a library that does not have Typings definitions, i get in a world of hurt. trying to quickly add my own typings or fix TS errors w/out disabling major compiler functions.. usually spend an hour or two and give up on the library.. is there a good way to deal with this scenario?
  - pault 8y ago
    That is a pain point, but I think of it as spending a few hours to save a few weeks down the road.
rasikjain 8y ago
Coming from C# background, Using Typescript for front-end programming was a breeze for me. This helped me in picking up newer frameworks and saved countless hours during debugging and build time errors. I liked strict validation of props using interfaces while working with restful APIs.
_bxg1 8y ago
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.
- mixmastamyk 8y ago
  > unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.
  - echelon 8y ago
    You'll find that the more you work with types, the less this becomes an issue. You begin to think in types as a first class construct. Types don't slow me down, and I can't imagine working without them.
    - mixmastamyk 8y ago
      You also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.
      - Normal_gaussian 8y ago
        Also working in both I don't have this issue. I generally find types make refactors faster - I have less bugs from the refactor.
        mixmastamyk 8y ago
        A mature refactor yes, a change in design often not.
    - lopatin 8y ago
      > types as a first class construct A wild Idris programmer appears
fourseventy 8y ago
Isn't anyone worried that TypeScript will go the way of CoffeeScript?
- Jare 8y ago
  No, it has a great team and the powerful Microsoft behind it, and MS is dogfooding it enough to make me feel they are not going to pull the plug.
- oaiey 8y ago
  I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.
  - dmit 8y ago
    To be fair to CoffeeScript, it introduced and popularized features that eventually made it to the EcmaScript standard. You could make a case for it being the kick that started the wave of improvements to JS that we've seen in the past decade. As for GP's post, I can only hope that Typescript leaves a similar legacy, even if the language itself ceases to exist.
    - danso 8y ago
      That kind of historical retrospective is an article I would definitely read. As much as Coffeescript seems like a dying language when compared to where JS is today, its appeal was very strong for it to have become a default include in Rails 3.1, and to have been the primary choice for teams like Dropbox and Github [0]. 0: https://en.wikipedia.org/wiki/CoffeeScript#Adoption https://en.wikipedia.org/wiki/CoffeeScript#Adoption
      - Jare 8y ago
        Its syntax and design was very appealing to Ruby developers. I was more surprised when Fog Creek chose it for Trello in '12, but yeah back then the raw Javascript experience was fairly poor, and Typescript would still take a couple of years to be ready for production.
z3t4 8y ago
The link to domain driven development wasn't useful. The post should explain more about that and SOLID.
giantsloth 8y ago
Having been reading hacker news since 2009, I’m really tired of these unevidenced clickbait listicles on some persons anecdote. There is no evidence presidented whatsoever in this article. It also seems that this person hasn’t worked with a numbered and diverse enough set of clients to even warrant listening to him as a practioner. He’s peddling tired DDD tropes amongst a spattering of meandering well worn blog posty unsciencey ideas he’s read throughout the years.
giancarlostoro 8y ago
> For example, it's almost always expected that your app is going to still work offline in some capacity; and when users ARE online, it's also usually expected that they're going to get real-time notifications without having to refresh the page. I never expect something to work while I'm offline, or do they mean the cached contents like a page would work if it were just cached HTML and CSS? As for real-time notifications, I don't know anybody who uses those, the other day someone was telling me how pissed off they were that they always get them from some news site, and they didn't mean to enable them, now they can't find where to turn them off!
a-saleh 8y ago
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?
- maaaats 8y ago
  What I mainly liked about TS is that it's basically plain js with some typeinfo sprinkled on top. So no barrier of entry for existing js developers. Now I work on a project with Elm for the frontend. It's not as easy to just jump into, so wouldn't use it for a project where lots of developers sometimes have to make additions. But once up to speed, Elm is great.
- hahamrfunnyguy 8y ago
  I know a lot of languages already, so unless there is a significant advantage to using a given language I'd probably pick one of the many I know already. Typescript has significant advantages over vanilla JS, so that's why I use it. If those other options offered a significant improvement over Typescript AND said features were something I needed, I wouldn't hesitate to use it. For now, getting better at the languages I already know seems like a better use of time.
- virtualwhys 8y ago
  > 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.
ChristianGeek 8y ago
Your DDD link is dead (so technically it’s a DDDD link :)
- stemmlerjs 8y ago
  Haha. Yeah, that's the next article for me to write. I just started this blog recently. My approach has been to track which dead links have been clicked the most and then write about that topic next. DDD is far in the lead. Expect it soon. Thanks for reading!
overgard 8y ago
Honestly, the only downside to me of typescript is occasional grief from @type libraries or some build complications when you're first getting setup. But having working code completion and non-surprising return values/argument parameters is so much worth the initial minor pain points.
- burtonator2011 8y ago
  The other issue is dealing with module compilation... this part still always screws me over. Once it's up and running TS is freaking amazing
flabbergast 8y ago
> it's actually dangerous for your project to NOT be written using TypeScript today. Wow! Bye bye Javascript! Such arrogance! In a way it always feels like Typescript developers are way beyond all those poor suckers still coding in Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and not abandoned in favor of C# or so. I know I can be way more popular preaching Typescript nowadays, it would make me really cool, smart and up to date. Not going for Typescript proves I'm mediocre at best. This is not cynic, this is real when I talk to fellow web developers. I believe static type checking should ideally be done by the IDE, we shouldn't need an entire new language for that with all its shortcomings, issues and whatsoever. And we'll see what's left when the hype is over and the next big thing in the Javascript world comes around. At least heaps of Typescript code bases that need to be rewritten.
- cheerlessbog 8y ago
  > static type checking should ideally be done by the IDE, we shouldn't need an entire new language I am not sure what you are trying to say here. Javascript is barely typed, so presumably you do need a new language to perform type checking. Unless you mean that your IDE should be able to infer types, which is unlikely because typing defines intent, and we've all read plenty of code where we can't figure out what the code author intended.
- smt88 8y ago
  Your comment seems to be a result of ignorance of what TypeScript is and how it works. The main point you're missing is that TypeScript is gradual. It's a superset of JavaScript, meaning that you can use TypeScript when you want it or ignore it when you don't want it. Any valid JavaScript file is also a valid TypeScript file. > Dynamically typed languages are DANGEROUS!!! See above. TypeScript is dynamically typed by default. It just also has a static type checker that you can opt into. A good practice in both JavaScript and TypeScript is to use "const" instead of "var" or "let" anyway. > I believe static type checking should ideally be done by the IDE JavaScript doesn't have enough explicit information for this to be possible. The IDE can do a lot, but it can't do nearly as much if the developer's intentions are implicit. In TypeScript, the developer has the option (again, not the requirement) to make her intentions explicit. > we shouldn't need an entire new language for that with all its shortcomings Again, see above. TypeScript is a superset of JavaScript, not an entirely new language. > At least heaps of Typescript code bases that need to be rewritten. No, they won't. TypeScript compilers will still be available, even if they're not actively developed. They produce JavaScript, so worst-case scenario, you'll just have a JavaScript code base.
FlorianRappl 8y ago
Such a guide can be reduced to: If you only have a single file that has a limited set of responsibilities (e.g., just a small tool) and is not shared / distributed then JS may still be okay, otherwise always go for TypeScript. Honestly, TypeScript never slows me down. The enhanced completion / IDE knowledge, compile-time type checking, and transpilation supporting newer ES features + React is a huge boost.
will_pseudonym 8y ago
FYI, the link to "concrete classes" is incorrectly linking to https://khalilstemmler.com/articles/when-to-use-typescript-guide/wiki/concrete-class/ https://khalilstemmler.com/articles/when-to-use-typescript-g.... I assume the correct link should be pointing to https://khalilstemmler.com/wiki/concrete-class/ https://khalilstemmler.com/wiki/concrete-class/
- stemmlerjs 8y ago
  I appreciate that. Thank you!
namelosw 8y ago
Just use it. I found with auto import and other stuff actually writing TypeScript is almost always faster than JavaScript. The type system is a little bit more advanced than those languages with nominal type systems like Java. Sometimes typing old code is tricky. But the good news is you can escape by using any anytime.
iamtypical 8y ago
My day to day value from typescript is that when you’re on a make things happen team that’s burdened by type pendants or grouchy C#/java/r/whatever “devs” who find themselves career “transitioning” to JavaScript/web-apps throw them typescript as a Turing Tarpit & then everyone shuts up and then makes a thing. Dumb arguments get relegated/channeled into PR/issues on the tsconfig. I say that half in jest but one of the dumbest & most destructive things in software engineering is tribalism or militant belief systems. Having a “neutral” way to deal with them (or something like “data” seeming like it’s neutral) once and for all does wonders for productivity People who don’t like or trust typescript, what’s your good-faith case against it. Personal productivity or ugly/confusing syntax are valid reasons I think
redact207 8y ago
I'm writing a DDD helper library in Typescript (https://www.npmjs.com/package/@node-ts/ddd https://www.npmjs.com/package/@node-ts/ddd), but found it more difficult doing something similar in Javascript. The richness and safety that static typings bring to a project compounds as time goes by. I've also found it easier for new developers to become productive sooner when the language and framework guides them in the direction they want to go. I'm all for anything that supports a positive developer experience, and it's more concise to express my design in terms of static types than it is through mounds of documentation or exploring the code.
lewisl9029 8y ago
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 babel). With babel 7 came @babel/preset-typescript, which I hoped would narrow the gap, but so far it's very clearly a second class citizen in the TypeScript ecosystem, with new features built only with tsc-based pipelines in mind (Project References is the one that stands out because we sorely need it for our monorepo codebase, but can't use because we chose to adopt @babel/preset-typescript), and having personally ran into several issues stemming from what seems to be fundamental incompatibilities between tsc and babel that have no real workarounds (here's one that I can remember off the top of my head: https://github.com/babel/babel/issues/8361 https://github.com/babel/babel/issues/8361). The reason this is so frustrating is TypeScript could have been just a type checker, like Flow. But instead, it had to introduce it's own compilation tooling which is still vastly inferior to babel in terms of overall flexibility and extensibility. All of this seems to be due to what I believe are a few fundamentally poorly thought-out decisions at the beginning of the project to allow TypeScript to specify its own language features that have runtime semantics (things like Enums and class visibility modifiers, neither of which are anywhere close to becoming standardized in JS-proper, by the way, and both of which are completely orthogonal to TypeScript's main responsibility of type checking), and implementing them using a separate build pipeline instead of as extensions to babel & its own type checker. If I were to use a JS type system for a new project today, I'd personally choose Flow over TypeScript in a heartbeat because of this. (this is getting a bit long so will continue in a reply)
- crooked-v 8y ago
  You can do tsc -> esnext syntax -> Babel -> whatever, though it's a pain to set up. I do agree on the extra stuff beyond types (enums, etc) being a mistake that Typescript would be better off deprecating at some point.
- 52-6F-62 8y ago
  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...
TimTheTinker 8y ago
The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful). I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional programming context. — this is one of its best strengths in my opinion, and one reason I now prefer TypeScript over C#.
- mandeepj 8y ago
  > TypeScript over C# TypeScript is a transpiler for JS. C# is a server side language. Can you please clarify how former is the replacement for latter?
  - charrondev 8y ago
    I don’t want to speak for the OP here, but when I refer to Typescript in comparison to other languages I tend to mean Javascript + the type system provided by the Typescript. Typescript is not even necessarily the transpiler nowadays. I use Babel for that and use Typescript exclusively for static type analysis in CI and during development.
  - weyman 8y ago
    They could just be referring to the language itself e.g. syntax and structure, not necessarily its primary use case.
  - dcre 8y ago
    JS is also a server-side language.
  - TimTheTinker 8y ago
    I didn’t mean as a replacement for C# or an alternative for a given project. I meant my personal preference as a developer (I do often get to choose what language to use, if only by where I choose to work or what projects I take on).
  - 8y ago
wesleyfsmith 8y ago
One challenge I have with TS is that when writing interfaces for untyped libs it's easy to make a mistake. I've had issues where VScode was telling me something was the incorrect type because someone else on the team had written an incorrect type in. Instead of debugging it like I would in normal JS I banged my head against the wall because I was convinced that is TypeScript was telling me something was a certain type, it HAD to be true.
ArtDev 8y ago
Seems like you should just learn javascript instead. Though I can see how Typescript might be easier, depending on your background.
Scarbutt 8y ago
This sounded more like an OOP pitch than a TS one.
ravenstine 8y ago
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, and implying that others are foolish for not using it reeks of software snobbery. Whoa, you mean people really still use plain JavaScript, bruh? I mean, don't you need like punchcards for that? That's how grandpas program, bruh. You can't even, like, scale an app without type-checking. An app written without TypeScript is like a house of cards, dude.
- thoughtfunction 8y ago
  It's like making your swords out of bronze when steel is just sitting there.
  - ravenstine 8y ago
    I'm sure there are users of Dart who feel the same way about TypeScript.
- Arbalest 8y ago
  >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. Implying that everyone has exceptional short term memory, and reading old code has virtually no cost.
  - ravenstine 8y ago
    I never said that TypeScript wasn't helpful. The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.
    - 8y ago
ajxs 8y ago
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 issues. Issues like Promise-fatigue, poor ecosystem, terrible native types are still there under the hood. For the extra tax you pay in terms of build pipeline, tooling and dealing with the ecosystem, you may as well upgrade to a language more suitable for this kind of development for little extra cost. I just feel this debate is somewhat of a false dichotomy. People in this thread are debating Typescript vs Javascript as if these are the only two possible options for web development.
- crooked-v 8y ago
  What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?
  - ajxs 8y ago
    My post was directed at back-end development in Typescript/Javascript. My apologies if that wasn't clearer. I don't really have any experience in front-end development in Typescript, so I can't really comment on that. It could be a real improvement there for all I know.
  - fxfan 8y ago
    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
- voidreaper 8y ago
  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?
quickthrower2 8y ago
> I certainly didn't see the benefit... up until I started experiencing some really annoying stuff. Things like builds not failing when they should, buggy code and typos finding their way into production code somehow started to get to me It's hard for me to understand how anyone can't see the benefit of types at compile time. I mean if you write more than 100 LOC you are bound to make a mistake that a typing system would catch and think "I wonder if there is a way the my build process could catch such as silly error". I can only imagine that such programmers are "write only" in that they add lots of features but rarely need to come back and maintain their code. With an ide with autocomplete it may mitigate some mistakes and give a false sense of security about non-static typing.
jaequery 8y ago
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!
kazinator 8y ago
By the way, fun fact: the script utility for recording a TTY session saves a file whose default name is "typescript".
fergie 8y ago
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.
bartimus 8y ago
On the other hand. If your code base has become so big that you need something like TypeScript to make your life bearable, you're probably doing it wrong. Having strongly typed languages has much more to do with those developers who can't live without the autocomplete feature in their IDE. Especially the army of ASP.NET developers who are used to working with Visual Studio. We'll probably be seeing more of those code generator patterns with TypeScript soon. Not saying TypeScript is a bad thing. But strongly typed languages do come with their pitfalls. Massive amounts of code providing a simple CRUD interface. An entire team working on their complex microservice solution which is just wrapping some already existing API. Things that can easily be achieved with a couple of lines of cough PHP cough.
Humphrey 8y ago
Recent Typescript convert here: I find Typescript a GREAT tool for those experimental projects. They are the ones that need constant refactoring as you build, which is where Typescript shines.
h1d 8y ago
People don't seem to point out but you need a decent editor to benefit from using TS. If your editor doesn't support live checking, then it probably feels like boring additional work by going back and forth between code and compilation error logs.

331 points by stemmlerjs 8y ago

I agree with this article. Good stuff. One minor gripe: > if you care about the code, you need to have unit tests for it. That's not really true. You can test at a differently granularity and still have the same confidence in your code. Scores of brittle unit tests crowding your productivity is not what you do to code you care about. I wish people would just stop propagating this detrimental rumor that is backed by zero evidence. I prefer to keep my unit test suite lite and sweet (try to test what is very sensitive at the unit level - easy to miss or algorithmic things) and then try to get the most out of my acceptance test suite. Sorry, but I just worked on too many systems where the unit tests suite breaks no matter what you touch and you spend more time updating the tests than actually getting shit done.

a_wild_dandan 8y ago
"Write tests. Not too many. Mostly integration."
vp8989 8y ago
+1, though this is an unpopular opinion. IMO appreciation for automated test ROI is a great litmus test for a "good programmer".
leeoniya 8y ago
agree. Acceptance Tests hit the sweet spot for me in terms of productivity and quickly catching causes of regressions (coupled with a well-groomed, atomic commit log).
eranation 8y ago
If you write a library, or expose a public interface, I do expect a lot of unit tests. Unit tests can run offline, fast, during build time. I don’t mind integ-unit tests that perhaps simulate a database in memory to avoid mocking the entire storage layer. I rather have tests that are technically integration tests as they include more than, well, a unit, as long as they are idempotent, test mainly one thing, and can run fast and offline. Not sure if there is a term for it but I call these integunit tests... (probably the worst name possible) But unit / unit++ tests are not just for you, they are for me, they give me confidence I can touch your code without inadvertently breaking something critical that you may have missed in your acceptance tests. It gives you peace of mind to be able to refactor. An acceptance test may tell you they something broke, but a good unit test will show you exactly where.
- externalreality 8y ago
  > breaking something critical that you may have missed in your acceptance tests. So you can miss things in your acceptance tests but can't miss them in your unit tests? Why do you feel more confident with unit tests than with acceptance tests? Maybe because unit tests break more often so they are providing you with a false sense of security? Do you know that when a test fails for a reason other than the specified assertion its a called a false negative and the failure is meaningless? Do you know if your tests fail and no functional or non-functional requirements of the program has changed the failure is also meaningless (you are testing implementation)? Ask yourself how often does your group give you time to do these hypothetical large refactoring that give merit to large unit test suites? How many times, even, do you do small refactorings and find all the test have to go away or significantly change anyway because they made some implementation assumption that is no longer true? How many times have you gone into a test suite and have seen that its been patched up so many times that you can swear its testing something but you just don't know what? I know that Uncle Bob tells us about test for refactoring and this and that, but I just don't buy it any more. The emperor is naked god dammit. Uncle Bob and the like are very famous because people swallow their anecdote without due scrutiny.
  - discreteevent 8y ago
    One thing I can't find much evidence of is Uncle Bob's experience in delivering commercial software. I get the feeling he works mainly on toy examples which might explain some of the things he advocates that, like you, don't match my experience at all.
- int_19h 8y ago
  If you write a library or expose a public interface, I expect functional tests that cover that interface. Unit testing would require going below that level, and test implementation details - which is exactly why those tests tend to be so brittle, and the overhead of maintaining them is so high.
Spartan-S63 8y ago
Biggest benefit of having a compiler in your toolchain is that it often serves as the majority of your integration testing layer. That said, you should proliferate unit tests for algorithmic logic. That can be a small subset of your code, but a large part of your domain (depending on richness). Integration testing can be written manually, or you can pick a compiled language that does a lot of the lifting by type checking and producing the binary. Acceptance tests guide the overall happy path and can protect against weird regressions.
ufmace 8y ago
I agree. I think it's important that your test suite gives you something useful with every test, instead of writing a bunch of pointless extra tests just to get to 100% coverage because you read somewhere that that's good. I feel like I ought to write more on this one of these days, but I have a few testing pet peeves, as far as tests you shouldn't write. Don't write tests that are a copy-paste of the code you're testing. Don't write tests to validate things that should be proven by your type system and lack of compile/parse errors. Beware of tests so tied to implementation details that they make your code harder to refactor. Don't write tests for things talking to external services - the only real test is that it correctly handles the actual service responses.
- ChristianGeek 8y ago
  Tests should be testing behavior, not implementation (this was the original intent of unit testing but it got sidetracked over time).
stemmlerjs 8y ago
Thanks for reading the article. Perhaps I should have been more specific about what needs testing. In The Clean Coder by Uncle Bob, he says that your unit tests should approach the asymptote of 100% test coverage. Here's where I agree with his statement: On the backend, I agree that all of the domain-layer code should be tested. This is a hard requirement for me. It's also code that has 0 dependencies so it should be easy to test. TDD pairs really nicely with DDD. Unit tests give you the needed confidence in order to do refactoring. You can't refactor code without tests. If you do, there's a risk involved. Therefore, in order to safely improve the design of existing code, it needs to have tests. This "detrimental rumor backed by zero evidence" is one of the fundamental takeaways from Martin Fowler's book on "Refactoring" in addition to Uncle Bob's chapter in The Clean Coder on Unit Testing. Here's where I disagree with his statement on 100% test coverage. I used to spend a lot of time writing brittle tests by testing front-end UI code. I used tools like Selenium and Cypress. Because the front-end is the most susceptible part of a system to change, I found myself spending an equivalent amount of time maintaining these tests in addition to adding new code. This is a hard place to find a balance. In Angular, I merely ensure that I write tests for services. In React, I spend a lot less time writing Enzyme tests on rendering and a lot more time testing the redux operators. Uncle Bob clears this up in his book by saying USUALLY, it's not necessary to write UI tests. I'd say by UI tests, he means "rendering tests". His solution is to ensure that you have a way to run acceptance tests that work through the API, as it should be a lot less susceptible to constant regressions. This way, you're essentially testing the features that the API is executing. If you're using DTOs, the inputs and outputs of your system should remain relatively the same anyways, and you should spend less time changing old tests, and more time adding new ones.
- externalreality 8y ago
  > You can't refactor code without tests See this is where the conversation goes south. You will use the phrase "unit tests" when it suits you, and then, like a magician using indirection, generalize to the word "tests" when it suits you. Why are you listening to Uncle Bob so much? I mean you can do as you like. However, the strong "Uncle Bob" style assertions should probably be left out of most articles in favor of a more humble "this is what worked for me/us" approach. Universal rules for any discipline are very hard to come by. Sharing what worked for you on your projects is great but it becomes somewhat obnoxious when you try to generalize it to universal rules that works in all environments for everyone. Also, I think that large unit test suites, where most of the tests are redundant, come about in competitive environments where if you try to make a commit without a test some other competitive coder will try to use it as a "I know better" stepping stone and call you out on the change - "Where is the test". After 3 years of this behavior what do you think your going to have. A nice clean suite of tests or a monstrous big ball of stubs, mocks, faked, copy pasta that resulted from defensive social coding. Honestly, write a light suite of tests that get to the point, and keep your ability to code swiftly and make changes quickly. As the code matures you'll find the trouble spots and focus testing on those areas. Don't blindly follow methodologies that are going to have you writing large test suite for version pre-alpha 0.0, and now your updating a large test suite for every micro-change just to make it to beta 1. Here is an old article by DHH where he rails against unit testing dogma. Ironically it was ideas from the Ruby community that formed a lot of the basis of the mad dog McCarthyan style unit test dogma. https://dhh.dk/2014/tdd-is-dead-long-live-testing.html https://dhh.dk/2014/tdd-is-dead-long-live-testing.html

chmln 8y ago

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

revskill 8y ago
This. I always focus more on the "foundation" part, in this case, it's common React Hooks and its API for the components to use. The good part is, if some hooks are wrong, we can just write new one and replace old ones within old components without the need of taking care of the old wrong Hooks.
- chrisweekly 8y ago
  Aren't Hooks too new for you to make claims about what you "always" do with them?
  - revskill 8y ago
    Before, it was HOC and RenderProps. This is just an example with Hooks, it's mostly how i approach the problem though.
    - chrisweekly 8y ago
      Right on, makes sense.
a_wild_dandan 8y ago
I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!" This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've never regretted that decision in the end. If people here want to use a 5 gallon bucket on an initial 5 gallon job, go for it. Best of luck to you. I'll be over here starting with a 10 gallon bucket and not sweating when the customer needs to add another gallon...

fxfan 8y ago

4 of the most popular language creators here https://www.youtube.com/watch?v=csL8DLXGNlU https://www.youtube.com/watch?v=csL8DLXGNlU agree that type systems are useful. I would suggest definitely not using Vanilla JS. There are excellent type systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with their pros and cons (I don't know what cons BuckleScript has though, maybe relatively smaller lib-ecosystem)

melling 8y ago
There are lots of alternatives to vanilla JavaScript. Why stop at types and encapsulation? http://bikeshed.fm/192 http://bikeshed.fm/192
tyingq 8y ago
Larry Wall is endorsing strong types? I'll have to watch that now. I guess you can use Perl 6 in a way that approximates it, but it's very optional.
- Shoop 8y ago
  Does anyone have a timestamp for Larry Wall talking about types?
- mst 8y ago
  I believe the idea is 'gradual typing', where you add types as you firm up an interface. Lots of the perl6 code I've seen types most stuff at least at interface boundaries.
Hermitian909 8y ago
I use bucklescript/reasonML extensively. The biggest con is definitely the smaller lib-ecosystem, creating bindings for functions is generally relatively painless but if you're using javascript libraries with large API surfaces that will be a large time sink. Otherwise it's been a joy to use.
Illniyar 8y ago
Not that I don't agree with their opinion, but being a language creator mostly like greatly biases you towards over estimating the usefulness of certain features. As such I wouldn't hold language creator's opinions on the value of certain language features over say the opinions of CTOs or VP engineering of large companies, especially as it relates to productivity, maintenance and onboarding.

parhamn 8y ago

Why does everyone treat TypeScript like a full language? Besides some features like generics 98% of it is just javascript with type annotations (sorta similar, including in syntax, to py3 with annotations). And in that view its probably foolish not to use it as the cost of these annotations is so low relative to the refactoring/safety/easy-of-use/code-completion/etc it offers. These type annotations are so easy to add! I can't even imagine writing JS without these annotations esp given all the odd behaviors of the language.

a_wild_dandan 8y ago
TypeScript is such an unbelievably powerful add-on that I simply refuse to use vanillaJS unless absolutely necessary. It eliminates entire classes of bugs, encourages me to write better code by thinking in JS about contracts (interfaces), and vastly improves my productivity with the aforementioned annotations. ("What was the signature for method X of class Y in library Z? Ah, that's it. Thanks, TS/VSCode!")
bengotow 8y ago
I know... when to use typescript = all the time? It's not a huge shift.

vore 8y ago

Regarding TypeScript, the benefit of catching way more errors at compile time greatly outweighs the amount of extra work for adding types. If you're starting a new JavaScript project, you should definitely think long and hard if you pledge not to use TypeScript.

a_wild_dandan 8y ago
And the best part is that TypeScript is just a superset of JS. If you're new to TS, you can use it like you've been using JS. Just by giving your variables the `any` type, or disabling null checking, and so on, you can write JS like you always have. No pressure. And, eventually, you'll be lulled into properly typing your variables, because damn it those type annotations are super handy! Oh, and you start defining your own interfaces because it makes your code more readable and easier to reason about. Oh, and...etc etc etc. If you start by gradually adopting the extra features that TS provides, you'll never want to go back.
tills13 8y ago
> greatly outweighs the amount of extra work for adding types this is such a bad excuse, imo - the "work" required to get your wheels off the ground in a JS -> TS transition is literally just changing the filename. 99% of syntax / TS errors that present themselves after that change are bugs that your code already had.

leeoniya 8y ago

i recently learned you can actually have typescript annotations without [imo] polluting the syntax or requiring the TS compiler: http://seg.phault.net/blog/2017/10/typescript-without-transpiling/ http://seg.phault.net/blog/2017/10/typescript-without-transp... does anyone know if there are limitations to this style?

netghost 8y ago
I suspect you can't do some of the fancier type contortions. For the simple case, I think it works just fine.
orta 8y ago
No limitations (only that it's a bit more verbose than just TS), this is canonical supported by the TypeScript powered tooling which VS Code provides by default on an JS project. https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
breck 8y ago
Cool, thanks. I generally love TS, but I have one project which I converted to TypeScript, and then reverted back to ES7, because the project is quite complex and the overhead of TS was not worth it. I wonder if by using this Jsdoc/ts strategy in critical sections I can get 80% of the benefit.
- monkpit 8y ago
  > the overhead of TS Do you have any concrete examples? I would argue that a complex project that is already in TS benefits more from remaining in TS, so I’m curious what your reasoning was.
  - breck 8y ago
    1) Import/export syntax hell. This project is 148 Javascript files, 12k LOC. Everything runs in both Node and Browser environments. Without TypeScript I just use CommonJS syntax and rewrite the scripts on the fly via a server-side pass through for a browser environment. But because of the module hell (import/export/script modules/relative vs absolute paths/defaults) I couldn't find a good formula for write once, run everywhere for this large project. I needed to be outputting 2 different builds to 2 different places which led to all kinds of path problems. This is very much unique to this project though, which has unique runtime require requirements. 2) Compile time overhead when iterating. For many visual development tasks it just takes too long to change something, compile and see results in the browser. Without TS it's 0 latency. With TS it was a few seconds. Without TS I could make 10 changes with 2 seconds latency, and perhaps I make 1 type mistake costing me 20 seconds of debug time, for a total of 40 seconds. With TS I make 10 changes with 5 seconds latency and zero mistakes but now total overhead if 50 seconds. I want to be able to get the documentation and static type checking benefits without giving up that instant feedback.

humbleMouse 8y ago

Typescript is wonderful, especially as someone used to writing a lot of java/groovy. Typescript is like pouring cement around your javascript house of cards. It makes writing front end code painless and predictable. It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff.

eitland 8y ago
> It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff. ... and in the free Visual Studio Code, also crossplatform like IntelliJ. (Nothing against IntelliJ, JetBrains is a cool company with amazing products IMO, I just prefer VSCode myself.)
- h1d 8y ago
  I think VS Code is almost like a little brother of IntelliJ now but better at a few places. (Especially rendering.)
widerporst 8y ago
>It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff. Yes, this makes writing Typescript actually faster for me than vanilla JS. The code completion in IntelliJ is really amazing.
- h1d 8y ago
  I wonder what people are using to write code with for those that complain vanilla JS works fine. Vanilla vim?

devit 8y ago

Always, unless it's a very short script that uses packages that have no type definitions.

SonicSoul 8y ago
the issue I run into (and maybe there is a quick solution) but when I work on a TS React project and want to add a library that does not have Typings definitions, i get in a world of hurt. trying to quickly add my own typings or fix TS errors w/out disabling major compiler functions.. usually spend an hour or two and give up on the library.. is there a good way to deal with this scenario?
- pault 8y ago
  That is a pain point, but I think of it as spending a few hours to save a few weeks down the road.

rasikjain 8y ago

Coming from C# background, Using Typescript for front-end programming was a breeze for me. This helped me in picking up newer frameworks and saved countless hours during debugging and build time errors. I liked strict validation of props using interfaces while working with restful APIs.

_bxg1 8y ago

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.

mixmastamyk 8y ago
> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.
- echelon 8y ago
  You'll find that the more you work with types, the less this becomes an issue. You begin to think in types as a first class construct. Types don't slow me down, and I can't imagine working without them.
  - mixmastamyk 8y ago
    You also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.
    - Normal_gaussian 8y ago
      Also working in both I don't have this issue. I generally find types make refactors faster - I have less bugs from the refactor.
      - mixmastamyk 8y ago
        A mature refactor yes, a change in design often not.
  - lopatin 8y ago
    > types as a first class construct A wild Idris programmer appears

fourseventy 8y ago

Isn't anyone worried that TypeScript will go the way of CoffeeScript?

Jare 8y ago
No, it has a great team and the powerful Microsoft behind it, and MS is dogfooding it enough to make me feel they are not going to pull the plug.
oaiey 8y ago
I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.
- dmit 8y ago
  To be fair to CoffeeScript, it introduced and popularized features that eventually made it to the EcmaScript standard. You could make a case for it being the kick that started the wave of improvements to JS that we've seen in the past decade. As for GP's post, I can only hope that Typescript leaves a similar legacy, even if the language itself ceases to exist.
  - danso 8y ago
    That kind of historical retrospective is an article I would definitely read. As much as Coffeescript seems like a dying language when compared to where JS is today, its appeal was very strong for it to have become a default include in Rails 3.1, and to have been the primary choice for teams like Dropbox and Github [0]. 0: https://en.wikipedia.org/wiki/CoffeeScript#Adoption https://en.wikipedia.org/wiki/CoffeeScript#Adoption
    - Jare 8y ago
      Its syntax and design was very appealing to Ruby developers. I was more surprised when Fog Creek chose it for Trello in '12, but yeah back then the raw Javascript experience was fairly poor, and Typescript would still take a couple of years to be ready for production.

z3t4 8y ago

The link to domain driven development wasn't useful. The post should explain more about that and SOLID.

giantsloth 8y ago

Having been reading hacker news since 2009, I’m really tired of these unevidenced clickbait listicles on some persons anecdote. There is no evidence presidented whatsoever in this article. It also seems that this person hasn’t worked with a numbered and diverse enough set of clients to even warrant listening to him as a practioner. He’s peddling tired DDD tropes amongst a spattering of meandering well worn blog posty unsciencey ideas he’s read throughout the years.

giancarlostoro 8y ago

> For example, it's almost always expected that your app is going to still work offline in some capacity; and when users ARE online, it's also usually expected that they're going to get real-time notifications without having to refresh the page. I never expect something to work while I'm offline, or do they mean the cached contents like a page would work if it were just cached HTML and CSS? As for real-time notifications, I don't know anybody who uses those, the other day someone was telling me how pissed off they were that they always get them from some news site, and they didn't mean to enable them, now they can't find where to turn them off!

a-saleh 8y ago

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?

maaaats 8y ago
What I mainly liked about TS is that it's basically plain js with some typeinfo sprinkled on top. So no barrier of entry for existing js developers. Now I work on a project with Elm for the frontend. It's not as easy to just jump into, so wouldn't use it for a project where lots of developers sometimes have to make additions. But once up to speed, Elm is great.
hahamrfunnyguy 8y ago
I know a lot of languages already, so unless there is a significant advantage to using a given language I'd probably pick one of the many I know already. Typescript has significant advantages over vanilla JS, so that's why I use it. If those other options offered a significant improvement over Typescript AND said features were something I needed, I wouldn't hesitate to use it. For now, getting better at the languages I already know seems like a better use of time.
virtualwhys 8y ago
> 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.

ChristianGeek 8y ago

Your DDD link is dead (so technically it’s a DDDD link :)

stemmlerjs 8y ago
Haha. Yeah, that's the next article for me to write. I just started this blog recently. My approach has been to track which dead links have been clicked the most and then write about that topic next. DDD is far in the lead. Expect it soon. Thanks for reading!

overgard 8y ago

Honestly, the only downside to me of typescript is occasional grief from @type libraries or some build complications when you're first getting setup. But having working code completion and non-surprising return values/argument parameters is so much worth the initial minor pain points.

burtonator2011 8y ago
The other issue is dealing with module compilation... this part still always screws me over. Once it's up and running TS is freaking amazing

flabbergast 8y ago

> it's actually dangerous for your project to NOT be written using TypeScript today. Wow! Bye bye Javascript! Such arrogance! In a way it always feels like Typescript developers are way beyond all those poor suckers still coding in Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and not abandoned in favor of C# or so. I know I can be way more popular preaching Typescript nowadays, it would make me really cool, smart and up to date. Not going for Typescript proves I'm mediocre at best. This is not cynic, this is real when I talk to fellow web developers. I believe static type checking should ideally be done by the IDE, we shouldn't need an entire new language for that with all its shortcomings, issues and whatsoever. And we'll see what's left when the hype is over and the next big thing in the Javascript world comes around. At least heaps of Typescript code bases that need to be rewritten.

cheerlessbog 8y ago
> static type checking should ideally be done by the IDE, we shouldn't need an entire new language I am not sure what you are trying to say here. Javascript is barely typed, so presumably you do need a new language to perform type checking. Unless you mean that your IDE should be able to infer types, which is unlikely because typing defines intent, and we've all read plenty of code where we can't figure out what the code author intended.
smt88 8y ago
Your comment seems to be a result of ignorance of what TypeScript is and how it works. The main point you're missing is that TypeScript is gradual. It's a superset of JavaScript, meaning that you can use TypeScript when you want it or ignore it when you don't want it. Any valid JavaScript file is also a valid TypeScript file. > Dynamically typed languages are DANGEROUS!!! See above. TypeScript is dynamically typed by default. It just also has a static type checker that you can opt into. A good practice in both JavaScript and TypeScript is to use "const" instead of "var" or "let" anyway. > I believe static type checking should ideally be done by the IDE JavaScript doesn't have enough explicit information for this to be possible. The IDE can do a lot, but it can't do nearly as much if the developer's intentions are implicit. In TypeScript, the developer has the option (again, not the requirement) to make her intentions explicit. > we shouldn't need an entire new language for that with all its shortcomings Again, see above. TypeScript is a superset of JavaScript, not an entirely new language. > At least heaps of Typescript code bases that need to be rewritten. No, they won't. TypeScript compilers will still be available, even if they're not actively developed. They produce JavaScript, so worst-case scenario, you'll just have a JavaScript code base.

FlorianRappl 8y ago

Such a guide can be reduced to: If you only have a single file that has a limited set of responsibilities (e.g., just a small tool) and is not shared / distributed then JS may still be okay, otherwise always go for TypeScript. Honestly, TypeScript never slows me down. The enhanced completion / IDE knowledge, compile-time type checking, and transpilation supporting newer ES features + React is a huge boost.

will_pseudonym 8y ago

FYI, the link to "concrete classes" is incorrectly linking to https://khalilstemmler.com/articles/when-to-use-typescript-guide/wiki/concrete-class/ https://khalilstemmler.com/articles/when-to-use-typescript-g.... I assume the correct link should be pointing to https://khalilstemmler.com/wiki/concrete-class/ https://khalilstemmler.com/wiki/concrete-class/

stemmlerjs 8y ago
I appreciate that. Thank you!

namelosw 8y ago

Just use it. I found with auto import and other stuff actually writing TypeScript is almost always faster than JavaScript. The type system is a little bit more advanced than those languages with nominal type systems like Java. Sometimes typing old code is tricky. But the good news is you can escape by using any anytime.

iamtypical 8y ago

My day to day value from typescript is that when you’re on a make things happen team that’s burdened by type pendants or grouchy C#/java/r/whatever “devs” who find themselves career “transitioning” to JavaScript/web-apps throw them typescript as a Turing Tarpit & then everyone shuts up and then makes a thing. Dumb arguments get relegated/channeled into PR/issues on the tsconfig. I say that half in jest but one of the dumbest & most destructive things in software engineering is tribalism or militant belief systems. Having a “neutral” way to deal with them (or something like “data” seeming like it’s neutral) once and for all does wonders for productivity People who don’t like or trust typescript, what’s your good-faith case against it. Personal productivity or ugly/confusing syntax are valid reasons I think

redact207 8y ago

I'm writing a DDD helper library in Typescript (https://www.npmjs.com/package/@node-ts/ddd https://www.npmjs.com/package/@node-ts/ddd), but found it more difficult doing something similar in Javascript. The richness and safety that static typings bring to a project compounds as time goes by. I've also found it easier for new developers to become productive sooner when the language and framework guides them in the direction they want to go. I'm all for anything that supports a positive developer experience, and it's more concise to express my design in terms of static types than it is through mounds of documentation or exploring the code.

lewisl9029 8y ago

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 babel). With babel 7 came @babel/preset-typescript, which I hoped would narrow the gap, but so far it's very clearly a second class citizen in the TypeScript ecosystem, with new features built only with tsc-based pipelines in mind (Project References is the one that stands out because we sorely need it for our monorepo codebase, but can't use because we chose to adopt @babel/preset-typescript), and having personally ran into several issues stemming from what seems to be fundamental incompatibilities between tsc and babel that have no real workarounds (here's one that I can remember off the top of my head: https://github.com/babel/babel/issues/8361 https://github.com/babel/babel/issues/8361). The reason this is so frustrating is TypeScript could have been just a type checker, like Flow. But instead, it had to introduce it's own compilation tooling which is still vastly inferior to babel in terms of overall flexibility and extensibility. All of this seems to be due to what I believe are a few fundamentally poorly thought-out decisions at the beginning of the project to allow TypeScript to specify its own language features that have runtime semantics (things like Enums and class visibility modifiers, neither of which are anywhere close to becoming standardized in JS-proper, by the way, and both of which are completely orthogonal to TypeScript's main responsibility of type checking), and implementing them using a separate build pipeline instead of as extensions to babel & its own type checker. If I were to use a JS type system for a new project today, I'd personally choose Flow over TypeScript in a heartbeat because of this. (this is getting a bit long so will continue in a reply)

crooked-v 8y ago
You can do tsc -> esnext syntax -> Babel -> whatever, though it's a pain to set up. I do agree on the extra stuff beyond types (enums, etc) being a mistake that Typescript would be better off deprecating at some point.
52-6F-62 8y ago
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...

TimTheTinker 8y ago

The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful). I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional programming context. — this is one of its best strengths in my opinion, and one reason I now prefer TypeScript over C#.

mandeepj 8y ago
> TypeScript over C# TypeScript is a transpiler for JS. C# is a server side language. Can you please clarify how former is the replacement for latter?
- charrondev 8y ago
  I don’t want to speak for the OP here, but when I refer to Typescript in comparison to other languages I tend to mean Javascript + the type system provided by the Typescript. Typescript is not even necessarily the transpiler nowadays. I use Babel for that and use Typescript exclusively for static type analysis in CI and during development.
- weyman 8y ago
  They could just be referring to the language itself e.g. syntax and structure, not necessarily its primary use case.
- dcre 8y ago
  JS is also a server-side language.
- TimTheTinker 8y ago
  I didn’t mean as a replacement for C# or an alternative for a given project. I meant my personal preference as a developer (I do often get to choose what language to use, if only by where I choose to work or what projects I take on).
- 8y ago

wesleyfsmith 8y ago

One challenge I have with TS is that when writing interfaces for untyped libs it's easy to make a mistake. I've had issues where VScode was telling me something was the incorrect type because someone else on the team had written an incorrect type in. Instead of debugging it like I would in normal JS I banged my head against the wall because I was convinced that is TypeScript was telling me something was a certain type, it HAD to be true.

ArtDev 8y ago

Seems like you should just learn javascript instead. Though I can see how Typescript might be easier, depending on your background.

Scarbutt 8y ago

This sounded more like an OOP pitch than a TS one.

ravenstine 8y ago

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, and implying that others are foolish for not using it reeks of software snobbery. Whoa, you mean people really still use plain JavaScript, bruh? I mean, don't you need like punchcards for that? That's how grandpas program, bruh. You can't even, like, scale an app without type-checking. An app written without TypeScript is like a house of cards, dude.

thoughtfunction 8y ago
It's like making your swords out of bronze when steel is just sitting there.
- ravenstine 8y ago
  I'm sure there are users of Dart who feel the same way about TypeScript.
Arbalest 8y ago
>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. Implying that everyone has exceptional short term memory, and reading old code has virtually no cost.
- ravenstine 8y ago
  I never said that TypeScript wasn't helpful. The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.
  - 8y ago

ajxs 8y ago

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 issues. Issues like Promise-fatigue, poor ecosystem, terrible native types are still there under the hood. For the extra tax you pay in terms of build pipeline, tooling and dealing with the ecosystem, you may as well upgrade to a language more suitable for this kind of development for little extra cost. I just feel this debate is somewhat of a false dichotomy. People in this thread are debating Typescript vs Javascript as if these are the only two possible options for web development.

crooked-v 8y ago
What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?
- ajxs 8y ago
  My post was directed at back-end development in Typescript/Javascript. My apologies if that wasn't clearer. I don't really have any experience in front-end development in Typescript, so I can't really comment on that. It could be a real improvement there for all I know.
- fxfan 8y ago
  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
voidreaper 8y ago
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?

quickthrower2 8y ago

> I certainly didn't see the benefit... up until I started experiencing some really annoying stuff. Things like builds not failing when they should, buggy code and typos finding their way into production code somehow started to get to me It's hard for me to understand how anyone can't see the benefit of types at compile time. I mean if you write more than 100 LOC you are bound to make a mistake that a typing system would catch and think "I wonder if there is a way the my build process could catch such as silly error". I can only imagine that such programmers are "write only" in that they add lots of features but rarely need to come back and maintain their code. With an ide with autocomplete it may mitigate some mistakes and give a false sense of security about non-static typing.

jaequery 8y ago

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!

kazinator 8y ago

By the way, fun fact: the script utility for recording a TTY session saves a file whose default name is "typescript".

fergie 8y ago

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.

bartimus 8y ago

On the other hand. If your code base has become so big that you need something like TypeScript to make your life bearable, you're probably doing it wrong. Having strongly typed languages has much more to do with those developers who can't live without the autocomplete feature in their IDE. Especially the army of ASP.NET developers who are used to working with Visual Studio. We'll probably be seeing more of those code generator patterns with TypeScript soon. Not saying TypeScript is a bad thing. But strongly typed languages do come with their pitfalls. Massive amounts of code providing a simple CRUD interface. An entire team working on their complex microservice solution which is just wrapping some already existing API. Things that can easily be achieved with a couple of lines of cough PHP cough.

Humphrey 8y ago

Recent Typescript convert here: I find Typescript a GREAT tool for those experimental projects. They are the ones that need constant refactoring as you build, which is where Typescript shines.

h1d 8y ago

People don't seem to point out but you need a decent editor to benefit from using TS. If your editor doesn't support live checking, then it probably feels like boring additional work by going back and forth between code and compilation error logs.