Glimmer.js: What’s the Deal with TypeScript?

What sold me on TypeScript was that it didn&#x27;t just add features, it actively solved a problem I&#x27;d been experiencing.<p>Once a JavaScript project scales beyond what can fit in your head, JS&#x27;s initial productivity boost crumbles because you have to constantly double back and make sure your methods&#x2F;constructors&#x2F;etc. are correctly used, which properties are optional, etc... A lot of the debugging happens in runtime and god help you if you try to make a breaking change to one of the major classes&#x2F;apis in your project.<p>It&#x27;s not unbearable, but the main reason for using JS is because of the productivity it allows.<p>With TS for the cost of taking the time to explicitly define your data you get a C#&#x2F;Java level of debugging that has clear productivity gains and shifts your debugging from the browser&#x2F;console to the IDE.<p>And when something doesn&#x27;t fit the TS model you can just exclude it or only type the wrappers that integrate with the rest of your project.<p>That and async&#x2F;await is a godsend over promises.

There&#x27;s two things that really stand out for me on TypeScript. There are other positive attributes, but these are the two things I liked.<p>The first is that it made some specific workflows a <i>lot</i> easier. In particular, I&#x27;m working on some pre-alpha libraries where there&#x27;s movement on how the API interface is defined. TypeScript made that transition a lot easier. Yes, my testing would have eventually caught all the method arity mismatches, but TypeScript made this happen about an order of magnitude faster.<p>The second is how unobtrusive the types actually are. I did a fair bit of J2EE programming in the 00s, and types and interfaces can be really annoying. With typescript, interfaces are assertions about the shape of an object, rather than things themselves. That means, if you defined an interface as HasFirstName: { firstName: string } and function greet(person: HasFirstName), you don&#x27;t actually have to put HasFirstName everywhere in the code that uses that function. You&#x27;re not required to set up inheritance or anything. You just have to make sure that all arguments to greet have a firstName property. That&#x27;s it. So I can say: const dude = { firstName: &#x27;the&#x27; }; greet(dude) just fine. But if I try to greet(potato), it&#x27;ll error.<p>Lexical typing this way gives you a lot of power while still staying out of your way in a language like javascript where it&#x27;s super common to create consts as bags of properties without worrying about what particular interface they&#x27;re instantiating. I really like that, as it is precisely the overbearing types of Java that annoy me.

I&#x27;ve done a few typescript projects. Some migrating an existing codebase, some starting from scratch. Every time it has been a nice experience, and with every release it gets nicer. Two of the projects had very complex requirements, and typescript was instrumental in being able to refactor them with confidence.<p>I think the upsides are quite well known by now. Honesty requires me to admit that I did run into some downsides:<p>- Initially it was difficult to understand the exact mechanics of how typescript ... types. Definition files seemed like a bit of a black art, and how to annotate existing code so that it had the proper type wasn&#x27;t always obvious, especially when you run into libraries with incomplete or wrong type definitions and when you want to do tricky stuff like creating typed mocks in unit tests. The typescript documentation is very good and I haven&#x27;t needed much beyond it, but some extra real-world type definition chapters would help.<p>- Setting up a complete dev toolchain is challenging. I wanted everything: source maps, in-IDE debugging with breakpoints, in-IDE unit tests with code coverage, tslint, gradual introduction into an existing codebase, and robust integration into the build of the rest of the app (which in my case meant SBT integration). I still don&#x27;t have code coverage in my in-IDE unit tests. The way I see it though, if your javascript has any build step at all you already have this pain, so this isn&#x27;t so much a problem with typescript as a problem with javascript build pipelines in general.<p>- Convincing other developers typescript has value and isn&#x27;t javascript&#x27;s weird ugly nephew is an uphill struggle. Once you do a typescript project you end up understanding the value, even if you might not find it valuable for yourself personally, so it&#x27;s only a matter of convincing developers to give it a go. However, getting to that point is a bit of a chicken and egg problem.

Anyone got a link on how to transition existing large webpack&#x2F;React&#x2F;babel project to using Typescript? Googling I only found <a href="https:&#x2F;&#x2F;medium.com&#x2F;@clayallsopp&#x2F;incrementally-migrating-javascript-to-typescript-565020e49c88" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@clayallsopp&#x2F;incrementally-migrating-java...</a> but it doesn’t use ts-loader and doesn’t go into details on how to use typings. I tried following ts-loader docs, but things broke at `import flatten from &#x27;lodash&#x2F;flatten&#x27;` and adding typings for `lodash ` didn’t help. Would be interesting what strategies people use to get it working in existing project.

I have a project that uses Flow. I&#x27;ve had no complaints with it so far, but I&#x27;ve been craving the IDE support of TypeScript. What&#x27;s the difference between the type system of TypeScript and Flow? Would it be worthwhile to switch?<p>Part of me wants to wait out the Flow team come up with better IntelliSense support. The `flow ide` command in the release 0.42 is a big step in the right direction. But it seems like TypeScript already has this, and if the delta between the two type systems is small, I might just go ahead and switch.

I haven&#x27;t used TypeScript extensively, but I feel that there should be more of a push (maybe there is, please correct me if I&#x27;m wrong) to introduce whatever functionality people deem worthy that exists in TypeScript and introduce it to JavaScript.<p>You can already see the conflict happening as some people prefer Flow and others TypeScript. Perhaps later Google will throw their hat into the ring and introduce GScript. Then, you have three different languages that introduce similar functionality, that all transpile into JavaScript.<p>Sound familiar?

TypeScript is amazing, enough said. If you&#x27;re building any application with any amount of code that has to be worked on by anyone other than yourself, you want to use TypeScript (I&#x27;d argue even for yourself, use it, it&#x27;ll catch enough errors to pay for itself in spades). Coupled with editors like Visual Studio Code which are cross-plat and have first-class tooling for TS&#x2F;JS, it just makes you objectively more productive both as a consumer and writer of Javascript. Even the most die-hard pessimists I&#x27;ve met love TypeScript once they try it.

Ok, when Glimmer&#x27;s motivation was only typechecking, why not just fb flow then?

Am I the only one who thinks typed Javascript, wether it&#x27;s TypeScript or Flow, is a really flakey experience?<p>I really enjoy Swift, so I&#x27;m not put off by types. But I find the experience of working in a real typed language to be very different to working with Flow or Typescript, where the types are for pretend, and type definitions are wrong often enough to be a real pain. And I found my self evaluating npm packages based on their type definitions, and not their suitability for the task, which seems bonkers to me.<p>Also, I don&#x27;t ever recall staying late to track down a bug that types would have fixed. But I&#x27;ve wasted many an hour tracking down bugs caused by mutations, and the state of Immutability and Typed Javascript is pretty grim as far as I can tell, unless I&#x27;m missing something.

Is there a way for typescript to be used as PropTypes in React?

Does anyone know when Ember will use TypeScript?

&gt;At the end of the day, though, JavaScript is the language of the web.<p>And when webassembly arrives that will be over, and Typescript will be deprecated. I can&#x27;t wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly. Then we can finally stop trying to fix Javascript&#x27;s flaws with new language features.

Well, if we already transpile ES7 to JS then why not tanspile TypeScript instead because of all the added benefits?

TypeScript provides the same value as intellisense.<p>E: i didnt mean this as a criticism

What turns me off immediately about TypeScript (and examples in the article show it) is the use of the class construct. If I could see some examples of teams writing TypeScript without falling into the use of classes I would feel a lot better about it. I am in full agreement with Douglas Crockford and others that adding pseudo-classes to JS was a big mistake.