18 ms·

If TypeScript is so great, how come all notable ReactJS projects use Babel?

• NhanH 10y ago
  From personal experience, you probably want Babel anyway even with TS to deal with some weird edge cases. I think this has been fixed now. But a couple of weeks ago, I had a case where TS compiler output has to be ES6 (since the code base were using something like constructor.name which isn't in ES5), but then Jest (the test framework) doesn't like ES6 syntax, so Babel is needed to compile whatever Jest didn't like down to just ES5 syntax.
  • baq 10y ago
    webassembly can't come soon enough. as a developer who doesn't deal with browser frontends what i read in this thread is madness. (3 comments at the time of writing this...)
    • nol13 10y ago
      it's like they don't even realize how ridiculous this shit sounds..
      • rplst8 10y ago
        I don't think the point of WebAssembly is to target the DOM. I think it it's to provide a common low level API across browsers that many languages can target.
        • nol13 10y ago
          Sorry was referring to the infinite layers of transpiling and sub-languages that people talk about like it's normal, which I admittedly get why they exist, but it's still fucked. But that too. (though maybe wasm + canvas will let someone eventually implement a decent ui toolkit? Think I saw at least one attempt at this.) Current project could maybe benefit from TypeScript, and certainly async/await, but still wonder if it's less of a hassle to just wait for wider support.
          • nol13 10y ago
            ..and no i dont want to use VS Code either! grumble grumble grumble (Of course if yc ever decides to fund our small startup it should know that we are a team of forward thinking progressive individuals who will use the best and most robust tools available to us, who's views i do not necessarily represent)
        • themihai 10y ago
          WASM is supposed to be first class citizen so I don't see any reason why it shouldn't have access to the DOM or any other browser feature available to JS.
    • spankalee 10y ago
      WASM doesn't have DOM access or GC. It's not the answer.
      • denisanerson 10y ago
        I read that DOM access is not available at the moment, but is planned for future releases.
      • SiVal 10y ago
        Is that correct? WASM has no DOM access? (I'm asking, not advocating anything.) How does code that runs in a browser do UI I/O without DOM access? Is the intent that you go on writing all of your I/O and DOM-manipulating code with JavaScript and call WASM-implemented helper functions from JS code?
        • markdog12 10y ago
          No DOM access for the MVP. They do plan on eventually supporting it though: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md https://github.com/WebAssembly/design/blob/master/FutureFeat...
          • themihai 10y ago
            I think we can hack a reverse js proxy before it gets native DOM access.
        • smitherfield 10y ago
          Inside a <canvas>/<object>/<embed> tag.
      • friendlygrammar 10y ago
        In the first release it wont have DOM access or GC
  • facepalm 10y ago
    lol
• amelius 10y ago
  OT: is it me or is Babel incredibly slow in translating ES6 to regular JS?
  • cprecioso 10y ago
    It is. Try enabling the `compact` option or using something like Buble [1]. [1]: https://buble.surge.sh https://buble.surge.sh
    • amelius 10y ago
      Interesting. Is Buble compatible with Babel? I.e., can you call functions in Babel-compiled code from Buble-compiled code, and vice versa?
      • marijn 10y ago
        Yes. They both just lower the code to ES5 syntax without introducing any incompatible constructs.
    • werkinprogress 10y ago
      I use buble. It transpiles ES6 to ES5 2.5 times faster than babel on average. But be aware that buble is still a work in progress and only supports a subset of ES6 features. A very usable subset, but a subset nonetheless.
      • hokkos 10y ago
        And has it progress it will be slower to handle the most complex cases and follow the spec, than they will use a plugin architecture to let users develop their own language extension and modularize it, than they will only have to rename it to Babel because it won't be different.
        • werkinprogress 10y ago
          The buble project wouldn't exist if babel ran faster and worked out of the box without setting up confusing config files. It fills a need.
• mhd 10y ago
  Because a lot of notable ReactJS projects are irritatingly enamored with all the latest ES6/ES7/ESCloudCuckooLand features, not all of which are supported by TypeScript. I've noticed this a lot in the Redux realm. For every possible problem there seems to be a solution that harnesses one particular new/proposed bell & whistle.
  • k__ 10y ago
    This. Many React projects use JSX, decorators and class properties to the max, so they needed babel in the first place. Now if you want to add types, Flow is easier to integrate than switching to another compiler.
    • patates 10y ago
      My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Well, when Babel first came out I also thought that it should have been a Sweet.js plugin so maybe I don't have the best understanding of this "transpiling" circus.
      • RyanCavanaugh 10y ago
        It's tempting to think this way, but it's a performance/complexity nightmare. If everything is a plugin, then you need ways for different parsers to talk to each other to deal with nested syntax, plus ways for different syntactic transformers to correctly handle nesting of certain things. For example, if you desired to implement a plugin for "thin arrows", and a plugin for JSX, how would you parse this? const x = <foo x = {y -> <y/> } /> You'd have to have the JSX parser know to invoke the thin arrow parser, then the thin arrow parser has to know how to invoke the JSX parser, then when you emit, you have to do the whole dance over again. If you're willing to take some trade-offs in the parsing phase, it's OK. But the emit is where you get killed - either every plugin has to be written generically and correctly enough to deal with any arbitrary nesting of syntaxes (including the cases where the semantics of nesting aren't even clear, like where a 'fat' arrow here would capture 'this' from), or you do one tree pass per transformer, which gets very expensive. There's a reason you don't usually see architectures like that live very long.
• rubber_duck 10y ago
  TypeScript is a PITA when working with typed immutable records, I don't think there will be a happy solution to that. React stack encourages stuff like immutable.js. In general TS React feels bolted on rather than designed with TS in mind like Angular 2. I love TS and using ng2 at work. If I was using React I would probably also skip on TS.
  • renke1 10y ago
    I recently started using TypeScript for my React projects and I am actually pretty happy. I am not actually sure what you mean by typed immutable records in this context, can you explain in more detail?
    • spion 10y ago
      Immutable.js (https://facebook.github.io/immutable-js/ https://facebook.github.io/immutable-js/) doesn't have the greatest typescript type annotations. Due to limitations of TypeScript, there is no way to write types for immutable.js heterogenous maps (homogenous Maps and Vectors are fine though). Since immutable.js collections are recommended to be used with redux, and no one wants to bother using IMJS records instead of just maps, the types end up being kinda useless. A nice typescript-friendly alternative to redux+immutablejs is MobX (https://mobxjs.github.io/mobx/getting-started.html https://mobxjs.github.io/mobx/getting-started.html). It does go a bit against the latest cool and hip trends (immutability, functional programming), but IMO its quite brilliant
      • tomduncalf 10y ago
        +1 for MobX being quite brilliant. So much fun to write an app with. Not saying it is the best solution for every case but if you work with React, you really owe it to yourself to try it.
      • renke1 10y ago
        I see, but using types for some parts of your code is still better than using none. And yes, actually I am using MobX, too, it's really a good choice for React. Although I miss redux-saga sometimes.
• denisanerson 10y ago
  The main reason for using Babel was async/await. However, the lastest TypeScript verion (typescript@next) can compile async/await for older browsers, so there is no reason for me to use Babel anymore.
  • k__ 10y ago
    OT: When will 2.0 finally released? I saw that they have a completed 2.0.3 milestone in Github, but just a RC release at the moment.
    • denisanerson 10y ago
      No, I mean nightly build 2.1.0: npm install typescript@next
      • k__ 10y ago
        I know. I just wanted to know when 2.0 will be officially released and it seems like never, since they already at 2.1, lol
        • moogly 10y ago
          They might be waiting for VS2015 tooling support, because VS2015 support for TypeScript is still hilariously atrocious. It feels like the TypeScript team and VS team do not communicate and are set on completely different workflows. The VS Code team gets it though, but that's probably because they use TS to write their very product.
  • whatever_dude 10y ago
    Things like babel-core are still a must though.
    • saosebastiao 10y ago
      They are? I haven't run into any problems with the latest typescript@next.
• deleted 10y ago
  [deleted]
• RyanCavanaugh 10y ago
  Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking that JSX) was a very popular feature request. I can tell you just from how quickly people notice when something JSX-related changes in the nightly build that there are a lot of people using TypeScript with React. Also, since this seem to be a popular misconception, JSX support in TypeScript is not wedded to React. The default JSX target is React, but you can set JSX to "preserve" and get very vanilla semantics as well as keeping the JSX in the emitted code so you can pipe it through a custom transformer. The question also points out that the reader is looking at lots of tutorials -- it should be unsurprising that these don't use TypeScript as it's an optional thing that would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain. If you need a notable React + TypeScript project, see the Delve team's write-up of their use of TypeScript - https://medium.com/@delveeng/why-we-love-typescript-bec2df88d6c2#.uvwtenu64 https://medium.com/@delveeng/why-we-love-typescript-bec2df88...
  • scrollaway 10y ago
    I'd like to offtopicly chime in and thank you :) Javascript is a language and an ecosystem I really disliked until React and TypeScript came around and changed everything. We're making extensive use of JSX in our React app (https://github.com/hearthsim/joust https://github.com/hearthsim/joust / https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa) and it's really wonderful to both read and write.
  • afarrell 10y ago
    > It would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain. As someone who has written a long tutorial, this makes total sense. When I was first looking at the react ecosystem, it was very frustrating because of the high cost of picking pieces to work together. I really liked http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... because it showed how to use mocha in the context of we webpack and react and redux. It would be nice to see more tutorials for curated toolchains, but they take a lot of work.
• hokkos 10y ago
  I don't feel the posts answer the question, they are more ads to Typescript or Flow. Unsurprisingly the people who answer are the one who use TS or Flow. So I tried a little to convert a big React project to Flow or Typescript. The Flow was a non-starter because of the absence of Windows support at the time, and we use like 40 (non dev) dependencies, and Typescript has a way better support for typings, I tried Flow on a mac it was chocking on the size of the node_modules or couldn't find the app modules because we use a webpack root dir (i don't tried hard to make it work). When the app was started Typescript didn't support React so it wasn't written in a "static" way, and accumulated a lot of dynamic idioms, also the backbone of the app is a dynamically generated schema based on XSD and that would be hard to make it compatible with TS type system, also React ecosystem doesn't really use it, leading to a chicken/egg problem, and React.PropTypes is already a form of type checking (but dynamic) so it probably lessen the feeling of a need of static typing in React ecosystem.
• z3t4 10y ago
  I do not believe compilation nor a type system belong in JavaScript. It's better to have something like "Flow" that does static analysis of the code as you write. I might even go as far as putting on a "tin foil hat" and state that Typescript is a trick to lock you into their proprietary ecosystem of expensive tools that everyone have to buy into just to communicate with you once you are locked in.
  • Longwelwind 10y ago
    Why not ? I only see advantages for static typing for a small cost of time: you prevent most of Type Error from happening, you get automatic auto-completion, refactoring errors are easier to catch and feel safer. Either way, you need to specify the type of the arguments in the documentation of your function (I can sometimes even find the C# LINQ's function I'm looking for just by looking at the return type of the list of function). You could even use Flow and Typescript to catch Aside from the proprietary reasons (which I believe are unfounded since the whole Typescript ecosystem is opensource), why do you think static typing doesn't belong in Javascript ?
    • z3t4 10y ago
      Because JavaScript has semantic types like List, Date, Number, String, Boolean, witch can easily be figured out by their context, like age is a number, name is a a string, married is a boolean, children is a list, born is a date, and adding type declarations are unnecessary, witch would only add extra cognitive load to the programmer. It's possible to be an productive JavaScript programmer without even knowing about types and how they are implemented. If the programmer however makes a mistake, like concatenating name and age, it will be caught during runtime, manually testing, automatic testing, runtime testing, or real time static analysis, or all of these five. Being able to concatenate and mix types like number and string is also a language feature that avoids a lot of boilerplate code.
  • d0100 10y ago
    True, VS Code is so damn expensive!
• tomduncalf 10y ago
  I've been very happy using Typescript with React, and have found the productivity and code quality gains to be remarkable compared to the relatively small amount of change required to use it vs. plain JS. Indeed there are some pain points as mentioned in the article, e.g. typing Redux actions can be a bit boilerplatey, and there's currently no object spread operator; but I feel it's worth the trade off - you can always opt out of typing something (e.g. with the "any" type), but I've always found that the places where you do this are the places where the bugs creep in! Obligatory plug for my Typescript 1.9 + React project set up guide - I need to update this for v2.0, but I think it should pretty much work as is: http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r... I actually prefer Flow's approach of being just annotations which can be stripped out, rather than a new language (albeit a superset of Javascript) with its own features and compiler - for one, I find this makes it an easier sell to teams worried about "lock in". However, there is a bit of FUD around this IMO, as you can use just the subset of Typescript which adds types to JS and avoid stuff like "enum" and the "class" enhancements - in my experience, TS's types can be stripped by Babel in the same way as it strips Flow's, so actually if you ignore the `.ts` extension, there's not such a big difference. The problem is that every time I've tried Flow (including very recently spending several days trying to convert an existing medium size React project to it), I've hit so many random undocumented issues, and ended up feeling that the benefits of it were outweighed by the amount of effort required to get it working properly. This is especially true because the editor experience offered by Nuclide is (again, in my experience) sub-par and buggy compared to VS Code (or the Typescript Sublime plugin), and I've always felt the editor support is actually one of the big selling points of working with "typed JS". I am really looking forward to seeing how Flow progresses, as in an ideal world it is what I would use, but for now (in a commercial situation especially), I have to go with what I feel brings the biggest productivity/code quality benefits and the best developer experience for the team, and for now I still think that is Typescript by a fair distance.
• tkubacki 10y ago
  I was always wondering why HN crowd is ok with TS and so prejudiced against Dart - Dart has NG2, await async in older browsers and good tooling (webstorm, vscode) and much saner package system. When doing lot of small web apps - it's easier to mantain.
  • gsnedders 10y ago
    At least in my view, there's a couple of big things: Dart doesn't introduce that many advantages over JS for all of its differences, and TS introduces many of them with a smaller diff; there's also the presentation of it—Dart was originally presented as a wholesale replacement of Dart, to ship in all browsers, the language more or less as a fait accompli, which rubs plenty of people the wrong way.
    • markdog12 10y ago
      > Dart doesn't introduce that many advantages over JS for all of its differences As someone with experience in both languages, I could not disagree more. > Dart was originally presented as a wholesale replacement of Dart I think you meant replacement of JS here. I guess it depends entirely on what you think of JS as a language. I, for one, would rather a language that fixes core issues with JS, instead of just being a superset of JS.
      • gsnedders 10y ago
        > I think you meant replacement of JS here. I guess it depends entirely on what you think of JS as a language. I, for one, would rather a language that fixes core issues with JS, instead of just being a superset of JS. If I were aiming to replace JS, I'd fix what Dart does, but I wouldn't stop with merely fixing what Dart does. Dart, despite being an entirely new language, has a less expressive type system than TS. It's transpiler (and it's VM) also does no optimisation based on the type system, instead heavily relying on the JIT to infer what the types already imply (e.g., it would be nice to do things like LICM at compile-time).
        • 10y ago
• forgottenacc56 10y ago
  I would have switched to typescript but I had to rename EVERYTHING from something to something else in order to use TypeScript. If that's how "compatible" starts, well, no thanks cause clearly that's just the start of the pain. Compatible should be same files, new compiler = "just works".
  • Allower 10y ago
    what? this makes no sense. Typescript is just a superset of javascript. you wouldnt have to rename anything..
  • whatever_dude 10y ago
    I have not encountered this problem. Can you provide an example?
    • Bahamut 10y ago
      I'm guessing he/she is referring to using .ts instead of .js
  • nojvek 10y ago
    I am actually just working on this. Being able to add commented types to a javascript file and being able to use typescript for type validation.
• ilaksh 10y ago
  Please don't bury this comment completely. I am going to be honest and tell you that I believe TypeScript is pure embrace, extend, extinguish from Microsoft. And I am amazed honestly that so many web developers are eating it up.
  • lsadam0 10y ago
    I would shed no tears if JS were extinguished. It's a terrible mongrel language that is not well suited for large projects. TS is a tremendous improvement, if you ask me.
  • deleted 10y ago
    [deleted]
  • moron4hire 10y ago
    Under what mechanism would the "extinguish" part be at all possible?
    • wccrawford 10y ago
      It's generally done by having the new "extended" version be so superior that others can't stand using the original anymore.
      • moron4hire 10y ago
        No, that's not how that works. EEE refers to the times when Microsoft would take an open standard--say HTML, or JavaScript, back when IE3 was actually the best browser on the market--shove in their own, proprietary, backwards-incompatible extensions, and keep calling it the same thing as the open standard. But MS makes it very clear that TypeScript is a different language. It helps a lot that they don't even have the same name, y'know. Also, it's a system for specifically staying backwards compatible with open-standard JavaScript. Using TypeScript does not replace JavaScript. It supplements it.
    • nol13 10y ago
      When using TypeScript subtly forces you into a MS toolchain. Then when everyone's hooked on VS Code BAM VS Code Pro Extreme Edition!
• giacomorebonato 10y ago
  I like to use TypeScript with ReactJS. And I was surprised to see some mainstream libraries using it: mobx, apollo stack. And it is also a surprise to see really well updated typings for a lot of things in the react world.
• nbevans 10y ago
  Since when are "all notable ReactJS projects" the authority on greatness?
• evmar 10y ago
  I found the comment about soundness in the linked post to be kind of an odd remark. It didn't take me long after reading that to come up with an invalid program that is accepted by Flow's type checker. (The typechecker normally rejects doing math against strings, but accepts this.) let array = [1,2]; array.pop(); array.push('hello'); console.log(array[1] - 3); To be clear, being completely sound is hard! There's a lot of space in type systems and Flow must make some hard decisions itself; whether it's "sound" or not is kinda orthogonal to whether it's useful or not. And I'm sure Flow is useful. So let's not talk about soundness. (Disclaimer: I work with TypeScript and am pretty fond of it.)
  • recursive 10y ago
    I guess they fixed it. Try it yourself. http://www.typescriptlang.org/play/ http://www.typescriptlang.org/play/ Argument of type 'string' is not assignable to parameter of type 'number' on line 3.
    • evmar 10y ago
      Sorry for the confusing comment -- I updated it. I was saying that it is strange for the linked post to talk about soundness being important when it's trivial to find an unsound Flow program. (This particular program is properly rejected by TypeScript but TypeScript is also unsound so there are plenty of other invalid programs that it accepts.)
      • recursive 10y ago
        I think it's a lot harder to get past TypeScript's type checker. It's probably possible, but I can't think of a way to do it off the top of my head without casting to any. It's a lot easier to show correctly executing javascript programs that would be rejected by the type checker.
        • evmar 10y ago
          Here's one that TypeScript gets wrong. It's kind of a canonical example of a program that is difficult to get right in a type system. (It's how I found the Flow example linked upthread.) let x: number[] = []; let y: Object[] = x; y.push('a'); let bad = x.pop(); // bad has type number but is actually a string.
• pygy_ 10y ago
  Edit: Misleading charts, figures and conclusions ahead, see @nathancahill's reply https://npm-stat.com/charts.html?package=babel&package=typescript&package=flow-bin&from=2013-09-19&to=2016-09-19 https://npm-stat.com/charts.html?package=babel&package=types... Babel has faltered since the V6 release, TypeScript is still growing fast, so I'd expect the React world to follow suite, even if Facebook itself pushes Flow... NPM downloads in August (rounded): typescript: 2,000,000 babel: 620,000 (down from 890,000 in November 2015) flow-bin: 120,000
  • nathancahill 10y ago
    Well, the V6 release made babel modular, so the babel package is no longer the right one to compare against. Look at babel-runtime: 4,600,000 or babel-core: 4,300,000 vs typescript: 2,100,000.
    • vcarl 10y ago
      Good call, that's a very different chart. https://npm-stat.com/charts.html?package=babel-core&package=typescript&package=flow-bin&from=2013-09-19&to=2016-09-19 https://npm-stat.com/charts.html?package=babel-core&package=...
      • nathancahill 10y ago
        It's irrationally irritating that September's incomplete stats are graphed incorrectly. Guess I need more coffee before dealing with JS in the morning.
    • pygy_ 10y ago
      Oh... indeed, I updated my post.
  • deleted 10y ago
    [deleted]
• apaprocki 10y ago
  Anecdotally, at Bloomberg we're in the middle of ramping up TypeScript support in our core server-side stack. Our custom IDE is Windows based, so it was very straightforward to integrate the tserver into the workflow to give developers the choice of writing vanilla JS or TS with additional annotations we send down to the IDE for the core stack. We have the largest single collection of JS I'm aware of and we're eager to see TS take off as we iron out a few corner cases and really get 2,000+ devs using it daily. This isn't the web or Node, so make of it what you will -- but the tserver integration and ease of layering on top of the existing vanilla JS in a progressive manner made it a simple decision.
  • jonursenbach 10y ago
    Curious, but why do you guys have a custom IDE?
    • apaprocki 10y ago
      We started using server-side JS around 2005 so things were a bit different back then. The main driving force for it was that we had to have WYSIWYG integration with the product and the only way we could achieve that was by embedding an HWND from the running product to ensure it wasn't some faked runtime that would behave slightly differently during development / in production.
  • oblio 10y ago
    That sounds really interesting. Could you give more details about your adoption plan? Which version of TS are you using? Are you planning to migrate to TS 2.0, when it comes out? In your experience so far, have the conversion done until now caught any bugs?
    • apaprocki 10y ago
      If I'm remembering correctly it first went live to some early adopters with 1.6.1 and it is using 1.8 now. We obviously want to track the latest releases as fast as we can because they bring new features we're interested in. I would need to ask some of the teams that tried converting larger projects specifically what they found that they felt was important. I'm certain TS would find some bugs in any sufficiently large project, but I'd have to go dig up data to know roughly how many or how serious they were. Just because there was a technical quality issue with the code doesn't mean that the vanilla JS version of it wasn't producing the actual desired result. It's hard to gather numbers for that type of thing. It's very similar to the let-down a lot of people feel with using static analyzers on mature, battle-tested C++ code for the first time. It will certainly find some nits, but most likely they were not that important to begin with.
• microcolonel 10y ago
  I do TypeScript every day for work, and honestly I don't see the point of it. I'm also of the opinion that the iterator pattern nonsense has ruined generated code quality for ES6 transpilers, and that ES5 getters and setters have made it considerably harder for JS engines to do high level optimizations (dead store elimination, invariant hoisting, load merging, etc.). The sky is falling. Anyway, you're not going to dissuade anyone. TypeScript looks visually similar to Java and C# enough that managers will think they can adapt Java and C# teams to it in a couple of days; and they won't know how wrong they are until a month or two have passed.
  • icholy 10y ago
    > I do TypeScript every day for work, and honestly I don't see the point of it. really? I'm assuming you never refactor anything.
    • lloyd-christmas 10y ago
      I use TS every day and it's a godsend, as long as you compare it solely to "using JS everyday".
    • Roboprog 10y ago
      Perhaps menu-driven refactoring is overrated? (much like IDE generated getter/setter code, which is solving the wrong problem)
      • choward 10y ago
        What do you mean? It's the typescript compiler that catches your errors. The IDE stuff is nice to have, but it's not the main benefit typescript adds to refactoring. Typescript doesn't rely on an IDE.
        • douchescript 10y ago
          I work with a typescript project, and the classes of errors that are caught by the TS compiler are not worth the hassle of having to use typescript.
• Keats 10y ago
  TypeScript works very well with React, less so with Redux/ImmutableJS. We just moved our app from Redux and ImmutableJS to mobx and it's been a treat: we now get full typing and it's much less verbose. We don't need to repeat the payload definition at every point, we have a store where we call a method and that's it. Highly recommend checking out mobx if you use TS.
  • gbog 10y ago
    mobx seem to be one year old, that not enough.
    • mst 10y ago
      I'm not sure what you mean, given the mobx project has existed as mobservable for quite some time.
  • saosebastiao 10y ago
    I too have switched to only using Mobx and have come to the same conclusion.
  • cloverich 10y ago
    I've been using Typescript, React, and mobx and absolutely in love with how they all work together. For me the high-level summary is that the vast majority of my logic is moved out of React views and into stores / controllers / whatever, with almost no boilerplate to make them play nicely together. The way its coming along reminds me of Ember quite a bit, but I get to use React and POJO's.
    • iamcasen 10y ago
      I definitely want to look into mobx now. Just thought I would throw out there that I've been using Nuclear-js/Immutable.js and it has a lot of the benefits you mentioned. All the data manipulation logic is encapsulated nicely, and merely appears as state to your components. You can observe memoized transforms in your components so that they only need to listen for the data they need, rather than a single change event on an entire store.
• kowdermeister 10y ago
  I'm not sure if this not a sophisticated trolling :) Imagine the question with random technologies: If ___________ is so great, how come all notable ________ projects use __________? Classic troll magnet :)
  • paulddraper 10y ago
    If Apache Spark is so great, how come do all notable JS projects use jQuery?
• HugoDaniel 10y ago
  Why waste your time with half-baked type systems that try to achieve some compromise over JS idiosyncrasies. Go all in with purescript[0] :D Simple, elegant, strong typed and compiles to JS. [0]: http://www.purescript.org/ http://www.purescript.org/
  • jawarner 10y ago
    Yeah, why waste your time learning a little bit of new syntax when you can learn a whole lot of new syntax /s
    • HugoDaniel 10y ago
      And not just any syntax. Jump on the bandwagon and learn the gods[0] syntax. :D [0] https://github.com/purescript/purescript/wiki/Differences-from-Haskell https://github.com/purescript/purescript/wiki/Differences-fr...
  • computerex 10y ago
    Because freedom? Typescript is a superset of JavaScript, which means all JavaScript is valid typescript. So you're never faced with the difficult choice of locking yourself to one language/platform. JavaScript is awesome, it just doesn't scale to large projects because you cannot efficiently refactor it. Typescript solves this problem beautifully. You can easily add whatever type information you need to effectively work with the codebase, whilst being compatible with all JavaScript libraries and the ecosystem.
    • HugoDaniel 10y ago
      Does that include ES6 ? What parts of JS do they consider a subset of typescript ? Can i keep my type declarations in a different file than my .js code like flow does ? (thus ensuring compatibility while keeping the functionality of typescript) How far can i go with typescript until i need to use babel ?
      • pitaj 10y ago
• pg_is_a_butt 10y ago
  community community community community facebook really likes saying community community community community community
• douchescript 10y ago
  Typescript is a pile of crap that's why.
  • deleted 10y ago
    [deleted]
• ZLeviathan 10y ago
  because Facebook doesn't want M wins?
• greggman 10y ago
  I got a link to these articles from HN a couple of weeks ago. https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/posts/designing-for-correctness.html https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/... What I loved about them is they show how a different type system and language design can massively reduce code size and errors. After reading them I felt frustrated back in JavaScript or C# or any other language I use regularly. Are Typescript and Flow missing the forest for the trees?
• hmans 10y ago
  Because the masses will always gravitate towards inferior options.
  • douchescript 10y ago
    Maybe "the masses" can code without struts.
• mpawelski 10y ago
  I've been using React + Redux + Typescript stack and I've been quite happy with it (It's hard for me to image how you could do big refactoring without TS). The fact that components props are verified by compiler instantly when I type is a big win. I believe with PropTypes you can't specifically describe what is the shape of your data, for example object with property of such name and the value of this property is object with other concrete properties. Or array of objects with specific property. In pure react you only have "React.PropTypes.object" and "React.PropTypes.array" in TypeScript you can say "{ foo: string, bar : { fieldNum : number}}" or "{foo: string}[]". Some other observations: - I use Typescript 2.0 RC, because it has union types [0] and it works great with Redux reducers. It's super cool! - I don't miss spread object operator that much, it would be nice but I'm fine with some utils function that can even verify that I "override" property that exist is source object[1] (I mean creating new object with changed properties) - What I really miss is the ability to say that what is the return type of the method. There is "typeof" operator in typescript for telling what is the type of particular object, I would like something like "returntypeof". Because now I always need to write the type of an action and very often it could be inferred from action creator function. Or I need to write type to describe what will be returned by Redux's "mapStateToProps" function, and sometimes this object can be big. [0] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#tagged-union-types https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T... [1] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#example-21 https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
  • berfarah 10y ago
    Don't you have React.PropTypes.shape({ foo: React.PropTypes.string, bar: React.PropTypes.shape({ fieldNum: React.PropTypes.number }) }) ? I'm not saying it isn't verbose, but I'm pretty sure that as of a few months ago, this existed in React natively.
    • sync 10y ago
      PropType support is pretty iffy, see e.g. https://github.com/facebook/react/issues/1833#issuecomment-148297807 https://github.com/facebook/react/issues/1833#issuecomment-1...
• greggman 10y ago
  Isn't a large part of the win for typescript the tooling? Specifically the auto completion and documentation that pops up in various typescript enabled editors. Does such a thing exist for Flow? Could it? If it did that would go a lot further to push me to flow than that it just catches more errors. I get huge productivity gains from my editor helping me with API completions etc...
  • Ezku 10y ago
    Our team is using Flow, and most devs use Nuclide[1] for the autocompletion and type hint popups. I can't compare it to any TS IDE, I'm afraid, but I can attest it's way more comfortable than doing without. [1]: https://nuclide.io/docs/languages/flow/ https://nuclide.io/docs/languages/flow/
  • Roboprog 10y ago
    Try using one of the JetBrains IDE's, such as IntelliJ or Webstorm, on plain old Javascript some time. It does a surprisingly good job inferring the methods on an object, as well as autocompleting the names of stand-alone functions (much of what I write) that are in scope. Aside: I tend to do much more with higher order functions than with classes, so Typescript and the like really don't excite me very much. I'm happier to skip the whole transpile and source-map shuffle. Also, I tend to put at least partial JSDoc comments on just about everything, so that an open documentation panel explains things as I move the cursor down the file. Any type annotation is also shown on the function names/params in the structure tree browser. Finally, autocomplete is not as useful when not using "Enterprise" style naming conventions. E.g. - "inv_acct.load()" vs "checkoutInvoicePayableAccount.asynchronousLazyLoadFromRemoteServer()". Hopefully, between context and comments, such ridiculous names aren't really necesary - like, how many "account" type values do you have floating around in the current scope/context???
  • t1amat 10y ago
    There are many code analysis engines for JavaScript that can be used as a plugin for code completion. One commonly available as a plugin to many extensible editors is TernJS[0]. [0]: http://ternjs.net/ http://ternjs.net/
• labrador 10y ago
  Why not both? I just installed flow and checked the JavaScript output of my TypeScript project (~2000 lines) and was a little disappointed it didn't turn up any errors.
  • AgentME 10y ago
    Flow only type-checks files that have opted into it with the //@flow comment. It will have some trouble dealing with the compiled output of another tool like Typescript. For example, it probably wouldn't understand that output of how Typescript compiles classes into ES5 represents a class. Even if using both of them on the same code worked, Flow and Typescript are both a bit anal about certain dynamic javascript patterns, and I think any possible extra gains from having both check your code would be canceled out by having to write your code in ways to please both type-systems.
    • labrador 10y ago
      I made the necessary mods (flow doc is not very clear by the way) and thought it was funny flow complained about TypeScript emitting this: var live_items = new Array(); ^^^^^^^^^^^ Use array literal instead of new Array(..)
• betolink 10y ago
  In my team we use both approaches depending on the size of the project, an inconvenience we ran into using typescript is the typings definitions, some are out of date or don't work at all, that and the fact that typing dependency management is not yet fully integrated means that you have to keep track of 2 set of dependencies.
• kuon 10y ago
  I am using TypeScript in a middle sized app (around 200 react components) and its help is invaluable for collaborating and sharing APIs. Currently it is based on redux, but I have a feeling I have to write too much code, I am looking into MobX as an alternative. I think TypeScript is the best thing that happened to the JS community in a long time.
  • saosebastiao 10y ago
    Don't hesitate to jump ship to Mobx. No regrets at all, it was like trading in a Lada for a Toyota. And being written in typescript, the TS support is impeccable.
    • kuon 10y ago
      I wonder if such comments: http://disq.us/p/1bpl2ua http://disq.us/p/1bpl2ua are actually based on reality or just a plain rant. I worked with SproutCore, Angular and others that tried to be "smart", and while it was awesome at first, in the long run it was hard to maintain.
      • spion 10y ago
        In this video: https://www.youtube.com/watch?v=TfxfRkNCnmk https://www.youtube.com/watch?v=TfxfRkNCnmk The author of MobX explains how MobX works and implements a 50 line version of it (a fast and functional one too, except without the sugary decorator syntax) You can see the presentation and decide for yourself.
  • Keats 10y ago
    I just did that (redux -> mobx) as mentioned in another comment and it made the code easier to understand, everything typed with less than half of the code. No more connect or action, we just call the store method (equivalent to a reducer fn) directly. I also moved most of the components that had state to use observable variables and it's been working well.
    • kuon 10y ago
• mythz 10y ago
  TypeScript with JSPM and VS.NET works great, IMO even better than Babel since it doesn't require additional configuration for Babel or managing a separate watcher process since VS.NET compiles on save - providing an optimal dev experience. The additional complexity TypeScript requires is typings for each library which is designed to add value over time through typing feedback, but sometimes the typings can deviate from the implementation which is currently the only friction I hit when using TypeScript. If you're interested in this combination, I've published a step-by-step guide showing how all pieces fit together in: https://github.com/ServiceStackApps/typescript-redux https://github.com/ServiceStackApps/typescript-redux For a decent sized TypeScript + React code-base checkout https://github.com/ServiceStack/Gistlyn https://github.com/ServiceStack/Gistlyn - a C# Gist IDE written in TypeScript + React and Redux - a large enough project that would've been painful to write without React or TypeScript. A Live demo is available at: http://gistlyn.com http://gistlyn.com
• intrasight 10y ago
  All this JS and TS churn and stress makes me want to just stick to HTML
• cpdean 10y ago
  "If we descended from monkeys, how come there's still monkeys?"
• KirinDave 10y ago
  The ceaseless drumbeat of "why do I have to correct every breaking error in my code just to try it" just... Don't people realize how old and flawed this argument is? And it's even stranger applied to Typescript, which is a fairly good implementation of a real-world gradual typing system. Most modern type systems are quite good at giving you info about problems, blocking errors about the outright incorrect stuff, and otherwise get out of your way. Typescript is no different in this. But many people (including the top reply) argue like secretly it's 2007 and we're talking about inscrutable C++ compiler errors from the last generation g++ compiler. We're not. Typescript is not only fast and friendly, but it's a heck of a lot more "batteries included" than Babel. The funniest part is that ultimately flow desires to asymptotically approach what TypeScript already (for the most part) _is_ today.
• neilellis 10y ago
  This is a bit of a false dichotomy, I use TypeScript + Babel to get full ES6 + TypeScript features - they work so seamlessly I forget that I have a Babel layer in there.