11 ms·

Absolutely not. This is the opposite of what you should do in my opinion. If you're writing an API to be consumed in language X then you need to write the API

• myared 11y ago
  Couldn't agree with this more. Specifically, the lost hours due to CoffeeScript.
  • voxic11 11y ago
    Typescript really isn't comparable to coffeescript
  • partycoder 11y ago
    CoffeeScript has the worst tooling ever. QBasic in the 90s had better tooling than CoffeeScript: an integrated editor, debugger, compiler, type validation... let's give it all up to code in vomitscript.
    • plugnburn 11y ago
      Have you ever tried Atom? Its interface is written in HTML5 + CoffeeScript, and it targets CoffeeScript as the primary language. Tell the GitHub guys about tooling... But besides, judging a language based on available tooling is akin to judging a CPU based on the computer casing looks. For a real programmer, GNU Nano with appropriate highlighting should be enough. If a language calls itself "high-level" but makes the coding process hard without tooling, it deserves no attention at all.
      • partycoder 11y ago
        A real programmer makes mistakes, and a real programmer automates tasks. That's what programmers are for.
• icholy 11y ago
  This reads like knee-jerk reaction from someone who's never tried TypeScript.
  • weego 11y ago
    Criticism of that statement kind of hinges on the source material being solid enough to be taken seriously. I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users. Another it is leads to better documentation, with no qualification of how that happens. It might make your intent more explicit to a reader of the source code, but that doesn't magically translate into documentation for an API user. I personally find nothing good about trying to coercing a language into something it isn't and then transpilling it back and that article has no strong argument to make me feel any different.
    • icholy 11y ago
      > I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users. I agree, that wasn't a good point. > Another it is leads to better documentation, with no qualification of how that happens The type annotations make the source self documenting in a way that doesn't go out of sync. There's also http://typedoc.io/ http://typedoc.io/
      • tlarkworthy 11y ago
        Typedoc doesn't keep up with TS versions. It's not really solid enough.
  • BinaryIdiot 11y ago
    I've used it but never in a serious project. Like I said when it can be compiled into WebAssembly then count me in I'll certainly give it another shot. But until then I just don't want to deal with an, albiet probably rare but possible, transpiling bug. Plus there is huge value, in my opinion, in writing an API in the same language it's going to be consumed in. It lets me dogfood more effectively and write better, real world unit tests.
• rtpg 11y ago
  I can absolutely understand that coming from coffeescript (optional parentheses resolution... yikes). But TypeScript is basically "Javascript + types + ES6". They call it an "erasing compiler" because it's not meant to do much but remove types/make ES6 code work with ES5. There is one gotcha in name resolution when you're working in modules (if you are in a module a.b, and a.c exists, then c will automatically refer to a.c, even if a global c exists). But that usually gets caught by the type system. Lot less issues than coffeescript IMO
  • wereHamster 11y ago
    With `--target=es6` I'm not sure if the TypeScript compiler does any code transformation other than removing type annotations. So the chance of a 'transpiler error' is basically zero.
    • emodendroket 11y ago
      Well the classes are converted into functions and it adds members to the prototypes, right? Or is that ES5 only?
      • boredpudding 11y ago
        What you mean is indeed ES5 only. ES6 has classes so it doesn't need to convert anything.
        • emodendroket 11y ago
          Oh. Cool. I didn't know that.
    • bd82 11y ago
      There are a few small things that still require conversion. But that is because Typescript also includes capabilities from ES7 (ES2016). For example - currently in Typescript but only planned for ES7: https://github.com/jeffmo/es-class-fields-and-static-properties https://github.com/jeffmo/es-class-fields-and-static-propert... or Support ES7: exponentiation operator https://github.com/Microsoft/TypeScript/issues/4812 https://github.com/Microsoft/TypeScript/issues/4812 Typescript seems to be more like ECMAScript.next + types rather than ES6 + types.
• jsight 11y ago
  If it can't be compiled to JavaScript reliably then how do you expect it to be compiled to WebAssembly reliably?
  • BinaryIdiot 11y ago
    Doesn't really need to be readable when compiled into WebAssembly though that I'd a goal. In that scenario it should work like any language in that you can debug in its native form. MSIL and Java bytecode are not that readable but I mentally lump WebAssembly in the same group (though I know it isn't quite that). I feel like the end goal will be closer aligned to byte code than JavaScript.
    • jsight 11y ago
      I still don't really see the argument. It can already be debugged in its native form. I'm not sure how making the final product less readable helps with that. WebAssembly is primarily useful from a performance standpoint.
    • taco_emoji 11y ago
      RELIABLE, not READABLE.
• snarfy 11y ago
  APIs written in C seem to do just fine.
• hacker_9 11y ago
  At work our entire front end is TypeScript, and thanks to source mapping I've never had to look at JavaScript even when debugging problems. Typescript simply adds type annotations so you can get error underlining when you misuse a variable, and even more importantly (productivity wise) you get auto-complete members as you type. Don't want types? Fine don't use them, and you have JavaScript code again.
• tzaman 11y ago
  I disagree. The last letter of the API stands for "interface", which by the definition (a point where two systems, subjects, organizations, etc. meet and interact.) means you don't always have the ability to put a "same language" constraint on. By presuming the API will be consumed by something you have no control over makes you think about all the implications and types act as a guard of sorts.
• tegeek 11y ago
  TypeScript is ES6 with types, so it is not a different language at all.
  • skeeterbug 11y ago
    Not true at all. TypeSript has ES6 modules and its own module syntax. I don't know if it has improved recently, but using ES6 modules in our TS was nearly impossible if using type definitions using the old module syntax.
• radicalbyte 11y ago
  Have you used TypeScript? Try it out for a month or two on a real project. It's the best thing that has happened to web development in recent years - it improves Javascript in a completely compatible and future proof way. The most amazing thing is that Microsoft created it. It's the polar opposite of Old Microsoft - standards are being followed (not subverted), it's simple pragmatic and has no lock-in.
  • awjr 11y ago
    I cannot vote this up enough. It really is such a different experience to developing in "plain" JavaScript.
    • echelon 11y ago
      It's so much more pleasant to write and maintain than wild, un(type)safe javascript.
      • acjohnson55 11y ago
        Only problem is that it's not sound. That means that while it may provide static checking that your program is validly linked together, it can't fully prevent run-time type errors. And kind of like you can't be "a little pregnant", you can't be "a little typesafe".
        • JoeAltmaier 11y ago
          Of course you can. Can't catch all the bugs; but can catch some of them. Which saves time and money. It doesn't actually have to be perfect to be useful and helpful.
          • acjohnson55 11y ago
            I'm not saying it doesn't help. I'm saying you can't count on it the same way you can if you're working in a truly end-to-end statically typed environment. Even Scala's type system has its leaks, due to nulls.
• incepted 11y ago
  Sounds like you've been tainted by your bad experience with CoffeeScript (which is very understandable). Typescript is a whole different beast and I think the article makes great points for libraries. The more types the better.
• trey-jones 11y ago
  This was my reaction upon reading the title of the post, having not used TypeScript. Mostly based on my experience and frustration with CoffeScript, mainly frustration at its existence. But if TypeScript is an abstraction of Javascript that adds type security, then I'm pretty much all for it, even having been burned pretty often by unnecessary abstraction. I would say that the lion's share of my own javascript bugs spring from type uncertainty.
• webbore 11y ago
  I do quite a bit of library development in TypeScript and one of the biggest wins is with new developers doing their first non-trivial bug fix or refactoring. The compiler has saved us from introducing all sorts of edge-case bugs because it catches downstream impacts that developers who are not intimately familiar with all of the code can introduce. A nice bonus feature is single line jsDoc comments replacing giant blocks of descriptive text.
• jhall1468 11y ago
  What an odd argument. If you were writing a DLL for Windows would you expect the binary executable that's using it to be written in the same language? Do you have an example of how writing something without types is supposed to help you capture edge cases? What are the idiosyncrasies of Javascript that can easily be caught in Javascript but NOT in Typescript? WebAssembly adds massive layers of complexity that Typescript doesn't. You argue going from Typescript to Javascript is bad because, but Typescript to WebAssembly is good. One of this is vastly more complex and complicated, and it isn't TS to JS.
• hipsterrific 11y ago
  JavaScript, IMO, forces the developer to do a lot more defensive coding. All API's have contracts. An add() method that computers two numbers shouldn't expect a JSON object. For that matter, your method's contract shouldn't return an "any" for the same reason that you shouldn't expect "any" as its input. What TypeScript does is remove the ambiguity of API development for front-end work. Considering I've worked in some big enterprise wide JS projects, TypeScript answers the question "Wtf is this returning?" which lessens my debugging time because I know exactly the type of the object being returned. Your arguments are actually kind of moot. When you write in Java, you're really just boiling it down to an intermediary language. Should you write it in IL? Why not C/C++? Why not assembly? Shoot, just handout punch cards again and let's get to working. Abstraction isn't the enemy here, it's the value of the abstraction that gives value to it. TypeScript isn't so much an abstraction as a superset but it's static typing alone is worth 1000x over.
  • partycoder 11y ago
    Defensive coding in JavaScript? That's absolutely not how most libraries are implemented.
    • hipsterrific 11y ago
      If you're expecting one type and get another, you have to handle it, right? Documentation is important in JavaScript by virtue that code contracts are never enforced due to implicit typing.
      • partycoder 11y ago
        JavaScript makes this process optional, and it only needs to go wrong once to become a problem. Personally I saw over a million dollars lost and an entire team laid off after a piece of code started working with a value that was expected to be a number but wasn't.
      • nly 11y ago
        > If you're expecting one type and get another, you have to handle it, right? Depends. You could debate the same philosophy wrt C and null pointers. Should you check all your arguments to see if they're null, if the documentation/specification says they should never be null, or accept undefined behaviour and segfault? In practice, most code assumes everything is checked, sanitized and used correctly at the outer most API boundary.
• Roboprog 11y ago
  Javascript IS pretty damn good. My IDE does a pretty good job at analyzing the structure of scripts. So, I guess I have not yet felt the pain that "requires" a language upgrade. Unlike Java, which has really gotten to chafe me. But then again, I started work back in 1985 using a scripted language (dBASE), with its own version of "eval", to make cute little UIs and reports that tied into the "real computer" / software (even if data swapping was swapping nightly batches of ISAM tuples, rather than REST calls). I also enjoyed using Perl in the 90s / early 2000s. Then as now, the Serious People want you to wallow with them in the bondage and discipline of a Real Language, so you can type until your fingers bleed :-) That said, I do write a lot of "JSDoc" in my code, and I resent the people who refuse to write Javadoc in their Java, because of course the types all make it crystal clear - NOT!
• agentgt 11y ago
  > "API to be consumed in language X then you need to write the API itself in language X" I have to agree with the OP's point if your writing a library you should write it in the base language (common denominator). I work on JVM stuff and nothing is more annoying then dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java. Plain Java on the other hand works fine in Scala,Clojure, and Groovy. The above JVM languages compile to byte code (which I guess would be analogous to WebAssembly). Thus I'm not sure if transpiling is as bad since Xtend (which is more analogous since its a Java transpiler) is very interoperable AND does not compile to bytecode directly. So WebAssembly might end up being just as bad as the plethora of JVM languages that are sort of interoperable.
  • vorg 11y ago
    > nothing is more annoying than dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java I don't think the backers of Scala and Clojure make the claim that libraries written in their language will work seamlessly in Java, only that libraries written in Java will work in their language. The marketers of Apache Groovy, otoh, do claim code written in it will work in Java but from what you say that claim is false.
    • agentgt 11y ago
      Sorry for the late reply but yes you can write some Groovy that will not work on Java (I'm trying to find when and where it happened to me... that could have changed). The issue is that there are things you can do in JVM bytecode that you just can't do in Java and as the JVM develops along with these languages I imagine further interoperability. You are right about the languages not making promises but there are plenty of library writers who disregard this. A fine example would be Akka and Finagle. Those libraries could have been written in Java thus minimizing dependencies and maybe even overall code size since they have to have a wrapper for Java anyway (typesafe did choose Java for typesafe config). But then again maybe Scala/Clojure buys enough that the wrappers are trivial. I'm just not sure how trivial interoperable wrappers for WebAssembly will be as I imagine WebAssembly will be a superset of what Javascript can do (or maybe not?).
• JamesBarney 11y ago
  Specifically regarding this discussion of typescript/javascript what are some edge cases and language idiosyncrasies problems you'd run into writing libraries in typescript?