5 ms·

I would be interested to hear other folks experience with TypeScript. We have move virtually all of the project I work on over to TypeScript but I am not seeing

• timdumol 11y ago
  Moving to TypeScript definitely helped us. The move itself revealed a couple undefined variable errors, and static typing has saved us a lot of pain. It was also extremely useful for when we decided to remove a few libraries; the static typing gave us confidence that we didn't miss a few usages.
  • nkassis 11y ago
    My experience as well. The benefits I've seen have been easier refactoring, code completion and I find it faster to implement things with typescript highlighting issues in my editor so that I can correct them before seeing if it runs in a browser.
  • dham 11y ago
    You can catch undefined variables with something like eslint or jshint.
• hockeybias 11y ago
  I have only been working with it for a few months, but I come from a .NET background and LOVE using TypeScript relative to JavaScript.
• joseraul 11y ago
  The ability to rename a function or class attribute, accross modules, has been a great help maintaining programs larger than a few thousands lines.
• softawre 11y ago
  We love TS here, and share the same experiences about finding bugs just in the conversion phase. What I think is the best part though, and it helps when bringing new people in, is the crazy-good intellisense you can get in Javascript now. Basically it makes averages developers much better, and skilled developers a bit better. Master level folks may just find some boilerplate generated code annoying, but for my definition of "Master" there aren't many of them around anyway (at least not where I work).
  • bkjelden 11y ago
    x2 on the intellisense. When I moved my team's JS code to typescript, I found myself way way faster with the improved intellisense. I wrote most of the code originally and understood it well, but even for an experienced developer, solid intellisense saves you from having to look up so many things.
• Eridrus 11y ago
  No good metrics on my end, but anecdotally, the compiler regularly catches bugs that I would have had to find via testing. So, depending on how you track bugs, these types of things might have never made it to your bug tracker, just manifested as dev time. Not that I don't have bugs, it's just catching some. Is it worth having a compile step? Not clear. In my mind though, the main benefit is types as documentation, both for devs & tool support. Via DefinitelyTyped it makes integrating new libraries simpler. It has made refactoring much more straight forward. I started a side project on the weekend where I wanted a chrome extension, and I made that a typescript and have absolutely no regrets. I've been doing lots of regular refactoring, and while the codebase is miniscule, it's a lot more mechanical to make changes (change the type, look for red squigglies) than really needing to think about where the changes are. But I feel like our code is very much much more navigable than just straight JS. Being able to know the type of a thing and just jump to its definition makes it that much easier to read. I might have been scarred by my previous experiences trying to read large dynamically typed projects, but you can't just jump into most files and be able to figure out what is going on (particularly with classes). We only have one typescript codebase, which we moved to from coffeescript, and that was a huge win, partly because of coffeescript, but also because the coffeescript codebase was a disaster and needed some rework. When I originally ported it, it was about 4k LoC in a single file, and now it is 11k across 93 files. My team wasn't entirely thrilled with typescript to start, but some of the features in 1.4 (union types, typedefs) made people happier. We have some very different coding styles, from my end where I want to type everything, to the any-soup we get in some parts. So, I can't call it an unmitigated success, some of what the codebase needed was just some general structure, but 11k isn't exactly a huge project either, and it's structure is really not very complicated (most of it is completely independent modules). So, after all that rambling, things I like: - code navigability (particularly because anything you do a method call tends to be typed) - code completion - refactoring is simple - catches straight forward bugs earlier, rather than me finding them when I test So, despite it having types, the main benefit has not really less bugs, it's made my life interacting with the code simpler, and it has made bugs caught by the compiler easier to track down. I think there was a real missed opportunity to have browser definitions split up by browser version so that you could more easily specify a target set and have it show you when you use something not supported though.
• jbrantly 11y ago
  There is definitely a learning curve, and sometimes it can feel like you're fighting against TypeScript instead of having it work for you. However, there have definitely been cases of it being useful. Upgrading from React v0.12 to v0.13 was great because I immediately saw all of the places where the API needed updating. I think moving forward much of the friction will slowly removed (added ES6 features, JSX support, etc).
• drinchev 11y ago
  I started 2 months ago a big project using TypeScript on NodeJS ( I'm freelancer and I'm building an API Service for a company ). CONS: 1. Contribute a couple of times to DefinitelyType repo, because I needed definitions that doesn't exist or modify existing ones with their updated versions ( this is really pain in the ass at this point, because you will most certainly end up using definitions that either doesn't match your version number or are poorly written ). 2. Report a couple of bugs to WebStorm 10 team ( I'm eagerly waiting for WS 11, which they say will improve the typescript support ). 3. Explain to my clients why I am using a beta version of a software for their precious product ( this is not a problem since today :) ) 4. Sometimes the flexibility of typescript can slow you down a lot if you want to go deep with the proper typings and interface declarations. I actually spend a lot of time thinking how to organize my classes and interfaces now, instead of writing code. PROS: 1. Code looks solid and professional ( CoffeeScript on the other - I was so much faster, but in the end I see not that easy readable code. ) 2. Creating documentation is way easier ( using typedoc ). I never understood JSDocs as a pro and usually I spend lots of time on properly annotating, which is unneeded in TS. 3. There is no need to write `function(options) { if ( !options ) { throw new Error("Options required"); } }`. this becomes `function(options : Object) {}`. This removes a lot of boilerplate and really cleans many of those typesafety checks from your code. 4. I'm catching far more errors in the compilation phase than ever before ( see 3 ). I'm also not writing any typesafety tests for my modules ( I was so happy, when I realised that! ).
  • pvnick 11y ago
    Agreed on the points listed. Typescript really helps with code being more solid and professional. We have a large-ish server application written in typescript the really benefits from the OOP principles that typescript enforces. Some initial investment upfront from learning curve and thinking about proper architecture like you mentioned, but really pays dividends over time for adding features or making major changes.
  • AdamTReineke 11y ago
    One thing to note about your third pro (removing boilerplate type safety) is that if other code outside your TypeScript ecosystem starts calling your code, the lack of checks could hurt them.
• cmdkeen 11y ago
  If you're using a typed server language, or can get typed API definitions you can get through stack compile time safety. Writing an ASP.Net MVC application using Entity Framework I can now have a DB change go into my C# and then into Typescript thanks to T4 templates like Typelite. The other aspect is that if you're a C# shop it is so similar as to reduce the learning curve. Especially if you want to write OO front end code.
• itsnotlupus 11y ago
  In general, I suspect you'd get more benefit from starting new projects with TypeScript than "converting" existing ones. The module/class/types system tends to push you in certain direction for your overall design, compared to a more amorphous vanillaJS. Even then, the language features don't replace coding rules and discipline. To pick one feature, protected and private members are little more than polite suggestions in typescript, and can be bypassed easily if that's culturally acceptable in your dev team, losing the benefit of well defined interfaces between chunks of code. If Typescript feels generally useless and even a hindrance to a team, it's very possible that team is working outside of the bounds Typescript is meant for. For example, I can certainly imagine a tight knit bunch of crazed coders writing fantastic JS code that really doesn't fit in a java-like development model. If that's the case, you'd probably want to think about why your team migrated to Typescript in the first place, and what you were hoping to gain from it. The generated boilerplate complaint surprises me a bit. Typescript produces very little extra code, and has almost zero runtime overhead. There's an 5 liner __extends helper function, but that's about it. Most of the time, a line of TS maps to an essentially identical line of JS. I understand that's becoming less true with the fancier syntactic sugar of recent releases, but we're still in the same general ballpark. (and of course, the extra code melts away if you're able to target higher ES versions.) The learning curve bit really depends on your team's background. Folks coming from many non-JS language will have been exposed to modules/namespaces, classes and types. They will be able to write reasonable code with typescript for a while before even realizing JS has this strange and intriguing prototype mechanism, although it can be a bit of a shock when the day comes, and an ancient JavaScript bearded one sits them down and gives them The Talk about what lurks in the basement.
• Keats 11y ago
  Typescript definitely helped on all the projects I've used it. The main con is that sometimes things are not very clear and you might end up spending time on something that typescript can't handle (eg a function that can return several types of objects, I had to put the return type of the function to any to have it compiled). The pros: - being able to refactor stuff easily with the compiler telling you - catch typos easily (I remember watching Dan Abramov video at react europe and some of the errors he showed would be a compilation error in TS) - if you maintain all your classes/object definitions in one file (except maybe stuff like state of a React component which doesn't need to be shared), you have all your types at one place and anyone can come in and have a clear view of the project: I had someone come help me on a previous project and it took him basically no time to get a grip on the project structure/models - DefinitelyTyped so you can also type your calls to third party libraries and what they return Make sure to only use ES6 imports (no internal modules) and it's pretty close to babel but with types.
  • Eridrus 11y ago
    > eg a function that can return several types of objects, I had to put the return type of the function to any to have it compiled Typescript 1.4 to the rescue with union types! Though I would argue that if this is code you're writing yourself, a function that returns multiple types is bad design. Though given the prevalence of different types for different strings, the way they've typed things like addEventListener is interesting.
    • Keats 11y ago
      It actually didn't work with 1.5 beta, can't remember the exact failure. This function actually returns an object depending on the single param, an enum member. All the objects are extending a main type with a couples different properties on each, it's cleaner than having a switch everywhere i want to instantiate one ofthose
• DCoder 11y ago
  To add to what everyone else is saying: I started using TS back in the 0.8 days, before generics were a thing. Since then, I have built several projects with TypeScript and migrated one JavaScript project to TS. These projects also involved Knockout, WebSQL, jQuery and other extras. Along the way, I got most of my colleagues hooked as well. When a new project starts up, the question is usually " Is there a compelling reason to use plain JavaScript instead of TypeScript here? ", not the other way around. The good parts : * The type system serves as a great safety net and prevents a whole class of bugs. * Intellisense is far smarter than you would get from JavaScript (no more silly IDEs with both jQuery's .append() and DOM's .appendChild() in the same intellisense suggestion). This enables refactorings and intelligent assistance such as Find All References, which is much more brittle in plain JS. * Classes are much more convenient and readable than old-school inheritance solutions. Those old solutions were also a huge problem for JS intellisense. * AMD Modules paired with Require.js are much more centralized than "add these fifty script tags to the HTML document, in the right order". That's more due to AMD, but TypeScript adds some nice syntax sugar on top of that. * Arrow functions. No more `var that = this` to keep callbacks working. * Generics, function overloads, etc. - depends on the things you use in your code. If most of your viewmodel properties are Knockout Observables, generics are a life saver. If you're chaining Promises, again, generics can cover their return/param types. Function overloads come in handy if you have factories building objects based on string parameters (example: document.createElement() returns different classes based on the name passed in). And so on. The bad parts : * New language to learn. And it keeps evolving. * Requires an additional build step. There's a large amount of small projects without any build process out there - integrating TS into such a project can be difficult and open a new can of worms related more to the build process than TS (e.g. "do you commit the generated JS and sourcemaps, or provision a build server to package them?"). Of course, if you're already using Grunt/Ant/Phing/whatever else, this is not a big problem. (You should be using a build process at least to aggregate your JS into one blob, if nothing else.) * Definitions for third-party libraries. DefinitelyTyped helps a lot here, but there are still things that it doesn't cover, and it can be time-consuming to keep a definition file in sync with a library as the library updates. * IDE support. After using PHPStorm/IntelliJ and Visual Studio Express/Community, Visual Studio wins hands down. IntelliJ's support was quite disappointing and glitchy, especially its lack of intellisense. Visual Studio Code, Community and Express are all free, but the latter two are quite bulky and running them alongside a different IDE can be slow. * Debugging can be a bit challenging due to sourcemaps, depending on the target browser. I prefer to disable sourcemaps and debug the generated JS directly, but that requires some mental juggling and is not everyone's cup of tea.
• tracker1 11y ago
  To me it seems like a lot of extra cognitive overhead, though if you are using VS it may or may not be worth it. I've been using babeljs and traceur before that for transpiling combined with browserify. You can get a similar experience with more extras with webpack. To me, simply being able to break up methods into discrete testable modules, then composing those methods into either workflows or structured utilities, you don't need the cognitive overhead of strict typing nearly as much. Unfortunately, going that route takes discipline. What typescript and es6 tends to bring is cleaner class syntax, which imho is a detriment to the use of JS in most cases. People tend to put things into classes that really don't need to be. You data structures can be plain objects instantiated as needed (generally via JSON passing), and most of your workflow logic can again be a module that is an object which returns a composite of discrete, or at least bound/wrapped functions that themselves are independent and testable. One thing you should probably strive for in a green project where there is a lot of JS, and multiple developers is 100% test coverage for JS. If you are having serious issues with being able to test your code, odds are your structure needs to be cleaned up. With utilities like sinon and proxyquire you should be able to shim for testing anything a method needs to be exercised. It's also worth noting that test coverage doesn't guarantee good code, it only ensures that you've looked at every piece of code a couple of times. It's that forced review/refactor for testing that gets you thinking in terms of usability. Filling out an existing software with unit tests without refactoring as you go, only gives you some protection against regressions. I have totally lost track of where I was going... I guess it just comes down to that, for me, TS brings the limitations in terms of testing that exist in Java and .Net and force them on JS. JS is inherently more easily testable than many other languages.
• drudru11 11y ago
  I find TS to be quite productive, especially when combined with a great editor that supports it (Visual Studio Code).