Hacker News new | past | comments | ask | show | jobs | submit login
Goodbye CoffeeScript, Hello TypeScript (heapanalytics.com)
327 points by matm on Oct 20, 2015 | hide | past | favorite | 256 comments



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?


Not at all. You're just not hearing so much about that kind of thing because, in my opinion, we've beaten that dead horse already. The fact that building simple CRUD apps can be done quickly, reliably, and efficiently without the need to be on the cutting-edge of JavaScript wizardry is amazing, but it also means that you probably won't hear about it on Hacker News because it's not what "hackers" (in this case I mean people who like to experiment with new technologies) are getting into.

The only reason why this is becoming more of a "thing" nowadays, at least on blogs and in the media, is because the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea, at least in practice on a grand scale. As a job, many web developers (myself included) use JavaScript only when absolutely necessary, and it's really just to make things "look nice". At work, JavaScript is not the thing that drives our entire application (in fact we have more than a few tests that ensure our apps' critical functions work even when JavaScript is disabled in the browser). But I've been experimenting with Ember, Electron, et. al., and it's pretty cool what you can do nowadays with JS alone. These new toolchains have brought and will continue to allow entirely new genres of web applications to be developed with ease, meaning my job gets a little more interesting. We'll probably always have/need CRUD apps, but as a web developer, your fate is no longer sealed in writing CRUD apps for the rest of your life. That's pretty neat!


"the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea"

No it isn't. This was written nearly 15 years ago: https://bitbucket.org/BerislavLopac/waexplorer


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.


"Is this such a bad thing to keep things simple?"

And you are claim that your way is simpler? To me all the thing that you rant about are just different. If things with the web rendering would started with the front-end instead the back-end, then you would be ranting the same stuff on the opposite side and you would be saying that SPA are simpler.


Beyond the technical reasons mentioned here, I'd wager that the emphasis on front-end specific apps and toolchains also has to do with dividing developers up in to front-end developers (who don't touch the database) and back-end developers (who don't touch HTML/CSS/JS). This approach has its merits and its drawbacks.


Good bye TypeScript, Hello JavaScript


"You still use bower instead of npm?" - this is a poor example, as bower is specifically geared towards frontend assets


npm is pushing pretty heavily towards being the source for both backend and frontend js assets. a lot of interesting work happening on that front.



i seen trend where people prefer to use npm, write libraries, which could be used on both sides, and then use browserify to prepare it for usage in the browser. I am not saying it is good or bad, this is just another trend.


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.


Can't all those three things be done with simple AJAX too, instead of having to make your entire application Javascript based?


Yes, but you often end up with half an angular app: a bit of templating, a bit of boilerplate around your AJAX calls, some AJAX here and there. But you quickly run into problems:

- Your designers need to change the markup of the invalid form alerts, and you have to point them to a string building function in your JS rather than an HTML template.

- Once they change the string builder, you need to run your unit tests to make sure it still works. If you don't have any way to do dependency injection, writing unit tests of client side code will be difficult.

- Now your presentation logic is split between front and back end. This makes engineering tasks like assessing test coverage and refactoring more difficult.

For some use cases AJAX only may work. When I'm doing a side project that involves a lot of visual stuff and little state management, I'll ditch the MVC framework and task runner and work with just jQuery or D3. But if I'm working on a large project where many other people are contributing, I want a framework that helps me write testable code and provides structure to help keep my concerns separated.


Every one of these features is doable in a more traditional web application with something like intercooler.js (which I created). Good UX does not require a SPA and it certainly does not require massive amounts of client-side code.


> 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:

Not really. While your points are all true, the two biggest factors that you can't really escape are 1) your SPA is still a 1 MB download 2) eval'ing 1 MB of JS before rendering is still slower than serving HTML.

SPAs are a better experience, but they're still slower than conventional pages, and I wouldn't recommend their use on high traffic areas of your site, like the landing page.


Sure, and to be fair there are people who needlessly use angular, scrolljacking, and other horrible magicks when building something that doesn't need it. But my experience of the debate has been that there are many many people who think that MVC frameworks are only suitable for "cool" projects like soundcloud, and that the other 90% of front-end developers don't have legitimate use cases for them. I don't think this is a fair or informed assessment of the field, but it can sound like one because it appears to offer a "simple" solution.

As for the 1MB download, angular is about 100KB minified (most of the space in angular is comments, which contain ALL of its documentation). Angular is also used in so many places that if you pull it from a CDN your users should never have to download it. In my experience, my SPAs themselves rarely outweigh 10-20KB. Worst case: I have to download 120KB of JavaScript and parse it. Still though, I find that AJAX requests to slow backends still take up most of the load time -- meaning that if my app was a conventional one, the page would take a while to appear at all, then load instantly. Of course, with Angular 2, I've heard server-side rendering comes into the picture, making the whole "where should I render my templates" discussion moot.

Sure there's a lot of back and forth and a lot of complexity. But in my experience, many clients and businesses want the kinds of modern touches that only a SPA can give them, and the tooling we have around our code exists to make the task easier, even if it may seem complex at first.


The scenarios you describe can be done with JS enhanced HTML pages. No need to do this as a complete single page application requiring tons of boilerplate framework code.


> 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.

That's what middle-click to create a new tab is for.

> 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.

If HN were a single-page app, I wouldn't use HN. Period.

> 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.

Again, that's what middle-click is for.

> 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.

Sure, that's a nice use for JavaScript. I just don't want to have to expose my entire system, and all my data, and every system I can connect to, to malware in return.


I have to admit, I'm not really interested in your restrictions on what people are allowed to use in browsers. You are definitely not the arbiter of the one true way, no matter how right you feel about your opinions.


Are you interested in security and privacy? Are you interested in functionality?

I am, of course, the arbiter of what I permit my browser, running on my computer and accessing my data, to do.


Ok how to middle click on a tablet? Press and hold, but that sucks.

How to middle click with an apple mighty mouse with no middle click? Press and hold cmd whilst clicking left click.

Middle click doesn't work and it if you are about to submit a comment on a thread how do you middle click to load the same page at the same scroll position?


What percentage of internet users either have a middle-click or know how?


Opening a new tab works, but come on... It's a crude tool!


One very important point against SPAs is URLs. URLs are central to the design of the web. Lets say I want to talk about a particular commit on github. I can just pick the URL for that commit and email it to someone else. They can click on the link and land directly on the commit page. If it is a single page app, I will have to tell them 'Go to this URL, click here, and then click there' etc.

Same case with blog posts. Sites like HN would not even exist if everyone published all their posts in SPAs.


Most SPAs I've used handle the routing with JavaScript, making your URL sharing use-case possible. It's not very hard to implement either, that stuff is covered quite early in most AngularJs resources out there. In fact, creating a large SPA without some sort of routing sounds like a nightmare.


Or you can build a SPA that supports jumping to a particular resource with a URL, Like not breaking the back button in a SPA, this is technically possible, even if it is all-to-rarely done.


I hear you loud and clear. But that is what sort of happened:

I figured out I could built simple CRUDS in minutes (literally) using scaffolding, and may a couple hours of editing for special cases.

But I got bored, and went to look for what I could do differently. How to make it "smoother". I'm sure scaffolding and quickly generating CRUD with SPA's will happen soon enough and we will move on to something like "pure browser functions" using links and changing pages statefully.


"Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?" Bloody hell! You've got to be kidding!


  > 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.


> [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).


> 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.

I hate this lesson. And it's not because short code is a bad thing...when you find code that's well structured and broken down such that no method/function needs to be long, it's a joy to read. The problem comes when people learn the rule without learning the why behind it. And that leads to one logical function/method that's huge and has now been broken down into many nested methods/functions simply to satisfy the "none are long" requirement. Now, as a reader, I've still got to keep the entire context of the method/function in my head, but I now have to jump all over the code to find out what the single, large method actually does. I'd rather have a single, 200-line code block to look at than this sort of jumble.

What developers need to learn is that short methods/functions are a consequence of good techniques, not a technique in and of themselves and that long methods/functions are not bad in and of themselves, but they indicate that it's very likely that the developer hasn't put the proper thought into separating concerns and ensuring that each unit of his/her code has a single responsibility.

Sorry to get on my soapbox, but I've seen this "lesson" make ugly code even uglier when programmers don't understand the why behind the lesson.


If you stick to purely functional pieces (=no mutable state), than following the letter of the lesson will yield the spirit---because the context becomes so much simpler.


"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;
    }


    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;
    }


What's the value of sum for an empty array in your example?


The reduce one needs an initial value of 0 for that to work. Then both versions will return 0 if the array is empty.

    array.reduce((a, b) => a + b, 0);


    sum = (values) ->
      values.reduce (result, x) -> result + x


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.


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).


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.


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.


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.


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 .


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/28e7bd4536d06a9e13...


As a person who uses Python to a great degree because of its explicitness, I complain about this in Ruby all the time.


> 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".


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!


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)


Only two steps away from embracing the dark side:

  (and (foo bar) (hello world))


Or from the other dark side (Haskell):

    foo bar && hello world
and for more than one argument:

    foo bin bar && hello world


Livescript has sane defaults: `foo bar and hello world` -> `foo(bar) && hello(world)`


>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

[2]https://github.com/jashkenas/coffee-script/commit/7f1088054c...

[3]http://programmers.stackexchange.com/a/221658


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.


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.


Static typing doesn't have to require typing substantially more characters though (ML-family languages are good example, other examples I can think of is Nim), the syntax choice is quite orthogonal to this but it seems like C-syntax appears in new languages mostly due to its familiarity.


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.


> 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).


imo these (esp indentation) are why I don't plan on abandoning coffeescript any time soon.. es6 be damned!


Same here - indentation saves so much trouble. We have a coding style guide that covers things like when to use parentheses and when not.


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. :-)


I don't think it makes that much sense w.r.t stream events:

1. most of the analytics/event-stream processing will be done on the backend anyway

2. If you are picky enough you can do functional programming in js. Reative.js is decent library for processing streams of events.

What screams to use something more haskell-like, is their example of 'Trys', i.e:

  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
            ));
          });
        });
      });
    }
  }
should look like something like:

  parse : Any -> Try GraphQuery
  parse object = do 
    timeRange <- TimeRange.parse object.over
    filter    <- Filter.parse object.where
    groupBy   <- GroupBy.parse object.by
    return (createGraphQuery filter groupBy timeRange)
(haven't used haskell in quite some time, so maybe I am missing something)


>should look like something like:

    >   parse : Any -> Try GraphQuery
    >   parse object = do 
    >     timeRange <- TimeRange.parse object.over
    >     filter    <- Filter.parse object.where
    >     groupBy   <- GroupBy.parse object.by
    >     return (createGraphQuery filter groupBy timeRange)
New ECMAScript 2015 Style

    parse = ({by, over, where}) => {
      timeRange = TimeRange.parse(over)
      filter    = Filter.parse(where)
      groupBy   = GroupBy.parse(by)
      return createGraphQuery(filter, groupBy, timeRange)
    }
or

    parse = ({by, over, where}) => 
      createGraphQuery(
        Filter.parse(where),
        GroupBy.parse(by),
        TimeRange.parse(over));
or

    parse = ({by, over, where}) => 
      createGraphQuery(
        Filter(where),
        GroupBy(by),
        TimeRange(over));
or

    parse = ({by, over, where}) => createGraphQuery( Filter(where), GroupBy(by), TimeRange(over) );
or

    parse = ({by, over, where}) => c(f(where), g(by), t(over));
and, if you're willing to put a front-end on it:

    parse = ({b, o, w}) => c(f(w), g(b), t(o));

Of course, I have not provided the definitions of `c`, `f`, `g`, or `t`.


This is slightly different from the original code. The reason for all the flatmapping is to avoid continuation if any of the subparsers fail, and notify the caller that something has failed because of {some exception}.

You can avoid excessive nesting/flatmapping with some syntax sugar, but it needs to be sufficiently different from normal declarative code.


I alluded to that in my last note. :)

If you properly define the functions (`c`, `f`, `g`, `t`), you can get the semantics of halted computation on failure. That is essentially what Haskell's `do` notation does.


You're absolutely right! I was hoping someone would point this out, since this is a much cleaner way of writing this code. This is pretty close to how it's done in Scala.

For the purposes of this article, we tried to avoid too much syntax sugar to make it more accessible. That aside, I'd love to add something like this to monapt![1].

[1] https://github.com/jiaweihli/monapt


Here’s a sketch of some potential syntax to simplify your TypeScript so it’s like that Haskell code.

  class GraphQuery extends Query {
    static parse(object: any): Try<GraphQuery> {
      return TimeRange.parse(object.over)
        .combinedWith(() => Filter.parse(object.where) )
        .combinedWith(() => GroupBy.parse(object.by) )
        .withCombinedValues((timeRange, filter, groupBy) => {
          return new Success(new GraphQuery(filter, groupBy, timeRange));
        });
    }
  }
In this design, `combinedWith` is a lot like `then` when using promises. It’s a bit more complicated because `then` assumes that arguments are always passed directly from the previous function, so you need special support to store the return value and retrieve them later as arguments.

If the type system requires it for some reason, you could add a `.startCombining()` call at the end of the first line within the method, so that `combinedWith` is sure to be possible.


You can build UIs as a left fold over events, just as you can build backend data processing pipelines. In fact it that is the architecture that makes the most sense to me now. I have a little toy framework here that demos these ideas. https://github.com/boothead/oHm


May be you can funscript? http://funscript.info/ It leverages TypeScript metadata to do typed interop with JavaScript libraries through an F# type provider


I know zero developers who know purescript or elm. That is a hiring problem, especially for young companies.


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

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!


PG has a couple essays directly related to this topic. The first about using a language which is implicitly more powerful than others ("Beating the Averages") [1] and the other is about how using a less common language is a positive selector in the hiring process ("The Python Paradox") [2].

[1]: http://www.paulgraham.com/avg.html [2]: http://www.paulgraham.com/pypar.html


Agree on the first. On the second, "And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.". I disagree, I like to solve problems more in Java. I tried several including Python over the years. I'm asked to do something in Python I will but for my money, Java is more readable than Python. It's an acute and false observation that he made. Less common does not necessarily equate to smarter/better/faster.


This was dramatically more true of Python when he wrote it than presently. FWIW, I've recently been using Python for a job and find it deeply unsatisfying. I'm inclined to think that current-gen Java may well be better; the last time I used Java in anger it was basically a different language. Though to be fair, truly modern Python is also a bit different than what I've been working in.


PG isn't God, and he related a single anecdote. I won't believe that argument unless I see current data that's language-specific.

For example, I could imagine easily being able to hire devs to work on Go, but it'd probably be really hard to get them to work on Haskell.


> PG isn't God

Can you prove that? Absence of evidence isn’t evidence of absence, after all. You’re being a bit militant in your pg-atheism.

Okay, in all seriousness, you are correct. Ability to hire coders to work in a particular language is a legitimate concern to have. Still, it’s sad to see lack of usage drive, well, lack of usage – sometimes it looks to me like an unexamined assumption, or a self-fulfilling prophecy. To take it back to the land of religious arguments: it’s a bit cargo-culty.


I agree with what you're saying, but "low popularity" is just one mark on one side of the pros/cons list.

New languages can outweigh low popularity with lots of other important qualities: syntax, tooling, appropriateness for a certain purpose, abundance of libraries, etc. If the new language is easy to learn, that pretty much defeats the issue of low popularity all together!

Unfortunately, a lot of new/amazing languages with great tooling are somewhat hard to learn. Again, Haskell might be a great language, but it's daunting to people who only have experience with C-like languages.

Go is one of the exceptions, and I think it did that intentionally. Instead of having complex syntax, it just has lots of boilerplate. It's easier to read and easier to learn at the expense of being harder to write and harder to modify.


> New languages can outweigh low popularity with lots of other important qualities [...] abundance of libraries, etc.

How?

> If the new language is easy to learn, that pretty much defeats the issue of low popularity all together!

If the language is easy to learn it's probably not worth learning. "Easy to learn" in most contexts and for most people means "similar" or "familiar".

Of course, there are languages truly easy to learn thanks to their small surface and internal consistency (like Erlang, PicoLisp, Forth...) but they are very rarely regarded as such.

> Again, Haskell might be a great language, but it's daunting to people who only have experience with C-like languages.

My opinion is that it's their problem, not Haskell's. Instead of "being daunted" they should go polyglot already and stop whining.


> > New languages can outweigh low popularity with lots of other important qualities [...] abundance of libraries, etc.

> How?

By "new" I didn't necessarily brand new. I meant something like Rust, Go, or Julia. They're more than 3 years old and relatively fully-baked, but they're much younger than the mainstream languages.

I don't know much about Julia, but in the Rust and Go communities, the early adopters are producing libraries for the not-so-early adopters. A good question would be, "Why?" I think the answers are: 1) fun, 2) because they want to get others to use the language, and 3) because their company has adopted the language in production.

So it does (and has to) happen. In this whole thread, I'm not talking about the decision-making process of an early adopter. I'm talking more about someone replacing a mainstream language in a production or business environment.

> "Easy to learn" in most contexts and for most people means "similar" or "familiar".

I meant "easy to learn" however you want to define that. Similar/familiar is fine, as it's definitely contributing to the popularity of Rust and Go. It really does hurt some excellent languages (e.g. OCaml) that they look so alien to mainstream, working programmers.

> My opinion is that it's their problem, not Haskell's

That's true. A language should have whatever syntax is most effective and not make the same mistakes that past languages made.

However, that's not the same thing as readability. A language can be totally different from C-family languages and still be readable. To mention OCaml again, I find it ridiculously hard to read because there are tiny, similar-looking characters that are significant all over the place. To my eye, significant dots and tildes are very hard to pick out when I'm scanning down a page.

So assuming Haskell is readable to a complete newbie, it isn't Haskell's problem that the syntax is new. But it is Haskell's problem if it can't overcome the catch-22 that people don't use a language if other people don't use it.

I'm glad we're talking about Haskell, because that community is very enthusiastic and has made some incredible, accessible Haskell resources to solve this problem. It may not be their problem, but they're still attacking it, as every language has to. It seems to me that the Rust community knows this and is going in the same direction with highly-accessible tutorials.

As for Go, the language is so small that it's "easy to learn" in terms of syntax, but the patterns and paradigms you use in Go might take longer as a result.


> It really does hurt some excellent languages (e.g. OCaml) that they look so alien to mainstream, working programmers.

How will you explain a relative success of F#, then?

In my opinion "looking alien" is not important at all. To the mainstream real qualities are much less important than marketing; that's true in many areas and mainstream programming is not an exception. Given enough marketing, you can turn "alien syntax" into a perceived advantage relatively easily.

> To mention OCaml again, I find it ridiculously hard to read because there are tiny, similar-looking characters that are significant all over the place.

Have you seen J? I'll just paste a bit of code in it:

   join =: 1 : 0
    ((([:{.[:>{.),:[:([:<(>"0))"1[:{:[:1 2 0&|:[:>([:,u"0)#]) (pr y))
   )
Is it readable? I'm told that yes, it is. There are people who can read this mess just fine, no problems at all.

Readability is an artifact of familiarity and, in some cases, tooling. You can get used to reading (and writing) even the most "unreadable" of syntaxes. Ask a PERL programmer if she finds her language readable. Will she say "no"?

My point is: until readability is formally defined and we're able to measure it objectively it's utterly useless to talk about it.

> But it is Haskell's problem if it can't overcome the catch-22 that people don't use a language if other people don't use it.

Yes, but this problem cannot be solved with technical qualities alone. Was it possible we wouldn't use C, Java or JavaScript at all.

It's marketing and "killer use-cases" that matter. You want to use the same language your OS is written in, for example. Was Windows written in OCaml you'd use OCaml to write Windows programs. If there's a program you really like, which is scriptable in Lua, you will use Lua.


> My point is: until readability is formally defined and we're able to measure it objectively it's utterly useless to talk about it.

It's more defined than we, as programmers, pretend it is. There's research in cognitive psychology, linguistics, and lexicology that tells us that some things are easier for human brains to process than others.

For example, if you skim through a block of code, it's easier to pick out "&&" than it is to pick out "and". There are lots of rules like this.

This is partially because of the way humans read words. If yuo spel a bunhc of words wrng in a sentence in minor ways that don't alter the shapes too much, it's still very readable.

That's why your example of J is very hard to read (objectively, not relatively). If someone removed or altered a few of those symbols, no one would notice upon skimming it. It's ludicrous to argue that it's readable just because some people say it is (and I think they're just bragging to begin with).


> There's research in cognitive psychology, linguistics, and lexicology that tells us that some things are easier for human brains to process than others.

I'm not convinced that such research controls for familiarity effects. Not to mention, programming languages have much richer syntaxes than natural languages. I think (suspect), in regard to PLs, what you're talking about (you mention "skimming" later) is actually legibility - ease of recognizing letters and words. Not readability, that is ease of understanding the meaning of what's written.

> For example, if you skim through a block of code, it's easier to pick out "&&" than it is to pick out "and".

Why? What if the rest of the line is similarly composed of punctuation? Are you sure in a line looking like this:

   >&.@:/"1\and[:    NB. some nonsensical J phrase
you'd have an easier time spotting the "and" were it written as "&&":

   >&.@:/"1\&&[:

> If someone removed or altered a few of those symbols, no one would notice upon skimming it.

Possibly, but we're not talking about "skimmability", but readability. Removing or altering a few characters in that line would result in an incorrect, nonsensical sentence and you'd notice it right away.

"Right away" is subjective, of course. I spent nearly an hour trying to read this damned thing when I attempted it for the first time. Every J phrase was a challenge then. It's still hard, but it got much easier with practice. The trick here is exactly the same as in your example:

> yuo spel a bunhc of words wrng

that is, once you learn how the words look like you can recognize them easily, even if they are a bit mangled.

> (and I think they're just bragging to begin with)

Yeah, I get the same feeling sometimes ;-)

But a human brain is great at pattern recognition. It has to be trained, and it's possible that some shapes are harder to learn to recognize than others, but once you learned them... is there really a difference?

Learning different PLs is my hobby, I've looked at ~80 languages to date and learned quite a chunk of them. Every single time I noticed this effect: once you internalize shapes of common phrases, you stop having trouble reading the code. It's much, much harder in some case (J is an abomination here - I'm trying to really learn it for the second year now and... it's not going that well) and easier in others (Smalltalk, Lisp, Forth, ...). But I strongly suspect every language, if studied and used enough, becomes readable.


> [..] but it'd probably be really hard to get them to work on Haskell.

I've been on both sides of Haskell hiring. There's more people who want nice Haskell jobs than Haskell jobs advertised these days.


Any recommendation on a good place to post Haskell jobs?



> That is a hiring problem

On the one hand there's a smaller pool of people, on the other hand a primary issue in hiring is sifting people who can do the job from a random draw[0], in which case interest and/or knowledge of Elm or Purescript is a huge prefilter, and can draw/poach people who wouldn't otherwise be interested (pg's "the python paradox"[1] talks about that)

[0] or worse, you don't get a random section of developers, you get a section of developers currently looking for a job, so the average competence of your draft is below average.

[1] http://www.paulgraham.com/pypar.html


Try ClojureScript.

There are plenty of developers, especially here on HN, who would absolutely love to work with Clojure/ClojureScript full-time.


I desperately want to extend my exposure to Clojure/Clojurescript. Unfortunately I can't use in my current company. I'm trying to play with it in my own time, which is of course very scarce. I wish more companies realized how amazing Clojurescript is.


A while ago, I had occasion to look for Haskell programmers, to hand off a project to. Despite promising to offer substantially below market rate, with no chance of a major pay-day, I got quite a pile of seemingly serious applicants for the position, some quite impressive. While the project had some non-profit volunteering good vibes around it, I think the experience is still worth noting for those interested in the ease of recruiting developers of niche languages.


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...


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.


It's counter intuitive but picking one of these niche technologies means:

1) you'll need less people (better more reusable code) 2) the best people will speak you out.

This was very much my experience when I put a Haskell team together, and everyone I've spoken to who has done the same has said the same.

It's an opportunity for a young company, not a problem.


I don't know purescript or elm, so I can't speak for their qualities. But, I also don't know half the languages cited nearby either (livescript, clojurescript). How can I pick and learn "the right one"? They all seem the same to me, and I think that's the problem.


Would make more sense to use a FRP library like Rx.js . Introducing yet another language+pipeline just for that is questionable.


Agreed, and a good middle-ground between JS and purescript/elm is livescript: http://livescript.net/blog/functional-programming-in-javascr...


> not picking a functional language

As opposed to what? In what ways do you not consider Javascript to a be a functional language?


Sure, Javascript has first class functions, which I guess meets the bare minimum requirements for being a functional language, but it also lacks some key features:

* Pure functions - JS functions are essentially subroutines. They might return a useful value or they might mutate a bunch of stuff and interact with the outside world. Who knows? JS functions aren't guarunteed to return the same value, or any value at all.

* Immutability - Anything and everything can be mutated in JS, including the contents of objects that are defined using the new ES6 `const` keyword

* Curried functions by default - Although it's possible to compose or partially apply JS functions, it's not nearly as nice as Haskell or Elm.


You're influenced by only one part of FP world. Let's take Lisp, or even better: Scheme.

   * pure functions - all you said is equally true for Scheme
   * immutability - set-cdr! and many SRFIs: vectors, boxes, records...
   * curried by default - nope, not in Scheme either
There are other flavours of FP languages other than ML descendants. They are not "less functional" at all.


It's true, not every language goes all-in on functional programming — but just because some functional languages are less strongly functional than others, that doesn't mean it makes sense to call every language currently in use a functional language.

I mean, it seems pretty useless to define "functional programming language" in a way that includes both C and OCaml just because you can pass functions around in both of them.


   var a = 1;
   a = 2;

   window.someGlobal = 'foo';



    const a = {b: "foo"};
    a.b = "bar";


Yea, const provides immutability with respect to assignment, but without immutable objects and collections, it isn't going to get you all the way.


    const a = icepick.freeze({b: "foo"});
Granted, that's not as elegant as built-in support but that is literally what I'm doing at the moment when I want immutability.


So if you go to extraordinary lengths you can use JavaScript functionally but it's not very functional by default aside from the first-class functions. Personally I just embrace it's imperative/functional blended nature and go with it.


Microsoft ruined C# by adding var. var is not your friend. Dynamic typing is not your friend and static languages pretending to be dynamic is akin to evil.


Implicit typing is not dynamic typing, or even "pretending to be dynamic". It's also, I think, off topic - as the example seemed to be talking about mutability in JS, with no C# for miles.


A functional language can allow mutations (see Haskell, LISP, etc.).

All a functional language really needs is first class functions. JS has had that since the very beginning.


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 :-)


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.


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.


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...


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.


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.


> 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`.


The TS compiler will complain but still generate working JS code, so you don't lose anything.


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.)


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.


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!


I hope this new feature 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.


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.)


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 ;)


I hope you are right!


My experience with Typescript is that I have spent the majority of what I would call 'wasted' time either messing with type definitions, or fumbling with getting modules to play nicely with code that needs to be used in the browser and in Node. My impression of the language is fairly positive, however I'm not currently using it for backend development because the burden of the type definition files is too great. Having to write a type definition file yourself for a library where none exists has been fairly painful in my experience.


If you don't have time to write a type definition file, there's always the fallback to any type. (I tend to start with any-typed things, see any as a TODO marker, and then fill in definitions as I have time, interest, or need.)

declare var SomeGlobal: any

declare module 'some-node-module' { declare var m: any; export = m }

Also, hopefully more npm package maintainers will start to add typings directly now that TypeScript searches node_modules.


Given the amount of debugging you'd save using a library that's untyped I wouldn't call it time wasted.

If a definition doesn't match the version of library you're using, changing the definition or adding to it omly takes a few minutes.


I haven't tried to use it for backend either, but I've used it for developing safari extensions, for which no typings exist, and I'm a little surprised about your comments wrt adding types being painful.

It has seemed pretty easy to add types for the parts of the library I need, rather than the entire library. Is there anything in particular that makes partially typing server-side libraries difficult?


This is one of the main reasons why we stopped using Typescript (a couple of years ago). I spend most of the time fixing type definitions on DefinitelyTyped


being cheap I tested the pipeline with eclipse and groovy, with nice results https://www.thinkingonsoftware.net/tech/eclipse-ide-configur...

minus a couple of bugs which should be fixed by now.

I was to build the startup front-end with typescript, but then there were too many libraries needing manual wrapping and I didn't want to experiment too much.


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.


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!


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.


I have some experience with C++'s templates, but I'm more comfortable with Generics in C# which I believe are done correctly. I view the code I saw as closer to C#'s approach to generics so I'm not sure your assumption is correct in my case.

I just don't want the extra mental overhead of writing and reading generic parameters whereas I never had to do that with javascript. I really enjoyed the concept of having types for my javascript objects, but am getting frightened at the concept of decreased readability due to generics.


I honestly dont see the overhead.

Its impossible to have any sort of typed functional programming without generics. Even the most basic of functions, map, has a type:

  declare function map<T,U>(a:Array<T>, f: (T) => U):Array<U>
Just like functions are parameterised by their arguments, generics are types parameterised by (type) variables. They don't have to be any more complex than that. Whats the mental overhead there?


C# generics are not the same creature as C++ templates. It isn't a matter of done correctly or incorrectly, it's apples and oranges.


Yes I know. I've done both. Typescript's syntax appears more like C#'s generics.

My issue is that I would like types for when I get data from the server, but I don't really want to deal with casting window to "any".

I personally went through the pains of learning javascript and have come out on the other side comfortable with its dynamic types. I really like the idea of compile time error checking, but I'm not sure I would stand for adding the complexity of generics.

The change in my workflow is not very difficult. For example, when I'm using plain old javascript, I use documentation to find out how to use third party libraries and DOM manipulations. Though it works out for all of my needs, I wouldn't mind adding types. Adding types on top of that would reduce casting and spelling mistakes, but it's not like I can't open up the browser and test my code with a step through debugger. I would personally prefer opening the browser and maintaining readability in my code versus having type safety in my code and giving up readability.


I almost forgot: generic type variables are used very little outside of generic libraries. We have a 20KLOC codebase which doesn't use type variables at all and has only a single in-house written dependency [1] that declares functions with type variables.

note: This is about declaring generics, not using them. You'll still have to write Array<string> and Promise<MyType>, thats true. But its hardly any different from ArrayOfString or PromiseOfMyType in terms of readability.

If I may be so bold, I'd really encourage you to give it a spin. You just might find that your fears about readability are exaggerated.

[1]: https://github.com/doxout/promise-observer


I didn't catch this at the time, but I will take a look. Thanks.


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.


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


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.


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.


>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-javascr...


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/


Significant whitespace just swaps out visible "brackets" for invisible ones. It looks nicer, but the basic syntax is still there, and you have to highlight non-printing characters in your text editor to make sure you're not mixing whitespace types anyway.

I understand why people might prefer the whitespace but to me the ambiguity and extra technical debt isn't worth the payoff in readability.

I also like semicolons. Especially in javascript.


It sure can be an eye sore. But, I'd rather that than deal with ambiguity working with Coffeescript syntax.


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
            ));
          });
        });
      });
    }
  }


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.


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


That code has nothing to do with TypeScript. First of all, it's a side-effect of JavaScript syntax, and it's also a really strange way to write code. This author's code doesn't seem simple or easy to reason about to me, partially because it's hard to read.


Trailing parents/braces seems like a bad reason to dislike a language. Ever heard of Lisp? :)


Presumably that's why some people dislike Lisp too.


Is that a valid reason? I know that personal taste plays a strong and important role but typescript is really cool.


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.


I could get over the parentheses but CAR and CDR instead of HEAD / TAIL or FIRST / REST annoy the crap out of me.


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.


I have no idea about the veracity of the claim but this page[0] contends that Lisp has had first/rest since 1959.

[0] https://en.wikipedia.org/wiki/CAR_and_CDR


It cited the claim with a source, so presumably you could check the veracity that way.


Perfectly valid. If it's difficult to read, it's difficult to use.


I agree. And it seems to me that it wasn't language issue, but lack of encapsulation. I also don't find those cons of using CoffeeScript convincing enough. Have these guys tried TDD? If you use TDD you'll probably find accidental overwriting out-of-scope variable in a matter of seconds. Because you should never rely on language syntax.


Once async/await support make it into TypeScript, it should be a lot cleaner dealing with promises. It's already in Babel, and imho I'm fine without the typing as long as modules are minimalistic, organized and straight forward.


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


I kinda agree - Coffeescript in particular seems like putting extra weight/overhead into the process for very little other than cosmetic gains over JavaScript. Whatever problems JS may have - I don't really feel that CoffeeScript addresses them. It addresses the fake problems (IMO).

TypeScript and related make a lot of sense for very large projects/teams because static type checking can be VERY useful, and the lack of a statically typed language choice for in-browser programming is a large weakness of the web ecosystem. So TypeScript is a tremendous advantage to have in the toolkit, and a much saner approach than older heavy-weight options like GWT.


GWT still has a major advantage in that you write the server in the same language as the client (Java). Indeed they are the same code base and can share code, classes, etc. I have yet to see an alternative with such a strong server side component to it.


Because it's really hard to build, test and maintain a non-trivial application in a dynamically-typed language like JavaScript.

I think it's telling that a lot of companies with the most mature products (Facebook, Dropbox, Asana) eventually resort to optional static typing in their products, whether that means extending their runtimes (e.g. Hack) or using a transpiler like TypeScript.


The implicit conversions and "we'll just randomly give you undefined to propagate ondwards" stuff is a much bigger source of bugs in JS than dynamic typing. Picky dynamically typed languages like Erlang or Python will pretty reliably produce an error/exception at the scene of the crime. (More so than C/C++!)

(Also I don't think optional static typing has gotten off the ground in Python land, or adopted in production at Dropbox?)


Dropbox Paper is written almost entirely in TypeScript.


What is it telling? It might just be telling that everyone is doing what you're doing here, and looking at each other to see what they should do. Another name for this is "fashion."


Well ,because Typescript makes a huge codebase easier to read and maintain (though ES6 is a huge improvement, no question)

I used to use Coffee Script, which I still like, but ES6 clearly made Coffee Script less relevant. Typescript value is clearly in the type annotations and the support for ES6 ...

Another problem with Coffee Script is the fact that it evolves way to slowly and it is unlikely to support most of ES6 features because its core maintainers are clearly not interested in adding significant features. In fact that the main issue for me. Both Backbone and Underscore suffer from the same issues.


> ES6 clearly made Coffee Script less relevant

I see that a lot and find it highly subjective. I don't find es6 useful at all and will stick with coffeescript for the foreseeable future but that also has to do with my reasons for using it.


In this case: because they want type enforcement. This removes a category of errors that - in a complex app - can be really annoying.

Better - it removes that ability for deliberate bad behavior by devs.

That said - I prefer JavaScript + Flow as thats a much more native solution which means you don't need to learn a pseudo language first.


Typescript isn't exactly a pseudo-language. It looks just like JavaScript with Flow annotations. In fact, Typescript is intended to be JavaScript + Type Annotations, so it's just as "native" as JavaScript + Flow annotations, with the addition of some Babel-style ES6 transpiling as well. The only difference is the explicit build process versus running the transforms in browser, and I've seen projects use the Typescript compiler (itself written in JS) as their in-browser transpiler (SystemJS supports it as a first-class transpiler option alongside Babel and Traceur, even).


> It looks just like JavaScript with Flow annotations.

It looks close to that, yes. However Flow can be also implemented via comments to native JS so... TS can't do that.

In which case...

> it's just as "native" as JavaScript + Flow annotations

is wrong. TypeScript requires a transpilation step. Flow doesn't. It can do, but it's not required.

I may have been a little harsh with the "pseudo-language" but I'm not sure what else to call something that is designed to be transpiled into the right language. It's not higher-level, it's sort of... a companion language I guess.


You can write TS and put the type definitions into a separate file, so you don’t need a transpilation step. I am using this at the moment.


This comment would be more useful if you made an actual argument. But to imply that you can't comprehend any possible gain for using another language that overcomes the downsides (which you don't specify) isn't constructive.


I like pure JS over CoffeeScript (and other something-to-JS solutions) because:

- Writing JS gives me a better feel for how the language actually works

- I like the line number in the JS I'm debugging to equal the line in my source code

- There's less magic to understand & deal with

- CoffeeScript automatically returns the last line of a function, and I don't always like that


> - Writing JS gives me a better feel for how the language actually works

Only because you know it better...

> - I like the line number in the JS I'm debugging to equal the line in my source code

Source maps.

> - There's less magic to understand & deal with

https://medium.com/@c2c/nodejs-a-quick-optimization-advice-7...

> - CoffeeScript automatically returns the last line of a function, and I don't always like that

Use explicit return then.


Well when you pretend that Coffeescript is just another language (like Java, or C#?), then it does become difficult to understand my statement.

Fortunately, most everyone else seems to understand what Coffeescript is, and thus they were able to grok my meaning.


I have the same feeling. When I was a less experienced programmer, I found coffeescript to be a great tool for helping me to write 'better-looking' code while avoiding the 'bad parts' of javascript. Later, I decided to focus my expertise on javascript, learning its imperfections and beauties. Reading through parts of the sourcecode for Node.js and the popular Express.js library, I became more comfortable writing pure javascript. It now seems to me like a much more practical solution to just learn javascript and stop trying to write in a different language than the one used by the runtime


I don't know very many people who write server-side code in C or ASM, so "stop trying to write in a different language than the one used by the runtime" doesn't seem to be a very popular rule outside of the JS world either.


But then you wouldn't have a complicated build process to run, allowing free time for web surfing.


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.


Javascript is a typed language.


and that type is the string.

    > 3 == "3"
    true
    > 3 * "3"
    9


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.


I defer to Wikipedia's definition:

> A language is typed if the specification of _every_ operation defines types of data to which the operation is applicable, with the implication that it is not applicable to other types.

For a language to be typed, both the data must have a type and the operations must have a type specification.

    > "a" * "b"
    NaN
In a dynamically typed language, that specification is enforced at runtime.

    > true / false
    Infinity
In a statically typed language, that specification is enforced by a compiler.

    > setInterval(function(){ console.log("hi") }, "later")
    > hi
    > hi
    > hi
    > hi
    ...
As far as I can tell, JavaScript doesn't concern itself with any of that. It's not typed.


You are a bit confused. The == operator specifically does implicit type conversion. You want to use === to avoid implicit coercion. And you always have the option to explicitly coerce type, as I explain below.

Javascript's type coercion leads to some wacky things like

> [] == []

> false

But it's actually all perfectly consistent once you understand what the compiler is doing with type (and JavaScript is compiled, not interpreted). == is an operator that will always try to coerce its operands to numbers, but the way it gets there can be circuitous.

You can specify type in JavaScript and avoid implicit coercion, you can use type constructors (generally worse) or certain unary operators. Ex:

> var foo = "12"

> var bar = +foo - 5; //+ explicitly converts foo to a number


See step 10 and onward of: http://www.ecma-international.org/ecma-262/6.0/index.html#se... (for example)

Javascript is typed, it just makes a lot of crazy decisions about what operations an operator does.


Sorry, I meant statically typed, I always misuse that bit of terminology when talking about JavaScript, thanks for correcting me.


Compiler error catching is a big bonus for me.


Too weakly typed (pre ES6) for big codebases.


ES6 doesn't have static typing either.


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.


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.


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');


I promise I started writing my comment before I saw yours ;)


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);
        }
    });


Adding to your point, nesting callbacks is quite elegant in coffeescript. I never understood "callback hell" until I looked at examples in pure JS.


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/issues/1664


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/


> 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%20htt...


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."


TypeScript supports disjoint unions: http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...

The two real pain points (among those you mentioned) of TypeScript are bivariant function parameters and structural classes, since they lead to potentially unsound code that compiles.


The link you provided doesn't seem to show disjoint union support. I'm talking about this: http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html


Thanks a lot for your input. I think I'll stay with ES6 and flow.


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.


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.


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/


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


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


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.


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.


Isn't the problem that the TypeScript compiler doesn't support all of the ES6 features that Babel does?


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?


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.


Seriously? 'You' ? 'like' : 'this'; if 'better' then 'than' else 'this?'


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.


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.


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


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.


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 as well as various react bindings such as https://github.com/joelburget/react-haskell


ghcjs.

For something that follows the semantics of JS and produces very readable code (a la TypeScript), PureScript is really nice.


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!


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.


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

Will your third-party-lib that doesn't use Typescript keep a dts file? Who knows...


..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.


How about using JavaScript with flow?


> 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.


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.


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)


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.


Which feature are you using in TypeScript that wasn't in Flow?


let, const, decorators, string interpolation, other ES6/7 goodies. Also a few other compelling things like abstract classes and community type definitions.


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.


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.


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.


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.


> 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.


> ES6/7 code is much cleaner, clearer, and more idiomatic

I'm assuming you're talking about the compiled javascript from coffeescript and not coffeescript itself? I find coffeescript code much, much nicer to read, write, and deciper.. but that's just me!


Well I could refer to both, but no I wasn't specifically (though it does apply).

I'm curious: were you a Ruby dev before using CoffeeScript, or at least had a reasonable amount of experience with it?

That said I find Ruby to be dense and annoying to read sometimes (due to its sometimes Perl Golf obsession with brevity in language constructs), so it could be just Ruby idioms annoy me ;)


I haven't used ruby but ive been writing python for many years and so the indentation-based syntax definitely something I enjoy. But that said I didn't even use coffeescript until I was forced to while working at a huge media company where the big project I worked on had the large client written in coffeescript... once I got used to working with it I think I enjoyed the clean code and productivity gains..

I guess your milage may vary though depending on what you're doing etc.


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.


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


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.


Babel + Flow?


> 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.


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-repl...


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?


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.


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


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


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


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.


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


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.


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




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: