10 ms·

Goodbye CoffeeScript, Hello TypeScript

327 points by matm 11y ago

geoffwoo 11y ago
interesting. we use coffeescript at nootrobox.com, but as you noted, it doesn't have a lot of hand rails. many a time, i've run javascript through a js2coffee translator to verify. will look into typescript.
unoti 11y ago
> It’s reasonable to assume "foo bar and hello world" will compile to either: > foo(bar) && hello(world) > foo(bar && hello(world)) Feel free to sprinkle in additional operators to increase the clarity and readability of your code. Coffeescript is extreme in what it allows. But even C code can be made more clear by using more operators than the compiler actually demands. I'm not really trying to come to the defense of Coffeescript here, but I think it's worth noting that adding more operators for clarity is a good thing. I even go as far as adding additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression. Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse.
- krisdol 11y ago
  agreed, add a good linter and problem solved. Ruby has been this flexible since its inception and you don't see people complaining about ambiguity because they learn how the language works. When there's ambiguity, be explicit.
  - seiji 11y ago
    When there's ambiguity, be explicit. Many (too many) programers seem to take a viewpoint of "only type the minimum numbers of characters necessary to get something to work." Then they make their programming goal to be the least characters possible as long as the compiler accepts their input. complaining about ambiguity because they learn how the language works. Some programmers also enjoy learning all the ambiguous edge cases then making sure their code fits them exactly in the way they intend, but not necessarily the way others will read the code. That's why we end up with awful things like "if (abc) def; else hij;" or worse "if (abc) { def; } else hij;", etc. Plus, if your language isn't line-sensitive, using weak syntax but pretty alignment is just a recipe for future failures a few steps removed from when you originally introduced the future inconsistencies.
    - vlunkr 11y ago
      Ugh, I used to write coffeescript and I was that way for a while. I left off parens, brackets, commas, etc. wherever possible. I thought it was great at the time, but when I came back to the code after writing in other languages it looked awful, and I wasn't always sure how to read it. Being a little more verbose will save you a lot of time in the future.
  - cma 11y ago
    Ruby had to make changes for almost this exact syntax case after it bit people by the thousands, they added: foo () (irb) :2: warning: don't put space before argument parentheses .
    - ninjin 11y ago
      Julia, as of v0.4, has deprecated this syntax [1]. I am not sure where it originally stems from, C? It makes sense from a compiler stand-point since the argument call semantics would most likely be inferred after tokenisation. [1]: https://github.com/JuliaLang/julia/commit/28e7bd4536d06a9e139ea3e3f8e8c868543fa861 https://github.com/JuliaLang/julia/commit/28e7bd4536d06a9e13...
  - Daishiman 11y ago
    As a person who uses Python to a great degree because of its explicitness, I complain about this in Ruby all the time.
- davnicwil 11y ago
  > [I use] additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression For me this was one of the greatest lessons of Clean Code by Bob Martin, in my opinion a wonderful book which completely changed and dramatically improved the way I write code. By improvement I mean simply the ease with which I can understand and modify my own code months after writing it/ seeing it last. There's a slight contradiction here with another great lesson of that book though which is short code (by lines) > longer code simply because it's easier to consume in a single glance. There's certainly a delicate balance at play here. It's a great thing to break down a complex process into steps, naming those steps as you go, and storing things in variables achieves that. However sometimes a better tool, and again another frequent suggestion in Clean Code (really, all credit to Bob Martin for all these ideas) is to instead break the steps into clearly-named functions, if this is possible. Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise. Another great tool for the belt and one of the reasons I have come to always prefer programming in a functional style vs a more stateful, OO style, where I can (even within pretty OO languages such as Java - though the lambdas in 8 have greatly improved the ease with which this can be done).
  - jfaucett 11y ago
    "Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise". Couldnt agree more, variables are just clutter you have to keep mental track of, and working with series of transformations is much easier (for me at least) to process. I would be interested to know if its like this for all developers, perhaps not, since I know some that are also opposed to recursion. but for me this: sum([]) = 0. sum([H|T]) = H + sum(T). is much easier to understand than: function sum(ary) { var i = ary.length, res; while(--i) { res += ary[i]; } return res; }
    - ahoge 11y ago
      function sum(array) { return array.reduce((a, b) => a + b); } With a loop: function sum(array) { let acc = 0; for(let val of array) { acc += val; } return acc; }
- bad_user 11y ago
  In most languages the parsing rules are pretty sane even for humans. The question you're quoting is the perfect example of a rule that's unreasonable, no matter the answer, because there's no way in hell a normal person can remember that without first being burned and I'm pretty sure that's hard for the compiler to parse as well. > Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse But regardless of the truthiness of this statement, it has no value. It's like saying that no matter what you eat, in large quantities it can cause humans harm. And yet there's a clear distinction between ingesting mercury or lettuce.
  - unoti 11y ago
    The message is: write clear code. Writing ambiguous code is a sin committed by the developer, not the language (although it is easier to commit that sin in CoffeeScript).
- catshirt 11y ago
  definitely! and, be consistent. an example that is clear and consistent, albeit contrived, would be to wrap arguments when there are more than one: foo bar foo (bin, bar) or if that's too "iffy" for you, you just always wrap with parens!
  - kaoD 11y ago
    In CoffeeScript I always do (foo bin, bar) when I need the clarity. Found it in a major style guide and I loved it. E.g. (foo bar) and (hello world)
    - arohner 11y ago
      Only two steps away from embracing the dark side: (and (foo bar) (hello world))
      - eru 11y ago
        Or from the other dark side (Haskell): foo bar && hello world and for more than one argument: foo bin bar && hello world
    - deleted 11y ago
      [deleted]
- kazinator 11y ago
  > any language will allow you to write expressions that are hard for humans to parse The problem isn't "hard to parse", but rather "easy to parse --- in two or more ways".
- smilekzs 11y ago
  Livescript has sane defaults: `foo bar and hello world` -> `foo(bar) && hello(world)`
chimeracoder 11y ago
The biggest advantage of TypeScript is that the output is unminified Javascript that closely resembles the input. In fact, you could show someone the output and convince them that you wrote the Javascript manually (rather than generating it from the TypeScript). This makes it really easy to interop with existing Javascript code, but it also makes it really easy for non-Typescript developers to pick up. For me, learning Typescript was pretty quick, because valid Javascript is already valid Typescript. All I had to do was remember the syntax for (optional) type annotations. Learning ES6 was actually the bigger hurdle, not Typescript.
cfontes 11y ago
I've been playing around with typescript and together with IntelliJ it's just great... Fast transpiling, easy to config, easy to debug, typed, the list goes on... The only thing that toke me a while to understand at the start was the whole "Definetly Typed" repo, why and how to use it. It is a bit strange to have to add types as you develop but you can live with it after it sits in. There is also Angular 2 which mergers very well with it, friendly advice, try it!
- santialbo 11y ago
  I hope this new feature https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm... means that little by little the type definitions will move to the projects themselves rather than having all of them together in a single repo.
  - WorldMaker 11y ago
    Yes, DefinitelyTyped has gotten huge and it would be great to at least see npm packages own typing definitions for themselves. Unfortunately, there will still be plenty of npm package maintainers that won't care for Typescript definitions in their repositories and I still think there probably needs to be a more distributed type definition package management option than DefinitelyTyped. (I don't know what that would look like just yet, otherwise I'd probably have tried to build it.)
  - cfontes 11y ago
    I hope you are right!
  - pyrophane 11y ago
    Absolutely needed. While the Definitely Typed project is a commendable effort, the definitions themselves are often incomplete and out of date, which is problematic because, at least in my mind, an out of date type definition is worse than having no definition at all. The problem core of the problem is that many of the definitions they host are contributed as one-offs by developers who create them as needed, and often there is no one responsible for making sure they get updated in lock step with the library itself. The only way I can think to solve this is to have a contributor to the library itself be responsible for maintaining its type definition, so that keeping it up to date becomes part of the release process. Of course, really everyone should just switch development to typescript so that the defs get generated automatically ;)
mreiland 11y ago
I'll never understand why people don't just use javascript.
- Animats 11y ago
  But then you wouldn't have a complicated build process to run, allowing free time for web surfing.
- dkarapetyan 11y ago
  People did but now that there are better languages that transpile to it and are just as readable and using plain javascript is kinda silly. TypeScript is a superset of javascript so if you're not using it you better have a really good technical reason.
- rblatz 11y ago
  Because the tooling you get when you start using a statically typed language is superior. In a massive JS application things become a lot easier to refactor when you start using Typescript.
  - ex_ex_nihilo 11y ago
    Javascript is a typed language.
    - alextgordon 11y ago
      and that type is the string. > 3 == "3" true > 3 * "3" 9
      - ex_ex_nihilo 11y ago
        In the above case, Javascript is coercing the strings to numbers. === does no type coercion. You can also coerce types manually. JS is not statically typed, but it is typed.
        11y ago
williamcotton 11y ago
There's no need to choose between TypeScript or Babel! You can use TypeScript with --target es6 and then use babel as a secondary transpiler.
- dangoor 11y ago
  Isn't the problem that the TypeScript compiler doesn't support all of the ES6 features that Babel does?
- claar 11y ago
  This was my first thought too, but this screws up source maps and I can't think of how to fix source maps when using two transpilers. Any ideas?
zyxley 11y ago
After Coffeescript, it's really hard to go back to excess brackets everywhere. I really wish there was a Coffeetypescript.
- acjohnson55 11y ago
  I used to feel the same way, but now I greatly prefer languages with brackets. Refactoring and auto-formatting in indentation-sensitive languages can be a real pain. Semicolons, though, I have no use for. Pity that omitting them in JS potentially leaves you open to some nasty issues.
  - jessaustin 11y ago
    Pity that omitting them in JS potentially leaves you open to some nasty issues. You may have seen this, but if not: http://standardjs.com/ http://standardjs.com/
  - WorldMaker 11y ago
    I've been using semicolon-free Typescript a lot lately (and really liking it that way) and its transpiler is ASI (automatic semicolon insertion) aware so it ends up adding the semicolons back into its JS output, which you can use as a safety net if you are worried that you don't quite have a handle on ASI. That said, JS ASI is not much different than Python/Coffeescript newline rules and if you are comfortable programming semicolon free in those languages there shouldn't be a reason that you should feel uncomfortable going semicolon free in Typescript and/or JS. The nasty issues are in fact mostly the same as Python/Coffescript.
  - Nadya 11y ago
    >Pity that omitting them in JS potentially leaves you open to some nasty issues. There is only a single instance I think of that is of legitimate concern - which is #4 listed on this blog [0]. The rest, to me, seem like arbitrarily shitty formatting or scenarios that never arise in an attempt to show why semicolons are needed. i ++ j Who would write that? Why would anyone write that? That being said - "remove all semicolons except the times you need semicolons" is silly. I also personally dislike the look of prefixed semicolons, so I'll continue to add semicolons. But I disagree the "nasty issues" are a legitimate concern anymore than "adding semicolons where they don't belong" is a legitimate concern. Both can bite you in the ass and both require a small understanding of where semicolons are needed and how Javascript gets parsed. Ultimately I think having semicolons will increase the amount of people who contribute - as people will be more comfortable with that style - but I think to have or to not have semicolons is a stylistic choice in the end. [0] http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...
kyrre 11y ago
How about using JavaScript with flow?
- jiaweihli 11y ago
  We considered Flow initially as well - but aside from its built-in maybe types (we use Monapt for this!), it's a subset of TypeScript feature-wise that doesn't iterate as quickly.
  - WorldMaker 11y ago
    Side question: when evaluating/updating Monapt did you take a look at any of the "Fantasy Land" compliant implementations? (https://github.com/fantasyland/fantasy-land https://github.com/fantasyland/fantasy-land)
    - jiaweihli 11y ago
      Ah! I think I saw this awhile back. I didn't refer to it too much when working on Monapt since it seems to serve a more abstract purpose, and since Monapt's original purpose was to emulate Scala syntax.
  - Keats 11y ago
    Which feature are you using in TypeScript that wasn't in Flow?
    - jiaweihli 11y ago
      let, const, decorators, string interpolation, other ES6/7 goodies. Also a few other compelling things like abstract classes and community type definitions.
- chimeracoder 11y ago
  > How about using JavaScript with flow? Flow is not really fundamentally different from Typescript. The syntax is almost the exact same. I tried them out side-by-side for the same project a few months ago. The main difference was that Typescript was installable through npm and simply read and wrote files to the directory, whereas Flow required an OCaml binary and ran a client-server setup that required some fiddling to get working. Flow is designed to work better with React, so it has that going for it, but if you're not using React, Typescript is almost exactly the same.
nv-vn 11y ago
>Non-mainstream syntax seems like this author already knew what they were looking for from the beginning.
barrkel 11y ago
The advantages of CoffeeScript that TypeScript is lacking aren't mentioned. I wouldn't casually give up lightweight indentation-based syntax and optional parentheses, despite the confusion both can cause. CoffeeScript makes it easy to create small DSLs that are fairly readable. Implicit hashes make for easy keyword-based arguments, only requiring '->' to make a value lazy is a bit better than () =>, and in particular not needing to end a big block of mixed code and data in a random mix of ")}]});" is a surprisingly big win, aesthetically.
- tallerholler 11y ago
  imo these (esp indentation) are why I don't plan on abandoning coffeescript any time soon.. es6 be damned!
  - drumdance 11y ago
    Same here - indentation saves so much trouble. We have a coding style guide that covers things like when to use parentheses and when not.
- cristianpascu 11y ago
  The first thought that came into mind when reading the article was: "We write bad code, the language is to blame". If all your variables are named "i", than yes, you have issues. If your code goes deeper and deeper in callbacks, it's not the language, it's you. No language on Earth will save you from that.
  - eru 11y ago
    > If your code goes deeper and deeper in callbacks, it's not the language, it's you. No language on Earth will save you from that. You can do 20 layers of callbacks in Haskell without any problem. That's how Haskell does imperative blocks of code (ie monads).
- Retozi 11y ago
  I have written a full production application in CS before switching to JS and then eventually migrated to TS. I was one of the "you save characters, you gain readability" proponents as well (I love Python too). However, it is a terribly flawed argument. Typing characters is incredibly cheap. Debugging and refactoring in a dynamic language. However, is very time-consuming. You might be a tad slower writing Typescript (with autocompletion and typechecking, I doubt it though). But over the whole lifecycle of a codebase, Typescript is a lot faster for everything but very small projects. I have done refactors in Typescript in hours that would have taken me days in CS... multiple times. Additionally the human brain can adjust to predictable noise very well (brackets). After a training period, I find Javascript and Typescript almost as readable as MY Coffeescript. However, even when developing 8 hours for multiple months in Coffeescript, I always had a hard time to grok other people's Coffeescript. There is just too much freedom. This does not happen that easy with Javascript/Typescript. Generally, static typing in a complex user interface is a huge huge win productivity wise. While you type more characters, you are still faster over the lifecycle of a project. Hitting keys on your keyboard is literally the least time-consuming part of programming.
abritinthebay 11y ago
After using ES2015 patterns for a while now CoffeeScript looks utterly barbaric in comparison. That said it's really for Ruby programmers (or those who know/want to know Ruby) who write JavaScript so I guess it will continue to fill that void. It adds no utility outside of that niche anymore however. TypeScript is great but I honestly prefer ES2015/ES6 + Flow comments. It means I write native JavaScript (ok, for now a transpile step, but that will go away in time and I'll still have valid JS code) but get all the benefits of typing like in TypeScript. However TypeScript is still pretty awesome, though I find the syntax rather verbose.
- shady_trails 11y ago
  You have an interesting opinion. Coffeescript has, for several years now, encompassed nearly the entire API surface of ES2015. * Comprehensions (more flexible with Coffeescript). Wait, that's ES7 now. * Template strings * For .. Of loops * Destructing * Classes. ES2015 has an awful implementation of this, without allowing an syntax for binding methods. Also enforces the somewhat arbitrary requirement of function properties only, as opposed to any type I choose. Don't forget, mixins with Coffeescript classes is a breeze, but no support with ES2015. * Arrow functions. Unnecessary syntax with ES2015 (the parens even without arguments), not to mention confusing implicit return. * Generators with ES2105. If you find a use for these in front end web dev I'll buy you a beer. ES2015 does succeed in introducing an entire set of confusing ideas: we rolled for years with var's, but now I get my hand held with const and let, because figuring out how var works (or just relying on Coffeescript to handle it for you) is too challenging. The point here is that it is frustrating to see people jump on the ES2015 bandwagon when Coffeescript has had the same feature set for years. It suffered adoption because of developers who didn't want to learn `another` language. I have met a tremendous quantity of developers - myself included - who initially rebelled against the use of Coffeescript, only to eventually fall in love with it.
  - abritinthebay 11y ago
    > Coffeescript has, for several years now, encompassed nearly the entire API surface of ES2015. Agreed. I didn't say features; I said looked. It looks horrible in comparison. ES6/7 code is much cleaner, clearer, and more idiomatic, than CoffeeScript. (in my experience, and I've used/debugged/worked with a LOT of both) Not going to crap all over the features of CoffeeScript, those were good (though they produced pretty awful looking JS code as a result). I would say however it wasn't worth the trade off in debugging pain.
boothead 11y ago
If you're an analytics shop (presumably) working with streams of events, I'm going to go out on a limb and say that not picking a functional language (purescript or elm) is a mistake. It's fits the domain so well, take a look at the mileage that slamdata are getting out of purescript for example. note I'm being deliberately provocative with the above statement to promote discussion, not argument. :-)
- oatmealsnap 11y ago
  I know zero developers who know purescript or elm. That is a hiring problem, especially for young companies.
  - jdhawk 11y ago
    Then hire someone who knows Coffee or Type and teach them Purescript? Its not that hard for developers to pick up a new syntax if they understand the framework and ecosystem around it...
    - 15155 11y ago
      Calling PureScript "new syntax" is a huge understatement. I love PureScript (and Haskell, FWIW), but it's a huge paradigm shift from CS, TS, or JS.
  - alanh 11y ago
    I know a few Elm developers. Using a less mainstream language can actually be a boon to hiring. (Isn’t there a classic PG essay on how ViaWeb benefitted enormously from using a Lisp when no competitors did?) > Had our first hire start today who applied because we use @elmlang in production. He rocked it! > PS: still hiring :) https://twitter.com/rtfeldman/status/656238188961226752 https://twitter.com/rtfeldman/status/656238188961226752 Furthermore, I’ve learned so many languages on the job in my career that I am unsympathetic to companies who refuse to believe that people who have learned programming can continue to learn programming!
    - 11y ago
jasode 11y ago
>Variable initialization and reassignment are the same It’s easy to accidentally overwrite a variable from a higher scope as a codebase increases in depth. Yep. There was a previous July 2013 article and related reddit thread about it.[1] The CoffeeScript compiler devs themselves were bitten by their own strange scoping rules! As to the other question about why people don't just write raw Javascript, Eric Lippert explained why plain Javascript is inadequate if you want to do more than just "make the monkey dance"[3] -- a.k.a. "large complex apps". [1]https://www.reddit.com/comments/1j1cw7 https://www.reddit.com/comments/1j1cw7 [2]https://github.com/jashkenas/coffee-script/commit/7f1088054c91f5ab3bf1ea1098b6ebffaa29a5a9 https://github.com/jashkenas/coffee-script/commit/7f1088054c... [3]http://programmers.stackexchange.com/a/221658 http://programmers.stackexchange.com/a/221658
octref 11y ago
Did you also consider Flow[0] as an alternative? I'm now using ES6 with Babel to build some small side-projects and it has been a great experience. But as the codebase grows, I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS. I wonder what will happen to all those compile-to-JS languages once ES6 becomes supported everywhere. [0]: http://flowtype.org/ http://flowtype.org/
- chimeracoder 11y ago
  > I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS. The Flow type annotations are almost identical to Typescript. There's one edge case around one of them requiring a space before/after the colon and the other not, but I can't remember what it is. I just tried running one of the Flow examples through the Typescript playground and it worked fine[0]. The biggest differences between Flow and Typescript are how you run the build system (`tsc` versus the Flow server) and the file extension you put on the file. [0] http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20https%3A%2F%2Fsmellegantcode.wordpress.com%2F2015%2F04%2F02%2Ftypescript-1-5-get-the-decorators-in%2F%0Afunction%20foo(x%3A%20string%2C%20y%3A%20number)%3A%20string%20%7B%0A%20%20return%20x.length%20*%20y%3B%0A%7D%0Afoo('Hello'%2C%2042)%3B http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20htt...
  - samwgoldman 11y ago
    While the type annotation syntax between Flow and Typescript are mostly identical (this is intentional), there are a bunch of differences between them: * TypeScript allows unsound casting, Flow doesn't. These casts are very practical, as you might know more than the analyzer. Flow takes a stricter position here, which is a theme. * Function are bivariant w.r.t. their parameters (which is unsound) in TypeScript, but contravariant in Flow. Again, this is an intentional, practical choice, but Flow emphasizes soundness. * TypeScript asks users to add annotations in scenarios where Flow will infer types. TypeScript will infer any (there is a "no implicit any" option). * Classes in Flow are nominal (interfaces are structural). Classes are structural in TypeScript. * Flow adds no additional runtime syntax to JavaScript; TypeScript does (enums, for example). Flow does support some ES2016 features (async/await, object spread), but generally holds off on experimental features (stage < 2). * Flow has a couple interesting features absent in TypeScript, like disjoint unions. I suspect/hope both systems will converge on useful features like this. * TypeScript treats null as a bottom type, but Flow uses explicit "maybe types."
seivan 11y ago
Have they fixed the issue where it was really hard to work with third party libraries unless they have type definitions? One problem I saw that it was heard to try out release candidates for React when they were lacking type definitions. Apart from that I really like TypeScript.
- pyrophane 11y ago
  Not that I can tell, and it is the one thing keeping me from embracing TypeScript. To get the full benefit from TS you really need to have type definitions for all 3rd-party libraries you use. Libs that aren't written in TS generally don't provide them, and many of the community definitions maintained by DefinitelyTyped are badly out of date or incomplete, which in my mind is worse than having no definition at all. Without defs you can get the compiler to stop complaining by turning off implicit any errors and creating definitions for just a few things like node's require and exports, but this felt like too much of a hack for me to really feel good about it. If anyone has found solid solution to this problem please let me know. I love TypeScript but don't want to spend too much time futzing with definitions.
OmarIsmail 11y ago
Once you go typed JS you don't go back. We had a large existing pure JS codebase, so Facebook's Flow was a better fit for us. We still have some portions of our code that don't have type annotations, and invariably that's where the majority of new bugs are introduced. Now we have a policy of making sure all the files we touch are typed, and adding types to a file if it doesn't already have it. Types + React is a whole new ballgame when it comes to front end dev.
- jaked89 11y ago
  Every JS code is a valid TS, since TS is a superset of JS. You can benefit immoderately from compiling your existing codebase in TS; you'll probably discover some bugs, even before adding any annotations.
  - DCoder 11y ago
    > Every JS code is a valid TS, since TS is a superset of JS. There are still cases where you'll need to sprinkle <any>. For example: var state = { foo: 1 }; if(something) { state.bar = 2; } is valid JS, but the TS compiler will complain that `state` does not have a member named `bar`.
    - addicted 11y ago
      The TS compiler will complain but still generate working JS code, so you don't lose anything.
      - DCoder 11y ago
        But the compiler's output will be polluted with these false positives, making it harder to see actual errors. (Also, there's a compiler flag to prevent codegen on error, which comes in handy sometimes.)
  - OmarIsmail 11y ago
    We made the decision some months ago and Flow's ES6 support was better than TypeScript's (and we already have a lot of ES6 code). We also have an established toolchain with gulp and browserify and babel, and again, at the time TS didn't play as nicely (vs Flow which just worked). Things are definitely improving in the TS world, and I keep tabs on it. The fortunate thing is that both Flow and TS' annotations are compatible, so it should be relatively easy to switch from one to another. Whichever one you go with doesn't actually matter though. As long as you go with one of them you'll see a massive increase in productivity vs vanilla JS.
dreamdu5t 11y ago
Why not Haskell? If you're going to be transpiling to JS might as well get all the power of purity and robust typing.
- jonahx 11y ago
  Which haskell to js project do you recommend? The wiki lists a number of them, but it's to tell which is the best choice.
  - dreamdu5t 11y ago
    GHCJS. That said, there's not necessarily a best choice because it depends on what type of application you're transpiling. There's an Om-like UI project with bindings to virtual-dom https://github.com/boothead/oHm https://github.com/boothead/oHm as well as various react bindings such as https://github.com/joelburget/react-haskell https://github.com/joelburget/react-haskell
  - 15155 11y ago
    ghcjs. For something that follows the semantics of JS and produces very readable code (a la TypeScript), PureScript is really nice.
- mrspeaker 11y ago
  I kind of agree with this - if you want to do JavaScript, do JavaScript... if you're going to bother transpiling to non-standard JavaScript - go all the way and get the power of Haskell!
  - z1mm32m4n 11y ago
    They did mention in the article that PureScript was one of the languages they considered rewriting their stack in. PureScript is very heavily influenced by Haskell (they're almost the same languages), but among other things PureScript is strictly evaluated. It seems from the article like the reason why the dismissed it was that it interoperated poorly with existing vanilla JavaScript libraries.
RomanPushkin 11y ago
)); }); // I }); // love }); // TypeScript } } Actual code from the article above. Just added comments.
- RussianCow 11y ago
  Trailing parents/braces seems like a bad reason to dislike a language. Ever heard of Lisp? :)
  - lazugod 11y ago
    Presumably that's why some people dislike Lisp too.
    - soapdog 11y ago
      Is that a valid reason? I know that personal taste plays a strong and important role but typescript is really cool.
      - giancarlostoro 11y ago
        I didn't like Lisp for a long time because of it, I've since given up and tried Lisp. My friends don't care for Lisp probably because of that as well.
        mdpopescu 11y ago
        I could get over the parentheses but CAR and CDR instead of HEAD / TAIL or FIRST / REST annoy the crap out of me.
        soapdog 11y ago
        CAR means Content of Address part of Register and CDR means Content of Decrement part of Register. They were tied to the 36-bits nature of the first LISP machines, with 15 bits to CAR and 15 bits to CDR (plus 2 bits for tags IIRC). So its not just naming keys in a structure, those had a very low level meaning related the the implementation of the CONS cell structure in hardware.
hharnisch 11y ago
Migrating away from CoffeeScript too. I'll be happy to have the ternary operator back. The existential operator was handy but became a source of land mines as the project grew. Will miss list comprehensions though.
- tiglionabbit 11y ago
  Seriously? 'You' ? 'like' : 'this'; if 'better' then 'than' else 'this?'
  - hharnisch 11y ago
    Ternary operator is more compact and consistent with many other programming languages. The bigger issue was the bugs the existential operator led to. Not worth it when checking for existence wasn't a problem in javascript anyways.
    - tiglionabbit 11y ago
      What sort of issues were you having with the existential operator? I've honestly never had a problem with that, and I often wish I had it in other programming languages.
hackerboos 11y ago
Typescript looks great until you realize you need special files that match types in third-part libraries: http://www.typescriptlang.org/Handbook#writing-dts-files http://www.typescriptlang.org/Handbook#writing-dts-files Will your third-party-lib that doesn't use Typescript keep a dts file? Who knows...
- radicalbyte 11y ago
  ..and for that work, you get a whole class of errors removed from your code.. Luckily most of the big libraries are covered; it's mainly smaller stuff - think random jQuery plugins - that aren't covered. These are libraries which are often hacked together, lack tests, clear documentation and anything approaching support. So things that you shouldn't really rely on.
jamra 11y ago
I've been looking into TypeScript recently, but after having clicked on this article, I'm thinking that I'll stick with ES6. Being able to have code completion in javascript is nice, but it's also something that you can work around by developing a good work regiment using browser-based debugging tools. The benefit of typescript is substantial, but circumventable. The drawback, one that I haven't seen anyone mention yet, is now having to deal with generics inside javascript. Trying to reason about this code and spending most of my cognitive focus on how the author is dealing with generics adds an entirely different complexity to reading and understanding javascript. On one hand, it's helpful to have types. On the other, adding a very Microsofty overhead to programming using meta-data on your data and generics inside javascript makes me want to pass on this.
- kuschku 11y ago
  It depends – if you write a library, using typescript is extremely helpful. If you just want to write a site while using a bunch of libraries, it might be useful to use VSCode, which provides autocomplete for normal JS code, as long as at least parts of the code have typescript bindings.
- smt88 11y ago
  Reasoning about generics in TypeScript isn't bad. I'm not totally sure what you meant by that. I just rewrote an API in TypeScript for Node, and I didn't spend most of my time reasoning about meta-anything. TypeScript mostly added amazing, insightful static analysis, and when I ran my code, it almost always worked perfectly at runtime. The debugger in VSCode is great, too!
  - spion 11y ago
    I think its a common meme that started because of the complexity of C++ templates and continues to be perpetuated by the creators (and moreso, users) of Go as an excuse to not implement generics. Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.
    - 11y ago
deleted 11y ago
[deleted]
LordHumungous 11y ago
Anyone know if TypeScript will ever be included in ECMAScript standard? If it is I will love Microsoft forever.
- tracker1 11y ago
  It's not that far off of ActionScript3, or ES4's proposals for strong typing... I think things are probably headed that way, I would love for the AS guys to integrate as a Babel plugin for typing (similar to flow), so that it's just one tool to rule them all... FB already deferred to Babel for JSX processing.
feyn 11y ago
You can have my CoffeeScript when you pry it from my cold, dead hands.
naitsirc 11y ago
Not trying to sell CoffeeScript here but most reasons of the author for dropping it looks more like a fault of the developer instead of the tool. * Ambiguous syntax? Just add a few parenthesis. * You don't like the existencial operator? Learn some JS, being able to easily differentiate between a truthy value and the existence of a variable with a single character is as sweet as it can get. * Comparing a language to Babel? Doesn't make sense. Babel translate ES6/2015 to ES5 for compatibility. Comparing ES6/2015 to CoffeeScript makes sense. * CoffeeScript is the reason you couldn't scale/solve data syncing or redrawable views? JS/CS/TypeScript/etc have nothing to do with that! Maybe he was thinking about Backbone? Seems like the guy is confusing tools and languages... and making (bad) decisions because of that. Personally I'm not going back to writing { }, return and ;'s :-)
- avmich 11y ago
  Language should be natural enough for the person to use and good enough to apply for the problem at hand. We don't yet know how to have consistently good solutions for these requirements. For me, {} are better than spaces - perhaps because of habits, but what will I get in - non-effortless - changing my habit in this place? "Add a few parenthesis" advice seems the opposite - don't we want not to have to use artifacts for clarification, but have simple and natural defaults working? Etc.
  - redka 11y ago
    It's not a choice of this versus that. In CoffeeScript you don't write spaces instead {} - you write neither. You express this with indentation anyway so why the extra boilerplate? CoffeeScript removes a lot of the excess work while TypeScript actually does the opposite.
- tallerholler 11y ago
  I completely agree with you but I think another reason some people aren't as keen to coffeescript as others might have to do with their other coding experiences/languages/habits... Coming from many years of python development, coffeescript is a natural fit...
_pdp_ 11y ago
I typically don't get into these types of conversations but here we go. CoffeeScript is a lovely language by all means and at my company we use it extensively because it reduces the amount of boiler plate code by a factor of 10 maybe even 20. Here is a simple example: some_func = (callback) -> callback new Error 'boom' some_func (err) -> return console.log err if err console.log 'everything is fine' The alternative JavaScript version is just too much to read. This makes huge difference when you write async code and no amount of TypeScript can really help it.
- yareally 11y ago
  I would disagree about that. TypeScript 1.6 has experimental support for async/await with ECMA6 + promises. TypeScript 2.0 will bring support for it with ECMA 3 and ECMA 5. https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/issues/1664 https://github.com/Microsoft/TypeScript/issues/1664
- mrspeaker 11y ago
  Have you tried diving into ES6 yet? It's much more terse now that they stole the good bits from coffeescript... let some_func = callback => callback(new Error('boom')); let some_func = err => console.log(err || 'everything is fine');
  - warfangle 11y ago
    I promise I started writing my comment before I saw yours ;)
- warfangle 11y ago
  The alternative JavaScript version: let some_func = (callback) => callback(new Error('boom')) let some_other_func = (err) => console.log(err || 'everything is fine') What makes a huge difference is when you write async code with generators, coroutines and promises: let some_func = co(function*() { try { const someData = yield asyncRequest(some_url); console.log('asyncRequest resolved with %j', someData) } catch(e) { console.log('asyncRequest rejected with %j', e); } });
bachmeier 11y ago
Is Typescript a good language for someone that has done very little in Javascript? Are resources available for newbies? I've programmed in dozens of languages over the last 30 years, so I'm not a beginning programmer, but have simply never messed with Javascript. How does Typescript compare with Dart? Is Javascript the place to start?
- recursive 11y ago
  I don't think you can expect to use typescript without really understanding javascript. Not to say you shouldn't learn typescript first. But by the time you're fluent in typescript, you basically know javascript also.
vorg 11y ago
> Existential operator accessor (?.) is a leaky abstraction for null I found this out the hard way when using it in groovy a while back. The Options abstraction you describe is better, or the one in Java 8, which Groovy still hasn't brought into its syntax. Groovy's creator James Strachan talked a lot about how he designed Groovy to avoid the "leaky abstractions" in Java.
- jiaweihli 11y ago
  There is also this gem of a quote by him[1]: > I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy. [1] http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl...
hit8run 11y ago
Is it really that important nowadays to build webapps in pure js or abstractions of it? We read articles about how many smartphones get superslow when executing loads of JS code, how broken the development process is and how framework x tries to solve that broken flow. We make use of super heavy and complicated toolchains that are outdated half a year from now. I often hear and read things like: "You still use bower instead of npm?", "You still use coffee script?! Go with TypeScript.", "BackboneJS? Why not go with Angular?". Some requirements make it mandatory to do lots of stuff in the frontend. For example: SoundCloud is supposed to continue playing songs when users navigate around. Okay they need a pure JS page refresh experience. But the standard CRUD admin panel you write 90% of the time? There it's not wrong if a browser does what it is supposed to do. Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?
- z1mm32m4n 11y ago
  I don't know if you've used Heap before, but they're (necessarily) doing quite a bit more than loading a page when a user clicks on a link. Some applications necessitate more sophisticated user interactions.
- Uehreka 11y ago
  Single Page Applications can enhance the user experience in many ways, even with more "boring" apps: * Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward. * Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one. * Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process. Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from: * Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text". * Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens. * Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions. My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.
kailuowang 11y ago
From the cons the author listed for typescript, this article is way too generous with this language. Like CoffeeScript it is just an intermediate solution to the problems JS has. We are still far away from inventing a good language for UI logic development. IMO Elm is pointing in the right direction, Scala.JS is getting some interesting traction and momentum.
- jiaweihli 11y ago
  Personally I'm not a huge fan of mixing language with UI architecture - it seems like it would slow down development on both fronts. Replacement costs are also much higher. That aside, we'll talk about how we built our architecture in our next blog post! I promise you that I thoroughly pored over the Elm architecture tutorial[1] before designing any building blocks. [1] https://github.com/evancz/elm-architecture-tutorial/ https://github.com/evancz/elm-architecture-tutorial/
nerdwaller 11y ago
Kind of feels like they're trying to jump from one popular thing to the next. The JavaScript world is exhausting.
vectorpush 11y ago
I do wish CoffeeScript had stronger type support, however, I don't want to give up indentation, optional object brackets, optional function parens and easy loops. There are a ton of other CoffeeScript features I love like the string interpolation syntax, comprehensions, implicit return, @ for this, improved switch syntax, ranges and a ton of other stuff, but I'm going to hang on to those first four for as long as its practical to do so.
jpochtar 11y ago
If you want to migrate a coffeescript codebase to typescript, try out https://github.com/palantir/coffeescript-to-typescript https://github.com/palantir/coffeescript-to-typescript which should do it for you automatically
tkubacki 11y ago
I heard Wikia gave up on TS - wondering why people are leaving TS ? Too much friction ?
ausjke 11y ago
http://www.walkercoderanger.com/blog/2014/02/typescript-isnt-the-answer/ http://www.walkercoderanger.com/blog/2014/02/typescript-isnt... so this blog is arguing typescript is not that good either. Can we have a typescript-alike tool that integrates the "best parts of javascript" and defaults to 'use strict'? if there is one I'm in.
- aeosynth 11y ago
  Babel + Flow?
elwell 11y ago
This is being portrayed as clear code / a helpful pattern?? class GraphQuery extends Query { static parse(object: any): Try<GraphQuery> { return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => { return Filter.parse(object.where).flatMap((filter: Option<Filter>) => { return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => { return new Success(new GraphQuery( filter, groupBy, timeRange )); }); }); }); } }
hack_mmmm 11y ago
Where is the developer community going 2 years from now? I think we can derive some sort of Moore's law for new languages/frameworks for JS/Web/Mobile. Objective C and now Swift. Coffee script and now Type script. JS frameworks and more frameworks. What can be the tighter bound Moore's law alternative for new frameworks and languages for Web / Mobile/ IOT. It almost always doubles every two years for sure.
ziahamza 11y ago
I wonder by Babel was ruled out, in conjunction with Flow. DefinatelyTyped was a game changer for us, as it already has a large repository for popular libraries. But except that, typescript has some catch up to do in terms of typesystem with Flow.
ilaksh 11y ago
Embrace, extend, extinguish. TypeScript doesn't implement ES6 fully.
arcosdev 11y ago
I am trying desperately to understand why TS. How does lumping in the baggage of Java/C# onto a functional language like JS make it better? We have to wait for the previous generation to retire or die before we can get critical mass on the next idea. - Douglas Crockford

327 points by matm 11y ago

interesting. we use coffeescript at nootrobox.com, but as you noted, it doesn't have a lot of hand rails. many a time, i've run javascript through a js2coffee translator to verify. will look into typescript.

unoti 11y ago

> It’s reasonable to assume "foo bar and hello world" will compile to either: > foo(bar) && hello(world) > foo(bar && hello(world)) Feel free to sprinkle in additional operators to increase the clarity and readability of your code. Coffeescript is extreme in what it allows. But even C code can be made more clear by using more operators than the compiler actually demands. I'm not really trying to come to the defense of Coffeescript here, but I think it's worth noting that adding more operators for clarity is a good thing. I even go as far as adding additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression. Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse.

krisdol 11y ago
agreed, add a good linter and problem solved. Ruby has been this flexible since its inception and you don't see people complaining about ambiguity because they learn how the language works. When there's ambiguity, be explicit.
- seiji 11y ago
  When there's ambiguity, be explicit. Many (too many) programers seem to take a viewpoint of "only type the minimum numbers of characters necessary to get something to work." Then they make their programming goal to be the least characters possible as long as the compiler accepts their input. complaining about ambiguity because they learn how the language works. Some programmers also enjoy learning all the ambiguous edge cases then making sure their code fits them exactly in the way they intend, but not necessarily the way others will read the code. That's why we end up with awful things like "if (abc) def; else hij;" or worse "if (abc) { def; } else hij;", etc. Plus, if your language isn't line-sensitive, using weak syntax but pretty alignment is just a recipe for future failures a few steps removed from when you originally introduced the future inconsistencies.
  - vlunkr 11y ago
    Ugh, I used to write coffeescript and I was that way for a while. I left off parens, brackets, commas, etc. wherever possible. I thought it was great at the time, but when I came back to the code after writing in other languages it looked awful, and I wasn't always sure how to read it. Being a little more verbose will save you a lot of time in the future.
- cma 11y ago
  Ruby had to make changes for almost this exact syntax case after it bit people by the thousands, they added: foo () (irb) :2: warning: don't put space before argument parentheses .
  - ninjin 11y ago
    Julia, as of v0.4, has deprecated this syntax [1]. I am not sure where it originally stems from, C? It makes sense from a compiler stand-point since the argument call semantics would most likely be inferred after tokenisation. [1]: https://github.com/JuliaLang/julia/commit/28e7bd4536d06a9e139ea3e3f8e8c868543fa861 https://github.com/JuliaLang/julia/commit/28e7bd4536d06a9e13...
- Daishiman 11y ago
  As a person who uses Python to a great degree because of its explicitness, I complain about this in Ruby all the time.
davnicwil 11y ago
> [I use] additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression For me this was one of the greatest lessons of Clean Code by Bob Martin, in my opinion a wonderful book which completely changed and dramatically improved the way I write code. By improvement I mean simply the ease with which I can understand and modify my own code months after writing it/ seeing it last. There's a slight contradiction here with another great lesson of that book though which is short code (by lines) > longer code simply because it's easier to consume in a single glance. There's certainly a delicate balance at play here. It's a great thing to break down a complex process into steps, naming those steps as you go, and storing things in variables achieves that. However sometimes a better tool, and again another frequent suggestion in Clean Code (really, all credit to Bob Martin for all these ideas) is to instead break the steps into clearly-named functions, if this is possible. Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise. Another great tool for the belt and one of the reasons I have come to always prefer programming in a functional style vs a more stateful, OO style, where I can (even within pretty OO languages such as Java - though the lambdas in 8 have greatly improved the ease with which this can be done).
- jfaucett 11y ago
  "Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise". Couldnt agree more, variables are just clutter you have to keep mental track of, and working with series of transformations is much easier (for me at least) to process. I would be interested to know if its like this for all developers, perhaps not, since I know some that are also opposed to recursion. but for me this: sum([]) = 0. sum([H|T]) = H + sum(T). is much easier to understand than: function sum(ary) { var i = ary.length, res; while(--i) { res += ary[i]; } return res; }
  - ahoge 11y ago
    function sum(array) { return array.reduce((a, b) => a + b); } With a loop: function sum(array) { let acc = 0; for(let val of array) { acc += val; } return acc; }
bad_user 11y ago
In most languages the parsing rules are pretty sane even for humans. The question you're quoting is the perfect example of a rule that's unreasonable, no matter the answer, because there's no way in hell a normal person can remember that without first being burned and I'm pretty sure that's hard for the compiler to parse as well. > Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse But regardless of the truthiness of this statement, it has no value. It's like saying that no matter what you eat, in large quantities it can cause humans harm. And yet there's a clear distinction between ingesting mercury or lettuce.
- unoti 11y ago
  The message is: write clear code. Writing ambiguous code is a sin committed by the developer, not the language (although it is easier to commit that sin in CoffeeScript).
catshirt 11y ago
definitely! and, be consistent. an example that is clear and consistent, albeit contrived, would be to wrap arguments when there are more than one: foo bar foo (bin, bar) or if that's too "iffy" for you, you just always wrap with parens!
- kaoD 11y ago
  In CoffeeScript I always do (foo bin, bar) when I need the clarity. Found it in a major style guide and I loved it. E.g. (foo bar) and (hello world)
  - arohner 11y ago
    Only two steps away from embracing the dark side: (and (foo bar) (hello world))
    - eru 11y ago
      Or from the other dark side (Haskell): foo bar && hello world and for more than one argument: foo bin bar && hello world
  - deleted 11y ago
    [deleted]
kazinator 11y ago
> any language will allow you to write expressions that are hard for humans to parse The problem isn't "hard to parse", but rather "easy to parse --- in two or more ways".
smilekzs 11y ago
Livescript has sane defaults: `foo bar and hello world` -> `foo(bar) && hello(world)`

chimeracoder 11y ago

The biggest advantage of TypeScript is that the output is unminified Javascript that closely resembles the input. In fact, you could show someone the output and convince them that you wrote the Javascript manually (rather than generating it from the TypeScript). This makes it really easy to interop with existing Javascript code, but it also makes it really easy for non-Typescript developers to pick up. For me, learning Typescript was pretty quick, because valid Javascript is already valid Typescript. All I had to do was remember the syntax for (optional) type annotations. Learning ES6 was actually the bigger hurdle, not Typescript.

cfontes 11y ago

I've been playing around with typescript and together with IntelliJ it's just great... Fast transpiling, easy to config, easy to debug, typed, the list goes on... The only thing that toke me a while to understand at the start was the whole "Definetly Typed" repo, why and how to use it. It is a bit strange to have to add types as you develop but you can live with it after it sits in. There is also Angular 2 which mergers very well with it, friendly advice, try it!

santialbo 11y ago
I hope this new feature https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm... means that little by little the type definitions will move to the projects themselves rather than having all of them together in a single repo.
- WorldMaker 11y ago
  Yes, DefinitelyTyped has gotten huge and it would be great to at least see npm packages own typing definitions for themselves. Unfortunately, there will still be plenty of npm package maintainers that won't care for Typescript definitions in their repositories and I still think there probably needs to be a more distributed type definition package management option than DefinitelyTyped. (I don't know what that would look like just yet, otherwise I'd probably have tried to build it.)
- cfontes 11y ago
  I hope you are right!
- pyrophane 11y ago
  Absolutely needed. While the Definitely Typed project is a commendable effort, the definitions themselves are often incomplete and out of date, which is problematic because, at least in my mind, an out of date type definition is worse than having no definition at all. The problem core of the problem is that many of the definitions they host are contributed as one-offs by developers who create them as needed, and often there is no one responsible for making sure they get updated in lock step with the library itself. The only way I can think to solve this is to have a contributor to the library itself be responsible for maintaining its type definition, so that keeping it up to date becomes part of the release process. Of course, really everyone should just switch development to typescript so that the defs get generated automatically ;)

mreiland 11y ago

I'll never understand why people don't just use javascript.

Animats 11y ago
But then you wouldn't have a complicated build process to run, allowing free time for web surfing.
dkarapetyan 11y ago
People did but now that there are better languages that transpile to it and are just as readable and using plain javascript is kinda silly. TypeScript is a superset of javascript so if you're not using it you better have a really good technical reason.
rblatz 11y ago
Because the tooling you get when you start using a statically typed language is superior. In a massive JS application things become a lot easier to refactor when you start using Typescript.
- ex_ex_nihilo 11y ago
  Javascript is a typed language.
  - alextgordon 11y ago
    and that type is the string. > 3 == "3" true > 3 * "3" 9
    - ex_ex_nihilo 11y ago
      In the above case, Javascript is coercing the strings to numbers. === does no type coercion. You can also coerce types manually. JS is not statically typed, but it is typed.
      - 11y ago

williamcotton 11y ago

There's no need to choose between TypeScript or Babel! You can use TypeScript with --target es6 and then use babel as a secondary transpiler.

dangoor 11y ago
Isn't the problem that the TypeScript compiler doesn't support all of the ES6 features that Babel does?
claar 11y ago
This was my first thought too, but this screws up source maps and I can't think of how to fix source maps when using two transpilers. Any ideas?

zyxley 11y ago

After Coffeescript, it's really hard to go back to excess brackets everywhere. I really wish there was a Coffeetypescript.

acjohnson55 11y ago
I used to feel the same way, but now I greatly prefer languages with brackets. Refactoring and auto-formatting in indentation-sensitive languages can be a real pain. Semicolons, though, I have no use for. Pity that omitting them in JS potentially leaves you open to some nasty issues.
- jessaustin 11y ago
  Pity that omitting them in JS potentially leaves you open to some nasty issues. You may have seen this, but if not: http://standardjs.com/ http://standardjs.com/
- WorldMaker 11y ago
  I've been using semicolon-free Typescript a lot lately (and really liking it that way) and its transpiler is ASI (automatic semicolon insertion) aware so it ends up adding the semicolons back into its JS output, which you can use as a safety net if you are worried that you don't quite have a handle on ASI. That said, JS ASI is not much different than Python/Coffeescript newline rules and if you are comfortable programming semicolon free in those languages there shouldn't be a reason that you should feel uncomfortable going semicolon free in Typescript and/or JS. The nasty issues are in fact mostly the same as Python/Coffescript.
- Nadya 11y ago
  >Pity that omitting them in JS potentially leaves you open to some nasty issues. There is only a single instance I think of that is of legitimate concern - which is #4 listed on this blog [0]. The rest, to me, seem like arbitrarily shitty formatting or scenarios that never arise in an attempt to show why semicolons are needed. i ++ j Who would write that? Why would anyone write that? That being said - "remove all semicolons except the times you need semicolons" is silly. I also personally dislike the look of prefixed semicolons, so I'll continue to add semicolons. But I disagree the "nasty issues" are a legitimate concern anymore than "adding semicolons where they don't belong" is a legitimate concern. Both can bite you in the ass and both require a small understanding of where semicolons are needed and how Javascript gets parsed. Ultimately I think having semicolons will increase the amount of people who contribute - as people will be more comfortable with that style - but I think to have or to not have semicolons is a stylistic choice in the end. [0] http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...

kyrre 11y ago

How about using JavaScript with flow?

jiaweihli 11y ago
We considered Flow initially as well - but aside from its built-in maybe types (we use Monapt for this!), it's a subset of TypeScript feature-wise that doesn't iterate as quickly.
- WorldMaker 11y ago
  Side question: when evaluating/updating Monapt did you take a look at any of the "Fantasy Land" compliant implementations? (https://github.com/fantasyland/fantasy-land https://github.com/fantasyland/fantasy-land)
  - jiaweihli 11y ago
    Ah! I think I saw this awhile back. I didn't refer to it too much when working on Monapt since it seems to serve a more abstract purpose, and since Monapt's original purpose was to emulate Scala syntax.
- Keats 11y ago
  Which feature are you using in TypeScript that wasn't in Flow?
  - jiaweihli 11y ago
    let, const, decorators, string interpolation, other ES6/7 goodies. Also a few other compelling things like abstract classes and community type definitions.
chimeracoder 11y ago
> How about using JavaScript with flow? Flow is not really fundamentally different from Typescript. The syntax is almost the exact same. I tried them out side-by-side for the same project a few months ago. The main difference was that Typescript was installable through npm and simply read and wrote files to the directory, whereas Flow required an OCaml binary and ran a client-server setup that required some fiddling to get working. Flow is designed to work better with React, so it has that going for it, but if you're not using React, Typescript is almost exactly the same.

nv-vn 11y ago

>Non-mainstream syntax seems like this author already knew what they were looking for from the beginning.

barrkel 11y ago

The advantages of CoffeeScript that TypeScript is lacking aren't mentioned. I wouldn't casually give up lightweight indentation-based syntax and optional parentheses, despite the confusion both can cause. CoffeeScript makes it easy to create small DSLs that are fairly readable. Implicit hashes make for easy keyword-based arguments, only requiring '->' to make a value lazy is a bit better than () =>, and in particular not needing to end a big block of mixed code and data in a random mix of ")}]});" is a surprisingly big win, aesthetically.

tallerholler 11y ago
imo these (esp indentation) are why I don't plan on abandoning coffeescript any time soon.. es6 be damned!
- drumdance 11y ago
  Same here - indentation saves so much trouble. We have a coding style guide that covers things like when to use parentheses and when not.
cristianpascu 11y ago
The first thought that came into mind when reading the article was: "We write bad code, the language is to blame". If all your variables are named "i", than yes, you have issues. If your code goes deeper and deeper in callbacks, it's not the language, it's you. No language on Earth will save you from that.
- eru 11y ago
  > If your code goes deeper and deeper in callbacks, it's not the language, it's you. No language on Earth will save you from that. You can do 20 layers of callbacks in Haskell without any problem. That's how Haskell does imperative blocks of code (ie monads).
Retozi 11y ago
I have written a full production application in CS before switching to JS and then eventually migrated to TS. I was one of the "you save characters, you gain readability" proponents as well (I love Python too). However, it is a terribly flawed argument. Typing characters is incredibly cheap. Debugging and refactoring in a dynamic language. However, is very time-consuming. You might be a tad slower writing Typescript (with autocompletion and typechecking, I doubt it though). But over the whole lifecycle of a codebase, Typescript is a lot faster for everything but very small projects. I have done refactors in Typescript in hours that would have taken me days in CS... multiple times. Additionally the human brain can adjust to predictable noise very well (brackets). After a training period, I find Javascript and Typescript almost as readable as MY Coffeescript. However, even when developing 8 hours for multiple months in Coffeescript, I always had a hard time to grok other people's Coffeescript. There is just too much freedom. This does not happen that easy with Javascript/Typescript. Generally, static typing in a complex user interface is a huge huge win productivity wise. While you type more characters, you are still faster over the lifecycle of a project. Hitting keys on your keyboard is literally the least time-consuming part of programming.

abritinthebay 11y ago

After using ES2015 patterns for a while now CoffeeScript looks utterly barbaric in comparison. That said it's really for Ruby programmers (or those who know/want to know Ruby) who write JavaScript so I guess it will continue to fill that void. It adds no utility outside of that niche anymore however. TypeScript is great but I honestly prefer ES2015/ES6 + Flow comments. It means I write native JavaScript (ok, for now a transpile step, but that will go away in time and I'll still have valid JS code) but get all the benefits of typing like in TypeScript. However TypeScript is still pretty awesome, though I find the syntax rather verbose.

shady_trails 11y ago
You have an interesting opinion. Coffeescript has, for several years now, encompassed nearly the entire API surface of ES2015. * Comprehensions (more flexible with Coffeescript). Wait, that's ES7 now. * Template strings * For .. Of loops * Destructing * Classes. ES2015 has an awful implementation of this, without allowing an syntax for binding methods. Also enforces the somewhat arbitrary requirement of function properties only, as opposed to any type I choose. Don't forget, mixins with Coffeescript classes is a breeze, but no support with ES2015. * Arrow functions. Unnecessary syntax with ES2015 (the parens even without arguments), not to mention confusing implicit return. * Generators with ES2105. If you find a use for these in front end web dev I'll buy you a beer. ES2015 does succeed in introducing an entire set of confusing ideas: we rolled for years with var's, but now I get my hand held with const and let, because figuring out how var works (or just relying on Coffeescript to handle it for you) is too challenging. The point here is that it is frustrating to see people jump on the ES2015 bandwagon when Coffeescript has had the same feature set for years. It suffered adoption because of developers who didn't want to learn `another` language. I have met a tremendous quantity of developers - myself included - who initially rebelled against the use of Coffeescript, only to eventually fall in love with it.
- abritinthebay 11y ago
  > Coffeescript has, for several years now, encompassed nearly the entire API surface of ES2015. Agreed. I didn't say features; I said looked. It looks horrible in comparison. ES6/7 code is much cleaner, clearer, and more idiomatic, than CoffeeScript. (in my experience, and I've used/debugged/worked with a LOT of both) Not going to crap all over the features of CoffeeScript, those were good (though they produced pretty awful looking JS code as a result). I would say however it wasn't worth the trade off in debugging pain.

boothead 11y ago

If you're an analytics shop (presumably) working with streams of events, I'm going to go out on a limb and say that not picking a functional language (purescript or elm) is a mistake. It's fits the domain so well, take a look at the mileage that slamdata are getting out of purescript for example. note I'm being deliberately provocative with the above statement to promote discussion, not argument. :-)

oatmealsnap 11y ago
I know zero developers who know purescript or elm. That is a hiring problem, especially for young companies.
- jdhawk 11y ago
  Then hire someone who knows Coffee or Type and teach them Purescript? Its not that hard for developers to pick up a new syntax if they understand the framework and ecosystem around it...
  - 15155 11y ago
    Calling PureScript "new syntax" is a huge understatement. I love PureScript (and Haskell, FWIW), but it's a huge paradigm shift from CS, TS, or JS.
- alanh 11y ago
  I know a few Elm developers. Using a less mainstream language can actually be a boon to hiring. (Isn’t there a classic PG essay on how ViaWeb benefitted enormously from using a Lisp when no competitors did?) > Had our first hire start today who applied because we use @elmlang in production. He rocked it! > PS: still hiring :) https://twitter.com/rtfeldman/status/656238188961226752 https://twitter.com/rtfeldman/status/656238188961226752 Furthermore, I’ve learned so many languages on the job in my career that I am unsympathetic to companies who refuse to believe that people who have learned programming can continue to learn programming!
  - 11y ago

jasode 11y ago

>Variable initialization and reassignment are the same It’s easy to accidentally overwrite a variable from a higher scope as a codebase increases in depth. Yep. There was a previous July 2013 article and related reddit thread about it.[1] The CoffeeScript compiler devs themselves were bitten by their own strange scoping rules! As to the other question about why people don't just write raw Javascript, Eric Lippert explained why plain Javascript is inadequate if you want to do more than just "make the monkey dance"[3] -- a.k.a. "large complex apps". [1]https://www.reddit.com/comments/1j1cw7 https://www.reddit.com/comments/1j1cw7 [2]https://github.com/jashkenas/coffee-script/commit/7f1088054c91f5ab3bf1ea1098b6ebffaa29a5a9 https://github.com/jashkenas/coffee-script/commit/7f1088054c... [3]http://programmers.stackexchange.com/a/221658 http://programmers.stackexchange.com/a/221658

octref 11y ago

Did you also consider Flow[0] as an alternative? I'm now using ES6 with Babel to build some small side-projects and it has been a great experience. But as the codebase grows, I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS. I wonder what will happen to all those compile-to-JS languages once ES6 becomes supported everywhere. [0]: http://flowtype.org/ http://flowtype.org/

chimeracoder 11y ago
> I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS. The Flow type annotations are almost identical to Typescript. There's one edge case around one of them requiring a space before/after the colon and the other not, but I can't remember what it is. I just tried running one of the Flow examples through the Typescript playground and it worked fine[0]. The biggest differences between Flow and Typescript are how you run the build system (`tsc` versus the Flow server) and the file extension you put on the file. [0] http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20https%3A%2F%2Fsmellegantcode.wordpress.com%2F2015%2F04%2F02%2Ftypescript-1-5-get-the-decorators-in%2F%0Afunction%20foo(x%3A%20string%2C%20y%3A%20number)%3A%20string%20%7B%0A%20%20return%20x.length%20*%20y%3B%0A%7D%0Afoo('Hello'%2C%2042)%3B http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20htt...
- samwgoldman 11y ago
  While the type annotation syntax between Flow and Typescript are mostly identical (this is intentional), there are a bunch of differences between them: * TypeScript allows unsound casting, Flow doesn't. These casts are very practical, as you might know more than the analyzer. Flow takes a stricter position here, which is a theme. * Function are bivariant w.r.t. their parameters (which is unsound) in TypeScript, but contravariant in Flow. Again, this is an intentional, practical choice, but Flow emphasizes soundness. * TypeScript asks users to add annotations in scenarios where Flow will infer types. TypeScript will infer any (there is a "no implicit any" option). * Classes in Flow are nominal (interfaces are structural). Classes are structural in TypeScript. * Flow adds no additional runtime syntax to JavaScript; TypeScript does (enums, for example). Flow does support some ES2016 features (async/await, object spread), but generally holds off on experimental features (stage < 2). * Flow has a couple interesting features absent in TypeScript, like disjoint unions. I suspect/hope both systems will converge on useful features like this. * TypeScript treats null as a bottom type, but Flow uses explicit "maybe types."

seivan 11y ago

Have they fixed the issue where it was really hard to work with third party libraries unless they have type definitions? One problem I saw that it was heard to try out release candidates for React when they were lacking type definitions. Apart from that I really like TypeScript.

pyrophane 11y ago
Not that I can tell, and it is the one thing keeping me from embracing TypeScript. To get the full benefit from TS you really need to have type definitions for all 3rd-party libraries you use. Libs that aren't written in TS generally don't provide them, and many of the community definitions maintained by DefinitelyTyped are badly out of date or incomplete, which in my mind is worse than having no definition at all. Without defs you can get the compiler to stop complaining by turning off implicit any errors and creating definitions for just a few things like node's require and exports, but this felt like too much of a hack for me to really feel good about it. If anyone has found solid solution to this problem please let me know. I love TypeScript but don't want to spend too much time futzing with definitions.

OmarIsmail 11y ago

Once you go typed JS you don't go back. We had a large existing pure JS codebase, so Facebook's Flow was a better fit for us. We still have some portions of our code that don't have type annotations, and invariably that's where the majority of new bugs are introduced. Now we have a policy of making sure all the files we touch are typed, and adding types to a file if it doesn't already have it. Types + React is a whole new ballgame when it comes to front end dev.

jaked89 11y ago
Every JS code is a valid TS, since TS is a superset of JS. You can benefit immoderately from compiling your existing codebase in TS; you'll probably discover some bugs, even before adding any annotations.
- DCoder 11y ago
  > Every JS code is a valid TS, since TS is a superset of JS. There are still cases where you'll need to sprinkle <any>. For example: var state = { foo: 1 }; if(something) { state.bar = 2; } is valid JS, but the TS compiler will complain that `state` does not have a member named `bar`.
  - addicted 11y ago
    The TS compiler will complain but still generate working JS code, so you don't lose anything.
    - DCoder 11y ago
      But the compiler's output will be polluted with these false positives, making it harder to see actual errors. (Also, there's a compiler flag to prevent codegen on error, which comes in handy sometimes.)
- OmarIsmail 11y ago
  We made the decision some months ago and Flow's ES6 support was better than TypeScript's (and we already have a lot of ES6 code). We also have an established toolchain with gulp and browserify and babel, and again, at the time TS didn't play as nicely (vs Flow which just worked). Things are definitely improving in the TS world, and I keep tabs on it. The fortunate thing is that both Flow and TS' annotations are compatible, so it should be relatively easy to switch from one to another. Whichever one you go with doesn't actually matter though. As long as you go with one of them you'll see a massive increase in productivity vs vanilla JS.

dreamdu5t 11y ago

Why not Haskell? If you're going to be transpiling to JS might as well get all the power of purity and robust typing.

jonahx 11y ago
Which haskell to js project do you recommend? The wiki lists a number of them, but it's to tell which is the best choice.
- dreamdu5t 11y ago
  GHCJS. That said, there's not necessarily a best choice because it depends on what type of application you're transpiling. There's an Om-like UI project with bindings to virtual-dom https://github.com/boothead/oHm https://github.com/boothead/oHm as well as various react bindings such as https://github.com/joelburget/react-haskell https://github.com/joelburget/react-haskell
- 15155 11y ago
  ghcjs. For something that follows the semantics of JS and produces very readable code (a la TypeScript), PureScript is really nice.
mrspeaker 11y ago
I kind of agree with this - if you want to do JavaScript, do JavaScript... if you're going to bother transpiling to non-standard JavaScript - go all the way and get the power of Haskell!
- z1mm32m4n 11y ago
  They did mention in the article that PureScript was one of the languages they considered rewriting their stack in. PureScript is very heavily influenced by Haskell (they're almost the same languages), but among other things PureScript is strictly evaluated. It seems from the article like the reason why the dismissed it was that it interoperated poorly with existing vanilla JavaScript libraries.

RomanPushkin 11y ago

)); }); // I }); // love }); // TypeScript } } Actual code from the article above. Just added comments.

RussianCow 11y ago
Trailing parents/braces seems like a bad reason to dislike a language. Ever heard of Lisp? :)
- lazugod 11y ago
  Presumably that's why some people dislike Lisp too.
  - soapdog 11y ago
    Is that a valid reason? I know that personal taste plays a strong and important role but typescript is really cool.
    - giancarlostoro 11y ago
      I didn't like Lisp for a long time because of it, I've since given up and tried Lisp. My friends don't care for Lisp probably because of that as well.
      - mdpopescu 11y ago
        I could get over the parentheses but CAR and CDR instead of HEAD / TAIL or FIRST / REST annoy the crap out of me.
        soapdog 11y ago
        CAR means Content of Address part of Register and CDR means Content of Decrement part of Register. They were tied to the 36-bits nature of the first LISP machines, with 15 bits to CAR and 15 bits to CDR (plus 2 bits for tags IIRC). So its not just naming keys in a structure, those had a very low level meaning related the the implementation of the CONS cell structure in hardware.

hharnisch 11y ago

Migrating away from CoffeeScript too. I'll be happy to have the ternary operator back. The existential operator was handy but became a source of land mines as the project grew. Will miss list comprehensions though.

tiglionabbit 11y ago
Seriously? 'You' ? 'like' : 'this'; if 'better' then 'than' else 'this?'
- hharnisch 11y ago
  Ternary operator is more compact and consistent with many other programming languages. The bigger issue was the bugs the existential operator led to. Not worth it when checking for existence wasn't a problem in javascript anyways.
  - tiglionabbit 11y ago
    What sort of issues were you having with the existential operator? I've honestly never had a problem with that, and I often wish I had it in other programming languages.

hackerboos 11y ago

Typescript looks great until you realize you need special files that match types in third-part libraries: http://www.typescriptlang.org/Handbook#writing-dts-files http://www.typescriptlang.org/Handbook#writing-dts-files Will your third-party-lib that doesn't use Typescript keep a dts file? Who knows...

radicalbyte 11y ago
..and for that work, you get a whole class of errors removed from your code.. Luckily most of the big libraries are covered; it's mainly smaller stuff - think random jQuery plugins - that aren't covered. These are libraries which are often hacked together, lack tests, clear documentation and anything approaching support. So things that you shouldn't really rely on.

jamra 11y ago

I've been looking into TypeScript recently, but after having clicked on this article, I'm thinking that I'll stick with ES6. Being able to have code completion in javascript is nice, but it's also something that you can work around by developing a good work regiment using browser-based debugging tools. The benefit of typescript is substantial, but circumventable. The drawback, one that I haven't seen anyone mention yet, is now having to deal with generics inside javascript. Trying to reason about this code and spending most of my cognitive focus on how the author is dealing with generics adds an entirely different complexity to reading and understanding javascript. On one hand, it's helpful to have types. On the other, adding a very Microsofty overhead to programming using meta-data on your data and generics inside javascript makes me want to pass on this.

kuschku 11y ago
It depends – if you write a library, using typescript is extremely helpful. If you just want to write a site while using a bunch of libraries, it might be useful to use VSCode, which provides autocomplete for normal JS code, as long as at least parts of the code have typescript bindings.
smt88 11y ago
Reasoning about generics in TypeScript isn't bad. I'm not totally sure what you meant by that. I just rewrote an API in TypeScript for Node, and I didn't spend most of my time reasoning about meta-anything. TypeScript mostly added amazing, insightful static analysis, and when I ran my code, it almost always worked perfectly at runtime. The debugger in VSCode is great, too!
- spion 11y ago
  I think its a common meme that started because of the complexity of C++ templates and continues to be perpetuated by the creators (and moreso, users) of Go as an excuse to not implement generics. Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.
  - 11y ago

deleted 11y ago

[deleted]

LordHumungous 11y ago

Anyone know if TypeScript will ever be included in ECMAScript standard? If it is I will love Microsoft forever.

tracker1 11y ago
It's not that far off of ActionScript3, or ES4's proposals for strong typing... I think things are probably headed that way, I would love for the AS guys to integrate as a Babel plugin for typing (similar to flow), so that it's just one tool to rule them all... FB already deferred to Babel for JSX processing.

feyn 11y ago

You can have my CoffeeScript when you pry it from my cold, dead hands.

naitsirc 11y ago

Not trying to sell CoffeeScript here but most reasons of the author for dropping it looks more like a fault of the developer instead of the tool. * Ambiguous syntax? Just add a few parenthesis. * You don't like the existencial operator? Learn some JS, being able to easily differentiate between a truthy value and the existence of a variable with a single character is as sweet as it can get. * Comparing a language to Babel? Doesn't make sense. Babel translate ES6/2015 to ES5 for compatibility. Comparing ES6/2015 to CoffeeScript makes sense. * CoffeeScript is the reason you couldn't scale/solve data syncing or redrawable views? JS/CS/TypeScript/etc have nothing to do with that! Maybe he was thinking about Backbone? Seems like the guy is confusing tools and languages... and making (bad) decisions because of that. Personally I'm not going back to writing { }, return and ;'s :-)

avmich 11y ago
Language should be natural enough for the person to use and good enough to apply for the problem at hand. We don't yet know how to have consistently good solutions for these requirements. For me, {} are better than spaces - perhaps because of habits, but what will I get in - non-effortless - changing my habit in this place? "Add a few parenthesis" advice seems the opposite - don't we want not to have to use artifacts for clarification, but have simple and natural defaults working? Etc.
- redka 11y ago
  It's not a choice of this versus that. In CoffeeScript you don't write spaces instead {} - you write neither. You express this with indentation anyway so why the extra boilerplate? CoffeeScript removes a lot of the excess work while TypeScript actually does the opposite.
tallerholler 11y ago
I completely agree with you but I think another reason some people aren't as keen to coffeescript as others might have to do with their other coding experiences/languages/habits... Coming from many years of python development, coffeescript is a natural fit...

_pdp_ 11y ago

I typically don't get into these types of conversations but here we go. CoffeeScript is a lovely language by all means and at my company we use it extensively because it reduces the amount of boiler plate code by a factor of 10 maybe even 20. Here is a simple example: some_func = (callback) -> callback new Error 'boom' some_func (err) -> return console.log err if err console.log 'everything is fine' The alternative JavaScript version is just too much to read. This makes huge difference when you write async code and no amount of TypeScript can really help it.

yareally 11y ago
I would disagree about that. TypeScript 1.6 has experimental support for async/await with ECMA6 + promises. TypeScript 2.0 will bring support for it with ECMA 3 and ECMA 5. https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/issues/1664 https://github.com/Microsoft/TypeScript/issues/1664
mrspeaker 11y ago
Have you tried diving into ES6 yet? It's much more terse now that they stole the good bits from coffeescript... let some_func = callback => callback(new Error('boom')); let some_func = err => console.log(err || 'everything is fine');
- warfangle 11y ago
  I promise I started writing my comment before I saw yours ;)
warfangle 11y ago
The alternative JavaScript version: let some_func = (callback) => callback(new Error('boom')) let some_other_func = (err) => console.log(err || 'everything is fine') What makes a huge difference is when you write async code with generators, coroutines and promises: let some_func = co(function*() { try { const someData = yield asyncRequest(some_url); console.log('asyncRequest resolved with %j', someData) } catch(e) { console.log('asyncRequest rejected with %j', e); } });

bachmeier 11y ago

Is Typescript a good language for someone that has done very little in Javascript? Are resources available for newbies? I've programmed in dozens of languages over the last 30 years, so I'm not a beginning programmer, but have simply never messed with Javascript. How does Typescript compare with Dart? Is Javascript the place to start?

recursive 11y ago
I don't think you can expect to use typescript without really understanding javascript. Not to say you shouldn't learn typescript first. But by the time you're fluent in typescript, you basically know javascript also.

vorg 11y ago

> Existential operator accessor (?.) is a leaky abstraction for null I found this out the hard way when using it in groovy a while back. The Options abstraction you describe is better, or the one in Java 8, which Groovy still hasn't brought into its syntax. Groovy's creator James Strachan talked a lot about how he designed Groovy to avoid the "leaky abstractions" in Java.

jiaweihli 11y ago
There is also this gem of a quote by him[1]: > I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy. [1] http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl...

hit8run 11y ago

Is it really that important nowadays to build webapps in pure js or abstractions of it? We read articles about how many smartphones get superslow when executing loads of JS code, how broken the development process is and how framework x tries to solve that broken flow. We make use of super heavy and complicated toolchains that are outdated half a year from now. I often hear and read things like: "You still use bower instead of npm?", "You still use coffee script?! Go with TypeScript.", "BackboneJS? Why not go with Angular?". Some requirements make it mandatory to do lots of stuff in the frontend. For example: SoundCloud is supposed to continue playing songs when users navigate around. Okay they need a pure JS page refresh experience. But the standard CRUD admin panel you write 90% of the time? There it's not wrong if a browser does what it is supposed to do. Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?

z1mm32m4n 11y ago
I don't know if you've used Heap before, but they're (necessarily) doing quite a bit more than loading a page when a user clicks on a link. Some applications necessitate more sophisticated user interactions.
Uehreka 11y ago
Single Page Applications can enhance the user experience in many ways, even with more "boring" apps: * Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward. * Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one. * Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process. Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from: * Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text". * Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens. * Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions. My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.

kailuowang 11y ago

From the cons the author listed for typescript, this article is way too generous with this language. Like CoffeeScript it is just an intermediate solution to the problems JS has. We are still far away from inventing a good language for UI logic development. IMO Elm is pointing in the right direction, Scala.JS is getting some interesting traction and momentum.

jiaweihli 11y ago
Personally I'm not a huge fan of mixing language with UI architecture - it seems like it would slow down development on both fronts. Replacement costs are also much higher. That aside, we'll talk about how we built our architecture in our next blog post! I promise you that I thoroughly pored over the Elm architecture tutorial[1] before designing any building blocks. [1] https://github.com/evancz/elm-architecture-tutorial/ https://github.com/evancz/elm-architecture-tutorial/

nerdwaller 11y ago

Kind of feels like they're trying to jump from one popular thing to the next. The JavaScript world is exhausting.

vectorpush 11y ago

I do wish CoffeeScript had stronger type support, however, I don't want to give up indentation, optional object brackets, optional function parens and easy loops. There are a ton of other CoffeeScript features I love like the string interpolation syntax, comprehensions, implicit return, @ for this, improved switch syntax, ranges and a ton of other stuff, but I'm going to hang on to those first four for as long as its practical to do so.

jpochtar 11y ago

If you want to migrate a coffeescript codebase to typescript, try out https://github.com/palantir/coffeescript-to-typescript https://github.com/palantir/coffeescript-to-typescript which should do it for you automatically

tkubacki 11y ago

I heard Wikia gave up on TS - wondering why people are leaving TS ? Too much friction ?

ausjke 11y ago

http://www.walkercoderanger.com/blog/2014/02/typescript-isnt-the-answer/ http://www.walkercoderanger.com/blog/2014/02/typescript-isnt... so this blog is arguing typescript is not that good either. Can we have a typescript-alike tool that integrates the "best parts of javascript" and defaults to 'use strict'? if there is one I'm in.

aeosynth 11y ago
Babel + Flow?

elwell 11y ago

This is being portrayed as clear code / a helpful pattern?? class GraphQuery extends Query { static parse(object: any): Try<GraphQuery> { return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => { return Filter.parse(object.where).flatMap((filter: Option<Filter>) => { return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => { return new Success(new GraphQuery( filter, groupBy, timeRange )); }); }); }); } }

hack_mmmm 11y ago

Where is the developer community going 2 years from now? I think we can derive some sort of Moore's law for new languages/frameworks for JS/Web/Mobile. Objective C and now Swift. Coffee script and now Type script. JS frameworks and more frameworks. What can be the tighter bound Moore's law alternative for new frameworks and languages for Web / Mobile/ IOT. It almost always doubles every two years for sure.

ziahamza 11y ago

I wonder by Babel was ruled out, in conjunction with Flow. DefinatelyTyped was a game changer for us, as it already has a large repository for popular libraries. But except that, typescript has some catch up to do in terms of typesystem with Flow.

ilaksh 11y ago

Embrace, extend, extinguish. TypeScript doesn't implement ES6 fully.

arcosdev 11y ago

I am trying desperately to understand why TS. How does lumping in the baggage of Java/C# onto a functional language like JS make it better? We have to wait for the previous generation to retire or die before we can get critical mass on the next idea. - Douglas Crockford