13 ms·
I Was Wrong About TypeScript
- dandare 10y agoI find it funny - the first language I learned was ActionScript 3 (built on ECMA 4 proposal) and I become a Flash developer aka laughing stock. I remember I had very rough time transitioning to JavaScript because it felt like a stone age compared to ActionScript 3. Then came TS and saved me and dare I say the whole web.
- pygy_ 10y agoDid you know that Microsoft was part of the cabal against ES4, proposing a competing and very modest ES3.1 which became ES5?
- jestar_jokin 10y agoYou should also have a look at Haxe, which comes from an ActionScript-inspired syntax, and compiles to JS (and a whole bunch of other languages, including ActionScript). It has even better language features than TypeScript (gotta love compile-time macros), although TypeScript has the benefit of adding features in an attempt to describe existing JavaScript code using types, so the interop with JS libs is easier.
- kkirsche 10y agoHaving avoided typescript thus far, I really appreciated this take. Thank you for sharing it!
- Tx3 10y agoI am pleased to hear! One of the goals of the blog post was to convince people to give a second thought for the great tool.
- johnny_reilly 10y agoIt is fantastic - so glad you posted. On the transpilation thing; Babel still has a total use case. TypeScript doesn't provide es6 APIs such as Map / Promise / Array.find etc I output es6 from my TypeScript and pipe that into Babel to get the new APIs and to do transpilation. Works great. (There's a number of ways to do it; I use WebPack with ts-loader and babel-loader which rocks.)
- burai 10y agoAnother good alternative is Facebook's flow. Rather than being a transpired language it works on top of JavaScript files. This two tools are amazing and it improves working with JavaScript to the point of never wanting to go back to not typed JavaScript
- Tx3 10y agoYou're absolutely right. Flow seems to be a very good alternative. One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files.
- lobster_johnson 10y agoIt sounds like --allowJs alleviates the need to create TypeScript definitions for everything? So if you have an existing project based entirely on JavaScript, you can gradually convert each file to .ts without having to do anything else?
- nojvek 10y agoThat is true. You slowly add more black typescript to a white js project as you go along and decide the shade of grey you want.
- danielearwicker 10y agoDefinitely an aim of TS to make it easier to continue using JS for those who prefer a half-way house, see: https://github.com/Microsoft/TypeScript/issues/4789 https://github.com/Microsoft/TypeScript/issues/4789
- hiphipjorge 10y agoWell, you still need some transpiling in order to remove the Flow type signatures. In practice, they end up being pretty similar in terms of needing a build step.
- 10y ago
- kyriakos 10y agoBeen using typescript since its introduction. It really helped me improve my JavaScript code quality and most importantly it's really good at keeping large projects tidy and easy to comprehend.
- Tx3 10y agoIt would be interesting to hear more about your experiences. I have been quite hesitant to use more advanced TypeScript features and stayed on a type system related annotations.
- mikerichards 10y agoInterestingly enough, the Typescript compiler team doesn't even use classes. If you want, you pretty much write just functional code.
- azurelogic 10y agoI recently started learning TS after reading a previous HN post on it (https://medium.com/@basarat/typescript-won-a4e0dfde4b08 https://medium.com/@basarat/typescript-won-a4e0dfde4b08) and listening to the JS Jabber episode with Anders Hejlsberg himself explaining the benefits (https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-hejlsberg https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-...). These two (plus knowing that Angular 2.0 is going to be much easier with TX) totally sold me on learning it. I'm in the middle of this Pluralsight course: https://app.pluralsight.com/library/courses/typescript-in-depth/table-of-contents https://app.pluralsight.com/library/courses/typescript-in-de.... Besides the benefits of TS, I'm learning how perfect VS Code is for writing it. I've been a big proponent of WebStorm in the past, but VS Code is really shining for this type of work.
- Tx3 10y agoAbout the text editor: I think all editors use the same TypeScript compiler APIs. That would mean that you would get pretty much same suggestions, error lists, etc. Correct me if I am wrong. VS Code could have some other API calls or project file support. JS Jabber episode was great! Full of great insights.
- evmar 10y agoI use TypeScript from both Emacs and VSCode, depending on my mood. They do both use the same underlying compiler API, but the VSCode support is more pleasant in how it's surfaced in the editor: ctl-click on a variable to jump to its definition, f2 to rename the variable under the cursor, or ctl-T to open a query field to jump to a symbol. Emacs is capable of all of these things (because Emacs is capable of anything) but it doesn't work that way out of the box nor is there an already-written package around that makes that easy. To rename you type M-x tide-rename-symbol and it's inconvenient enough that I forget to use it.
- jasonm23 10y agoSo bind f2 to tide-rename-symbol in the mode map. And throw the bind into your .emacs
- bdcravens 10y agoAshamedly at one point I was on the anti-Angular 2 bandwagon due to Typescript, because Microsoft. When I started learning Angular 2 myself I've found I actually enjoyed working with Typescript, for many reasons. (confidence that my code wasn't a ball of mystery before it ran, using inline templates, succinctness of annotations, etc) At the same time, you're gonna need to use some preexisting libraries, and run into the issue of not having types available. (though they do exist for most mainstream libs) However, I found creating types for any given lib pretty flexible, and that you can usually get away with just enough types.
- smt88 10y agoMicrosoft has done some great work with languages: C# (shares a lot of DNA/people with TypeScript), F#, and now TypeScript.
- daxfohl 10y agoWell, Altair BASIC was their first product.
- Tx3 10y agoAbout pre-existing libraries that don't have type definitions. The way I dealt (until proper type definitions are written) was: declare module "react-loader" { var noTypeInfoYet: any; export = noTypeInfoYet; }
- daxfohl 10y agoHa, I'm on the anti-Angular2 bandwagon due to Angular1. I use React and Typescript and love it. Curious if you've tried React. Or Angular1 (TBH Angular1 was pretty great at the time, but after React I look back at those monstrous template files, ng-everything, plugins and workarounds, and only the bad memories surface).
- jinglebells 10y agoI'm interested to know if you can build a hybrid app using just React? I tried React but I hit a wall of needing synchronisation, routing, notifications, can you do that now?
- zxcvcxz 10y agoI prefer frameworks that focus on pure javascript because the ones that don't tend to allow you too use javascript but have sparse documentation on how to use it effectively, instead focusing on typescript. When I first tried Angular 2 their javascript "hello world" example wouldn't even work, it was some bug in their site. I already need to use all sorts of other tools and abstraction layers when building websites/apps, typescript feels like just another abstraction layer (which it is), that means another vim plugin for typescript (or a bloated IDE), another npm dev dependency, another layer to the build process, so I try to avoid it for these reasons.
- bdcravens 10y agoI don't really work in the Javascript ecosystem, so when learning Angular 2 recently, I found all the other tools to carry far more cognitive load than Typescript.
- spriggan3 10y ago> I found all the other tools to carry far more cognitive load What tools are you talking about?
- robwormald 10y agoThe great irony of this (and fwiw, I completely agree, and I work on the angular core team...) is that by embracing platform features in ng2 we've opened up a mess of other issues to learn. A good example of this is modules. Angular 1 had its own module syntax (partly because modules weren't really a thing when it started). You could write scripts, concat them together and go. In angular2 we embraced ES6 modules, which means a developer has to deal with loading and bundling etc. One nice side effect here though is we can leverage more tooling from the rest of the JS community (eg, the great work of webpack) rather than having angular-specific solutions.
- stevehiehn 10y agoLast week was my first week trying out Angular2 + TypeScript. I use mostly Java & C# at my day job. I was actually a really shocked at how fast i was able to gain a working knowledge of TypeScript. The only thing i don't like is my project has extra files everywhere (.js + .ts). However there is probably a way to make my IDE hide them or something.
- bdcravens 10y agoWebStorm does a nice job of this. It'll compile on the fly for you, and it collapses the compiled files as child files under the .ts files. So by default you'll only see source files, but can expand and see output if you really need to.
- stevehiehn 10y agoThanks for the tip. I'm look into it.
- robwormald 10y agoI'd suggest using the --outDir option, so TS writes the .js files to a different directory which you can easily blow away.
- Tx3 10y agoRob is exactly right that you should use --outDir You should aim for deployment process where outDir would be in .gitignore and building of the JS files would happen on a build server.
- rymohr 10y agoIf you use --outDir, wouldn't the .js files that import the transpiled .ts files need to point to outDir instead? This is the kind of stuff that makes the "incremental" adoption argument hard for me to swallow. If I can't rewrite a .js file to .ts without any further ripple effects within the project, then it's not truly incremental. I wrestled with this stuff last week and ultimately ended up going with flow since it gave me type checking _and_ incremental adoption, without complicating my existing babel/webpack stack.
- Waterluvian 10y agoI just can't justify writing my team's code base in typescript. I don't want to make that move, setting us down a very specific path. I don't want to add another layer of training to develop on our codebase, but mainly, I just don't have the confidence that it's a right or wrong choice, and its a big choice. But I get a sense that it would be great to try for smaller, disposable projects as that's limited risk. Does anyone else struggle with TypeScript simply because of how big a choice it can be?
- spraak 10y agoYou could start incrementally with Tx3's suggestion - > One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files. Or burai's suggestion - > Another good alternative is Facebook's flow. Rather than being a transpired language it works on top of JavaScript files.
- Tx3 10y agoIt also depends on how deep do you want to go with language features. Let's say you have existing ES2015 source code. You could start experimenting on a local machine and use a script to rename js files to ts. Run the TypeScript compiler and annotate some of the most used functions. You can then check what is the experience of using those functions that have type annotations, what is the speed of the development, etc. Sit down with colleagues, show what you have done and ask what do they think. You can then decide to proceed and stick with type annotations until you're sure. Use boy scouts rule: "Always leave the campground cleaner than you found it." aka add typings to the function declaration.
- treve 10y agoMy impression of TypeScript, is that the .js it produces is actually extremely legible. This is especially true if you mainly use it for strict typing. So in theory you could give it a go, and if you decide you don't like it after a while, you could continue development on your .js files and ditch the .ts files. Chances are that you'll love TypeScript though.
- mikerichards 10y ago
- Scarbutt 10y agoBy the title I though he was going to talk more about the language but it was 95% about tooling.
- tacos 10y agoThat's because there's not much language to talk about. Which is sort of the point--and 95% of the elegance.
- joostdevries 10y agoWith the arrival of TS 2.0 this month (hopefully) we'll have some cool features: a union types [1] b type guards to work with them [1] c nonullable types [2] [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript/pull/7140 https://github.com/Microsoft/TypeScript/pull/7140 As a Scala developer I like Typescript a lot. Which is a first for me in browser development. But I'm not so fond of webpack et al. So I created a sbt-typescript plugin. And now I have incremental compilation of NG2 - Play apps for both the browser side and the server side. In a single build definition. It's a nice experience.
- Tx3 10y agoI wonder is it some black humour to choose padLeft as an example source code. :) Thanks for the links, future looks promising indeed.
- virtualwhys 10y ago> As a Scala developer Interesting, choosing TypeScript over Scala.js; what does TS offer vs. working directly in Scala across the board?
- kodablah 10y agoI am in the same boat as the poster. The main reasons I use typescript instead of scala.js are the vast amount of definition files already made (the scala.js translator of these leaves a lot to be desired), and the fact that it's closer to the es6 community which makes maintenance, contributions, and adoption much more likely. So basically because you stay closer to the JS world. The only downside is lack of "isomorphic" code reuse which I gladly accept anyways because I rarely see server and client side code reuse as beneficial beyond simple models and validation.
- joostdevries 10y agoAs codablah said: the availability of type definitions is a major difference in ease of use. The other reason is that I can add a specialised frontend dev to the team and reasonably expect them to be able to work in Typescript.
- gmac 10y agoAs something of a side note on this post, suggesting there is a single 'Dart/CoffeeScript route' that languages can take seems a bit misleading. Dart is a whole different language that happens to be transpilable to JS. CoffeeScript is just a dash of syntactic sugar that (IMHO) makes JS a whole lot less tedious to write ('The golden rule of CoffeeScript is: "It's just JavaScript"'). Notwithstanding that, I am keen to try using TypeScript on a new project one of these days.
- Tx3 10y agoGood point! I used similar categorising as Anders Hejlberg used in the JavaScript Jabber podcast (https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-hejlsberg https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-...). For those who don't like audio, he basically referred TypeScript being superset of JavaScript, unlike some other languages.
- k__ 10y agoSomehow I can't stand listening to Hejlberg. Often it feels like the CS professors I met at university, who wanted to teach you about "real programming languages and not such toys like JavaScript"
- johnny_reilly 10y agoI can't go with that. Anders H is one of the most avuncular, helpful and accessible voices out there. Oh and his very verbs twinkle!
- k__ 10y agoWell, I just saw a talk about TypeScript 2 and it felt to me that he was belittling JavaScript.
- alkonaut 10y agoJS is very cool because of how readily available it is and the awesome ecosystem that has grown around it. That said - you don't have to be a CS professor to see that the language (especially in early incarnations) wasn't well designed, to put it nicely. A.H. knows this just like anyone with the skills to design languages and compilers.
- k__ 10y agoThe thing with 3rd party libs is, often there are no type defs, especially bleeding edge stuff :/ Also VSC often is flunky with picking up defs... sometimes you open a file and some are missing. Or imports with numbers don't work. On the other hand, using big libs like babylonjs is charming with all the auto complete :)
- solomatov 10y agoIt's not a problem. You can resort to any type and works with 3rd party stuff like with normal JS code.
- k__ 10y agoYes, I can write my own types, but typing isn't always easy. Especially with advanced techniques like parametric polymorphism etc.
- calebegg 10y agoNo, I think solomatov is saying you can always use the 'any' type built-in to TypeScript. You can always do: declare var fancyNewLib: any; fancyNewLib('hello'); fancyNewLib.someCoolFeature = 3; You don't get any suggestions or typechecking (obviously), but you're no worse off than just using JS in that sense. And you can easily replace your 'declare' with the actual // <reference> tag when you find it or make it, and clean up any errors.
- k__ 10y agoAh, yes, that's what I'm doing most of the time. But like you said it's no better than using JS directly, haha.
- swax 10y agoJust changing the file extension from js to ts will often bring out bugs in your code. The type inference will often catch things. Functions that are declared multiple types or that have duplicate parameters, and a lot of other stuff will be caught.
- LionessLover 10y ago"Introduction to TypeScript" by MicroSoft - a free (untimed) course https://www.edx.org/course/introduction-typescript-microsoft-dev201x-1 https://www.edx.org/course/introduction-typescript-microsoft...
- daxfohl 10y agoI just wish TS was based on CoffeeScript.
- kodablah 10y agoI've often thought about a CoffeeScript variant with optional typing that transpiled to TS. The types would be ascribed via a backslash, e.g. `(hello\string) -> hello + ' world'`. But considering the huge benefit of TS is the tooling such as intellisence, I doubt it's worth the effort to start a whole separate ecosystem.
- daxfohl 10y agoI envisioned it somewhat the opposite way. Gradual types a-la TS tacked onto CoffeeScript. No actual TS integration per-se. Though even better would be if the TS team could figure out a way to factor out the type inference logic so that it could be applied just as simply to CoffeeScript as to Javascript, and even allow definitelytyped defs and perhaps intellisense logic to be reused everywhere. Roslyn does this somewhat for C# and VB, so it might not be too big of a jump.
- colemickens 10y agoWhy? Coffeescripts syntax and scoping rules are a barrier to adoption and using ts/js syntax avoids that.
- daxfohl 10y ago'could be used with' is really what I meant.
- doublerebel 10y agoContracts.coffee was great but sadly didn't live long. It would be worth reviving if there is an easier way to maintain it alongside mainline (iced) coffeescript. http://disnetdev.com/contracts.coffee/ http://disnetdev.com/contracts.coffee/
- spartanatreyu 10y ago
- chrisan 10y agoI see a lot of Angular comments, has anyone had good/bad experiences with TypeScript and React?
- Tx3 10y agoIn the blog post, I have one example of the React use case with screen capture. I find it very helpful to have properties defined, so when I use the component, I immediately know what are the props I can provide. There are some 3rd party React components that won't have type definitions yet, but the popular ones are well covered. I have written most of the components I have used, so I haven't had many problems.
- mikerichards 10y agoFrom a React newbies's perspective, the React community is much more in the es6 camp than Typescript. Many of the starter kits are in es6. It's not a huge deal. I actually write most of my front-end code these days in Aurelia, which is written in es6, but they actually have type annotations which Babel knows how to deal with. So basically the tooling can auto-generate the *.d.ts files for you. That said, Typescript natively supports React syntax through TSX files, which is nice.
- batuhanicoz 10y agoShameless plug: When we've started switching to TypeScript and was looking for a good starter, we've couldn't find any that we've liked so we've created & open sourced our own. Maybe it can help people who are considering using TypeScript with React: https://github.com/barbar/vortigern https://github.com/barbar/vortigern
- DanRosenwasser 10y agoWe also have an official doc on getting started with TypeScript, React, and Webpack if anyone's interested: https://www.typescriptlang.org/docs/handbook/react-&-webpack.html https://www.typescriptlang.org/docs/handbook/react-&-webpack...
- 10y ago
- mikerichards 10y agoAt the high risk of starting a huge flamewar, I think the benefits of static-typing have won in a way. I've been using Typescript exclusively as my transpiled language for about a little over a year now. The benefits of intellisense/code-completion and refactoring because of static types can't be underestimated, especially in large apps. That said, I actually like the opt-in nature of Typescript. There's some parts of code I don't feel like I need to define an interface for. It's just not worth it. Typescript is turning out to be quite a powerful little language...maybe approaching the point of quite a bit of complexity, but all in-all it's pretty much been a win for my development efforts.
- jcsnv 10y agoAnyone have feedback on using Flow vs TypeScript?
- dmnd 10y agoI'm also interested in this question. Here's two things I saw on Jeff Morrison's (Flow author) Twitter: * http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm... * https://gist.github.com/jeffmo/ef9214ca3acfe76c54a237b5710d37be https://gist.github.com/jeffmo/ef9214ca3acfe76c54a237b5710d3...
- danielearwicker 10y agoInteresting last line in that presentation: "Flow written in OCaml, Typescript in Typescript"
- mercer 10y agoI found it easier to get started with Flow, but I eventually moved to TypeScript because it just has more mindshare, and isn't worse by any measure I care about. I found it much easier to find tutorials, typings, and so on, for TypeScript. Editor support also seems to be a bit better (especially with VSCode), although the Flow-centered Nucleus plugin for Atom is pretty nice.
- lloyd-christmas 10y ago> I have written tests in TypeScript, compiled to JavaScript, and then used Mocha, for example, to run tests. I would like to hear your thoughts on this. We use ts-node to run our mocha tests without ever compiling: https://github.com/TypeStrong/ts-node https://github.com/TypeStrong/ts-node
- ihsw 10y agoAnother vote for ts-node running your tests, it makes things a lot simpler. Running tests directly instead of running compiled tests is faster and more reliable.
- camwest 10y agots-node has some issues with source maps unfortunately. When your project gets big enough you might want to move back to ts->js then running mocha.
- lloyd-christmas 10y agoMind being a bit more specific with "has some issues"? Our project isn't exactly small, and we haven't bumped into a problem yet. I'd really like to know what to expect if something is about to jump out from behind a wall.
- Tx3 10y agoInteresting solution, thank you for the link!
- fiatjaf 10y agoHow much memory does the compiler use?
- chadcmulligan 10y agoseriously? what does it matter? I run it on a 8GB VM with VS and never noticed an issue.
- fiatjaf 10y agoIt doesn't matter to you, I understand that.
- venuzr 10y agoAre there any patterns / recommended practices for unit testing Typescript. I recently joined a project which uses Angular1 + Typescript and had to introduce unit testing to the code base and it has been painful. A lot of backend API calls (wrapped in services) are being (chained and) invoked in the constructor. Any initialization is being squashed into the constructor. This makes setup of karma tests extremely painful/brittle without a complete refactor for each component. However wrapping initialization code in public methods feel strange to me. Any suggestions?
- jestar_jokin 10y agoI don't know exactly what your code looks like, but a major reason for using Dependency Injection, like AngularJS does, is to allow your tests to "mock" the injected services. Then, you verify the behaviour (but not the implementation), by checking that each mock is invoked with the expected arguments, and set it to return a particular value. On the server side, I've used TypeMoq, which is pretty nice. I have only used it to mock imported modules; for AngularJS 1, you'd need to invoke the "inject" service, to insert your mocks into the controller. Further reading: https://en.wikipedia.org/wiki/Mock_object https://en.wikipedia.org/wiki/Mock_object
- ihsw 10y agoI have found Angular 1 to be an untestable hot mess, especially on projects with a lot of technical debt. This is largely unrelated to TypeScript (and probably unrelated to Angular 1's shortcomings too). My only suggestion is start migrating to Angular 2 immediately.
- Dr_tldr 10y agoIt seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?
- deleted 10y ago[deleted]
- wyager 10y agoTests are weak evidence of the validity of a piece of data at runtime. Types are proof. The stronger your type system, the more you can prove.
- Dr_tldr 10y agoBut doesn't Typescript compile to JS, thus there's actually no type-checking at runtime? Certainly type checking can prove that it's the right type, but in my experience knowing that it's the right type but the wrong data is useless, I care if it's the exact data it's supposed to be. How does type checking protect you (or someone else) from inadvertently mutating a value without changing it type and causing problems later? It's perfectly possible to do this without having any checks for class/instance throw a warning, unless there's something I'm missing.
- ihsw 10y agoYou are correct, there is no type-checking at runtime. Getting garbage data where you are expecting properly formed data will throw a nasty wrench in your application. Thankfully this rarely happens.
- seanwilson 10y ago> But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime? Sure, but that's what happens in every other language e.g. C's type system will enforce certain properties for you but when you compile to machine code the machine code is not checking those properties at runtime. If you know the compiler is correct you don't have to worry. Nobody is saying you should stop writing tests but a good type system will mean you have to write less tests because the type system will do some of the checking for you in a more robust way.
- joshschreuder 10y agoDoes anyone have a good tutorial on migrating existing JS codebases to TS? Talking specifically Angular 1 if you have one, otherwise a general tutorial is fine. I'm interested in whether it is worth the effort migrating a pretty large frontend codebase.
- jestar_jokin 10y agoI did this on my current project. Basically: - Set up your TypeScript config - Set up Typings (or some other type def manager) - Rename all ".js" files to ".ts" - Replace all "var x = require()" calls to "import x = require()" - Gradually refactor components (controllers, directives, services) to classes, or at least add type annotations to everything. Because TypeScript is a superset of JavaScript, you can work on an untyped system and add gradual typing until the codebase starts looking nicer. Any new functionality can be implemented in TypeScript; any existing functionality can be slowly refactored when it is touched by changes.
- whatever_dude 10y agoI'd add tslint to that once the basic migration is done. It can get a lot of issues in the code that are either bad stylistic options, or things that can produce errors in the future.
- Pxtl 10y ago> Web Forms abstracted away the core technologies of the Web with mixed results Understatement of the century.
- Tx3 10y agoHey, I just tried to be polite.. but yes, you're absolutely right, understatement of the century!
- smegel 10y agohttp://walkercoderanger.com/blog/2014/02/javascript-minefield/ http://walkercoderanger.com/blog/2014/02/javascript-minefiel...
- likeclockwork 10y agoAll the TypeScript fervor kind of passes me by because I simply don't want to structure my work around classes and 'ideal TypeScript' that I've seen looks a lot like Java or another class-oriented language.
- spo81rty 10y agoYou mean it looks too much like normal javascript?
- WorldMaker 10y agoTypescript is still extremely useful even if you are writing more functional code. There is no "ideal Typescript", TS is still ES underneath and just about all the ES paradigms including high functional code are still available in TS and benefit from typing information. (The possible exception being that TS is not entirely great at some of the more complex prototype-oriented paradigms, but even that has gotten significantly better in TS >= 1.8 with support for things like intersection types.)
- 235337 10y agoI signed up just to tell you that a slam dunk is not an easy shot. Its when the player jumps up and places "slams" the ball in the net rather then taking the shot from a distance. Its A) hard to get that close unobstructed and B) for most people hard to actually jump that high. Its almost a boastful move of skill to slam dunk the ball. I'm actually no a sports person....
- jondubois 10y agoI'm not a huge fan of TypeScript (though I will admit that it's way more useful than CoffeeScript). My main issues with it are that: 1. The type definition files tend to get out of date. 2. The build step is time consuming for large apps. 3. It adds complexity to your app and opens it up to new kinds of errors (particularly during setup, different typescript versions...). I prefer using plain JavaScript - When I need to find a definition for a function, I just do a text search for it in my IDE. Text search isn't as nice as intellisense for beginners but you get used to it pretty quickly and it's actually pretty efficient once you do. I also like to read through the code a bit before using a function written by someone else, I find that just knowing the interface is often not enough - Often you want to know how specific edge cases are handled and it encourages you to fix bugs in other people's code instead of thinking "This class doesn't work, it's not my problem - I'll just hack a solution to work around it".
- josdejong 10y agoThanks for your story. Funny thing is, just yesterday I wrote a similar article about static typing but from a different angle, see: http://josdejong.com/blog/2016/06/05/static-typing-the-good-parts/ http://josdejong.com/blog/2016/06/05/static-typing-the-good-...
- ryancmartin1976 10y agoI don't see any reason to use TypeScript over Babel. I'm a big supporter of Microsoft technologies, especially since I started out my career developing web applications in the late 90's with Classic ASP. Then adopting .NET in 2000 and working in that space solely until 2011 at which point I jumped shipped over to the isomorphic JavaScript world of Node.js and Angular. Over the past few years I've really taken to Node.js and Angular and when the Angular team told the world it choose TypeScript as its main language of choice to build out the new version of Angular 2.0, I had to seriously consider adopting it as well for Angular development going forward. If it's good enough for the Google team to use for Angular 2.0 then it should be good enough for me to use as well. Then during my research into the technology I ran across Babel. After spending decent amount of time reading up on blog posts defending, promoting or choosing one of the two technologies over the other and alert spending countless hours building applications with each of them in order to get a real good understanding on how each feels to work with. I came to the conclusion that Babel is the only library I need to use on all of my projects and for good reason. Babel provides the development world a tool that allows them the ability to use tomorrow's features and tools today and within mostly ever browser that's in use in some form commercially or professionally. Having the ability to use features in future ECMAScript standards planned for down the road today, makes perfect sense for me to use today if there will not be any side effects to doing so. These features help me write less code, cleaner code and more robust code, just by using a library that handles all of the heavy work behind the scenes when it's time to transpile all of my futuristic code into today's boring standard for browser consumption. Yes TypeScript can provide the end user a large portion of the features and functionality I am referring to with the Babel library but Babel provides the end user a lot more than TypeScript can and it will always be able to provide that and more going into the future as well.
- gabssnake 10y agoIt seems the whole argument is for better tooling in Javascript... why the new language?
- wigam 10y agoThe lack of multiple type definitions for some libraries discouraged me at first. I'll give it a go in the next huge JS project I have.
- StephenCleary 10y agoI still use Babel with TypeScript. This gives me the benefit of TS (specifically, typing), on my preferred development machine (Windows, where FB Flow is really crappy), while getting language-level polyfills (like generators) from Babel. A nice side effect of having TS "compile" to ES6 modules is that Babel's nice-module-loading is used, which means I can just "import _ from 'lodash'" and never have to mess around with "* as" and the endless manipulation of .d.ts files. That said, there are still things missing. In particular, object spread support, which is so nice when using Redux. I've thought about maybe doing a Babel precompile, followed by TS for typing, then a Babel "real compile", but that's probably just crazy.