20 ms·

Why We Chose Typescript

• paulborza 9y ago
  TypeScript is an excellent language.
  • tkubacki 9y ago
    No it's not. It has all JS flaws - it's just better than js and it's easy to use it with js. Otherwise Dart would win.
    • bcherny 9y ago
      Like what? TypeScript is careful to avoid a lot of JS's footguns (implicits, undefineds, etc.)
      • tkubacki 9y ago
        TS has nice features to avoid js bombs but all JS 'bad code' is legit by definition (JS superset). TS is super nice compared to JS but it is NOT excellent Lang.
        • johnfn 9y ago
          > all JS 'bad code' is legit by definition (JS superset) That's not true. There's a lot of JS code out there that is certainly not legit in TS. Probably the shortest example is `1 === "a"` which produces a TypeError, but if you use TS at all you'll understand that a lot of bad patterns are made painful or impossible thanks to the strict type system.
      • legulere 9y ago
        == versus === and all the other weak typing wats, undefined type still exists in typescript, no integer type, UTF16 strings are the ones coming to my mind and I don't even program in JS/TS
        • johnfn 9y ago
          I'm pretty sure all weak typing warts basically stem from equality checks with ==/===. If you use === all the time you'll never run into them. TS has optionals so undefined is not an issue. The rest is valid.
          • legulere 9y ago
            There are also some JavaScript functions like isNaN that also do type coercion and of course +. How is this handled in typescript?
            • nycdotnet 9y ago
              In a word, "correctly". The result of an expression with + or isNaN() will be of whatever type the JS spec says it should be. This is one of the less frequently touted, but more useful aspects of TypeScript - the lib.d.ts file acts as a partner to explain to you how the built-in JS type system actually works without you having to memorize or look up everything in docs.
          • bcherny 9y ago
            By optionals I assume you mean null and undefined types, not optionals in the Scala or Swift sense.
        • bcherny 9y ago
          For == vs === use a linter, same as you would for warts in other languages. What's the issue with undefined - is it that you would use null instead? I don't feel a need for integer type, but maybe that's because I grew up on JS. Integers feel like warts to me in a lot of cases, ie why would 2/3 == 1?
          • ridiculous_fish 9y ago
            2/3 === .666666666666666629659232512495 is probably worse, because it can seduce you into thinking it's accurate. Why is `2 / 3 * 3 === 3`, but `1 / 3 * 3 < 3`? JS's floating-point-or-bust, combined with some weird Math semantics, makes it challenging to write numerically correct functions.
      • ridiculous_fish 9y ago
        TypeScript addresses many of JavaScript's type-related issues but retains other JavaScript insanity: bizarre array semantics, Unicode ignorance, no integer arithmetic, regex facepalms, Math weirdness, etc.
        • bcherny 9y ago
          What do you mean by bizarre array semantics? Genuinely curious.
          • ridiculous_fish 9y ago
            Oh man, how much time do you have... The root of the wtf is how Arrays play double-duty as both indexed and associative. The ES spec says that if you modify a property of an array object, the implementation must check if the (necessarily String) key changes after being round-tripped through a UInt32 conversion. If not, the key is a special array index that bumps the length; otherwise the length is unaffected. var arr1 = []; arr1[2147483648]=1; // arr1.length == 0 var arr2 = []; arr2[2147483647]=1; // arr2.length == 2147483648 var arr3 = []; arr3[-1]=1; // arr3.length == 0 Of course strings participate in this nonsense: var arr = []; arr["12345"] = 1; // arr.length == 123456 This is JavaScript so naturally .length is settable: var arr = []; arr.length = 3; // works! But implementations are still required to distinguish between keys that are undefined and keys that outright don't exist: var arr = []; arr.length = 3; arr[0] = arr[2] = undefined; for (key in arr) print(key); // 0, 2 And of course you can set whatever random associative array property you like: var arr = []; arr[1] = true; arr[3.5] = false; // "works", .length is still 2 The intent is that array implementations may use efficient unboxed contiguous storage, but the spec requires that arrays may be sparse so it's still necessary to track which keys are actually set even if values are undefined. Want to iterate an array's keys? There's no requirement that array indexes start at 0, and you may encounter random other keys from the array prototype. TypedArrays are more limited/sane, thankfully.
            • int_19h 9y ago
              Every time I see something like this, I stop and consider just how saner Lua is, even though in many ways it adopted similar approaches (e.g. associative arrays doubling as regular ones).
    • mixedCase 9y ago
      I don't see how Dart wins at anything, really. It's an extremely conservative language, offering little to nothing interesting that would make anyone switch from other solutions. The ecosystem doesn't help it either: For the frontend, it's stuck in a middle ground where it requires a JS interop layer (unlike TS, where it's typings are just an extra) but doesn't offer anything significant like Elm, BuckleScript, F#, ClojureScript and so many other great languages do when it comes to expresiveness. It doesn't even have algebraic data types, something TS does. For the backend, it competes against almost all the frontend languages (due to node or native) as well as the big boys with huge ecosystems, variety of paradigms and amazing performance. For mobile it has Flutter, which competes with Xamarin, Kivy, Qt and other bring-your-own-widgets solutions (deal-breaker for some apps and teams). In this case, Flutter is something I wanted to try out since those other solutions left me wanting and so did React Native, but Dart being such a lackluster language completely put me off of it, now having to turn to native with Kotlin after all this time looking at (and somewhat helping develop) the x-plat ecosystem. I don't doubt that Dart will remain healthy for a long time due to Google's investment in it, but honestly, even if Fuchsia ends up being Android's succesor and Flutter ends up as its graphical toolkit, I'd instantly start looking for languages targeting the Dart VM or native interop.
      • chrisweekly 9y ago
        > "other solutions left me wanting and so did React Native" Could you please give specific examples of where you felt RN let you down? (Also, did you use Expo or vanilla RN?) Thanks
        • mixedCase 9y ago
          The three biggest issues I have with it are these: 1) Language. Elm has set the standard for web languages and after using it for a while, JS or many of the popular replacements such as TypeScript are plain insufficient when it comes to providing as many compile-time safety guarantees. Doesn't help that I'm getting into Idris and even Elm's shoes are starting to feel a little too tight. There's a project to write Elm and target React Native, but it's still too immature and it makes the next two issues worse. I've yet to look at RN development through a BuckleScript stack, so that may be an acceptable alternative (even if not as safe as Elm, but on par/better than Kotlin)... but won't help at all with the next point. 2) Requires very complex tooling. This complexity will rear its ugly head when doing anything slightly out of the ordinary. All solutions (including Expo) I've seen seem to suffer from that issue, just with different defaults and different amounts of work necessary for different tasks. I am not oblivious to why this is, since RN is not only based around the JS ecosystem and all the insanity that comes with it, it also has to deal with being a fat abstraction over native rather than take the easy way out, rolling its own cross-plat rendering and give up native widgets. 3) While it has come a long, long way, performance on old Android devices is still not always as smooth as native. I'm not sure how much this can realistically be improved since the bottleneck is interop, and avoiding it or shifting work around between native and JS is just not something I want to worry about. However, this third point has improved so much I'm ready to handwave it away if the former two weren't a thing. Lastly, not an issue with React Native itself, but JetBrains absolutely has the intention to bite into iOS' territory with Kotlin Native... and assuming they can pull off a half-decent adaptation of Apple's APIs I'm betting they will be the ones to finally take the x-plat cake, which makes it hard for me to believe investing time and code into RN solutions is a better proposition than native. Hope that was useful in some way. If I should clarify anything or I have any misconception about RN please let me know.
    • TheAceOfHearts 9y ago
      I've been digging a bit into Dart as I've read through Fuchsia's docs and poking around with the source. It looks like a great language, but I think it hasn't done well on the web because it has very poor interop capabilities with JavaScript and its ecosystem. I'll note that I haven't dug that deeply into Dart, so maybe there's some great resources I've simply missed so far. TypeScript and Flow are both great options because they work completely with existing codebases. They can be adopted gradually and integrate well with the ecosystem. Another language that looks promising is Reason [0]. It's still very young, but they seem to be working hard to create an awesome language with a great interop story. Check out their getting started [1] guide. Most of the info related their interop is in the BuckleScript User Manual [2]. [0] https://facebook.github.io/reason/index.html https://facebook.github.io/reason/index.html [1] https://facebook.github.io/reason/gettingStarted.html#javascript-workflow https://facebook.github.io/reason/gettingStarted.html#javasc... [2] http://bucklescript.github.io/bucklescript/Manual.html http://bucklescript.github.io/bucklescript/Manual.html
  • smithkl42 9y ago
    I've been using TS since it's .8 days, and love it - but I think it's stretching things to say that it's an excellent language. It's a pragmatic language that makes JavaScript (which is an awful language) tolerable.
• dcgudeman 9y ago
  I would like to know if they are moving towards a SPA architecture and, if so, what framework they will be using.
  • underwater 9y ago
    The mobile experience is a single page app. It's not very good.
    • KingMob 9y ago
      If you land on the desktop site, it consistently pushes you to download the app, and buries the mobile link.
      • h_r 9y ago
        It is an incredibly ham-handed way to try to push people into the app. Extremely irritating.
    • tspike 9y ago
      Agreed. I don't see the use case for Reddit to be a SPA. Given that it's a list of documents linked together, I can't see a better use case for a plain old static hypertext document.
  • colonelxc 9y ago
    The mobile site seems to already be a SPA. Clicking on comments or the next page button shows a loading image, while the top header sticks around.
    • ajacksified 9y ago
      https://github.com/reddit/reddit-mobile https://github.com/reddit/reddit-mobile - React / Node.
  • Deimorz 9y ago
    Yes, using React. You can see what they're moving towards on the new profile pages like https://www.reddit.com/user/kn0thing https://www.reddit.com/user/kn0thing
• revelation 9y ago
  "We picked Typescript because this is what we feel everyone else is using and wow are we late to this party" Take nothing away from TS but the mobile Reddit is all the proof in the world that no matter the language, the paradigm or the ecosystem, someone can still use it to turn out a horrible product.
  • SquareWheel 9y ago
    Using quotation marks with false quotes is a pet peeve of mine. It misleads the reader, and is essentially admitting to setting up a strawman.
    • deleted 9y ago
      [deleted]
• deleted 9y ago
  [deleted]
• slimsag 9y ago
  > Should work on both the client and the server. SEO is very important to Reddit, so lack of universal rendering is a deal breaker. Are client-side only JavaScript applications not handled well by the likes of Google et. al. today? I was under the impression that they run a full JS interpreter.
  • shados 9y ago
    Its still nowhere as accurate nor as good SEO wise. It means you don't get zero SEO, but if you want to be at the top, you want to do everything you can.
  • mrdmnd 9y ago
    https://www.stephanboyer.com/post/122/does-google-execute-javascript https://www.stephanboyer.com/post/122/does-google-execute-ja...
  • fooey 9y ago
    Even if/when google can spider it, other spiders can't, and social sharing tools like Facebook and Twitter can't
• tqkxzugoaupvwqr 9y ago
  > Using a typed language in our frontend has already paid dividends: our code has fewer type-related bugs, we are more confident making large refactors, and our inline documentation is focused around concepts instead of object shapes and function parameters. Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible.
  • TekMol 9y ago
    Dynamically typed languages for large code bases are terrible The success of Wikipedia, Wordpress, Facebook, Youtube, GitHub etc etc etc and last but not least Reddit seem to prove otherwise.
    • minitech 9y ago
      > seem to prove otherwise Prove how? They could have succeeded in spite of dynamic typing, not because of it. Facebook defined a new programming language to add static typing to HHVM. The process of plugging into WordPress is infamous in its disorganization. There’s a lack of good statically-typed languages, so it’s natural for many popular things to be built in dynamically-typed ones, but that doesn’t make the dynamic typing approach better.
      • TekMol 9y ago
        Prove how? By means of natural selection. They could have succeeded in spite of dynamic typing, not because of it. You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job? Facebook defined a new programming language No, they wrote a faster runtime. to add static typing to HHVM No, they added type annotations. There’s a lack of good statically-typed languages No, in the past statically typed languages were the norm. C, C++, Java... It's just that dynamic languages outcompeted them.
        • minitech 9y ago
• TheAceOfHearts 9y ago
  If you want runtime assertions with flow you can use flow-runtime [0]. Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript. I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that. [0] https://codemix.github.io/flow-runtime/#/ https://codemix.github.io/flow-runtime/#/ [1] https://github.com/babel/babylon/pull/523#issuecomment-311720960 https://github.com/babel/babylon/pull/523#issuecomment-31172...
  • gnarmis 9y ago
    Ah, useful things to know about! flow-typed does exist, so that's something. https://github.com/flowtype/flow-typed https://github.com/flowtype/flow-typed.
  • peteretep 9y ago
    TypeScript's IRC channel on Freenode is an amazing, supportive place, too. In sharp contrast to #gonuts, which is a cesspool.
  • hzoo 9y ago
    Yep, if anyone can/wants to help out with this effort I would follow/review the issues/PRs in our typescript label https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+label%3A%22area%3A+typescript%22 https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+lab... (I help with Babel). We'll be working with the TS team to definetely get some better docs on how to setup both Babel and TS once we land the changes in Babel and release 7.0
    • benjaminjackman 9y ago
      I was wondering does this make it possible to use proposals which have support in babel but not yet in typescript (e.g. do expression) when writing typescript?
  • 9y ago
• sushisource 9y ago
  Lord that font in the header image is disgusting. Who would want a faux-cursive programming font?
  • DonHopkins 9y ago
    I thought it was an adorable font that made the comments read light and whimsical, but then again I shipped a product that used Comic Sans as its main font.
  • LeoNatan25 9y ago
    Anyone knows what that font is?
    • _ar7 9y ago
      Operator mono I think. It costs a lot.
      • LeoNatan25 9y ago
        Thank you!
    • deleted 9y ago
      [deleted]
  • pikzen 9y ago
    It's actually pretty good. I have no idea how or why, but it's pleasant to the eye and very readable. ... It's probably not worth $200 though.
  • Houshalter 9y ago
    It looks like there are at least 2 different fonts there. With different fonts used for different parts of the syntax. Which actually seems like a good idea, to further visually distinguish different things beyond just color. But to work right you need to choose fonts that are very visually different.
    • 9y ago
• maxxxxx 9y ago
  I recently had to do some Node.js scripting. My JavaScript experience was minimal and having worked almost exclusively with typed languages I considered Typescript. I decided against it eventually because I figured you need to know JavaScript first to understand the JavaScript ecosystem even if you are writing your own code in TypeScript. Does this make sense or is it feasible to skip learning JavaScript and jump directly to TypeScript?
  • _ar7 9y ago
    Short answer is yes. TypeScript to JS is kinda like C++ to C. You can learn one before the other and a lot of the skills are transferable.
    • maxxxxx 9y ago
      I didn't expect TypeScript to be a problem. I was more worried about not understanding other code and libraries that are written in JavaScript style. It seems a lot of design patterns used in the JavaScript world make sense once you understand the strengths and weaknesses of JavaScript.
      • mercer 9y ago
        You'll need to understand JavaScript. One of the things I like about TypeScript is that it tries to 'fit' JavaScript, but the consequence is that you need to understand JavaScript to be proficient in TypeScript. That said, I suspect it won't be too difficult, and quite worth your while, to learn 'idiomatic JavaScript' if you have experience with at least one other language. And especially with ES6 (which is 'included' in TS), if you have any experience with Ruby or Python you'll be fine with JS and it might even be a relatively pleasant experience.
  • kevindqc 9y ago
    Typescript is very similar to ES6 (new JavaScript). You can probably learn both with TS. You might not learn the weird JS quirks if you have to go back to ES5 at some point though.
  • 9y ago
• tkubacki 9y ago
  Wondering why Dart was not considered. Large apps are written in it (Ad sense UI, Ad Words UI, Google CRM). Has good tooling (IntelliJ plugin, Webstorm). It's fairly easy to pick up - Java/C# like syntax. It's harder to shot yourself on your own foot (it's not JS superset). It has strong mode. It has superb tooling and package manager ( dartanalyzer, pub)
  • sim0n 9y ago
    Does any major tech company use Dart other than Google?
    • tkubacki 9y ago
      Well can't say if any of those are major - but here is a list https://www.dartlang.org/community/who-uses-dart https://www.dartlang.org/community/who-uses-dart
  • JeremyBanks 9y ago
    Dart is for Google, by Google, and external engagement has been as neglected as for all of Google's front end efforts. Google ceded the thought leader position in this area years ago and everybody knows better than to trust any of their new efforts.
    • tkubacki 9y ago
      So this is official reason why it was not considered ?
      • vmarsy 9y ago
        I don't know, but the reddit blog post says: > One of the worries we had with Flow was that it was built to solve specific needs at Facebook and that its future would be determined by that scope. if you replace [Flow/Facebook] with [Dart/Google] , I guess you could make the same point.
        • 9y ago
• dom96 9y ago
  As much as I am disappointed that Nim wasn't chosen, I am impressed that it was mentioned at all. Nim's JS backend is still rather young, and tooling is definitely lacking. But you can make some pretty cool things with it[1]. 1 - https://picheta.me/snake/ https://picheta.me/snake/
  • girvo 9y ago
    Yeah, I did a double take when I saw it on the list. We use Nim at my new work extensively for some back end stuff (mainly homomorphic encryption experiments, but a full implementation of Paillier is also in it!) and I've just started getting the team to leverage it for the front-end too :)
    • dom96 9y ago
      That's awesome. Can we expect a blog post from you about Nim in the near future? :)
      • girvo 9y ago
        Yep, especially because IBM just gave me a 20-core (8 hardware threads per core) POWER8 server with 256GB of RAM to run this stuff on, so I'm going to have a lot of fun getting Nim up and running on it!
        • dom96 9y ago
          Awesome! If you want it posted on nim-lang.org then just create a PR on the website[1] repo :) 1 - https://github.com/nim-lang/website https://github.com/nim-lang/website
• opvasger 9y ago
  I'm coming at this from the Elm-camp, and my first impression (and largely why I think languages like Elm is promising) is how languages that are implemented as supersets of other languages have the potential to be as bad as their subsets. The example that I was given was C++ and C, but I think TypeScript with it's gradual-typing approach is forced to remain potentially as bad as JavaScript itself - that is, if you're feeling weak and want to "get shit done", you can bypass all the goodness that TypeScript undeniably offers you. For a language like Elm, the type-system is invariably gonna have your back - a value-proposition I think means a lot more in practice than some self-proclaimed pragmatists realize :)
  • Gaelan 9y ago
    tsc --noImplicitAny solves that.
    • DanRosenwasser 9y ago
      Or to go all-in - we have a `--strict` flag that gives you `noImplicitAny`, `strictNullChecks`, `noImplicitThis`, and a mode that always puts you in `"use strict"` mode.
      • Gaelan 9y ago
        Ah, cool! The last major project I worked on in TS was still before null and this checking.
      • zumu 9y ago
        I don't understand why `strictNullChecks` is not the default behavior. It being a special compiler option makes me somewhat dubious of TypeScript in general.
        • Gaelan 9y ago
          Backwards compatibility.
    • aphexairlines 9y ago
• macmac 9y ago
  I would have more confidence in the list if they spelled ClojureScript correctly.
  • taspeotis 9y ago
    I suppose I'll piggy-back this off your comment, since mine doesn't really deserve to stand at the top level, but I am also surprised this blog post can't stylise TypeScript correctly...
• emilsedgh 9y ago
  I personally skipped Coffescript, Javascript Generators and Angular. And none of them passed the test of time. So I think I made the right call by not adopting them super early. I think I'm going to do the same with Typescript. Hopefully static typing will be adopted by ES.Next and then I'll port my programs to it.
  • nine_k 9y ago
    I wonder what are the chances of Typescript becoming (part of) ES.Next. It joins with plain JS as seamlessly as possible.
    • tycho01 9y ago
      See this thread: https://esdiscuss.org/topic/es8-proposal-optional-static-typing https://esdiscuss.org/topic/es8-proposal-optional-static-typ... Note that things have moved a bit, and we're now only a few standing proposals away from being able to properly infer the challenging functions mentioned there.
  • johnfn 9y ago
    Er, JS generators definitely did pass the test of time and are now part of modern JS.
    • dvlsg 9y ago
      In fact, they are how async / await is implemented.
    • 18nleung 9y ago
      With async/await there's not much of a case for their use anymore, though
      • AgentME 9y ago
        The regular generator use (return a lazily-evaluated iterator) still exists.
• iamleppert 9y ago
  From what I know of the Reddit community and their feedback on anything any of these "new devs" have done, it's not going to matter how pretty, well-typed or "scalable" (whatever that means) the code is. All the new product is just awful. I feel sorry for them.
• deleted 9y ago
  [deleted]
• peruvian 9y ago
  It's hard to take these kind of posts seriously when Reddit mobile site is one of the worst performing SPAs I've ever used.
  • founder_advice 9y ago
    What are your specific criticisms?
    • bcherny 9y ago
      On Chrome on iOS on iPhone 6, posts take too long to load, and having more than 3 gifs expanded at once crashes my browser. Also manual pagination instead of infinite scroll is a little annoying. Works very well otherwise.
    • andrewguenther 9y ago
      Personally, I find the entire experience to be incredibly slow. Loading the front page takes multiple seconds, there is a noticeable delay between tapping a link and any form of response, and back navigations are often unexpectedly slow. Non-SPA related, I also think that many of the touch targets are too small, or work in unexpected ways. Tapping a username collapses a comment, even though there's an arrow next to it. Tapping an image associated with a link doesn't follow the link, it expands the image (even if it is an article link). Tapping the title takes you to the comments, not the article. The only way to get to the content is to click the itty bitty domain title beneath the title. All of these behaviors are different than how the desktop view behaves. For a site that calls itself the front page of the internet, it's getting harder and harder to get to actual content.
      • haimez 9y ago
        Install the app! It solves these usability problems. No? ... waits 5 seconds... HEY INSTALL THE APP. HEY, HAVE YOU HEARD OF THE APP?
      • alanbernstein 9y ago
        That's funny. Reddit took over my [desktop] web surfing precisely because of how much faster/cleaner it is than any other comparable website. Beaten only by HN.
• bjterry 9y ago
  I recently moved to a company using Flow from one using TypeScript, and it seems like the tooling ecosystem for TypeScript is way better than flow. The emacs plugin for flow in particular is practically nonexistent, and doesn't even provide proper syntax highlighting. TypeScript's by contrast is amazing.
• lapsock 9y ago
  Buy why are you redesigning the site? It looks fine as it is. Let me guess some designer told you to redesign it in order to justify his paycheck.
• coldtea 9y ago
  >Should work on both the client and the server. SEO is very important to Reddit, so lack of universal rendering is a deal breaker. This sounds like a total non-sequitur.
• jondubois 9y ago
  I've worked with TypeScript on and off for a couple of years now. I don't like it. The compilation step is a major pain. Even after using it for several months straight, I feel like I'm in a constant battle with the compiler. It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time); you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome. I have gone back and forth from dynamically typed languages to statically typed languages many times for years and I've spoken with engineers who used to be Java developers for many years, then switched to Javascript, then TypeScript and they shared the same thoughts as I did. TypeScript is slow and restrictive in a way that is unnecessary. It's got Microsoft all over it. Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately. At my previous work, even developers who said that they liked TypeScript secretly didn't like it because they used the 'any' type Everywhere. I wonder if the people who are making this decision have actually tried TypeScript themselves for any decent amount of time on a decent sized project. I don't think they know what they're getting into. I decided not to renew a lucrative contract at a finance firm as a front-end developer in part because I did not enjoy using TypeScript every day.
  • DaiPlusPlus 9y ago
    What about using the TypeScript toolchain as a JavaScript static analyis tool without actually writing in TypeScript? (tsc can still verify your js files are minimally 'correct' through type-inference, for example).
    • deleted 9y ago
      [deleted]
  • Kiro 9y ago
    This is the first negative comment I've ever heard about TypeScript, which makes it really interesting. I thought it was all praise.
• erokar 9y ago
  The intellisense you get with TS is quite nice, as is improved refactoring. I also think typing in function signatures is a good thing and increases comprehension. But the type-safety you get with these kinds of static languages only catches a few trivial bugs. There are also some situations where TS complains where it shouldn't, for instance it doesn't handle JS' built in reduce function very well. In the end, it's a trade-off between the benefits and added costs. It is in no way a given that adding static typing to your JS project will be beneficial when all factors are considered.
  • jstimpfle 9y ago
    By contrast, does anybody think that having "stronger" dynamic typing (don't convert strings to numbers as implicitly, etc.) like Python's would not be a huge benefit?
    • mercer 9y ago
      That's actually one reason why I often opt for TS. While the 'stronger dynamic typing' isn't the most sexy benefit, it has saved my ass quite often. There are so many situations where my input is strings (JSON through various API's) that should get turned into just integers, floats or (string) constants shortly after being consumed. Using TS types from this point onward promotes discipline to do so on my part, removes any ambiguity going forward, and alerts me if I treat these values as strings or any other wrong type (which commonly happens to me, at least, when using vanilla js).
      • jstimpfle 9y ago
        I agree - one thing is noticing bugs, which is easier with stronger dynamic types. And as you say it's also important to setup some boundaries so that bad values can't travel to the other end of the program before you notice, which is a pain to debug. I like to make value checks on module boundaries, but do much fewer checks inside modules. I typically do this using assertions. Optional types can be a way to do it with less noise. But they still can't replace asserting arbitrary invariants, like invariants involving multiple values.
• amagumori 9y ago
  ok. i get why you chose typescript. however, why did you choose this weird cursive-ish monospace font? and...where can i get it?
  • deleted 9y ago
    [deleted]
  • zuzun 9y ago
    Operator Mono https://www.typography.com/fonts/operator/ https://www.typography.com/fonts/operator/
  • swah 9y ago
    Its so easy to know who programs a retina screen... those newer monospace fonts with decorations look like crap on my windows pc.
• noway421 9y ago
  The screenshot in the header is strange. Why would they reimplement arrayToDict function instead of using lodash's _.indexBy
• mdip 9y ago
  Gotta comment ... I dove into TypeScript about a year ago and dropped it. I saw the value but because of a large number of libraries and custom components of my own, switching purely to TypeScript wasn't easy and I was in a hurry. Fast forward several months and I picked it up again. I've now been writing everything that I would have done in JS in TypeScript and have built several applications using both Angular and React entirely in TypeScript. I've also sold my teammates on switching to the language. When I was (stuck) writing JavaScript, the frustration factor was high for me. I'd get nebulous errors[0], hunt around the line it referenced, swear a little, and trace the code back to the cause. I would wildly estimate that one out of ten attempts at blindly running my code would succeed[1]. Even on unit tests, which had a higher degree of success since they were testing much less, still had a much higher fall-over[2] rate than I get in typed languages that I enjoy. The addition of types, which adds a little overhead, flipped that over. I am still surprised every time I refresh a page that uses code I'm modifying and it loads. The reduction in time spent debugging (and swearing) makes me enjoy the language more every day that I use it. It's even left me longing when I am writing code in other languages (mostly Java/C# these days) and features I have come to really enjoy (union types, intersection types and to a lesser extent the duck-typing nature of the language[3]). Since crapping on any language, or feature/lack of feature of a language tends to become a religious war fought with verbal violence, allow me to admit a few points: Traditionally, I avoided JavaScript and jobs related to it. Personally, I hate the language. This means I've spent considerably less time researching all of the best practices/techniques for surviving those cases where I have to write JavaScript. I started in C and Pascal and prior to a few months ago spent 99% of my time in typed languages. I am an advocate for unit testing[4], but I find test-driven development requires me to work backward and it's less productive for me. I'd imagine that if I went all in with TDD, I might see fewer of these problems, but many of the best practices for JS development are best practices in the languages I am more proficient in and despite following these practices, JS design led to these practices being less effective at reducing bug frequency. Yes, I could just be a yelling 'get off my lawn' because I'm unwilling to change[5]. But I've also worked closely with highly-skilled JS developers who could rapidly produce incredible things as a result of its flexible, dynamic typing. Incredibly, though, one of those 'huge JavaScript advocates' was the one who told me to give TypeScript a chance late last year. Though he would always fight me on the "dynamic vs. static" thing, his argument was that TypeScript's type system was light-weight enough to keep out of his way while strict enough to lower the frequency of self-inflicted foot bullet-holes (paraphrased). Really, though, ... two nulls, asinine boolean implicit conversions necessitating code like double-bang and === / !== operators[6] should be enough. [0] Often depending on whatever framework I was using, but I've rarely found one that returns an error that results in a really obvious 'oh, I know what I did to cause that' [1] I like to check that a component renders visually appropriately and often do a quick check before I've written all of the required unit/integration tests to make sure it's rendering accurately (right data/right result). [2] As in, something fails badly enough to stop execution rather than just failing on an assert for an incorrect result. [3] It's a love-hate thing for me -- the result is being able to reduce boilerplate making mostly-compatible types interact, but the down-side is that the compiler giving a pass to "A=B" when "A" has at the properties of "B" results in some subtle bugs that have already bitten me more than once. [4] Though I don't buy into TDD (either before writing the code or after) solves most of the issues of dynamic typing. I've had more than a few tests fail because of a type-related issue...in the test. [5] Except that I love learning new languages and 'keeping up' and have found that as I've aged, I can pick up new languages far more quickly than I could in my early 20s... [plug]RUST![/plug] I'm also not terribly old, nor terribly sensitive about being called an oldster. [6] I don't recall who, but someone was once reading code out-loud and said "if action fuckin' equals 'ADD' and payload.Length doesn't fuckin' equal zero". Adding in the fuckin' every time he encountered the "really, really [not] equals" operator. So that is how I mentally read those. I'll never forgive him (sorry for the swears ... and doubly sorry if you end up reading code like this as a result).
• rmuratov 9y ago
  Anyone know existing open source projects written in Flow?
  • gaastonsr 9y ago
    There are quite a few. I know some Facebook projects are. From the top of my mind https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components.
  • OmarIsmail 9y ago
    Here at Streak with have 10s of thousands of lines of code written in Flow. Our main app and the InboxSDK are not open source but we do have some smaller open source libraries on our github. Check them out! https://github.com/StreakYC https://github.com/StreakYC Everything updated in 2017 (so from react-float-anchor and later) has flow types included.
• flavio81 9y ago
  Javascript is a weakly typed language and no superset like Typescript or Flow will solve this problem, just mitigate it. However, on the other hand, I think that a good, experienced developer has no problem with that. The bugs that the experienced developer "fears" have nothing to do with type errors, which at the end are rather easy to solve...
  • kpmah 9y ago
    Types can turn all runtime exceptions in to compile time errors. See: https://www.infoq.com/news/2017/05/elm-zero-runtime-exception https://www.infoq.com/news/2017/05/elm-zero-runtime-exceptio... I assume you're not claiming that experienced developers never have runtime exceptions, or that they're always easy to solve.
  • vog 9y ago
    > The bugs that the experienced developer "fears" have nothing to do with type errors, which at the end are rather easy to solve Not sure how you define "experienced developer", but I think you got it backwards. A good type system enables you to structure your code in a way that most sublte bugs are "converted" to type errors. That's the magic of types! Your type definitions aren't just some syntactic sugar so that the type checker finds some typos. Your type definitions are a vital part of the code base that you design to protect it from changes that introduce subtle bugs - the kind of kind you can easily foresee when you wrote a particular module, but which others (or yourself after 6 months) won't be aware of. This is especially important on refactoring, but also super helpful for non-trivial extensions. In that sense the types are like unit tests. Although they are less flexible than unit tests (so they are no substitute), they make most of your unit tests unnecessary and are shorter and easier to write and to maintain than those unit tests. Most importantly, however, they "test" all cases, statically at compile time, not just the specific cases of your unit tests.
    • flavio81 9y ago
      Good reply, but the benefits you described are already realized by strong typing, which is not the same as static typing. A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code. Thus, those are bugs that are trivial to solve. And this, to paraphrase your post, protects your code from changes that introduce subtle bugs. You can also have a language that is statically typed but that has weak typing! Which language? C. And i think everybody knows the extra effort needed to keep a C program bug free. And this not only due to lack of automatic memory management! I have been programming for most of my life, that is about 23 years of programming on where 20 of those years were using statically typed languages, including many years programming on large, business-core systems on Java and C#. I since have gone to dynamically typed languages and never looked back. You just need strong typing, that's enough.
• z3t4 9y ago
  upvote should be a global with capital letters. but writing it like that might be a leaky abstraction of the underlaying database storage. should the web dev really have to know that some variable is represented by a tinyint later converted to a float, then "optimized" to a 32 bit int !? why make it into a failure point when there is so little gain in performance and make little sence in a high level, lose typed language such as javascript. stop writing javascript like its java!
• vog 9y ago
  From the article: > Typescript also came with a lot of “social proof” and better assurances about its longevity There are several large projects using Typescript (examples include VSCode, Rxjs, Angular, and Typescript itself), While I agree with the sentiment, I don't understand why they include "Typescript itself" in this list. Isn't that a circular argument?
  • ubershmekel 9y ago
    Typescript as a project might be bigger than the rest. E.g. compared to flow the typescript repo has double the stars and quadruple the commits. If those metrics mean anything.
  • nycdotnet 9y ago
    Not really. It's direct proof that the language is good/fast enough that the people creating it chose it for themselves. The flow team, for example, wrote their language in ocaml.
• deleted 9y ago
  [deleted]
• bayesian_horse 9y ago
  Can someone please _prove_ that types make development somehow safer and more productive? I for example believe that readability matters, and typescript is not that, compared to Python or even coffeescript. And I really don't like how all the cool new languages lack significant whitespace. You can probably tell I'm a Pythonista. A Pythonista always pays his technical debt.
  • bayesian_horse 9y ago
    Apparently nobody can prove type systems are more productive, or point at studies showing a benefit... And still, everybody agrees, according to the down votes. That is frustrating!
  • fpgaminer 9y ago
    > And I really don't like how all the cool new languages lack significant whitespace. Significant whitespace is redundant in the face of auto formatters. The latter are becoming more popular, and rightfully so.
    • bayesian_horse 9y ago
      Auto formatters still make you look at the braces... and typescript needs a lot of those. It's not just about formatting...
  • christophilus 9y ago
    I think this [1] is one of the better references I've seen on this question. It's an analysis of bug-counts across Github projects. There's a correlation between number of lines of code and bugs. And there's a correlation between languages that favor simplicity and bugs. But there's not a a correlation between static typing and bugs. So, I think we can say that you don't choose static typing in order to write fewer bugs. I've worked in lots of code-bases, both static and non. Indeed, the bug rates are fairly consistent across them. The worst code bases I've seen (from a maintainability perspective) were actually old C++ and Visual Basic ones. Refactoring is easier in statically typed code-bases. But, in my experience, it's not significantly better. What makes a bigger difference is immutability, functional purity (within reason) and a preference for obviousness (as opposed to, say Ruby-like magic which makes me pull my hair out on a semi-daily basis). [1] https://dev.to/danlebrero/the-broken-promise-of-static-typing https://dev.to/danlebrero/the-broken-promise-of-static-typin...
• martin_drapeau 9y ago
  Is Typescript necessary for front-end Javascript? In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Textbook logic as why to use strong types make absolute sense. Yet in the real world, I've had to fight with logic, DOM, UX, framework incomprehension and other types of bugs - not types. Type issues were anomalies among bugs. When they came up, they were the easiest to fix. Am I alone here? Anyone in the community have concrete examples of type-related bugs that took so much time to required using something like Typescript? Can anyone quantify that?
  • place1 9y ago
    Type errors might not be the biggest issue up-front when writing new frontend code, but refactoring JS becomes really hard as the LOCs grow. Typescript (static typeing in general) really helps with this as you can get instance feedback about how you're changing interfaces between parts of the system. Another reason i've enjoyed TS is the editor intellisense support. It's really helpful when using a library to get type info in your editor instead of having to google when you forget what a function returns, for example. This is also helpful when you're coming back to code you wrote a long time ago, or a colleague wrote it, and you don't know what particular variables/function arguments/object properties are at a given spot in the code.
    • emodendroket 9y ago
      Oh yeah, that's another great point (although you're still stuck with the fact that somebody can access object properties by key).
      • davidjnelson 9y ago
        Couldn't you solve this with privates, either via a naming convention or with symbols, as well as using getters?
        • emodendroket 9y ago
          Not really. If I declare that an object has property xyz obj.xyz and obj['xyz'] are both valid ways of addressing it.
• spiderfarmer 9y ago
  Reddit should stop promoting their app on every freaking action you do on their website. I refuse to install because of it. Just build a better website.
• tycho01 9y ago
  I tried typing functional programming library Ramda using TS, and got frustrated it still had some limitations (e.g. needing overload codegen in lieu of variadic support). I tried finding what TS can do now, and figured out type-level tuple iteration, among a few others. The current roadblock seems to be getting function return types. Progress, for anyone interested: https://github.com/Microsoft/TypeScript/issues/16392 https://github.com/Microsoft/TypeScript/issues/16392 At this point I'm amazed how close we are to typing anything, despite having only 5 (!) type-level operators, with their respective warts.