5 ms·

TypeScript is, in fact, awesome. 2.0 adds still more awesomeness, and 2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see. The only

TypeScript is, in fact, awesome. 2.0 adds still more awesomeness, and 2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see. The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point. There are other languages that I prefer for specific domains, of course. But if you're writing code that needs to run on a web client and/or that needs to run in Node, TypeScript is the only way to go.

michaelchisari 10y ago
For me, I've simply decided to just focus on javascript. I have to use it, and while I had quite a bit of enthusiasm for Coffeescript, the move towards ES6 has made me realize that I need to just buckle in. Maybe it's a little bit of fatigue setting in, but at this point, my next foray into a new language will be something properly compiled like Rust or Swift, not a transpiled language. This is not to detract from Typescript or Purescript or anything else like it. There's some amazing work going on, but for now, I'd rather learn the ins and outs of javascript instead, warts and all.
- eloisant 10y ago
  It is good indeed to have a deep understanding of Javascript before using other tools. I've never really cared for Coffeescript (because I felt like it brought very little at the cost of a very different syntax) but Typescript really improves my productivity.
  - michaelchisari 10y ago
    I do miss meaningful whitespace. It's my favorite thing about Python. Although I recognize it's not for everyone, and it's purely a matter of aesthetics and preference.
    - gmac 10y ago
      Yeah, I have been all-in on CoffeeScript until recently, and significant whitespace is one of its best features for me. It's a DRY issue.
- cel1ne 10y ago
  Give Kotlin a try. It's a JVM-language and 100% java-compatible, but it can also compile to Javascript (not sure if that backend is production-ready yet though) https://kotlinlang.org/ https://kotlinlang.org/ It's also backed by JetBrains the IDE-maker.
  - jbverschoor 10y ago
    Kotlin is a JVM clone of swift.
    - realharo 10y ago
      A clone of something that appeared 3 years later? (2011 vs 2014 according to wikipedia)
    - Nullabillity 10y ago
      AFAIK the official line has always been that it's a "simpler Scala". Not to mention that it's several years older...
    - nostrademons 10y ago
      They're actually quite different - a good chunk of my current project is in Kotlin, and all of my last project was in Swift. Things Swift has that Kotlin doesn't: associated types, file-based access control (changing in Swift 3.0), pervasive use of keyword arguments, trailing closures, full pattern matching (Kotlin can only destructure component1...N sequences), reference counting. Things Kotlin has that Swift doesn't: smart casts, declaring properties directly in the constructor, declaring constructors directly in the class statement, auto-delegation, data classes, singleton objects, implicit parameterizable 'this' (handy for builders & DSLs), garbage collection. Things they both have: null chaining & defaulting, class extensions, somewhat clumsy first-class method syntax, concise lambda syntax, lambda anaphora ('it' in Kotlin, $0 and $1 in Swift), concise range operators, property descriptors, operator overloading. Kotlin generally has the feel of a much more pragmatic, industrial language. It's Java without the warts, where the designers took note of the common Java patterns they wrote and provided a lot of syntactic sugar to dramatically improve brevity. Swift feels more academic; its type system is more modern and less ad-hoc, it has polished implementations of many features that academic languages have been trying to get right for years. Both are heavily influenced by their ecosystems; Swift feels like a better Objective-C, and Kotlin feels like a better Java.
- premium-concern 10y ago
  Scala compiles to JavaScript, to the JVM, to Android, and (soon) to native. Give it a try!
  - Nullabillity 10y ago
    I love Scala, but last time I tried to build an Android app using it (about a month ago), I just got various weird errors in IntelliJ when trying to build it. Eventually I just gave up and rewrote my app in Kotlin instead. But yeah, it's absolutely my first choice for JVM or web work.
    - premium-concern 10y ago
      That sounds weird. How did you build it? Can you paste the SBT error?
      - Nullabillity 10y ago
        It happened with both the make button and when running it (yes, I had removed the "Gradle-aware make" step and replaced it with android:packageDebug from the SBT shell plugin). Sadly, I don't have the error message anymore, and it seemed to work when building from the command-line tool. I suppose I could have kept going like that, but it's very nice to have the proper debugging tools that an IDE provides. :/
        premium-concern 10y ago
        Which version of sbt-android do you use?
        Nullabillity 10y ago
        1.6.1, I think, but I'm not sure. I was stupid enough to delete my project files...
  - lomnakkus 10y ago
- youdontknowtho 10y ago
  Typescript doesn't really transpile, kinda sorta...its output is idiomatic JS. It's syntax is basically just javascript. It's really just a natural way to annotate the types that you pass to javascript functions so that the compiler can check them. Not trying to be "that guy", just saying that it isn't like learning a whole new language. It's just adding a few things to the JS that you already know.
theprotocol 10y ago
>2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see The complete lack of visibility for such things is what prevented me from adopting TypeScript. I couldn't get a clear answer which platforms supported async/await (there was a huge conversation on github which heavily implied, but never outright stated, that there was an ES5 target; yet the docs said it was ES6 only). A lot of the features have unspecified targets. I wish their documentation were better.
- mercurial 10y ago
  I agree with the spotty documentation. That said, it is nonetheless such a titanic improvement over standard JS, both in terms of safety and of readability (documentation via type signatures), that I firmly intend to not write "standard Javascript" in the future if I have any say at all in the matter.
kelkes 10y ago
Because there are ppl (like me) who think that strong types are highly overrated and the transpiling stuff becomes more and more obsolete with ES2015/ES7 coming. If i have to use JavaScript (and i enyoj it) then please pure without anything on top.
- SomeCallMeTim 10y ago
  It's actually really, really hard to overestimate how amazing having optional specified types is. I used to use C++, then went to Lua, and more recently to JavaScript with the occasional Python. I loved the freedom of getting away from the strict C++ type system, which mostly felt like it was holding me back. But the thing that bothered me the most about JavaScript/Python was the fact that the tooling just doesn't have a clue, most of the time, what types things are. Misremember what has a member of what, exactly, or the spelling of a member, and you've got a bug. TypeScript eliminates that kind of stupid bug and overall speeds up development by 2-3x. Yes, some of those bugs can be found in tests. But having to go back and fix them at all, tracking down exactly what the object structure is by hand (either in a debugger or digging through docs) versus "let the editor tell you exactly what members this class/object has, and what members its children have, so I can get it right the first time"? And what about refactoring? TypeScript knows what everything in your code is. You decide to rename a member? Done! Just because there are twenty "init" methods, if you decide this particular call should become "init2", it will rename exactly the right members throughout your project. Finally, the fact that it just has your back when assigning types prevents another entire class of bug. No question; (optional!) strong types are a huge win, and as I said above, should be a required practice for any nontrivial app. You get the best of both worlds: Type safety without the manacles of having to specify everything. Transpiling won't be obsolete until TypeScript is standard in browsers (where it could help improve JIT optimizations!), and probably not even then: We're looking at ES2017 before async/await is ready, which probably won't be in most browsers until 2018 at the earliest, and there will likely be more killer features on the horizon in the future that many people will want to use.
spriggan3 10y ago
> The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point. Seriously ? because it's not javascript and never will be.
woah 10y ago
Can typescript be integrated with other, standards-compliant preprocessors? It sounds irritating that Typescript 2.1 will "add" async/await when it's been available in Browserify and Babel for years already. I want to get into using js types, and typescript seems to have the most momentum, but I don't want to get locked into o e monolithic preprocessor which lags behind everything else by several years.
- DanRosenwasser 10y ago
  Yes, you can just target ES6/ES2015 in your emit and TypeScript will use generators to enable `async` & `await`. You can then use Babel as the next step. We have a tutorial on Gulp & TypeScript that hooks up Babel and Browserify: https://www.typescriptlang.org/docs/handbook/gulp.html https://www.typescriptlang.org/docs/handbook/gulp.html
- deleted 10y ago
  [deleted]
- unscaled 10y ago
  Typescript actually already supports async/await since version 1.7, but only for ES6 targets - i.e. it compiles everything down to generator-based coroutines, which is essentially the same as the 'transform-async-to-generator' plugin in Babel, I guess. If you want to support ES5/3, I guess you can always target ES6 with Typescript and then feed the result to Babel. It's a bit clunky, but it would probably work. Where Babel shines vs. Typescript is that you get much more fine-grained control over which transformations to apply. Typescript doesn't seem to support just emitting async/await directly, which is what you would want if you target a browser which support async/await directly (Beta Chrome and Edge already support it behind a flag, and it's going to come to other browsers soon)

michaelchisari 10y ago

For me, I've simply decided to just focus on javascript. I have to use it, and while I had quite a bit of enthusiasm for Coffeescript, the move towards ES6 has made me realize that I need to just buckle in. Maybe it's a little bit of fatigue setting in, but at this point, my next foray into a new language will be something properly compiled like Rust or Swift, not a transpiled language. This is not to detract from Typescript or Purescript or anything else like it. There's some amazing work going on, but for now, I'd rather learn the ins and outs of javascript instead, warts and all.

eloisant 10y ago
It is good indeed to have a deep understanding of Javascript before using other tools. I've never really cared for Coffeescript (because I felt like it brought very little at the cost of a very different syntax) but Typescript really improves my productivity.
- michaelchisari 10y ago
  I do miss meaningful whitespace. It's my favorite thing about Python. Although I recognize it's not for everyone, and it's purely a matter of aesthetics and preference.
  - gmac 10y ago
    Yeah, I have been all-in on CoffeeScript until recently, and significant whitespace is one of its best features for me. It's a DRY issue.
cel1ne 10y ago
Give Kotlin a try. It's a JVM-language and 100% java-compatible, but it can also compile to Javascript (not sure if that backend is production-ready yet though) https://kotlinlang.org/ https://kotlinlang.org/ It's also backed by JetBrains the IDE-maker.
- jbverschoor 10y ago
  Kotlin is a JVM clone of swift.
  - realharo 10y ago
    A clone of something that appeared 3 years later? (2011 vs 2014 according to wikipedia)
  - Nullabillity 10y ago
    AFAIK the official line has always been that it's a "simpler Scala". Not to mention that it's several years older...
  - nostrademons 10y ago
    They're actually quite different - a good chunk of my current project is in Kotlin, and all of my last project was in Swift. Things Swift has that Kotlin doesn't: associated types, file-based access control (changing in Swift 3.0), pervasive use of keyword arguments, trailing closures, full pattern matching (Kotlin can only destructure component1...N sequences), reference counting. Things Kotlin has that Swift doesn't: smart casts, declaring properties directly in the constructor, declaring constructors directly in the class statement, auto-delegation, data classes, singleton objects, implicit parameterizable 'this' (handy for builders & DSLs), garbage collection. Things they both have: null chaining & defaulting, class extensions, somewhat clumsy first-class method syntax, concise lambda syntax, lambda anaphora ('it' in Kotlin, $0 and $1 in Swift), concise range operators, property descriptors, operator overloading. Kotlin generally has the feel of a much more pragmatic, industrial language. It's Java without the warts, where the designers took note of the common Java patterns they wrote and provided a lot of syntactic sugar to dramatically improve brevity. Swift feels more academic; its type system is more modern and less ad-hoc, it has polished implementations of many features that academic languages have been trying to get right for years. Both are heavily influenced by their ecosystems; Swift feels like a better Objective-C, and Kotlin feels like a better Java.
premium-concern 10y ago
Scala compiles to JavaScript, to the JVM, to Android, and (soon) to native. Give it a try!
- Nullabillity 10y ago
  I love Scala, but last time I tried to build an Android app using it (about a month ago), I just got various weird errors in IntelliJ when trying to build it. Eventually I just gave up and rewrote my app in Kotlin instead. But yeah, it's absolutely my first choice for JVM or web work.
  - premium-concern 10y ago
    That sounds weird. How did you build it? Can you paste the SBT error?
    - Nullabillity 10y ago
      It happened with both the make button and when running it (yes, I had removed the "Gradle-aware make" step and replaced it with android:packageDebug from the SBT shell plugin). Sadly, I don't have the error message anymore, and it seemed to work when building from the command-line tool. I suppose I could have kept going like that, but it's very nice to have the proper debugging tools that an IDE provides. :/
      - premium-concern 10y ago
        Which version of sbt-android do you use?
        Nullabillity 10y ago
        1.6.1, I think, but I'm not sure. I was stupid enough to delete my project files...
- lomnakkus 10y ago
youdontknowtho 10y ago
Typescript doesn't really transpile, kinda sorta...its output is idiomatic JS. It's syntax is basically just javascript. It's really just a natural way to annotate the types that you pass to javascript functions so that the compiler can check them. Not trying to be "that guy", just saying that it isn't like learning a whole new language. It's just adding a few things to the JS that you already know.

theprotocol 10y ago

>2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see The complete lack of visibility for such things is what prevented me from adopting TypeScript. I couldn't get a clear answer which platforms supported async/await (there was a huge conversation on github which heavily implied, but never outright stated, that there was an ES5 target; yet the docs said it was ES6 only). A lot of the features have unspecified targets. I wish their documentation were better.

mercurial 10y ago
I agree with the spotty documentation. That said, it is nonetheless such a titanic improvement over standard JS, both in terms of safety and of readability (documentation via type signatures), that I firmly intend to not write "standard Javascript" in the future if I have any say at all in the matter.

kelkes 10y ago

Because there are ppl (like me) who think that strong types are highly overrated and the transpiling stuff becomes more and more obsolete with ES2015/ES7 coming. If i have to use JavaScript (and i enyoj it) then please pure without anything on top.

SomeCallMeTim 10y ago
It's actually really, really hard to overestimate how amazing having optional specified types is. I used to use C++, then went to Lua, and more recently to JavaScript with the occasional Python. I loved the freedom of getting away from the strict C++ type system, which mostly felt like it was holding me back. But the thing that bothered me the most about JavaScript/Python was the fact that the tooling just doesn't have a clue, most of the time, what types things are. Misremember what has a member of what, exactly, or the spelling of a member, and you've got a bug. TypeScript eliminates that kind of stupid bug and overall speeds up development by 2-3x. Yes, some of those bugs can be found in tests. But having to go back and fix them at all, tracking down exactly what the object structure is by hand (either in a debugger or digging through docs) versus "let the editor tell you exactly what members this class/object has, and what members its children have, so I can get it right the first time"? And what about refactoring? TypeScript knows what everything in your code is. You decide to rename a member? Done! Just because there are twenty "init" methods, if you decide this particular call should become "init2", it will rename exactly the right members throughout your project. Finally, the fact that it just has your back when assigning types prevents another entire class of bug. No question; (optional!) strong types are a huge win, and as I said above, should be a required practice for any nontrivial app. You get the best of both worlds: Type safety without the manacles of having to specify everything. Transpiling won't be obsolete until TypeScript is standard in browsers (where it could help improve JIT optimizations!), and probably not even then: We're looking at ES2017 before async/await is ready, which probably won't be in most browsers until 2018 at the earliest, and there will likely be more killer features on the horizon in the future that many people will want to use.

spriggan3 10y ago

> The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point. Seriously ? because it's not javascript and never will be.

woah 10y ago

Can typescript be integrated with other, standards-compliant preprocessors? It sounds irritating that Typescript 2.1 will "add" async/await when it's been available in Browserify and Babel for years already. I want to get into using js types, and typescript seems to have the most momentum, but I don't want to get locked into o e monolithic preprocessor which lags behind everything else by several years.

DanRosenwasser 10y ago
Yes, you can just target ES6/ES2015 in your emit and TypeScript will use generators to enable `async` & `await`. You can then use Babel as the next step. We have a tutorial on Gulp & TypeScript that hooks up Babel and Browserify: https://www.typescriptlang.org/docs/handbook/gulp.html https://www.typescriptlang.org/docs/handbook/gulp.html
deleted 10y ago
[deleted]
unscaled 10y ago
Typescript actually already supports async/await since version 1.7, but only for ES6 targets - i.e. it compiles everything down to generator-based coroutines, which is essentially the same as the 'transform-async-to-generator' plugin in Babel, I guess. If you want to support ES5/3, I guess you can always target ES6 with Typescript and then feed the result to Babel. It's a bit clunky, but it would probably work. Where Babel shines vs. Typescript is that you get much more fine-grained control over which transformations to apply. Typescript doesn't seem to support just emitting async/await directly, which is what you would want if you target a browser which support async/await directly (Beta Chrome and Edge already support it behind a flag, and it's going to come to other browsers soon)