15 ms·
Glimmer.js: What’s the Deal with TypeScript?
- tabeth 9y agoI haven't used TypeScript extensively, but I feel that there should be more of a push (maybe there is, please correct me if I'm wrong) to introduce whatever functionality people deem worthy that exists in TypeScript and introduce it to JavaScript. You can already see the conflict happening as some people prefer Flow and others TypeScript. Perhaps later Google will throw their hat into the ring and introduce GScript. Then, you have three different languages that introduce similar functionality, that all transpile into JavaScript. Sound familiar?
- smt88 9y agoJavaScript changes slowly, and adoption of its changes is even slower. TypeScript has the major benefit of working now. Also, TS is a superset of JS, so the fact that it's a different language isn't really problematic.
- manojlds 9y agoAngular 2 was written with TypeScript.
- oblio 9y ago> I haven't used TypeScript extensively, but I feel that there should be more of a push (maybe there is, please correct me if I'm wrong) to introduce whatever functionality people deem worthy that exists in TypeScript and introduce it to JavaScript. There is a huge push going on. But Javascript has a consensus driven community: all the big players involved have to agree on something for it to be adopted (Google, Apple, Microsoft, Mozilla, etc.). Plus, even when it's adopted there's usually a 2-5 year delay before mass diffusion.
- deleted 9y ago[deleted]
- mixedCase 9y agoGoogle already has Dart.
- trimbo 9y ago> Perhaps later Google will throw their hat into the ring and introduce GScript Google had one called Atscript, but rallied Angular 2 around Typescript instead. http://sdtimes.com/google-microsoft-combine-typescript-atscript-angular-2/ http://sdtimes.com/google-microsoft-combine-typescript-atscr...
- stupidcar 9y agoThe Angular team also managed to get TypeScript approved as a new language for internal development at Google, joining a pretty short list (Java, C/C++, Python, JavaScript, and Dart I believe). All the others were apparently decided by fiat in earlier days then grandfathered in. TypeScript is the first, and so far only, language to successfully go through the official approval process. I feel like we're going to see a big increase in TypeScript related activity from Google in the next couple of years, due to this.
- reducesuffering 9y agoI believe Go would also be an approved language for internal development.
- recursive 9y agoThe flagship feature of TS is static typing. That will never exist in JS.
- Lio 9y agoI'd never say never. As I'm sure you're aware, JavaScript has had statically typed arrays since WebGL was introduced. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
- WorldMaker 9y agoES4 the version of JavaScript that time mostly forgot (except for Adobe and ActionScript) had static types that looked rather similar to Typescript/Flow. It's not impossible that it will be revisited. Especially now with the precedent from Python of defining/standardizing no runtime behavior for it, only syntax acceptance; that seems like something browsers might be more okay with versus the runtime behaviors required/encouraged by ES4.
- recursive 9y agoIt has typed arrays, but they're still not statically typed. In a statically typed language, this would not run. console.log("hello"); typedArr[0] = incompatibleType(); In javascript, it will produce "hello" as output, and then a run-time failure.
- goatlover 9y agoThey got class stuff into the language, and that was no small feat (very contentious issue), even if it is still syntactic sugar over prototypes.
- tantalor 9y agoIf you just want type checking for JavaScript, use Closure Compiler: https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/ Code checking. The Closure Compiler provides warnings for illegal JavaScript and warnings for potentially dangerous operations, helping you to produce JavaScript that is less buggy and easier to maintain.
- YCode 9y agoWhat sold me on TypeScript was that it didn't just add features, it actively solved a problem I'd been experiencing. Once a JavaScript project scales beyond what can fit in your head, JS's initial productivity boost crumbles because you have to constantly double back and make sure your methods/constructors/etc. are correctly used, which properties are optional, etc... A lot of the debugging happens in runtime and god help you if you try to make a breaking change to one of the major classes/apis in your project. It's not unbearable, but the main reason for using JS is because of the productivity it allows. With TS for the cost of taking the time to explicitly define your data you get a C#/Java level of debugging that has clear productivity gains and shifts your debugging from the browser/console to the IDE. And when something doesn't fit the TS model you can just exclude it or only type the wrappers that integrate with the rest of your project. That and async/await is a godsend over promises.
- pryelluw 9y agoHave you tried Elm? Id love to know your experiences.
- YCode 9y agoI haven't; I haven't tried Flow either which looked promising. For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm highlights errors inline(?). The syntax also looks a little foreign, whereas TS generally still looks like JS with a few exceptions. I imagine Elm/Flow both have this, but another thing I like that TS does in VSCode at least with a watching task is collecting errors project-wide in a "problems" window.
- pryelluw 9y agoYes, the Elm syntax is more Haskell than JS. Not C based, which makes it an outlier. Please try Elm and email me with your feedback. Id love to know more about it. Im a programming languages nerd. :)
- bpp 9y agoFlow gets a good amount of the way there; it doesn't have quite the tooling of TypeScript but VSCode is actually able to bring a lot of that tooling to a Flow-typed codebase. Just yesterday I finished a major refactor that I'm not even sure I'd have attempted if we weren't using Flow. One giant action file feeding three insane reducers – yet I'm confident (with some testing) that it'll still work when I deploy today.
- uranian 9y ago>At the end of the day, though, JavaScript is the language of the web. And when webassembly arrives that will be over, and Typescript will be deprecated. I can't wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly. Then we can finally stop trying to fix Javascript's flaws with new language features.
- mixedCase 9y agoWA with a performant web API, you mean. First iteration of WA won't let you touch things like the DOM without jumping through JS-land.
- talmand 9y agoYep, then we can focus on other language's flaws by implementing new features.
- Enginerd3 9y agoAt the end of the day, JS will always be the language of the web. You're still going to be doing DOM manipulation through JS. WASM is really going to benefit people who want to do more heavy duty edge cases such as image processing.
- weberc2 9y agoIs this because browsers won't expose DOM manipulation at the WASM level, or is there a different reason?
- Enginerd3 9y agoDOM manipulation is going to be available at the WASM level in the future but it's going to be inefficient to do so just as it is inefficient to do image processing in JS right now. The only difference is that JS is the only viable option now if you want to do image processing on the web. WASM exists to solve this problem and complement JS. Hell, look at WASM's and JS's logo. They're two puzzle pieces that fit together.
- edance 9y agoDoes anyone know when Ember will use TypeScript?
- gryzzly 9y agoAnyone got a link on how to transition existing large webpack/React/babel project to using Typescript? Googling I only found https://medium.com/@clayallsopp/incrementally-migrating-javascript-to-typescript-565020e49c88 https://medium.com/@clayallsopp/incrementally-migrating-java... but it doesn’t use ts-loader and doesn’t go into details on how to use typings. I tried following ts-loader docs, but things broke at `import flatten from 'lodash/flatten'` and adding typings for `lodash ` didn’t help. Would be interesting what strategies people use to get it working in existing project.
- barake 9y agoES2015/commonjs interop currently sucks with TS. This is how you only import flatten: import flatten = require('lodash/flatten') TS expects any modules imported using ES2015 import to have the shape of a ES2015 module. This is an issue for many UMD/commonjs modules. In the case of lodash, it's effectively doing this: module.exports = flatten And then you're importing it like so: import flatten from 'lodash/flatten' and that is being transpiled to something like: var flatten = require('lodash/flatten').default Note the default. I haven't migrated to webpack 2, but some brief experiments suggest all modules get massaged in to ES2015 format.
- wagi_ch 9y agoI've been using `allowSyntheticDefaultImports` which does some magic behind the scenes for you to be able to use `import flatten from 'lodash/flatten'` making it really easy to use modules that don't define default exports. So far (a bit unexpectedly) I didn't really run into any nasty side-effects or things that went wrong with it. See https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#support-for-default-import-interop-with-systemjs https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in... for a (short) explanation.
- arcosdev 9y agoWhat turns me off immediately about TypeScript (and examples in the article show it) is the use of the class construct. If I could see some examples of teams writing TypeScript without falling into the use of classes I would feel a lot better about it. I am in full agreement with Douglas Crockford and others that adding pseudo-classes to JS was a big mistake.
- pimterry 9y ago> I am in full agreement with Douglas Crockford and others that adding pseudo-classes to JS was a big mistake. Why? It's certainly not a requirement of TS, any more than it is in JS, and I've seen people writing large TS codebases without classes. Typically with a much more functional approach though. I don't see people writing many prototypical objects with TS. Is there a good reason they should be?
- zebrafish 9y agoI'm curious as to why you don't like the use of classes. Are you against classes in all languages or just JavaScript?
- sotojuan 9y agoA lot of people are into the "functional JS!!1!!1!!" hype and blindly dislike anything related to OOP with little information. Also, TS does not force you into OOP. TS codebase itself does not have any classes.
- arcosdev 9y agoI'm not against classes in other languages, especially those that follow a typical OOP pattern (i.e. Java, C#, etc.). See above for my reason re: JavaScript.
- valuearb 9y agoSo appeal to authority?
- egeozcan 9y ago
- tomelders 9y agoAm I the only one who thinks typed Javascript, wether it's TypeScript or Flow, is a really flakey experience? I really enjoy Swift, so I'm not put off by types. But I find the experience of working in a real typed language to be very different to working with Flow or Typescript, where the types are for pretend, and type definitions are wrong often enough to be a real pain. And I found my self evaluating npm packages based on their type definitions, and not their suitability for the task, which seems bonkers to me. Also, I don't ever recall staying late to track down a bug that types would have fixed. But I've wasted many an hour tracking down bugs caused by mutations, and the state of Immutability and Typed Javascript is pretty grim as far as I can tell, unless I'm missing something.
- rubiquity 9y agoTypes are pretend in TypeScript and Flow the same way that types are pretend in any other typed language. Types are used at compile-time and not runtime in both cases.
- egeozcan 9y agoIn contrast to many typed languages, currently in Typescript, you can't do any kind of reflection so runtime really has no access to the type system. Well, I still love TS though.
- finchisko 9y agoOk, when Glimmer's motivation was only typechecking, why not just fb flow then?
- Etheryte 9y agoHaving used both extensively, TS is simply the better choice. Flow has multiple large bugs and issues, which many would consider critical, open and unsolved on their GitHub repo for more than a year(!) [1][2][3]. [1] https://github.com/facebook/flow/issues/245 https://github.com/facebook/flow/issues/245 [2] https://github.com/facebook/flow/issues/869 https://github.com/facebook/flow/issues/869 [3] https://github.com/facebook/flow/issues/1528 https://github.com/facebook/flow/issues/1528
- lfischer 9y agoI struggled with multiple blind spots in Flow in the past, but recently tried porting the same code to Flow and Typescript and I was surprised that Flow took less work than TypeScript. Flow 0.43.1 has become very fast and seems to need less type annotations compared to TypeScript with noImplicitAny enabled. I wonder whether Flow’s happily infers any without complaining or whether its program flow analysis remains more sophisticated.
- Rapzid 9y agoYou say "just fb flow" as if it's the default choice. If I were looking at project and community momentum, tooling, and adoption then TypeScript would seem like the obvious choice. I'm curious why you think "why not just fb flow" for somebody who wants typed JS. It's certainly an option, but it hardly seems the go-to solution.
- ruleabidinguser 9y agoTypeScript provides the same value as intellisense. E: i didnt mean this as a criticism
- johnfn 9y agoIt's a bit more than intellisense. * find definition * find usages * auto import (never type "../../../../../dumb.js" manually again) * er... types
- pfooti 9y agoThere's two things that really stand out for me on TypeScript. There are other positive attributes, but these are the two things I liked. The first is that it made some specific workflows a lot easier. In particular, I'm working on some pre-alpha libraries where there's movement on how the API interface is defined. TypeScript made that transition a lot easier. Yes, my testing would have eventually caught all the method arity mismatches, but TypeScript made this happen about an order of magnitude faster. The second is how unobtrusive the types actually are. I did a fair bit of J2EE programming in the 00s, and types and interfaces can be really annoying. With typescript, interfaces are assertions about the shape of an object, rather than things themselves. That means, if you defined an interface as HasFirstName: { firstName: string } and function greet(person: HasFirstName), you don't actually have to put HasFirstName everywhere in the code that uses that function. You're not required to set up inheritance or anything. You just have to make sure that all arguments to greet have a firstName property. That's it. So I can say: const dude = { firstName: 'the' }; greet(dude) just fine. But if I try to greet(potato), it'll error. Lexical typing this way gives you a lot of power while still staying out of your way in a language like javascript where it's super common to create consts as bags of properties without worrying about what particular interface they're instantiating. I really like that, as it is precisely the overbearing types of Java that annoy me.
- Joeri 9y agoI've done a few typescript projects. Some migrating an existing codebase, some starting from scratch. Every time it has been a nice experience, and with every release it gets nicer. Two of the projects had very complex requirements, and typescript was instrumental in being able to refactor them with confidence. I think the upsides are quite well known by now. Honesty requires me to admit that I did run into some downsides: - Initially it was difficult to understand the exact mechanics of how typescript ... types. Definition files seemed like a bit of a black art, and how to annotate existing code so that it had the proper type wasn't always obvious, especially when you run into libraries with incomplete or wrong type definitions and when you want to do tricky stuff like creating typed mocks in unit tests. The typescript documentation is very good and I haven't needed much beyond it, but some extra real-world type definition chapters would help. - Setting up a complete dev toolchain is challenging. I wanted everything: source maps, in-IDE debugging with breakpoints, in-IDE unit tests with code coverage, tslint, gradual introduction into an existing codebase, and robust integration into the build of the rest of the app (which in my case meant SBT integration). I still don't have code coverage in my in-IDE unit tests. The way I see it though, if your javascript has any build step at all you already have this pain, so this isn't so much a problem with typescript as a problem with javascript build pipelines in general. - Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle. Once you do a typescript project you end up understanding the value, even if you might not find it valuable for yourself personally, so it's only a matter of convincing developers to give it a go. However, getting to that point is a bit of a chicken and egg problem.
- KurtMueller 9y ago> Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle. I feel the same way about Elm, F# and Fable, Facebook's ReasonML, and any other language that has an ML type system and compiles to javascript. I think the value becomes more apparent when: a) you work in a large codebase and have to refactor either a large swath of code and/or a critical piece of logic and b) you need to make illegal states unrepresentable. In both cases, I have found having a compiled, ml-typed language extremely helpful. I think for both Typescript or an ML language, having immutable non-nullable types by default really cuts down on complexity - instead of having to specify everything that's immutable with something like a `const` keyword, you instead have to specifically point out which attritibutes on a type are mutable. That's a small win but has huge benefits - especially when you're trying to debug code. That's just my two cents anyway.
- petre 9y agoWell, if we already transpile ES7 to JS then why not tanspile TypeScript instead because of all the added benefits?
- Achshar 9y agoBecause eventually in a couple of years you can take your ES7 code and remove the transpiration and it will all work seamlessly. Not so much with Typescript.
- petre 9y agoM$ can achieve world domination again by making the already opensourced Chakra engine run TypeScript directly w/o the need to transpile. Goodbye ES7, hello ES6 soon to be ES7 optionally typed superset.
- sangnoir 9y ago"Not transpiling" sounds like a marginal benefit, considering most apps are going to have a build step anyway.
- vladimir-y 9y agoTranspiling is going to stay, currently you transpile es6/7/typescript=>es5, later you will do es8/9/typescript=>es6/7, and so on, so this point is not relevant.
- Achshar 9y agoI meant it in the code's current state. Suppose the development stops or stagnates in a month or two. The product is complete. So you can remove the transpilation. Also we won't have to transpile current features in the future. That and code can go as is and have the benefit of native execution that it doesn't currently have.
- picardo 9y agoI have a project that uses Flow. I've had no complaints with it so far, but I've been craving the IDE support of TypeScript. What's the difference between the type system of TypeScript and Flow? Would it be worthwhile to switch? Part of me wants to wait out the Flow team come up with better IntelliSense support. The `flow ide` command in the release 0.42 is a big step in the right direction. But it seems like TypeScript already has this, and if the delta between the two type systems is small, I might just go ahead and switch.
- Rusky 9y agoTypeScript's type system is intentionally unsound in a handful of places- function parameters are bivariant, for example. I believe Flow is at least closer to being sound. I suspect switching from Flow to TypeScript would be relatively straightforward as far as the types go, but going the other direction would not.
- lfischer 9y agoThe delta between the type systems is small enough that people have tried to automatically convert TypeScript type definitions to Flow. One notable difference is that Flow supports declaring types as covariant/contravariant. I suspect that as far as most application code bases go (as opposed to libraries), you would almost see no difference.
- kej 9y ago>What's the difference between the type system of TypeScript and Flow? This presentation [1] was posted to HN recently and gave a pretty good overview of the differences between TypeScript and Flow. [1] https://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html#/ https://djcordhose.github.io/flow-vs-typescript/flow-typescr...
- picardo 9y agoAwesome prez! Thanks for the link!
- tumblen 9y agoIs there a way for typescript to be used as PropTypes in React?
- subkamran 9y agoTypeScript is amazing, enough said. If you're building any application with any amount of code that has to be worked on by anyone other than yourself, you want to use TypeScript (I'd argue even for yourself, use it, it'll catch enough errors to pay for itself in spades). Coupled with editors like Visual Studio Code which are cross-plat and have first-class tooling for TS/JS, it just makes you objectively more productive both as a consumer and writer of Javascript. Even the most die-hard pessimists I've met love TypeScript once they try it.