20 ms·

TypeScript at Slack

440 points by anaisbetts 10y ago

felixrieseberg 10y ago
Hey! Author here - let me know if you have any questions about anything in that post (or, you know, anything else... like, erm, Electron).
- vmasto 10y ago
  I have to ask the obvious, Flow vs TypeScript. I'm sure as React users you took your time weighing the two; care to comment on what drove your final decision?
  - felixrieseberg 10y ago
    I'll be careful not to tell anyone not to use Flow - we're using many of Facebook's tools and we're grateful for their gifts to the community. If Flow works for people, that's great! That said, back when we got started, we found that TypeScript is all around a better team player. For us, we found that it worked better with npm modules, different operating systems, vanilla JavaScript, and various coding tools (VIM, Visual Studio Code, Atom, etc).
  - MarcusBrutus 10y ago
    I 've used both. Flow wins hands down: (1) It is less intrusive. Flow's type system is built on annotations which are simply stripped away at runtime (as opposed to writing in another - albeit similar - language that gets transpiled to JS. Sure the transformations are always "file-local" as TS folks say but still it is another, totally unecessary level of abstraction and transpilation. (2) Flow's type system is at least equally and quite possibly much more expressive and nuanced than TS. (3) Flow annotations can be applied in a much more piece-meal way than TS. (4) zero issues integrating with 3rd party libraries (because of 1) - and that includes the ability to type-check said 3rd party libraries (which is a breeze with flow-typed) (5) To take advantage of TS you have to write JS code in the "JS with classes" style (a.k.a "JS for C# coders"). In contrast Flow allows you to take advantage of its type checking while coding: (a) in idiomatic JS (prototypes) (b) in JS with classes (c) any combination and mix of the two approaches. Flow feels a lot less opinioned as to your JS programming style. (6) Flow it is not coming from microsoft (but hey, don't you know we've changed, please give us another chance and we won't fuck you over this time, please we love you so). TS team is trying very hard (perhaps too hard) to distance themselves from the negative brand value of microsoft (7) Flow is not a blueprint for the Mother of all embrace-extend-extigunish strategies (see #6).
    - jnordwick 10y ago
      the whole "MS is evil" thing is so played out.
    - nycdotnet 10y ago
      I have not used Flow, but there's a few misconceptions about TypeScript in the above comment. - There's an implication that Flow is vastly different than TypeScript because its annotations are stripped away - that's how TypeScript works too. - There's an implication that TypeScript has some sort of unusual syntax - Modern JavaScript (ES6+) and TypeScript code is identical (except for the addition of type annotations where desired). - Flow may have a nuanced and expressive type system - I don't know - but TypeScript attempts to accurately model the type system of JavaScript. - TypeScript can be used in a very loose mode where it type-checks plain .js files with no annotations at all, all the way up to a very strict mode where it must know the type of everything (which you can set to `any` on a per-variable basis if you don't care). - TypeScript is JavaScript, so it has no issues integrating with any JavaScript library. If you want perfect strong typing of a given version of a given JS library, someone has to do that work and this is where some people do struggle. Microsoft has put forth a lot of effort to help here recently. Flow-type may be a great resource (I don't know), but I can scroll its list of supported libraries on its repo on GitHub. https://github.com/flowtype/flow-typed/tree/master/definitions/npm https://github.com/flowtype/flow-typed/tree/master/definitio... . The DefinitelyTyped repo breaks GitHub with the number of libraries it has definitions for: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast... (nearly 2000 entries are omitted). - Item 5 is flatly false. For example, TypeScript is itself written in TypeScript and there is not a class in the entire code base - it is 100% idiomatic functional JS. By contrast, Flow is not self-hosted. - Regarding item 6, TypeScript is the poster child for the new Microsoft. It has been open source (Apache 2.0) and cross platform from its original release in 2012. And regardless of what happens with TypeScript (I forsee it tracking ECMAScript standards for the next several years at a bare minimum), the emitted JS is basically identical to your TypeScript code (minus the annotations) so worst case scenario if Microsoft somehow magically deleted all copies of TypeScript in the world, you'd just keep going with the ES6+ code you have.
- scrollaway 10y ago
  Less engineering, more practical question: What's your setup? I see vscode screenshots, care to share your typescript config and preferences? :)
  - ojkwon 10y ago
    It does have a small additional own flavor of configuration, but basically, it's nearly identical to some of OSS project written in typescript, like RxJS (https://github.com/ReactiveX/rxjs/blob/master/tsconfig.json https://github.com/ReactiveX/rxjs/blob/master/tsconfig.json / https://github.com/ReactiveX/rxjs/blob/master/tslint.json https://github.com/ReactiveX/rxjs/blob/master/tslint.json) cause basically it just inherited those configurations. For VS code preferences, there isn't one unified one but just leave each individual picks configs based on own preferences.
- ArchReaper 10y ago
  There was a big discussion on Electron today here - https://news.ycombinator.com/item?id=14087381 https://news.ycombinator.com/item?id=14087381 One of the points was talking about React Native vs Electron. What are your thoughts? Why did you guys go with Electron?
  - cwyers 10y ago
    Isn't Slack older than React Native for platforms outside of iOS?
- 35bge57dtjku 10y ago
  Have you tried ScalaJs? Typescript seems like a better alternative to plain Js, but still seems pretty lacking. For example, the standard libraries are so much nicer than what TS or Javascript offer.
  - kornish 10y ago
    My suspicion is that the ease of porting an existing JS codebase to Typescript is an order of magnitude easier than rewriting it in Scala, even if the eventual benefit is higher.
    - ludicast 10y ago
      I think scala.js is having better integration these days (due to typings etc.) But still not 100%. But I would switch to all-scala if it ever had a dev-friendly 100% integration strategy.
      - 35bge57dtjku 10y ago
        What do you mean by that? It's had the ability for a while now to easily specify types for external js code and call js code.
        ludicast 10y ago
        I'll have to reexamine then. Last I saw the typings story wasn't well documented but would be beyond overjoyed to be wrong.
  - abiox 10y ago
    or Fable, or PureScript, or Kotlin... :)
    - Rapzid 10y ago
      Fable has such potential. F# is fantastic and I could totally get behind that as a TypeScript alternative under the right circumstances.
- groovypuppy 10y ago
  Hey Felix, was Dart ever in consideration? I use both TS & Dart (I'm on a TS project currently) but I find Dart so much cleaner but the JS code it generates is very hairy. Thoughts?
  - felixrieseberg 10y ago
    I personally haven't spent too much time looking at Dart, but I find it pretty suspicious that TypeScript is on Google's list of approved languages for projects, while Dart is interestingly missing. I'm sure there's upsides to Dart, but I would certainly need to spend more time with it to make a judgement call. https://www.reddit.com/r/programming/comments/64e6x7/typescript_got_approved_as_internal_development/ https://www.reddit.com/r/programming/comments/64e6x7/typescr...
    - floitsch 10y ago
      Dart is doing fine inside Google. It is used by extremely important projects, like, for example Adwords. These teams are very happy with it and have no intention of changing. Brad Green already posted a follow-up post on the omission of Dart on his slides: http://angularjs.blogspot.dk/2017/04/official-languages-at-google.html http://angularjs.blogspot.dk/2017/04/official-languages-at-g... (I work on Dart.)
      - felixrieseberg 10y ago
        Thanks for the update, good to know!
      - groovypuppy 10y ago
        Even though I work with Typescript daily, Typescript feels like a stop-gap measure until ES6 /ES.Next take hold. Dart feels like the future - given Fuchsia + Flutter + Android apps in Chrome, etc. - if they can just work out some of the rough edges(e.g. isolates with Flutter) and make it more harmonious with JS/DOM - let's face it: We are stuck with the JS/HTML/CSS stack for the foreseeable future.
    - 10y ago
- sydd 10y ago
  > To improve our situation, we decided to give static type checking a shot. I wonder why it took you years to realize this. I'd never use a dynamically typed language for more than a few hundred lines of code, it becomes an unmaintainable mess afterwards. So serious question: Why?
  - azrazalea 10y ago
    In case you are wondering about the downvotes: There are millions(trillions?) of lines of code out there that is maintainable and dynamically typed.
    - jiaweihli 10y ago
      Maintainable, but at what cost? A large chunk of unit tests for dynamically typed code is dedicated to checking types.
  - felixrieseberg 10y ago
    It's probably worth pointing out that Slack _also_ contains a ton of native code, written in C++ (with a bit of C++/CX and Objective-C). All of us on our small team have an extensive background in typed languages, including giant code bases (Windows, for example). We just also happen to really like JavaScript, feeling that it and the ecosystem around us makes us more productive given our needs. TypeScript a few years ago was simply not good enough, and neither were the alternatives. It's okay if you feel otherwise, but trust that there are quite a few developers out there who are comfortable with building and maintaining rather large JavaScript codebases, building pretty impressive applications with it. This post isn't yet another "JavaScript is terrible" rant, I quite like it.
  - dilap 10y ago
    I'm right there with you, but dynamically-typed languages still have their advocates (though it seems they're losing out more recently). (I think this is because a lot of the advantages associated with dynamic typing were in fact portable back to statically typed languages. If you're comparing C++98 to Python, the dynamically typed language seems pretty nice. If you're comparing Javascript to Golang or TypeScript, not so much.)
- seattle_spring 10y ago
  Is the article's hero picture (the Seattle skyline) a hint that you'll be opening an office here soon?
  - felixrieseberg 10y ago
    Sorry, I just chose the image because TypeScript's official hero image is a Seattle skyline. I hope I didn't disappoint - I love Seattle though, I can't wait to be back this year for //build.
    - seattle_spring 10y ago
      No worries, was mostly joking! I have a good friend at the SF office and hope to one day work with her again. That can only happen if your team opens some offices up here in the Emerald City :)
- z3t4 10y ago
  It would be interesting to see examples of bugs you found.
vmasto 10y ago
Although I don't use TypeScript (I'm looking at Flow more and more recently instead) I have to acknowledge Microsoft's huge contribution to the JS scene (and not only) with TS and VSCode, truly exceptional products. What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). It's also quite amusing that this article came out today where HN's top article for a few hours was a bashing against Electron (and Slack specifically).
- djtriptych 10y ago
  And AJAX :) I'm also really hoping that the current crop of JS programmers learn event-driven / reactive style programming, and for that, RX is probably the best JS library out.
  - zghst 10y ago
    I spent a lot of the earlier parts of my life hating MS, however later after working at a .NET shop and with the late developments at the company, my love for MS is becoming near-infinite. Reactive is definitely the way to go
    - mmgutz 10y ago
      It's strange but I went the other way. I started hating MS because of working in .NET. Basically, if something wasn't blessed by MS, it wasn't used. There were open source MVC projects but since MS only blessed ASP.NET forms back then, you couldn't convince managers to use MVC. Same with IoC. Same with ORMs I do like the new Microsoft. VS.Code is hands down the best all-around editor right now. TypeScript is awesome sauce.
      - bobwaycott 10y ago
        I started here, too. First production app was an early C# ASP.NET OSHA safety management and training platform for Mohawk carpets, built from the ground up back in 2007-08. Experienced all these headaches. Next major project was Python-based. Never went back to .NET.
ng12 10y ago
Typescript's single biggest win for me is the ability to provide type definitions for my models. This is where the vast majority of my JS bugs come from -- somebody trying to access a nonexistent property of some object (or, if it does exist, incorrectly assuming the type) which was serialized from JSON. Better yet, if you write your back-end in Node you can use the same models in your rest endpoint. It's a huge boost to both maintainability and developer productivity. However, my biggest frustration with Typescript is the general unreliability of @types. The odds that a given set of typings are complete, correct, and up-to-date are basically nil -- even for some relatively popular projects. Sad to say I've become an expert in Typescript's crazy module augmentation nonsense. Hopefully more big players like Slack contributing to DT will help.
- whatever_dude 10y ago
  In my ideal world, every library would be written in TypeScript and therefore benefit from their automatic type definition output, shipped as an invisible part of their npm package.
- rattray 10y ago
  For anyone unfamiliar: DT is "DefinitelyTyped", a github repo that consolidates type declaration files for open-source packages on npm. Ironically, given the above comment, its tagline is: > The repository for high quality TypeScript type definitions. (emphasis theirs) https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped
- sadlion 10y ago
  How does one validate typescript models at runtime? I have seen combinations of JSON schema and validator libraries but I'd love to do it using typescript's type system. From my understanding, it doesn't work because of type erasure.
  - ng12 10y ago
    AFAIK there's no good solution. That's why it works best when your back end is using Typescript as well -- your route returns the same interface the client is expecting.
throw5938 10y ago
Seems like Apple needs to disincentivize the use of Electron and other user hostile technologies somehow before anything will change. They also need to crackdown on the Facebook app. http://blog.timac.org/?p=1707 http://blog.timac.org/?p=1707
Androider 10y ago
Question for TypeScript users from someone who's still on the fence: Are you at all worried that TS will end up like CoffeeScript? That is, it starts out with some great ideas that are quite easy to get behind, but JavaScript keeps on advancing year after year and soon you have the same features available but with an annoyingly different syntax, or you actually end up falling behind the curve. You're also not able to simply use the latest JS features, my last attempt at adopting TS died when I found it didn't at the time support object rest and spread properties, which I had been liberally using via Babel for quite some time. It seems like Flow is a "safer" choice to me, but I'd love to hear if you disagree.
- deleted 10y ago
  [deleted]
- Strom 10y ago
  The TypeScript team has a goal of keeping it a superset of JavaScript. This means that when JavaScript gets some new features, TypeScript also supports that. If TypeScript supported it before with some other syntax, the syntax gets changed. [1] The hero feature of TypeScript, static typing, will never be available in pure JavaScript based on any current prophecies. -- [1] One reason the object spread/rest situation took so long was because they didn't want to implement it and then have to change the syntax/meaning later. It's better to wait until new proposals have gotten a decent amount of progress, so that they're fairly stable. Do note that spread/rest still isn't in the JavaScript standard, it's a proposal.
  - sixdimensional 10y ago
    Side related question- has this going outside of standards with such things as Typescript been harmful? I mean, standards move slowly, but your question raises an interesting point - why didn't we just extend actual Javascript to have typing supported? Have we given up on advancing the core language in such regards?
    - WorldMaker 10y ago
mi100hael 10y ago
Slack & its use of JS are sure getting a lot of attention on the front page of HN today...
blauditore 10y ago
The article mentions multi-threaded desktop applications along with JS. Since JS is inherently single-threaded, what does that mean? Do they actually refer to multiple processes or some other magic?
- chickenfries 10y ago
  JavaScript doesn't really have "threads" but node JS has it's `child_process` module and the browser has web workers.
  - blauditore 10y ago
    Yeah, but Node child processes are actually separate OS processes, which behave quite differently from threads (higher overhead to spawn, separate memory). The same goes for web workers; they're more like daemon processes than different threads. So I guess this was just poor terminology in the article, not any new magic... :)
anko 10y ago
one thing I wish typescript had was an ability mark typechecks as runtime. Commonly I'll have a nodejs express app which serves an api and i've love a easy way to validate an interface against the payload passed in. Maybe it would be as simple as a function JSON.parseWithChecking<User>(payload) or some annotation to get the interface reflected and passed into this function at runtime. It's normally always at deserialisation that this problem occurs.
- dean177 10y ago
  I do this with a custom jasmine matcher in integration tests, you provide the matcher with some objects (which all satisfy the type you are expecting) and the matcher tells you if the response satisfies the type. It's a bit rough around the edges, but has been very useful so far. I'd consider creating an npm module if there is interest.
- whatever_dude 10y ago
  Wouldn't it be better to use a JSON Schema validator in this case?
  - anko 10y ago
    Then you're maintaining two definitions - typescript ones and json schema ones. But thanks for the idea :)
    - whatever_dude 10y ago
      Well, you could have one or the other and then just convert a schema to an Interface [1], or vice versa [2]. The reason I like schema-first is because a schema allows you to be way more strict about what's accepted in most cases, e.g. validating an entry via RegEx. It tends to make APIs safer and runtime errors more clear. [1] https://github.com/bcherny/json-schema-to-typescript https://github.com/bcherny/json-schema-to-typescript [2] https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema
    - gcanti 10y ago
ChicagoDave 10y ago
A slightly forked discussion, but having been in IT for over 30 years, I sense a theme... A long time ago, people argued over the merits of assembly versus C. After that, people argued over Pascal over C. Then BASIC caused all kinds of consternation. BASIC versus "structured programming" was a common argument. With BASIC, there was this sort of wildness to it that drove people crazy. (this should be sounding familiar) Then Visual Basic added structure (procedural at first, OO in .NET). Then JavaScript was added to browsers and everyone cried that it was too unstructured and "wild". Then Google Maps was released and JavaScript suddenly became popular. Then NodeJS solidified JS as a real solution. Now TypeScript comes along to make JS more "structured" and we have the same old arguments. Structure over low level unconstrained programming. The weird part (to me) is that each side garners the louder voice about every ten years. I'm pretty sure some new-fangled unstructured platform will arrive in 2020 that everyone will jump on and say is better. It offers freedom and the ability to sculpt a vision that the structured platforms don't. Am I right or am I right?
- seanmcdirmid 10y ago
  With TypeScript, it is more like opening up old wounds between structural and nominal subtyping. The error reporting one gets with structural subtyping are really chaotic. On the other hand, it really works when bolting a type system on top of Javascript.
- krona 10y ago
  One significant difference with the past examples you cite is that Typescript is gradually typed, so it's a false dichotomy you're presenting. Personally I think this is one of Typescript's biggest achievements, since the Typescript programmer gets to decide how structured their system should be.
  - ChicagoDave 10y ago
    Maybe. But anecdotally I've heard from more than a few JS devs that they'd _never_ learn TypeScript because it adds structure they don't feel is necessary and that just following ES6 is good enough.
vinhboy 10y ago
> he did not expect how far the Slack Desktop App would take his invention Kind of funny to read this article, after just reading that Electron article.
LeoNatan25 10y ago
> TypeScript at Slack > Or, How I Learned to Stop Worrying & Trust the Compiler So revolutionary. Who knew that compiling code has advantages over interpreted scripts.
- iends 10y ago
  I'm not sure what you're trying to convey. Most/All? modern JavaScript engines compile JavaScript (including v8).
  - dimgl 10y ago
    lolwat?
    - chillacy 10y ago
      I think the parent is referring to JIT Compilation as a type of "compilation" as opposed to being interpreted. Of course the original post is tackling the type-safe aspect of compiling vs performance.
  - __float 10y ago
    But you still have to actually run the code to find a lot of problems you can find in TS at "compile" time.
- revmoo 10y ago
  Why is there no downvote on here
jondubois 10y ago
I do not particularly like TypeScript because: - It adds complexity and unnecessary dependencies to the project and this makes it more brittle and more difficult to set up and get running (I often run into issues with it). - Slows down your debug cycle (it typically takes at least 15 seconds to compile for a small project) so you can't test your assumptions quickly as you would with plain JS - You have to wait all the time and try not to get distracted. - For an experienced JS developer like me, the vast majority of errors raised by the compiler are pedantic and not related to any real logical flaws - I spend a lot of time catering to the fussiness of the compiler instead of thinking purely about logic. - Working with legacy JS libraries is a pain. I will admit though that being able to look up references and usages of various classes and functions without having to leave the IDE is a nice feature - I don't really need it though because I got used to searching through my code with text-matching (sift) and by adhering to a proper source directory structure.
- parent5446 10y ago
  Surprisingly I have not run into those compile time issues. Maybe it's just my company's own infrastructure, but our TS projects, which can get rather large, all recompile in less than five seconds.
  - jondubois 10y ago
    Yeah I'm not sure why it takes so long for me. We're using Angular 2.
- ludicast 10y ago
  My compile time is very fast (near instant), but I split up my projects into a zillion private modules. Adds some complexity but great for tdd. TS has been worth it to me, even if once in a while the compiler is too fussy like you say.
- anko 10y ago
  total side point, but did you know in visual studio code you can enable "editor.codelens" and it will show class references in javascript above the declaration - no typescript required.
tabeth 10y ago
I haven't used TypeScript yet, but it seems like it's similar to a pattern I sometimes use, like the following: function foo(a, b, c) { g.param(String, a); g.param(Object, b); g.param(XMLHttpRequest, c); /* stuff */ g.return(String, bar); } Seems like the main benefit to using TypeScript is that it can tell you if you have poor types during "compile" time, right? I guess the question for me is, is TypeScript superior than the above pattern?
- chillacy 10y ago
  Autocomplete is a big productivity boost too: VS Code will suggest methods on the object, then tell you exactly what arguments it takes and what types they all are. Of course maybe you can have another system which reads in the code you have and autocompletes for you too.. after all, the type info is all there, it's just in a different place. Compared to everything in the function definition: function foo(a: string, b: object, c: XMLHttpRequest): string
- to3m 10y ago
  Yes, because it will check for you before you run the code, and you can be certain as you can be about anything that no case was missed.
revmoo 10y ago
> First, we were surprised by the number of small bugs we found when converting our code. Talking to other developers who began using a type checker, we were delighted to hear that this was a common experience: the more lines of code a human writes, the more inevitable it becomes to misspell a property, assume the parent of a nested object to always exist, or to use a non-standard error object. Howwwwwww?? How does your app work with these sorts of bugs existing in the code without anybody noticing?
iamwil 10y ago
After using types in Elm, types in Typescript have felt like a step backwards.
- deleted 10y ago
  [deleted]
- bbcbasic 10y ago
  After using types in Haskell, types in Elm also feel like a step backwards.
  - KurtMueller 10y ago
    If you're starting from JS, going to Elm and then to Haskell are two steps forward :).
  - weavie 10y ago
    After using types in Idris, types in Haskell feel like a step backwards...
    - bbcbasic 10y ago
      A nice poset developing here.
- KurtMueller 10y ago
  I agree completely. If you enjoy Typescript, why not just go whole hog and go with Elm, F# and Fable, ReasonML, or even Purescript.
- mambodog 10y ago
  Coming from Javascript, Typescript and Flow have huge benefits which a much smaller learning curve than going straight to Elm. I recommend people who don't have experience with static types start with one of those two.
  - iamwil 10y ago
rdiddly 10y ago
I've been working in this kind of environment with strongly typed languages for a long time, but TypeScript might be the thing that gets me to go back & give JS another chance. Funny to be coming at it the other way!
ken47 10y ago
Typescript is GREAT. Strict null-checking eliminates the dreaded null-pointer exception. It enables type-safe mixins. It allows for mapped types. Literal types, especially string literal types, makes it so easy to work with pre-existing JS libraries. The way I look at Typescript vs. Javascript is that with Typescript, it's like having always having a pair programming buddy (the compiler) who never makes mistakes.
- kough 10y ago
  What exactly do you mean by "null-pointer exception"?
  - Dru89 10y ago
    He's referring to the dereference of a null object. For instance, calling "foo.bar" when foo is null (or potentially undefined).
- yoklov 10y ago
  > Strict null-checking eliminates the dreaded null-pointer exception When I was using typescript this still came up if you missed an array bounds check, you'd end up with an unexpected undefined. Pretty annoying and tough to debug. Has this changed (I can't see how it could have, but... maybe?)
  - curveship 10y ago
    Sort of. Strict null checking now lets you distinguish between the types Foo[] and (Foo | undefined)[]. The first will type with the assumption that there are no out of bounds indices (which, as you say, could be wrong). The second will require you to always check the result of array dereferences to see if they're undefined before you reference the object. var foos1 = [] as Foo[], foos2 = [] as (Foo | undefined)[]; // ... later var foo1 = foos1[i], foo2 = foos2[i]; foo1.bar(); // types fine, TS assumes non-undefined foo2.bar(); // TS type error, as you haven't checked undef if (foo2) foo2.bar(); // types fine, undef excluded
msie 10y ago
The more code is in TS, the easier it is to write tools to manage that code.
deleted 10y ago
[deleted]
nathan_f77 10y ago
Where can I find a good list of pros and cons for Flow and TypeScript? I've been really enjoying Flow, and I have experienced all of the benefits mentioned in this article. I'm using VSCode, and the Flow integration is really good. Feels like a full IDE for Javascript, without being bloated and slow. (Startup is a little slower than Sublime, but it's very fast once everything has loaded.) I'm wondering if I'm missing out on anything by choosing Flow instead of Typescript. I've been developing React and React Native apps, and it seems like Flow is the default choice for that ecosystem. Has anyone switched from Flow to Typescript, and how did it go?
- vanwalj 10y ago
  Having experience with both on Node back-end projects, I can tell you than IMHO Flow is smarter, especially on union types, BUT there are way more TS community type definitions available right now.
  - johnfn 10y ago
    I'd be curious in which ways flow is more intelligent than TS.
    - boubiyeah 10y ago
      Me too. I don't really see how you can get any smarter with union types than with TS 2.2+
    - vanwalj 10y ago
      Here are some examples: TS: https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%7B%0D%0A%20%20%20%20valA%3A%20string%0D%0A%7D%0D%0A%0D%0Atype%20TB%20%3D%20%7B%0D%0A%20%20%20%20valB%3A%20string%0D%0A%7D%0D%0A%0D%0Atype%20TAorTB%20%3D%20TA%20%7C%20TB%0D%0A%0D%0Afunction%20isTA(x%3A%20any)%3A%20x%20is%20TA%20%7B%0D%0A%20%20%20%20return%20x.valA%0D%0A%7D%0D%0A%0D%0Afunction%20func%20(param%3A%20TAorTB)%20%7B%0D%0A%20%20%20%20if%20(isTA(param))%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log('This%20is%20IA')%0D%0A%20%20%20%20%7D%20else%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log('This%20is%20IB')%0D%0A%20%20%20%20%7D%0D%0A%7D https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%... Flow: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmALxgDeqYtYAbgIYzEBcYAzhgE4CWAdgHNUAX3TZ8RAELkqNOkxhT2XPkNHjcBYnG4yKJMAB9p6KAFd+AYwy84-MBetgAFDkbdGAW3Y69ASjk6MF4oV3dPLwA6RWJA6mDgq3sOOBg8KPhBFwByABUAC14OEJKSHP95WhEwPBgOAgTE2mT+VPTMuGz8opLi6QqqsDExIA https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmA... With Typescript, you have to write custom Type Guards functions, whereas Flow is smart enough to infer type
deleted 10y ago
[deleted]
z3t4 10y ago
I'm a strong opponent against type annotations in JavaScript. JavaScript only have a few types: strings, numbers, boolean, null, undefined, and Symbol (ES6). And annotating them feels stupid. Feel free to use Flow, Typescript et.al. but let the type inferencer do the work, not you. You should only have to think about the abstract meaning of the code. And pick good names for variables and functions. In order to catch more parameter errors, your functions should throw errors if the parameters are incorrect!
boubiyeah 10y ago
Typescript is a truly great project, I'm not sure many people understand the amount of work that has gone into this compiler. They have the crazy constraint of being 100% compatible with Javascript, which is a bit broken by design and yet they managed to make it so much better to work with TS than with JS. After trying Flow numerous times, I came to the conclusion it simply can't compete with the power of the team Microsoft put together. Even their alpha versions are stable enough to be used in production. Some advices: - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. - Use a noAny tslint rule. disable it on a case by case basis, only in util code. Most of the time, any is not necessary, often you can use {} or Object instead. - You can get away with just using undefined everywhere, null adds no value. - Use union types. Make impossible data combinations impossible to write! Example: export type RemoteData<D, E> = NotAsked | Loading | Refreshing<D> | Success<D> | Failure<E>
- mercer 10y ago
  > - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. This is exactly what I did and it's the main reason I keep dropping TypeScript because I 'need to get shit done'! It's good advice though, and I would definitely advise new TypeScript users (especially those unfamiliar with type systems) to at least try it. But if it results in giving up and going back to just js, it might be worth going with the 'barely better' approach and only enable those flags if you're more comfortable with TypeScript.
  - ash 10y ago
    strictNullChecks errors are easy to fix: 1. Add `| null` or `?` for things that could be null/undefined. 2. Start handling "is this thing null?" cases. In some occasions it could be annoying. E.g. when you are absolutely sure it's not null. E.g. in tests. TypeScript provides `!` operator for that: interface Baz { foo?: string; } let bar = (t: Baz) => // yes, I'm sure t.foo!.length; https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#non-null-assertion-operator https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
misotaur 10y ago
Is Typescript already supported on most browsers or do I need to install a library?
- whatever_dude 10y ago
  Typescript doesn't need browser support, it's transpiled as JavaScript.
uranian 10y ago
I really don't understand why some developers are so happy with Typescript. Javascript was already years ago highly improved with transpilers like Coffeescript, Livescript etc.. IMHO this whole Babel, ES5, ES6, ES7, ES???, Typescript thing with it's countless options is much worse than simply Coffeescript with a dynamic type checker. I use the latter in quite some production environments currently. No need for Babel, Typescript, linters etc.. It really makes my life way, way easier, less npm modules, less bugs, less lines of code, much more readable, etc, etc.. And please, before you start preaching all those 'amazing' benefits of Babel, Typescript, linters, ES5, ES6, ESx, I come from that misery and it sucks!
- kgabis 10y ago
  Would you rather have your program fail at runtime instead of using a statically typed language? It really baffles me why so many people prefer dynamically typed languages and write large projects in them.
  - uranian 10y ago
    My apps don't fail at runtime because of type errors, at least, not that I remember. It really baffles me how many people need Typescript to avoid having type errors at runtime, what the hack are they doing wrong then? This is not C++, we only have a few types in JS, really hard to mess up for me.
    - kgabis 10y ago
      Are you serious? You can define custom types in javascript, nobody programs using only primitives like strings, numbers and booleans.
- choward 10y ago
  What exactly does coffeescript buy you besides the sugar? How does it prevent bugs?
  - uranian 10y ago
renlinx 10y ago
Instead of wasting time on this, try to understand javascript, Why slack web app & desktop app(electron) is taking too much cpu & memory, it will help you...
pacoverdi 10y ago
I have become a create-react-app junkie but unfortunately TS is still not (officially) supported in it [1] so for the moment I stick to using flowtype. [1] https://github.com/facebookincubator/create-react-app/issues/142 https://github.com/facebookincubator/create-react-app/issues...
jacobr 10y ago
Last time I tried TypeScript we ended up abandoning it after having mismatches between dependencies and TS definitions. We had to postpone upgrading libraries to wait for definition updates or write and maintain them ourselves. This was in the early stage of a project though, we needed to get a quick first version out in 2 weeks and it just wasn't worth the hassle. Has this situation improved - I understand typings are no longer installed with a 3rd party tool/registry?
- simooooo 10y ago
  They aren't? How does it validate the code without typings for everything
- Ciantic 10y ago
  There is one significant change with TS 2.2, you don't have to use type definitions for libraries anymore. Since all JavaScript is valid TypeScript. With out of the box setup the import from library that has no type definitions, works just fine. It returns `any` type, so you can use all libraries just like you would in JavaScript. So if you ram your head against bad type definition of a module, just delete it and continue using it like you would in normal JS.

440 points by anaisbetts 10y ago

Hey! Author here - let me know if you have any questions about anything in that post (or, you know, anything else... like, erm, Electron).

vmasto 10y ago
I have to ask the obvious, Flow vs TypeScript. I'm sure as React users you took your time weighing the two; care to comment on what drove your final decision?
- felixrieseberg 10y ago
  I'll be careful not to tell anyone not to use Flow - we're using many of Facebook's tools and we're grateful for their gifts to the community. If Flow works for people, that's great! That said, back when we got started, we found that TypeScript is all around a better team player. For us, we found that it worked better with npm modules, different operating systems, vanilla JavaScript, and various coding tools (VIM, Visual Studio Code, Atom, etc).
- MarcusBrutus 10y ago
  I 've used both. Flow wins hands down: (1) It is less intrusive. Flow's type system is built on annotations which are simply stripped away at runtime (as opposed to writing in another - albeit similar - language that gets transpiled to JS. Sure the transformations are always "file-local" as TS folks say but still it is another, totally unecessary level of abstraction and transpilation. (2) Flow's type system is at least equally and quite possibly much more expressive and nuanced than TS. (3) Flow annotations can be applied in a much more piece-meal way than TS. (4) zero issues integrating with 3rd party libraries (because of 1) - and that includes the ability to type-check said 3rd party libraries (which is a breeze with flow-typed) (5) To take advantage of TS you have to write JS code in the "JS with classes" style (a.k.a "JS for C# coders"). In contrast Flow allows you to take advantage of its type checking while coding: (a) in idiomatic JS (prototypes) (b) in JS with classes (c) any combination and mix of the two approaches. Flow feels a lot less opinioned as to your JS programming style. (6) Flow it is not coming from microsoft (but hey, don't you know we've changed, please give us another chance and we won't fuck you over this time, please we love you so). TS team is trying very hard (perhaps too hard) to distance themselves from the negative brand value of microsoft (7) Flow is not a blueprint for the Mother of all embrace-extend-extigunish strategies (see #6).
  - jnordwick 10y ago
    the whole "MS is evil" thing is so played out.
  - nycdotnet 10y ago
    I have not used Flow, but there's a few misconceptions about TypeScript in the above comment. - There's an implication that Flow is vastly different than TypeScript because its annotations are stripped away - that's how TypeScript works too. - There's an implication that TypeScript has some sort of unusual syntax - Modern JavaScript (ES6+) and TypeScript code is identical (except for the addition of type annotations where desired). - Flow may have a nuanced and expressive type system - I don't know - but TypeScript attempts to accurately model the type system of JavaScript. - TypeScript can be used in a very loose mode where it type-checks plain .js files with no annotations at all, all the way up to a very strict mode where it must know the type of everything (which you can set to `any` on a per-variable basis if you don't care). - TypeScript is JavaScript, so it has no issues integrating with any JavaScript library. If you want perfect strong typing of a given version of a given JS library, someone has to do that work and this is where some people do struggle. Microsoft has put forth a lot of effort to help here recently. Flow-type may be a great resource (I don't know), but I can scroll its list of supported libraries on its repo on GitHub. https://github.com/flowtype/flow-typed/tree/master/definitions/npm https://github.com/flowtype/flow-typed/tree/master/definitio... . The DefinitelyTyped repo breaks GitHub with the number of libraries it has definitions for: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast... (nearly 2000 entries are omitted). - Item 5 is flatly false. For example, TypeScript is itself written in TypeScript and there is not a class in the entire code base - it is 100% idiomatic functional JS. By contrast, Flow is not self-hosted. - Regarding item 6, TypeScript is the poster child for the new Microsoft. It has been open source (Apache 2.0) and cross platform from its original release in 2012. And regardless of what happens with TypeScript (I forsee it tracking ECMAScript standards for the next several years at a bare minimum), the emitted JS is basically identical to your TypeScript code (minus the annotations) so worst case scenario if Microsoft somehow magically deleted all copies of TypeScript in the world, you'd just keep going with the ES6+ code you have.
scrollaway 10y ago
Less engineering, more practical question: What's your setup? I see vscode screenshots, care to share your typescript config and preferences? :)
- ojkwon 10y ago
  It does have a small additional own flavor of configuration, but basically, it's nearly identical to some of OSS project written in typescript, like RxJS (https://github.com/ReactiveX/rxjs/blob/master/tsconfig.json https://github.com/ReactiveX/rxjs/blob/master/tsconfig.json / https://github.com/ReactiveX/rxjs/blob/master/tslint.json https://github.com/ReactiveX/rxjs/blob/master/tslint.json) cause basically it just inherited those configurations. For VS code preferences, there isn't one unified one but just leave each individual picks configs based on own preferences.
ArchReaper 10y ago
There was a big discussion on Electron today here - https://news.ycombinator.com/item?id=14087381 https://news.ycombinator.com/item?id=14087381 One of the points was talking about React Native vs Electron. What are your thoughts? Why did you guys go with Electron?
- cwyers 10y ago
  Isn't Slack older than React Native for platforms outside of iOS?
35bge57dtjku 10y ago
Have you tried ScalaJs? Typescript seems like a better alternative to plain Js, but still seems pretty lacking. For example, the standard libraries are so much nicer than what TS or Javascript offer.
- kornish 10y ago
  My suspicion is that the ease of porting an existing JS codebase to Typescript is an order of magnitude easier than rewriting it in Scala, even if the eventual benefit is higher.
  - ludicast 10y ago
    I think scala.js is having better integration these days (due to typings etc.) But still not 100%. But I would switch to all-scala if it ever had a dev-friendly 100% integration strategy.
    - 35bge57dtjku 10y ago
      What do you mean by that? It's had the ability for a while now to easily specify types for external js code and call js code.
      - ludicast 10y ago
        I'll have to reexamine then. Last I saw the typings story wasn't well documented but would be beyond overjoyed to be wrong.
- abiox 10y ago
  or Fable, or PureScript, or Kotlin... :)
  - Rapzid 10y ago
    Fable has such potential. F# is fantastic and I could totally get behind that as a TypeScript alternative under the right circumstances.
groovypuppy 10y ago
Hey Felix, was Dart ever in consideration? I use both TS & Dart (I'm on a TS project currently) but I find Dart so much cleaner but the JS code it generates is very hairy. Thoughts?
- felixrieseberg 10y ago
  I personally haven't spent too much time looking at Dart, but I find it pretty suspicious that TypeScript is on Google's list of approved languages for projects, while Dart is interestingly missing. I'm sure there's upsides to Dart, but I would certainly need to spend more time with it to make a judgement call. https://www.reddit.com/r/programming/comments/64e6x7/typescript_got_approved_as_internal_development/ https://www.reddit.com/r/programming/comments/64e6x7/typescr...
  - floitsch 10y ago
    Dart is doing fine inside Google. It is used by extremely important projects, like, for example Adwords. These teams are very happy with it and have no intention of changing. Brad Green already posted a follow-up post on the omission of Dart on his slides: http://angularjs.blogspot.dk/2017/04/official-languages-at-google.html http://angularjs.blogspot.dk/2017/04/official-languages-at-g... (I work on Dart.)
    - felixrieseberg 10y ago
      Thanks for the update, good to know!
    - groovypuppy 10y ago
      Even though I work with Typescript daily, Typescript feels like a stop-gap measure until ES6 /ES.Next take hold. Dart feels like the future - given Fuchsia + Flutter + Android apps in Chrome, etc. - if they can just work out some of the rough edges(e.g. isolates with Flutter) and make it more harmonious with JS/DOM - let's face it: We are stuck with the JS/HTML/CSS stack for the foreseeable future.
  - 10y ago
sydd 10y ago
> To improve our situation, we decided to give static type checking a shot. I wonder why it took you years to realize this. I'd never use a dynamically typed language for more than a few hundred lines of code, it becomes an unmaintainable mess afterwards. So serious question: Why?
- azrazalea 10y ago
  In case you are wondering about the downvotes: There are millions(trillions?) of lines of code out there that is maintainable and dynamically typed.
  - jiaweihli 10y ago
    Maintainable, but at what cost? A large chunk of unit tests for dynamically typed code is dedicated to checking types.
- felixrieseberg 10y ago
  It's probably worth pointing out that Slack _also_ contains a ton of native code, written in C++ (with a bit of C++/CX and Objective-C). All of us on our small team have an extensive background in typed languages, including giant code bases (Windows, for example). We just also happen to really like JavaScript, feeling that it and the ecosystem around us makes us more productive given our needs. TypeScript a few years ago was simply not good enough, and neither were the alternatives. It's okay if you feel otherwise, but trust that there are quite a few developers out there who are comfortable with building and maintaining rather large JavaScript codebases, building pretty impressive applications with it. This post isn't yet another "JavaScript is terrible" rant, I quite like it.
- dilap 10y ago
  I'm right there with you, but dynamically-typed languages still have their advocates (though it seems they're losing out more recently). (I think this is because a lot of the advantages associated with dynamic typing were in fact portable back to statically typed languages. If you're comparing C++98 to Python, the dynamically typed language seems pretty nice. If you're comparing Javascript to Golang or TypeScript, not so much.)
seattle_spring 10y ago
Is the article's hero picture (the Seattle skyline) a hint that you'll be opening an office here soon?
- felixrieseberg 10y ago
  Sorry, I just chose the image because TypeScript's official hero image is a Seattle skyline. I hope I didn't disappoint - I love Seattle though, I can't wait to be back this year for //build.
  - seattle_spring 10y ago
    No worries, was mostly joking! I have a good friend at the SF office and hope to one day work with her again. That can only happen if your team opens some offices up here in the Emerald City :)
z3t4 10y ago
It would be interesting to see examples of bugs you found.

vmasto 10y ago

Although I don't use TypeScript (I'm looking at Flow more and more recently instead) I have to acknowledge Microsoft's huge contribution to the JS scene (and not only) with TS and VSCode, truly exceptional products. What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). It's also quite amusing that this article came out today where HN's top article for a few hours was a bashing against Electron (and Slack specifically).

djtriptych 10y ago
And AJAX :) I'm also really hoping that the current crop of JS programmers learn event-driven / reactive style programming, and for that, RX is probably the best JS library out.
- zghst 10y ago
  I spent a lot of the earlier parts of my life hating MS, however later after working at a .NET shop and with the late developments at the company, my love for MS is becoming near-infinite. Reactive is definitely the way to go
  - mmgutz 10y ago
    It's strange but I went the other way. I started hating MS because of working in .NET. Basically, if something wasn't blessed by MS, it wasn't used. There were open source MVC projects but since MS only blessed ASP.NET forms back then, you couldn't convince managers to use MVC. Same with IoC. Same with ORMs I do like the new Microsoft. VS.Code is hands down the best all-around editor right now. TypeScript is awesome sauce.
    - bobwaycott 10y ago
      I started here, too. First production app was an early C# ASP.NET OSHA safety management and training platform for Mohawk carpets, built from the ground up back in 2007-08. Experienced all these headaches. Next major project was Python-based. Never went back to .NET.

ng12 10y ago

Typescript's single biggest win for me is the ability to provide type definitions for my models. This is where the vast majority of my JS bugs come from -- somebody trying to access a nonexistent property of some object (or, if it does exist, incorrectly assuming the type) which was serialized from JSON. Better yet, if you write your back-end in Node you can use the same models in your rest endpoint. It's a huge boost to both maintainability and developer productivity. However, my biggest frustration with Typescript is the general unreliability of @types. The odds that a given set of typings are complete, correct, and up-to-date are basically nil -- even for some relatively popular projects. Sad to say I've become an expert in Typescript's crazy module augmentation nonsense. Hopefully more big players like Slack contributing to DT will help.

whatever_dude 10y ago
In my ideal world, every library would be written in TypeScript and therefore benefit from their automatic type definition output, shipped as an invisible part of their npm package.
rattray 10y ago
For anyone unfamiliar: DT is "DefinitelyTyped", a github repo that consolidates type declaration files for open-source packages on npm. Ironically, given the above comment, its tagline is: > The repository for high quality TypeScript type definitions. (emphasis theirs) https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped
sadlion 10y ago
How does one validate typescript models at runtime? I have seen combinations of JSON schema and validator libraries but I'd love to do it using typescript's type system. From my understanding, it doesn't work because of type erasure.
- ng12 10y ago
  AFAIK there's no good solution. That's why it works best when your back end is using Typescript as well -- your route returns the same interface the client is expecting.

throw5938 10y ago

Seems like Apple needs to disincentivize the use of Electron and other user hostile technologies somehow before anything will change. They also need to crackdown on the Facebook app. http://blog.timac.org/?p=1707 http://blog.timac.org/?p=1707

Androider 10y ago

Question for TypeScript users from someone who's still on the fence: Are you at all worried that TS will end up like CoffeeScript? That is, it starts out with some great ideas that are quite easy to get behind, but JavaScript keeps on advancing year after year and soon you have the same features available but with an annoyingly different syntax, or you actually end up falling behind the curve. You're also not able to simply use the latest JS features, my last attempt at adopting TS died when I found it didn't at the time support object rest and spread properties, which I had been liberally using via Babel for quite some time. It seems like Flow is a "safer" choice to me, but I'd love to hear if you disagree.

deleted 10y ago
[deleted]
Strom 10y ago
The TypeScript team has a goal of keeping it a superset of JavaScript. This means that when JavaScript gets some new features, TypeScript also supports that. If TypeScript supported it before with some other syntax, the syntax gets changed. [1] The hero feature of TypeScript, static typing, will never be available in pure JavaScript based on any current prophecies. -- [1] One reason the object spread/rest situation took so long was because they didn't want to implement it and then have to change the syntax/meaning later. It's better to wait until new proposals have gotten a decent amount of progress, so that they're fairly stable. Do note that spread/rest still isn't in the JavaScript standard, it's a proposal.
- sixdimensional 10y ago
  Side related question- has this going outside of standards with such things as Typescript been harmful? I mean, standards move slowly, but your question raises an interesting point - why didn't we just extend actual Javascript to have typing supported? Have we given up on advancing the core language in such regards?
  - WorldMaker 10y ago

mi100hael 10y ago

Slack & its use of JS are sure getting a lot of attention on the front page of HN today...

blauditore 10y ago

The article mentions multi-threaded desktop applications along with JS. Since JS is inherently single-threaded, what does that mean? Do they actually refer to multiple processes or some other magic?

chickenfries 10y ago
JavaScript doesn't really have "threads" but node JS has it's `child_process` module and the browser has web workers.
- blauditore 10y ago
  Yeah, but Node child processes are actually separate OS processes, which behave quite differently from threads (higher overhead to spawn, separate memory). The same goes for web workers; they're more like daemon processes than different threads. So I guess this was just poor terminology in the article, not any new magic... :)

anko 10y ago

one thing I wish typescript had was an ability mark typechecks as runtime. Commonly I'll have a nodejs express app which serves an api and i've love a easy way to validate an interface against the payload passed in. Maybe it would be as simple as a function JSON.parseWithChecking<User>(payload) or some annotation to get the interface reflected and passed into this function at runtime. It's normally always at deserialisation that this problem occurs.

dean177 10y ago
I do this with a custom jasmine matcher in integration tests, you provide the matcher with some objects (which all satisfy the type you are expecting) and the matcher tells you if the response satisfies the type. It's a bit rough around the edges, but has been very useful so far. I'd consider creating an npm module if there is interest.
whatever_dude 10y ago
Wouldn't it be better to use a JSON Schema validator in this case?
- anko 10y ago
  Then you're maintaining two definitions - typescript ones and json schema ones. But thanks for the idea :)
  - whatever_dude 10y ago
    Well, you could have one or the other and then just convert a schema to an Interface [1], or vice versa [2]. The reason I like schema-first is because a schema allows you to be way more strict about what's accepted in most cases, e.g. validating an entry via RegEx. It tends to make APIs safer and runtime errors more clear. [1] https://github.com/bcherny/json-schema-to-typescript https://github.com/bcherny/json-schema-to-typescript [2] https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema
  - gcanti 10y ago

ChicagoDave 10y ago

A slightly forked discussion, but having been in IT for over 30 years, I sense a theme... A long time ago, people argued over the merits of assembly versus C. After that, people argued over Pascal over C. Then BASIC caused all kinds of consternation. BASIC versus "structured programming" was a common argument. With BASIC, there was this sort of wildness to it that drove people crazy. (this should be sounding familiar) Then Visual Basic added structure (procedural at first, OO in .NET). Then JavaScript was added to browsers and everyone cried that it was too unstructured and "wild". Then Google Maps was released and JavaScript suddenly became popular. Then NodeJS solidified JS as a real solution. Now TypeScript comes along to make JS more "structured" and we have the same old arguments. Structure over low level unconstrained programming. The weird part (to me) is that each side garners the louder voice about every ten years. I'm pretty sure some new-fangled unstructured platform will arrive in 2020 that everyone will jump on and say is better. It offers freedom and the ability to sculpt a vision that the structured platforms don't. Am I right or am I right?

seanmcdirmid 10y ago
With TypeScript, it is more like opening up old wounds between structural and nominal subtyping. The error reporting one gets with structural subtyping are really chaotic. On the other hand, it really works when bolting a type system on top of Javascript.
krona 10y ago
One significant difference with the past examples you cite is that Typescript is gradually typed, so it's a false dichotomy you're presenting. Personally I think this is one of Typescript's biggest achievements, since the Typescript programmer gets to decide how structured their system should be.
- ChicagoDave 10y ago
  Maybe. But anecdotally I've heard from more than a few JS devs that they'd _never_ learn TypeScript because it adds structure they don't feel is necessary and that just following ES6 is good enough.

vinhboy 10y ago

> he did not expect how far the Slack Desktop App would take his invention Kind of funny to read this article, after just reading that Electron article.

LeoNatan25 10y ago

> TypeScript at Slack > Or, How I Learned to Stop Worrying & Trust the Compiler So revolutionary. Who knew that compiling code has advantages over interpreted scripts.

iends 10y ago
I'm not sure what you're trying to convey. Most/All? modern JavaScript engines compile JavaScript (including v8).
- dimgl 10y ago
  lolwat?
  - chillacy 10y ago
    I think the parent is referring to JIT Compilation as a type of "compilation" as opposed to being interpreted. Of course the original post is tackling the type-safe aspect of compiling vs performance.
- __float 10y ago
  But you still have to actually run the code to find a lot of problems you can find in TS at "compile" time.
revmoo 10y ago
Why is there no downvote on here

jondubois 10y ago

I do not particularly like TypeScript because: - It adds complexity and unnecessary dependencies to the project and this makes it more brittle and more difficult to set up and get running (I often run into issues with it). - Slows down your debug cycle (it typically takes at least 15 seconds to compile for a small project) so you can't test your assumptions quickly as you would with plain JS - You have to wait all the time and try not to get distracted. - For an experienced JS developer like me, the vast majority of errors raised by the compiler are pedantic and not related to any real logical flaws - I spend a lot of time catering to the fussiness of the compiler instead of thinking purely about logic. - Working with legacy JS libraries is a pain. I will admit though that being able to look up references and usages of various classes and functions without having to leave the IDE is a nice feature - I don't really need it though because I got used to searching through my code with text-matching (sift) and by adhering to a proper source directory structure.

parent5446 10y ago
Surprisingly I have not run into those compile time issues. Maybe it's just my company's own infrastructure, but our TS projects, which can get rather large, all recompile in less than five seconds.
- jondubois 10y ago
  Yeah I'm not sure why it takes so long for me. We're using Angular 2.
ludicast 10y ago
My compile time is very fast (near instant), but I split up my projects into a zillion private modules. Adds some complexity but great for tdd. TS has been worth it to me, even if once in a while the compiler is too fussy like you say.
anko 10y ago
total side point, but did you know in visual studio code you can enable "editor.codelens" and it will show class references in javascript above the declaration - no typescript required.

tabeth 10y ago

I haven't used TypeScript yet, but it seems like it's similar to a pattern I sometimes use, like the following: function foo(a, b, c) { g.param(String, a); g.param(Object, b); g.param(XMLHttpRequest, c); /* stuff */ g.return(String, bar); } Seems like the main benefit to using TypeScript is that it can tell you if you have poor types during "compile" time, right? I guess the question for me is, is TypeScript superior than the above pattern?

chillacy 10y ago
Autocomplete is a big productivity boost too: VS Code will suggest methods on the object, then tell you exactly what arguments it takes and what types they all are. Of course maybe you can have another system which reads in the code you have and autocompletes for you too.. after all, the type info is all there, it's just in a different place. Compared to everything in the function definition: function foo(a: string, b: object, c: XMLHttpRequest): string
to3m 10y ago
Yes, because it will check for you before you run the code, and you can be certain as you can be about anything that no case was missed.

revmoo 10y ago

> First, we were surprised by the number of small bugs we found when converting our code. Talking to other developers who began using a type checker, we were delighted to hear that this was a common experience: the more lines of code a human writes, the more inevitable it becomes to misspell a property, assume the parent of a nested object to always exist, or to use a non-standard error object. Howwwwwww?? How does your app work with these sorts of bugs existing in the code without anybody noticing?

iamwil 10y ago

After using types in Elm, types in Typescript have felt like a step backwards.

deleted 10y ago
[deleted]
bbcbasic 10y ago
After using types in Haskell, types in Elm also feel like a step backwards.
- KurtMueller 10y ago
  If you're starting from JS, going to Elm and then to Haskell are two steps forward :).
- weavie 10y ago
  After using types in Idris, types in Haskell feel like a step backwards...
  - bbcbasic 10y ago
    A nice poset developing here.
KurtMueller 10y ago
I agree completely. If you enjoy Typescript, why not just go whole hog and go with Elm, F# and Fable, ReasonML, or even Purescript.
mambodog 10y ago
Coming from Javascript, Typescript and Flow have huge benefits which a much smaller learning curve than going straight to Elm. I recommend people who don't have experience with static types start with one of those two.
- iamwil 10y ago

rdiddly 10y ago

I've been working in this kind of environment with strongly typed languages for a long time, but TypeScript might be the thing that gets me to go back & give JS another chance. Funny to be coming at it the other way!

ken47 10y ago

Typescript is GREAT. Strict null-checking eliminates the dreaded null-pointer exception. It enables type-safe mixins. It allows for mapped types. Literal types, especially string literal types, makes it so easy to work with pre-existing JS libraries. The way I look at Typescript vs. Javascript is that with Typescript, it's like having always having a pair programming buddy (the compiler) who never makes mistakes.

kough 10y ago
What exactly do you mean by "null-pointer exception"?
- Dru89 10y ago
  He's referring to the dereference of a null object. For instance, calling "foo.bar" when foo is null (or potentially undefined).
yoklov 10y ago
> Strict null-checking eliminates the dreaded null-pointer exception When I was using typescript this still came up if you missed an array bounds check, you'd end up with an unexpected undefined. Pretty annoying and tough to debug. Has this changed (I can't see how it could have, but... maybe?)
- curveship 10y ago
  Sort of. Strict null checking now lets you distinguish between the types Foo[] and (Foo | undefined)[]. The first will type with the assumption that there are no out of bounds indices (which, as you say, could be wrong). The second will require you to always check the result of array dereferences to see if they're undefined before you reference the object. var foos1 = [] as Foo[], foos2 = [] as (Foo | undefined)[]; // ... later var foo1 = foos1[i], foo2 = foos2[i]; foo1.bar(); // types fine, TS assumes non-undefined foo2.bar(); // TS type error, as you haven't checked undef if (foo2) foo2.bar(); // types fine, undef excluded

msie 10y ago

The more code is in TS, the easier it is to write tools to manage that code.

deleted 10y ago

[deleted]

nathan_f77 10y ago

Where can I find a good list of pros and cons for Flow and TypeScript? I've been really enjoying Flow, and I have experienced all of the benefits mentioned in this article. I'm using VSCode, and the Flow integration is really good. Feels like a full IDE for Javascript, without being bloated and slow. (Startup is a little slower than Sublime, but it's very fast once everything has loaded.) I'm wondering if I'm missing out on anything by choosing Flow instead of Typescript. I've been developing React and React Native apps, and it seems like Flow is the default choice for that ecosystem. Has anyone switched from Flow to Typescript, and how did it go?

vanwalj 10y ago
Having experience with both on Node back-end projects, I can tell you than IMHO Flow is smarter, especially on union types, BUT there are way more TS community type definitions available right now.
- johnfn 10y ago
  I'd be curious in which ways flow is more intelligent than TS.
  - boubiyeah 10y ago
    Me too. I don't really see how you can get any smarter with union types than with TS 2.2+
  - vanwalj 10y ago
    Here are some examples: TS: https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%7B%0D%0A%20%20%20%20valA%3A%20string%0D%0A%7D%0D%0A%0D%0Atype%20TB%20%3D%20%7B%0D%0A%20%20%20%20valB%3A%20string%0D%0A%7D%0D%0A%0D%0Atype%20TAorTB%20%3D%20TA%20%7C%20TB%0D%0A%0D%0Afunction%20isTA(x%3A%20any)%3A%20x%20is%20TA%20%7B%0D%0A%20%20%20%20return%20x.valA%0D%0A%7D%0D%0A%0D%0Afunction%20func%20(param%3A%20TAorTB)%20%7B%0D%0A%20%20%20%20if%20(isTA(param))%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log('This%20is%20IA')%0D%0A%20%20%20%20%7D%20else%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log('This%20is%20IB')%0D%0A%20%20%20%20%7D%0D%0A%7D https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%... Flow: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmALxgDeqYtYAbgIYzEBcYAzhgE4CWAdgHNUAX3TZ8RAELkqNOkxhT2XPkNHjcBYnG4yKJMAB9p6KAFd+AYwy84-MBetgAFDkbdGAW3Y69ASjk6MF4oV3dPLwA6RWJA6mDgq3sOOBg8KPhBFwByABUAC14OEJKSHP95WhEwPBgOAgTE2mT+VPTMuGz8opLi6QqqsDExIA https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmA... With Typescript, you have to write custom Type Guards functions, whereas Flow is smart enough to infer type

deleted 10y ago

[deleted]

z3t4 10y ago

I'm a strong opponent against type annotations in JavaScript. JavaScript only have a few types: strings, numbers, boolean, null, undefined, and Symbol (ES6). And annotating them feels stupid. Feel free to use Flow, Typescript et.al. but let the type inferencer do the work, not you. You should only have to think about the abstract meaning of the code. And pick good names for variables and functions. In order to catch more parameter errors, your functions should throw errors if the parameters are incorrect!

boubiyeah 10y ago

Typescript is a truly great project, I'm not sure many people understand the amount of work that has gone into this compiler. They have the crazy constraint of being 100% compatible with Javascript, which is a bit broken by design and yet they managed to make it so much better to work with TS than with JS. After trying Flow numerous times, I came to the conclusion it simply can't compete with the power of the team Microsoft put together. Even their alpha versions are stable enough to be used in production. Some advices: - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. - Use a noAny tslint rule. disable it on a case by case basis, only in util code. Most of the time, any is not necessary, often you can use {} or Object instead. - You can get away with just using undefined everywhere, null adds no value. - Use union types. Make impossible data combinations impossible to write! Example: export type RemoteData<D, E> = NotAsked | Loading | Refreshing<D> | Success<D> | Failure<E>

mercer 10y ago
> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. This is exactly what I did and it's the main reason I keep dropping TypeScript because I 'need to get shit done'! It's good advice though, and I would definitely advise new TypeScript users (especially those unfamiliar with type systems) to at least try it. But if it results in giving up and going back to just js, it might be worth going with the 'barely better' approach and only enable those flags if you're more comfortable with TypeScript.
- ash 10y ago
  strictNullChecks errors are easy to fix: 1. Add `| null` or `?` for things that could be null/undefined. 2. Start handling "is this thing null?" cases. In some occasions it could be annoying. E.g. when you are absolutely sure it's not null. E.g. in tests. TypeScript provides `!` operator for that: interface Baz { foo?: string; } let bar = (t: Baz) => // yes, I'm sure t.foo!.length; https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#non-null-assertion-operator https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

misotaur 10y ago

Is Typescript already supported on most browsers or do I need to install a library?

whatever_dude 10y ago
Typescript doesn't need browser support, it's transpiled as JavaScript.

uranian 10y ago

I really don't understand why some developers are so happy with Typescript. Javascript was already years ago highly improved with transpilers like Coffeescript, Livescript etc.. IMHO this whole Babel, ES5, ES6, ES7, ES???, Typescript thing with it's countless options is much worse than simply Coffeescript with a dynamic type checker. I use the latter in quite some production environments currently. No need for Babel, Typescript, linters etc.. It really makes my life way, way easier, less npm modules, less bugs, less lines of code, much more readable, etc, etc.. And please, before you start preaching all those 'amazing' benefits of Babel, Typescript, linters, ES5, ES6, ESx, I come from that misery and it sucks!

kgabis 10y ago
Would you rather have your program fail at runtime instead of using a statically typed language? It really baffles me why so many people prefer dynamically typed languages and write large projects in them.
- uranian 10y ago
  My apps don't fail at runtime because of type errors, at least, not that I remember. It really baffles me how many people need Typescript to avoid having type errors at runtime, what the hack are they doing wrong then? This is not C++, we only have a few types in JS, really hard to mess up for me.
  - kgabis 10y ago
    Are you serious? You can define custom types in javascript, nobody programs using only primitives like strings, numbers and booleans.
choward 10y ago
What exactly does coffeescript buy you besides the sugar? How does it prevent bugs?
- uranian 10y ago

renlinx 10y ago

Instead of wasting time on this, try to understand javascript, Why slack web app & desktop app(electron) is taking too much cpu & memory, it will help you...

pacoverdi 10y ago

I have become a create-react-app junkie but unfortunately TS is still not (officially) supported in it [1] so for the moment I stick to using flowtype. [1] https://github.com/facebookincubator/create-react-app/issues/142 https://github.com/facebookincubator/create-react-app/issues...

jacobr 10y ago

Last time I tried TypeScript we ended up abandoning it after having mismatches between dependencies and TS definitions. We had to postpone upgrading libraries to wait for definition updates or write and maintain them ourselves. This was in the early stage of a project though, we needed to get a quick first version out in 2 weeks and it just wasn't worth the hassle. Has this situation improved - I understand typings are no longer installed with a 3rd party tool/registry?

simooooo 10y ago
They aren't? How does it validate the code without typings for everything
Ciantic 10y ago
There is one significant change with TS 2.2, you don't have to use type definitions for libraries anymore. Since all JavaScript is valid TypeScript. With out of the box setup the import from library that has no type definitions, works just fine. It returns `any` type, so you can use all libraries just like you would in JavaScript. So if you ram your head against bad type definition of a module, just delete it and continue using it like you would in normal JS.