Love for TypeScript | Hacker News Reader

Love for TypeScript

github.com

220 pointssvieira162 comments

TypeScript is the one technology I would discard last of the entire web stack.

Using TypeScript instead of JavaScript is such a productivity boost for a team developing a sizeable single page application, any other technical decision (which Framework, tooling decisions) is almost irrelevant relative to this major improvement.

TypeScript has ALL the properties that should make adoption a no-brainer:

1) Increases developer productivity, especially over long term maintenance timeframes. (My non-scientific, ymmv estimate is at least 30%)

2) Reduces production exception rate significantly

3) Can be adopted gradually

4) Full JavaScript ecosystem still at disposal

People seem to massively underestimate the benefit of a typed language in a frontend codebase. At gunpoint, I would rather have the backend in a dynamically typed language and keep TypeScript for the frontend. Chances are that the distance between your database and the API is not far, so static typing is not that useful.

However, if you have decided for a client side rendered application, your app is stateful, dynamic and probably quite big. Static typing really helps to avoid mistakes and increases the ability to refactor quickly and correctly by order of magnitude.

There are too many hardly ever visited code branches, and tests are very costly to write for an application where users can click a lot of things.

It's not even the fact that JS is dynamically typed it's that it's the worst of dynamic typing - magic strings, monkey-patching, retarded scoping rules coupled with callback pyramids all over the place, no proper modules - you just get no meaningful help from tooling as soon as your code base grows to even medium complexity. ES6 helps but TS brings all that + more.

Python IDEs like PyCharm offer far superior tooling even without static typing, and Clojure is so nice I don't usually even need the tools.

I get your point, but while I am a big advocate of typescript, I think that the topology of the javascript language is perfectly suited for front-end development.

There are a lot of impedance mismatches to deal with in the front end, (javascript to DOM, json to javascript, diversity of execution environments etc...), and I feel that when correctly used, dynamism the way javascript does it is a god-send.

All my core developments are in typescript, but in many situations it feels so magic to just do : myprop.undeclared = value and encapsulate the stuff in a knockout component written in typescript, while the situation would have caused a drama / major redesign in a back-end static language (C#, Java etc...). There are many valid scenarios (not resulting from a wrong OOP design) where this is very useful.

I'm actually amazed that people who designed Javascript got it so right. Static languages are great in the backend, typescript is great for the front-end and solved a real maintenance and Q&A issue by providing a level of typing and popularizing OOP in the front-end, but javacript is great for the web browser in general. Typescript is the piece that was missing, but this doesn't mean that javascript is broken, the elasticity of the language is a very powerful and elegant solution for the problems specific to the front-end.

>myprop.unDeclared = value and encapsulate the stuff in a knockout component written in typescript

And when I need to read this code later on and figure out what the shape of myprop is what do I do ? When I come across a function in a different file that touches that "unDeclared" property how the hell do I figure out what type it is, where it was assigned, etc. How do I find all references to that if "unDeclared" is a common word or is used on multiple types as a property name ?

JavaScript is just a nightmare to maintain - sure it might be easier to bang out the code initially - but good luck finding someone who will maintain that stuff once the author moves on. Hell - good luck coming back to your code base a year later and finding your way around that. From my experience most of non-trivial JS ends up being write only.

> I think that the topology [emphasis mine] of the javascript language is perfectly suited for front-end development.

What exactly does “topology” mean in the context of programming languages? Are you trying to pull a Derrida (using fancy words without any actual meaning)?

> I'm actually amazed that people who designed Javascript got it so right.

Are you assuming that, even with a better language, the DOM's crappiness was inevitable, and thus we need a loosey-goosey language like JavaScript to deal with it? I doubt this is the case. Good languages make it easier to design good programs and APIs.

I agree.

One benefit I've seen a lot is typing external services. A lot of code (both the frontend and the backend in say Node.js) tends to deal with calling external APIs, which would be dynamic in JavaScript and end up being quite loosely documented in the code.

With TypeScript, however, you can type in the JSON responses, which makes reading any code dealing with external services so much quicker. And these days with literal types you can even document that a particular property is either "magic_string_1" or "magic_string_2".

3 & 4 in your list are so key. I was very skeptical of it until I started using it and realized that javascript is always valid typescript. So it never gets in your way. It only helps, and only if you want it to.

Although, dynamic languages force extra incentive to unit-test the shit out of the codebase. Compilers certainly catch a lot of syntax mistakes and whatnot, but it also relaxes the requirement to add extra code coverage. The onus is more on the developer with dynamic typing but I'd take more-accurate code coverage over static types any day!

EDIT:

If you have static-typing and good unit-test coverage it's the best of both worlds I suppose. I tend to prefer duck-typing though which is sort of wedged in-between dynamic and static-typing in a sense. This however then becomes not a question of static vs. dynamic typing but of the language implementation of the type system.

In C++ for instance, the over-object-orientation is a pet peeve of mine when people define so many types and interfaces for this-and-that. I tend to prefer the "looseness" of template functions since you can pass whatever type in there so long as it contains the appropriate methods on the passed-in object. Such is static typing though so I'm digging myself into a hole from my original post :)

Now, a good static-analysis tool could catch issues on a dynamically-typed language in the same sense. Then I suppose the dynamic language becomes a pseudo-static language since a static-analysis algorithm is executed on the codebase. Since most build systems are set up to do: compile codebase; run static analysis to detect issues; run unit tests; run integration tests, it could theoretically be redundant step at compile-time doing static analysis when it's also done by an external tool. Just some stream-of-consciousness thoughts :)

And that's why I prefer static typing. All those trivial unit tests get in the way.

You really shouldn't have a "trivial" test that a type system like TypeScript makes redundant, when doing pure JavaScript either.

If you have a function, eg: (a, b) => a + b The only thing TypeScript will help you enforce here is that a and b should be numbers, and the function should return a number.

Except, the test for this will be something such: "given 10 and 21, return 31". So you're testing the return type already. TypeScript will ensure that you never pass a string to a or b, for sure, but you should not have a test for that (unless you literred your code with type guards and wanted to test those. Don't do that).

Now, unless the function above is your final, public API (where TypeScript/Flow will have the biggest bang for the buck and have the most value add), you're probably calling that function somewhere. That somewhere will be tested too, and the full test harness will make sure strings never end up there.

You'll never actually need to write a test: "Make sure this is a string", and the only vulnerable area is the top level API, and that is a responsibility of the caller.

The only tests you have to discard when using a statically typed language are some of the tests validating your input data. I don't see how static typing leads to less test coverage...

These are a lot of tedious to write tests in a frontend codebase that mainly renders a lot of state into HTML.

Additionally, these are tests that you will have to tediously adjust every refactor since HTML frontends and it's data APIs behind it tend to change often over the lifecycle of a product.

From my experience, "only those tests" save you hours and hours of programming time.

> The only tests you have to discard (...) are some of the tests validating your input data.

That's not true. You can safely discard anything that tests something you've proven. A good type system doesn't only prove things for you - it also makes it easier to manually prove what the type system can't prove.

A good type system, yes. Something like TypeScript though? Only checks that variable types match. We're a far cry from ML/Elm/Scala/Haskell here.

So the only thing it helps is get rid of bad tests (eg: tests that check a function return any string...tests you shouldn't write even in a purely dynamic language).

> Something like TypeScript though? Only checks that variable types match.

TypeScript's type system is unsound, so you can't rely on the type checker alone to prove anything useful. However, manually proving things about TypeScript programs is still easier than doing so with JavaScript programs.

I don't believe it's practical to rely on type checkers to prove absolutely everything. There are mathematically proven upper bounds on how much you can automate reasoning. For instance, global type inference only works with first-order type languages. Higher-order anything flies out of the window, yet higher-order properties of programs need to be proven!

What we ought to do is find the optimal division of labor between automated and manual proving, always keeping in mind that the optimal case isn't being able to prove something. The optimal case is not having to prove it because it's obviously true. How do we design a programming language so that more interesting things are obviously true?

Sound type systems help you prove things. In other words, a type system is a tool that partially discharges part of the programmer's proof obligation. Of course, what you can't prove, you still need to test. This isn't news to anyone.

The problem is when the programmer doesn't know how much of his proof obligation is actually discharged by his use of the type system. (Hint: Not all of it!) And the solution is educating programmers, not replacing types with tests.

> Chances are that the distance between your database and the API is not far, so static typing is not that useful.

For me, this mostly brings up the question of why the distance between data sources and front-end code apparently seems so big these days, and whether or not that's really an asset.

TypeScript is straight up one of the best technologies I work with, rivaled only possibly by giants like Postgres. It takes one of the worst parts of my day - refactoring Javascript code - and makes it straightforward and enjoyable.

TypeScript 2.0 goes beyond that and begins to push the envelope on what type systems can do. Recently I've been loving the combination of discriminated union types and nullable types. It means that you can have code like this:

    function myFunction(x: number | null) {
        if (x === null) { 
            return;
        }

        console.log(x + 1); // x is now a number
    }

The argument to the function is x, which is either number or null (that's what number | null means). But the if statement ensures it's not null by exiting the function, so by the time you get to the log TypeScript has (correctly) set the type of x to be just number!

The types match up exactly with how you'd write the Javascript code. It's awesome and it just works.

What happens when x is 0?

Good question - edited my code to be correct.

I think it's just the sample code needs to be x === null. Nothing to do with TypeScript. The sample is a good example to illustrate the union type.

On that note, are there any documentation that explains the == and === operators in Typescript ? The language spec is only briefly acknowledges the existence of those operators.

They behave exactly like they would in JavaScript.

Kotlin can do something similar, in fact I think the code would work exactly like that if you ported it, but it can also do things like:

> if (a instanceOf SomeClass && a.someGetterOnSomeClassNotAvailableOnTheStaticTypeOfa != null)

Which is pretty awesome because it means you don't have to pollute your code with unnecessary casts.

Kotlin has compile-time null-safety. The ? denotes a type than can be null.

    fun myFunction(x: Number?) {
       if (x == null) return;
       print(x + 1);
    }

if you don't check for null first the compiler warns.

You can also do:

    x?.let {notNullX -> print(notNullX + 1)}

    print((x ?: 4) + 1)

https://kotlinlang.org/docs/reference/null-safety.html

It really is an awesome language. Especially the delegated properties are wonderful. I use them to fill javascript-state for redux/react-native.

I have not used TypeScript, so can anyone explain to me what is the difference between the above the normal JavaScript code like this:

    function myFunction(x) {
        if (x === null) { 
            return;
        }

        console.log(x + 1); // x is now a number
    }

Edit: Or is this example being used to show that TypeScript now support multiple types including null in the parameter?

I assumed that such feature would be available by default.

You could call your js function with a string, and rather than a compile time error you'd get broken behaviour at runtime.

Inside the function you also have to continue using x as a number, like you wouldnt be able to accidentally pass it into a function accepting only string as argument etc.

I haven't used Typescript either, but some of the differences are self evident to me. myFunction(x) can be called with any argument type; tooling can't detect an inappropriate type and output a warning/error(?), so you get to find certain mistakes the hard way; at runtime. "foo"+1 might make sense, but "foo"/1 is garbage, silently propagating 'undefined' up the stack in conventional Javascript, costing time and money for everyone. The user of myFunction(n: number | null) is provided with a meaningful signature during development, this saves time by providing precise information in a concise manner. Those of us that have spent time with statically typed languages and good tooling know what a blessing this is. The Typescript variant offers the possibility of a performance optimization; x+1 might compile down to a single instruction, as opposed to whatever runtime type check has to be invoked when the type of x isn't/can't be known at compile time. I don't know if that optimization is 'real' in practice given our contemporary javascript/typescript stack, but you can bet it will be eventually.

your js version:

y = myFunction(1); // y = 2

y = myFunction("1"); // y = "11"

the ts version wouldn't allow you to compile myFunction("1")

Except for a few cases where Typescript let's you transpile ES6 syntax to JavaScript ES5, the compiler does not change your code; it just checks it for type errors.

The point of the example is that Typescript recently added support for non-null types, but is flexible enough to analyze where types have been further restricted by an early function return.

> TypeScript 2.0 goes beyond that and begins to push the envelope on what type systems can do

Type systems could do stuff like that many, many years ago. I'm glad that you like these ideas, but let me assure you that TypeScript is far from pushing "what type systems can do".

I realize that I made a factual error in my post and I thank you for pointing that out, but to me your post reads as very condescending, to the point of being rude. It reminds me very clearly why I don't often post comments here.

It's the classic "not invented here" syndrome, but on the level of languages. It's not enough to be able to have strong types in Javascript, they want people to stop writing Javascript, scrap the entire ecosystem, create all new browsers on every platform, and only write in their strongly typed language that's just as flawed as Javascript.

He simply wrote that TS isn't on the edge, without getting personal.

I astouned what some people read into a perfectly reasonable critique...

What about PureScript, it's way beyond TypeScript and still compiles and interacts with JavaScript.

What I find very funny about PureScript is how it has these super-fancy types, designed from the ground up to express things like semigroupoids, lenses and profunctor-based optics... yet it doesn't have a numeric type better than JavaScript's good old floating points.

Just to be clear, this isn't meant as criticism, since I absolutely love how Haskell (and now PureScript too!) exploit algebraic structures to make code more reusable and robust. But the contrast between “can express fancy structures precisely” and “doesn't have precise arithmetic” is very amusing.

If you want to find the reason to be upset, you will.

That seems like a really weird thing to read into k_bx's post. I think you might want to try re-calibrating your "is this post meant personally"-meter :).

FWIW, I didn't see any condescension there. I got more of a "Oh, you ain't seen nothin' yet!" vibe from it. Obviously, YMMV.

EDIT: Words

It sounded a bit condescending to me. Besides that it was an empty comment; a claim with zero citations - not very useful at all.

Anyway, I'm sure that I don't care if an unknown language pioneered something. The language that makes good features popular is the better one.

> a claim with zero citations - not very useful at all.

Gradual typing isn't exactly a TypeScript invention: Typed Racket is gradually typed, has unions and intersections (which in turn date from further back than TR), refinement types, occurrence types, and even comes with a guarantee that typed code won't violate contracts. If the Racket runtime detects a contract violation, blame will always be assigned to untyped code. TR does more than TS does, and it was designed and implemented earlier.

> It sounded a bit condescending to me.

I didn't read k_bx's comment as belittlement of TypeScript: anything that makes JavaScript better is obviously a good thing! (Since we can't get rid of it.) But, as a matter of fact, TypeScript isn't pushing “what types can do”.

And it adds nothing to the conversation, and has spawned an entire subthread of comments like ours which also adds nothing to the conversations. Its exactly the type of comment that should be banned from HN.

It's not just a factual error, its kind of a sore spot to many people.

TypeScript is a pretty bad type system, but compared to Java and other mainstream ones, it looks like it "pushes the envelop".

Because of this, we're stuck with an half baked, crappy type system designed for mass consumption, and people adopt it with a round of applause.

That's no excuse to me an ass in response to your post...but it's part of why you'll see answers like that.

I'm not a native English speaker and didn't try to be rude, I'm sorry if you felt like that. I don't encourage you to post comments here more often though, posting more often doesn't necessary means it's good for you and everyone else.

Thanks, I appreciate it.

Yeah, but in languages that anybody uses?

That people are actually using TypeScript could be the difference here.

Are you assuming typescript is the _only_ good typed language people use?

C# is one of the most popular languages and is one of the inspirations for TypeScript's type system

I don't have telepathic abilities to guess what exactly author meant. My goal was to let them know that type systems are much more developed than what TypeScript provides, and to encourage them to go out and learn them, read many great books and discover all the type-system goodness that's lying out there for free.

does TS2 fix this?

    function uhoh (x:string|number) {
        if (typeof x === 'string') {
            return x.length
        } else {
            return 'bar'
        }
    }

    const a = uhoh('foo') //= string | number
    const b = uhoh(3)     //= string | number

You may already be aware of this, but it's semi-fixable in TS1:

    function uhoh (x:string|number) {
        if (typeof x === 'string') {
            return x.length
        } else {
            return 'bar'
        }
    }
    function uhoh (x:string): number;
    function uhoh (x:number): string;
    
    const a = uhoh('foo') //= number
    const b = uhoh(3)     //= string

I don't know about TS, but in the main competitor, Flowtype, you can give uhoh this type:

    uhoh : ((x : string) => number) & ((x : number) => string)

And get what you expect:

    const a = uhoh('foo') // : number
    const b = uhoh(3)     // : string

Sort of. I tried the above and it reported the following error message:

error TS2354: No best common type exists among return expressions.

So at least it detects the problem. However the type inference algorithm should arguably return a union type here.

I find it good practice to always specify the return type of functions anyway. Then it will pick up cases where you return a type you didn't intend to; instead of just using a more general type it will tell you about the inconsistency.

Typescript does not infer union types for return types. You can explicitly annotate them just fine though.

I suppose the reasoning is that, when adding types to js, this is exactly the kind of bad behaviour you want to catch. But I'm not sure, perhaps there are just technical implications for not inferring union return types.

Exactly. Leaving off the return type annotation is just asking for trouble, and this example proves it.

And the actual type of the const won't be `string | number` -- it will be `any`.

MaulingMonkey[1] has the right idea, though.

[1] https://news.ycombinator.com/item?id=12192240

> TypeScript 2.0 goes beyond that and begins to push the envelope on what type systems can do. Recently I've been loving the combination of discriminated union types and nullable types.

As a side node, the FlowType system for JavaScript has had these features for over a year now, while TypeScript 2 is still in beta. These are the exact features which made us decide to go for FlowType instead of TypeScript 6 months ago. Happy to see that these two type systems now converge.

still waiting on flow to be cross platform (windows)

Just to add to this, here's the tracking issue, upvote to support it: https://github.com/facebook/flow/issues/6

29 days ago somebody posted an unofficial Windows binary: https://github.com/facebook/flow/issues/6#issuecomment-22989...

That does sound awesome. Does it mean that if you have:

  function second(y: number) {
      return y + 3;
  }

And you call second(x) from myFunction, the compiler complains if you haven't put the if() ensuring that null cannot pass to second()?

I am 99% certain that this is indeed the case. Non-nullable types are one of my favorite new additions to TypeScript.

But it goes further than that. TypeScript 2 adds control flow analysis, so adding to the top of a function that accepts a string or an array:

if (typeof someVarThatCanBeStringOrArrayOfStrings === "string") { // turn string into array }

any code below it can safely assume that the variable is string[], as well as the rest of the code that calls this function if this variable is returned.

(correct me if I'm wrong, y'all)

You are almost correct -- it's just that it's not a "safe" assumption.

In your example, the JS interpreter will not throw an error when one provides a number (for example). Your code could break things. But why would this happen?

It's completely unrelated to TypeScript.

A number could be provided by the data, which in all likelihood is JSON from the network (eg: HTTP request or message queue body). Strongly typed languages will give you strongly typed data to protect you from this, but a dynamic language like JS doesn't afford you the same protection.

TypeScript doesn't mitigate this issue -- nor could it. TypeScript ensures your plumbing fits together, not that the sludge flowing through it won't cause a mess.

A strongly typed language will throw an exception before unexpected behavior can occur, JS on the other-hand will attempt to continue. It rarely happens, but since it does you can't say it safely works properly.

That's a good point, but I don't quite see how a strongly typed language fixes this issue. Could you elaborate on that?

If a strongly typed language receives data that is malformed, wouldn't the same problem arise? Isn't it always the case that you only have control over your own plumbing, and put up defenses to deal with external input?

(I have little experience with strongly typed languages, so I'm really interested to understand this a bit better)

I haven't had the chance to try typescript yet but I absolutely love postgres, I mean I want to have sex with postgres. It is what is keeping our codebase somewhat sane. It pairs really well with the insufficiently typed javascript/nodejs. With postgres, at least the code interacting with state, the most perilous code, is typed, transactioned and manipulated in the functional sql way. I shudder to imagine in what mess we would be if we had gone with something like mongo.

This thread, with people like you that seem to get it, is definitely making me want to try typescript.

Wait? Same guy built Turbo Pascal, Delphi, C# and now Type Script? First three is the list of languages that make me feel at home when I'm doing desktop development. Yet another reason to seriosly try TypeScript with default tooling if it's comming from this guy. His work is beacon of sanity in tangled world of software development.

Yeah, for me one reason to give TypeScript a serious go was that I grew up on Turbo Pascal and Delphi, and a bit of C# experience. Haven't been disappointed.

It is interesting for me to follow how the community mindset develops around TypeScript/JS/... over the years. Many in the JavaScript community frowned upon GWT, Closure Compiler, Dart and other typed compile-to-JS tools, most of which predate TypeScript, and provided state-of-the-art tooling at the time. "Types are overrated, everything that is non-JS must go away" was a common mentality.

Now some of these people started to see some value in tool-based refactoring, and suddenly realize that types are not always bad. TypeScript undeniably improves the situation over JavaScript, with the caveat that it won't stop you shooting in the foot with the bad parts of JS. So now, types are good, nevertheless JS must stay.

I wonder how many years it will take for people to lobby for a clear break of JS backwards-compatibility, to use something that is not ad-hoc, has good tooling and a great base API, etc. Something where sorting number doesn't need additional extra care.

These usually start to matter when the team size is beyond 10 person working on the same part of the codebase. It will be interesting to see how this spans over the years. I bet the earliest "clear break of bad JS" will happen around 2019, with mostly linters and data flow analysis improving but hitting the eventual limits.

Uninteresting times, in a certain sense. I'm glad we have other tools to compete with.

I think at this point we just have to wait for a good support for webassembly on all main browsers and then everyone can have its own ""isomorphic"" stack and we can finally stop these wars about how to modify javascript and what features to introduce because we all will finally have other alternatives to choose.

What do you see as the difference between a language that compiles to javascript and a language that compiles to webassembly?

Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.

Parsing Javascript can also be a performance bottleneck for some applications as Javascript parsing is somewhat expensive in comparison with Webassembly.

Performance and size. You can't get better performance or smaller size than a manual written js solution. wasm is supposed to give you both( better performance and smaller payload size). I'm wondering how many people will see value in JS once wasm and compiled to wasm languages are first class citizens. I doubt there will be many(excluding the js developers who may be biases)

> You can't get better performance or smaller size than a manual written js solution.

Except in cases where the handwritten solution must be transformed to a different pattern (doing essentially the same thing). For example, the handwritten solution may write:

    element.innterHTML = '<div><span>x</span></div>';

While the compiler will unpack that and would use document.createElement() and would append these nodes together. The example may be lame, but most people would prefer a short string over 4+ lines of createElement() calls in their handwritten version. (Same old story with assembly vs. compiled C code).

Similar pattern may arise for various parts of the JS execution profiles and/or browser runtime quirks.

GWT came with a language that has a poor type system for JavaScript's needs.

Closure Compiler types are/were too verbose. It didn't support most module systems until this year.

Dart didn't provide an easy interface to existing JS libraries. Everything goes through a very cumbersome FFI. Also the only "tooling" was Eclipse.

TypeScript comes with a structural type system (with generics) designed exactly to fit existing JavaScript code perfectly, as well as a type definition scheme for existing code, as well as support for all current JS module systems (ES6, CommonJS, AMD). The tooling also comes in the form of an embeddable language service.

It succeeded because its a type system for JS, and not a compile-to-JS language for another ecosystem.

Software development is always about tradeoffs, in an always-changing environment, at a given time. Tools evolve, and so did almost all of things you mention as a drawback.

TypeScript didn't succeeded yet, but it is emerging with a great press coverage. It will be interesting to see people's preferences changing once they got a feeling how safe programming adds not only to the productivity, but also to longer term maintenance.

And in my opinion, the ecosystem doesn't matter that much. Otherwise Java should have won with its coverage of open source libraries.... or Perl should have won earlier... or... you get the point. It matters in the beginning, but not on the long run.

> Closure Compiler types are/were too verbose.

The difference is about the length of an additional "/ @type /" and the fact that the annotation is in a comment, not in code. That had the benefit that that all code for closure was valid JavaScript, which was key in the days before basically all production JavaScript went through a transpilation step.

> It didn't support most module systems until this year.*

ES6 modules maybe, but it's supported CommonJS and AMD modules since 2011[1] and its own module format before that.

The real reasons I think it didn't catch on are that it came out too early for much of the JS world, the closure library is written verbosely/awkwardly (though there's no reason to touch it when using the compiler, they're associated by name), and many thought you to annotate all existing code to use it instead of adding annotations incrementally.

[1] http://www.nonblocking.io/2011/12/experimental-support-for-c...

1. Its unclear how you can declare new generic types using @type

Here is an example type of a map function in TypeScript:

declare var map: <T, U>(f: (t:T) => U, t:T[]) => U[]

I cannot figure out the equivalent @type annotation in Closure using these docs: https://developers.google.com/closure/compiler/docs/js-for-c...

I wonder how much the popularity of Angular had to do with the recent adoption of TypeScript?

I don't think it's had much of an effect to be honest. Angular 2 (which has TypeScript going on) isn't even stable yet and seems to have lost a lot of mindset compared to React (which doesn't have TypeScript going on).

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

The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point.

There are other languages that I prefer for specific domains, of course. But if you're writing code that needs to run on a web client and/or that needs to run in Node, TypeScript is the only way to go.

For me, I've simply decided to just focus on javascript. I have to use it, and while I had quite a bit of enthusiasm for Coffeescript, the move towards ES6 has made me realize that I need to just buckle in.

Maybe it's a little bit of fatigue setting in, but at this point, my next foray into a new language will be something properly compiled like Rust or Swift, not a transpiled language.

This is not to detract from Typescript or Purescript or anything else like it. There's some amazing work going on, but for now, I'd rather learn the ins and outs of javascript instead, warts and all.

It is good indeed to have a deep understanding of Javascript before using other tools.

I've never really cared for Coffeescript (because I felt like it brought very little at the cost of a very different syntax) but Typescript really improves my productivity.

I do miss meaningful whitespace. It's my favorite thing about Python. Although I recognize it's not for everyone, and it's purely a matter of aesthetics and preference.

Yeah, I have been all-in on CoffeeScript until recently, and significant whitespace is one of its best features for me. It's a DRY issue.

Give Kotlin a try. It's a JVM-language and 100% java-compatible, but it can also compile to Javascript (not sure if that backend is production-ready yet though)

https://kotlinlang.org/

It's also backed by JetBrains the IDE-maker.

Kotlin is a JVM clone of swift.

A clone of something that appeared 3 years later? (2011 vs 2014 according to wikipedia)

AFAIK the official line has always been that it's a "simpler Scala". Not to mention that it's several years older...

They're actually quite different - a good chunk of my current project is in Kotlin, and all of my last project was in Swift.

Things Swift has that Kotlin doesn't: associated types, file-based access control (changing in Swift 3.0), pervasive use of keyword arguments, trailing closures, full pattern matching (Kotlin can only destructure component1...N sequences), reference counting.

Things Kotlin has that Swift doesn't: smart casts, declaring properties directly in the constructor, declaring constructors directly in the class statement, auto-delegation, data classes, singleton objects, implicit parameterizable 'this' (handy for builders & DSLs), garbage collection.

Things they both have: null chaining & defaulting, class extensions, somewhat clumsy first-class method syntax, concise lambda syntax, lambda anaphora ('it' in Kotlin, $0 and $1 in Swift), concise range operators, property descriptors, operator overloading.

Kotlin generally has the feel of a much more pragmatic, industrial language. It's Java without the warts, where the designers took note of the common Java patterns they wrote and provided a lot of syntactic sugar to dramatically improve brevity. Swift feels more academic; its type system is more modern and less ad-hoc, it has polished implementations of many features that academic languages have been trying to get right for years. Both are heavily influenced by their ecosystems; Swift feels like a better Objective-C, and Kotlin feels like a better Java.

Kotlin does have trailing closures: https://kotlinlang.org/docs/reference/lambdas.html#higher-or...

And some form of pattern matching via the "when" keyword: https://kotlinlang.org/docs/reference/control-flow.html#when...

It's a bit different in Swift. Kotlin lets you omit the parentheses if the closure is the only argument to the function. Swift lefts you place the lambda outside of the parentheses if the closure is the last argument to the function. That lets you construct a much larger variety of control-structure-like HOFs. Event handlers, for example, often take a functional argument plus a bunch of other data.

No, it's the same in Kotlin, from the docs:

"There is a convention that if the last parameter to a function is a function, that parameter can be specified outside of the parentheses."

So you can have normal arguments and specify the last parameter outside like.

    val col = "A"
    val row = 3
    table.update(col, row) {
       it * 5
    }

You may have confused that with SAM-conversions (?), which are for java-interop: https://kotlinlang.org/docs/reference/java-interop.html#sam-...

Cool. Learn something new every day. (I was confused because all the examples except for lock() are single-arg, and IntelliJ usually autocompletes with parentheses because there's often a non-functional overload.)

I recommend you try the JavaScript backend.

I'm so sick of people spewing JetBrains' marketing points without checking the substance of it.

> I'm so sick of people spewing JetBrains' marketing points without checking the substance of it.

I tried the backend already, last time I checked it wasn't production ready, like I pointed out in my post. Maybe it is now?

OP mentioned he wanted to "foray into a new language will be something properly compiled like Rust or Swift, not a transpiled language."

Where exactly did my suggestion to try Kotlin go awry?

Scala compiles to JavaScript, to the JVM, to Android, and (soon) to native. Give it a try!

I love Scala, but last time I tried to build an Android app using it (about a month ago), I just got various weird errors in IntelliJ when trying to build it. Eventually I just gave up and rewrote my app in Kotlin instead.

But yeah, it's absolutely my first choice for JVM or web work.

That sounds weird. How did you build it? Can you paste the SBT error?

It happened with both the make button and when running it (yes, I had removed the "Gradle-aware make" step and replaced it with android:packageDebug from the SBT shell plugin).

Sadly, I don't have the error message anymore, and it seemed to work when building from the command-line tool. I suppose I could have kept going like that, but it's very nice to have the proper debugging tools that an IDE provides. :/

Which version of sbt-android do you use?

1.6.1, I think, but I'm not sure. I was stupid enough to delete my project files...

Not a huge fan of Scala[1], but it must be said that Scala.js is AMAZING for what is does. We've been using it in production since 0.4 (I think?) and we've never had any problems that could be traced back to sjs.

[1] Long story. "Trapped" programming Scala instead of Haskell by my own conservatism -- and now -- the need to support legacy systems. Still... it's way better than Java, so at least there's that. When thinking of Kotlin I always think of it as a sort of "what Java should have been", but when thinking of Scala I can't help but think "Well, it's not quite Haskell, is it?". (The poor type inference, the whole OOP thing, the lack of TCO means that any Monadic abstraction must be trampolined and that's just cruel.)

> but when thinking of Scala I can't help but think "Well, it's not quite Haskell, is it?". (The poor type inference, the whole OOP thing, the lack of TCO means that any Monadic abstraction must be trampolined and that's just cruel.

Some good news:

- Better type inference at the place were it was sorely needed landed in 2.12 (use -Ypartial-unification to enable) or use it on 2.11 with a compiler plugin.

- Even if you are not a fan of OO (I'm not), I still love that I get a great module system for free. Haskell's module system is a completely mess.

- Scala-Native already supports all kinds of TCO, including mutually recursive ones.

Oh yeah, definitely looking forward to 2.12. Don't get me wrong Scala is still good, just not great. (Hence the scare quotes around "trapped")

> - Better type inference at the place were it was sorely needed landed in 2.12 (use -Ypartial-unification to enable) or use it on 2.11 with a compiler plugin.

I was actually thinking of things like local definitions not needing type signatures. It's really easy to underestimate how much more fluent this makes the language feel. (Think of functions defined in 'where' clauses and things like that. Entirely subjective, but there's this feeling of fluency when you don't need any type signatures for non-top-level things.)

I don't think Scala is ever going to move away from requiring all functions to have an explicit type signature.

> - Even if you are not a fan of OO (I'm not), I still love that I get a great module system for free. Haskell's module system is a completely mess.

Not so much "mess", I think... more completely underpowered? It's really just a namespacing mechanism.

Hopefully we'll get Backpack at some point...

> - Scala-Native already supports all kinds of TCO, including mutually recursive ones.

Really? This is surprising to me, but perhaps they've gone with the Pascal(?) calling convention so as to make it trivially supportable?

It's still sad it can't be relied upon per language spec. :/

> It's still sad it can't be relied upon per language spec. :/

There is a @tailrec annotation which ensures that a method was optimized. It probably needs to be updated to understand Scala-Native's new abilities, but the infrastructure is there!

Yes, but IIRC it doesn't work for mutually recursive methods or dynamic(!) tail calls.

Yes, because Scala-Native only exists for a month at this point in time.

Hm? Not sure why you're bringing up Scala-Native again... @tailrec has existed since 2.8(?).

The limitations of @tailrec are obviously due to the JVM, but I was thinking (given your mention) that maybe Scala-Native had done away with the problem -- if you use the "Pascal" calling convention I believe it's mostly completely trivial to do TCO. (Just omit the "push/pop things onto/off stack" bit in the caller and use "goto".)

> Not sure why you're bringing up Scala-Native again

Weren't talking about that?

> @tailrec has existed since 2.8

Yes?

> I was thinking (given your mention) that maybe Scala-Native had done away with the problem

It uses fastcc, and yes it does. I don't understand the issue.

I'm a Scala Dev now, and I also played with Haskell and various LISPs.

I'm one of those that likes OOP and Scala's OOP is the best I've used thus far. And the great thing about Scala is that OOP is consistently used to express everything in it.

Scala gets compared with Haskel, but let's compare it with Ocaml. This isn't like Ocaml where you have the HM type system and functors and ADTs and then you have OOP as a separate thing, effectively having two type systems in the same language, while at the same time providing no means for ad-hoc polymorphism, while higher kinds are sort of a hack.

People also underestimate the importance of having the JVM as your runtime. At the very least it means you get a capable GC, which makes it feasible to use persistent data structures, and it also means you get multithreading and thus a memory model. Ocaml still doesn't have a memory model, while the GC needs improvement.

But back to Haskell. Type-classes are great as a concept, but the implementation leaves something to be desired. First of all in Haskel they are anti modular, because you can't have two conflicting definitions in the same project (not scope, but project). The standard, Haskell 98, is actually unfit for real work, with people referring in fact to GHC and its extensions. Extensions that are often experimental and unstable. And then you've got a powerful type system, but guess what, virtually no IDE tooling is available. And while its laziness is cool, in practice it can get really hard to reason about performance or about the time and space complexity.

On the poor type inference of Scala, well, it comes with subtyping. While I'm sure it can be improved, basically if you want OOP, you have to accept weaker type inference. As I said, I happen to like OOP, so I consider that to be a reasonable trade-off.

On the lack of TCO, this only really matters for performance reasons. But guess what, the JVM usually beats Haskell in performance by a significant margin, even without TCO. And no, not all monadic abstraction need trampolines. Those are quite few actually, most commonly: Free, IO and Task.

Then there's the tooling aspect. Scala has really capable IDEs (plural). And it has SBT and Scala.js. I mean, when I first started to play with Haskell I wondered if a language be that good as people say, when its build tool Cabal is such a piece of shit. You like Scala.js, yet you're not wondering why only a couple of people managed to build it and it's miles ahead of anything similar for Haskell or Ocaml or F#? Actually the only achievement similar to Scala.js would be ClojureScript.

One last note: if you want Haskell, then use Haskell. But functional programming isn't necessarily about Haskell and its idioms and Scala is its own language. In other words, you can also say that Haskell isn't Scala and people expecting Scala would be disappointed.

Thanks. I couldn't have said that any better!

>2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see

The complete lack of visibility for such things is what prevented me from adopting TypeScript. I couldn't get a clear answer which platforms supported async/await (there was a huge conversation on github which heavily implied, but never outright stated, that there was an ES5 target; yet the docs said it was ES6 only). A lot of the features have unspecified targets.

I wish their documentation were better.

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

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

It's actually really, really hard to overestimate how amazing having optional specified types is. I used to use C++, then went to Lua, and more recently to JavaScript with the occasional Python. I loved the freedom of getting away from the strict C++ type system, which mostly felt like it was holding me back.

But the thing that bothered me the most about JavaScript/Python was the fact that the tooling just doesn't have a clue, most of the time, what types things are. Misremember what has a member of what, exactly, or the spelling of a member, and you've got a bug.

TypeScript eliminates that kind of stupid bug and overall speeds up development by 2-3x. Yes, some of those bugs can be found in tests. But having to go back and fix them at all, tracking down exactly what the object structure is by hand (either in a debugger or digging through docs) versus "let the editor tell you exactly what members this class/object has, and what members its children have, so I can get it right the first time"?

And what about refactoring? TypeScript knows what everything in your code is. You decide to rename a member? Done! Just because there are twenty "init" methods, if you decide this particular call should become "init2", it will rename exactly the right members throughout your project.

Finally, the fact that it just has your back when assigning types prevents another entire class of bug.

No question; (optional!) strong types are a huge win, and as I said above, should be a required practice for any nontrivial app. You get the best of both worlds: Type safety without the manacles of having to specify everything.

Transpiling won't be obsolete until TypeScript is standard in browsers (where it could help improve JIT optimizations!), and probably not even then: We're looking at ES2017 before async/await is ready, which probably won't be in most browsers until 2018 at the earliest, and there will likely be more killer features on the horizon in the future that many people will want to use.

> The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point.

Seriously ? because it's not javascript and never will be.

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

Yes, you can just target ES6/ES2015 in your emit and TypeScript will use generators to enable `async` & `await`. You can then use Babel as the next step. We have a tutorial on Gulp & TypeScript that hooks up Babel and Browserify: https://www.typescriptlang.org/docs/handbook/gulp.html

Typescript actually already supports async/await since version 1.7, but only for ES6 targets - i.e. it compiles everything down to generator-based coroutines, which is essentially the same as the 'transform-async-to-generator' plugin in Babel, I guess. If you want to support ES5/3, I guess you can always target ES6 with Typescript and then feed the result to Babel. It's a bit clunky, but it would probably work.

Where Babel shines vs. Typescript is that you get much more fine-grained control over which transformations to apply. Typescript doesn't seem to support just emitting async/await directly, which is what you would want if you target a browser which support async/await directly (Beta Chrome and Edge already support it behind a flag, and it's going to come to other browsers soon)

I too, love TypeScript.

The client side JS where I work was becoming a bit of a horrible beast so I started using TypeScript here and there when I worked on new things. It has really helped rein in some un-maintainable messes.

It's got to the point now where TypeScript is my default go-to language because it's so powerful.

Someone mentioned how great it is for strongly typing API's and libraries, and I have to second this. When there aren't typings available it forces me to RTFM instead of just prodding around in intellisense, so in some cases it actually helps me learn libraries better.

Just today I created a boilerplate project for webpack/typescript 2 [0]. It's not finished yet, but it's usable if you wanted to jump right into TypeScript with no run-time dependencies. As a bonus I modified the same boilerplate but for HTML [1]

[0]: https://github.com/deevus/webpack-typescript2-boilerplate

[1]: https://github.com/deevus/webpack-typescript2-html-boilerpla...

I cant believe how much more accessible typescript is than javascript. Type signatures are helpful. Refactoring is so much less stressful. Even things as simple as catching misspelled imports have saved me tons of time.

At one point in time, a 'this' bug ate up half of my day. Ever since moving to typescript, I haven't had a single 'this' bug make it past the compiler. I still don't fucking understand 'this'...all I know is that Typescript knows what it is and can tell me to fix something before I send it off to the browser.

Typescript will never be my favorite language...not even close. But since we can't actually get rid of javascript, I'm pretty happy we have typescript around to make it not suck so much.

TypeScript catches a lot, but "this" bugs are still one of the most common things it misses. For example, when factoring a method into a free function, I'll often miss a this:

    function hypot(x:number, y:number) {
        return Math.sqrt(this.x * this.x + this.y * this.y)
    }

TypeScript does not warn about this case.

Check out the option "noImplicitThis" in TS2, for this exact case. It will ban using `this` when it's implicitly `any`. I agree that it was much needed!

Great addition! Thanks for pointing it out.

A very happy way to live as a Javascript coder is to avoid the `this` keyword, in my experience. You really don't need it. Instead write this function as

    (x, y) => Math.sqrt(x*x + y*y)

That can never have any state bugs, because it's a pure function (just like you can never have type errors with a sufficiently good type system).

And you might be interested in the native JS function (since ES6) called Math.hypot. Happy hacking :-)

> I cant believe how much more accessible typescript is than javascript.

Can you elaborate on your meaning? A language that requires transpiling by definition can't be more accessible than the language it transpiles into.

> At one point in time, a 'this' bug ate up half of my day. Ever since moving to typescript, I haven't had a single 'this' bug make it past the compiler. I still don't fucking understand 'this'.

'this' can be a little complicated but it's really not that bad. I like the dry way the MDN explains 'this' [1] if you find it helpful. Even if you're using TypeScript I still think it's important to understand (TypeScript does compile into JavaScript after-all; debugging the transpiled output without chrome maps can be necessary at times).

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> A language that requires transpiling by definition can't be more accessible than the language it transpiles into.

It's a funny definition of "accessible" that counts C as less accessible than assembler.

C doesn't transpile to assembler.

That's a rather arbitrary statement; C _compiles_ to machine code that maps pretty directly to an assembly language, which is normally not far off of the abstraction level offered by C. Taking the definition of transpile being translating to a language with a similar abstraction level, you're just picking hairs.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This is the best guide to "This".

We introduced Typescript into our architecture. We start to love it, too.

One thing though: the engineers started to write classes for everything. I had to catch that and forced them to stay as functional as possible. Does that happen to other teams, too?

And I really like to see WebAssembly to become part of our browsers and Typescript generating it instantly.

I've written a lot of Angular code with Typescript and although you're right in saying functional code is preferrable I've found that a little bit OO when used correctly makes your code DRYer.

For example, if you have a lot of paginated lists you can write an abstract class that handles all the "get the results", "put them on a list", "display pagination", "on click display the next/previous page" trivia and then inherit from that to add the UI/presentation and any specific logic. It's absolutely possible in plain javascript but I shudder at the thought of writing something like that and even worse, refactor it. Typescript with OO and generics simplifies the task considerably.

As in everything in life: "dogma is bad", "παν μέτρον άριστον", "use the best tool for the job" etc. Words to live by.

Of course, I don't forbid to use OO. Its just adds more boilerplate if ES5 is generated and increases the size of the code. And the ES5 code we migrate is already mostly functional.

For cross cutting concerns like pagination, we already have functions that enhance the pagination controls.

I'm hoping WebAssembly opens up lots of other languages to browser development. Any language could compile to WebAssembly: rust, haskell, go, swift, etc. I think it will really open up the browser.

TypeScript will never generate WebAssembly for you. WA is used for hosting your own sandboxed native code environments, it doesn't offer any of the tooling you'd need to run TypeScript-based libraries/applications.

I don't understand this line of reasoning. WebAssembly isn't 'sandboxed native code', it's a compressed AST, and even if it was native code there's nothing stopping someone creating a native compiler for TypeScript.

That said, Typescript is most likely to support WebAssembly when WebAssembly offers a GC implementation for it to use (the WebAssembly GC is planned in the medium to long term IIRC).

Why not? Someone might write a compiler. And I expect that if WebAssembly becomes the primary source for browser runtimes, browser vendors will probably try to compile Javascript to WebAssembly first. It does not make sense to have two engines or two interpreters for a single WebAssembly engine.

The same thing kinda happened with a few developers when we started to use TypeScript, but that 2 years ago.

I like TypeScript for what is probably a different reason than most people. I have started using TypeScript as a great languge for book examples. The language is so easy to read and understand, and it is so quick to install the compiler and runtime. Right now I am using it for many of the examples for a book Introduction to Cognitive Science that I am writing. TypeScript is a great universal language for thinking about code and algorithms.

Ahem... TypeScript is 100% Javascript, they only add optional type annotations. The "to-ES5" compilation serves a different issue - that's just a different version of Javascript.

But I use the surface TypeScript syntax for the book examples. It is a clear and concise notation, which is why I like it for this use case.

I have no idea what you mean by

    > surface TypeScript syntax

TypeScript syntax is... Javascript (ES 2015 or above) - plus the optional type annotations and some few minor additions like "enum" or decorators. Things like "interface" don't compile to actual code, they only serve the compile-time type checks.

I will say that I'm my experience developers with a background in C# seem to love Typescript while developers with a background in Javascript seem to be slower to warm up (a lot slower).

In our office it seems like the JS folks are sensing that they should "get on board" with the clear enthusiasm from the C# folks but there is resistance (mostly muttered quietly to each other to avoid looking like they don't get something that seems so obvious to others).

Did any of you have good experience using typescript on node.js project?

I remember trying out typescript with few tutorials, but so far mostly on the browser side (i.e angular 2 is in typescript) and when I poked around I couldn't really figure out how to hook up to the npm ecosystem.

Was that just a lack of decent google-fu that particular day?

Sure, there are a few steps to make a hello world work but then you soon realise they make sense and it's smooth sailing.

I would suggest this link: https://code.visualstudio.com/docs/runtimes/nodejs

Yes, wouldn't even consider using node without TypeScript, personally.

Really, the main pieces that could seems a little mysterious are type definitions and compiler options. tsconfig.json exists in the root of the project for compiler options. Type definitions can be managed by a library called 'typings', or for TypeScript 2.0, type definitions can be managed with npm.

The biggest problems I had with TypeScript involved type definitions, combined with the module system. Now, the latter is not TS' fault and a bit clusterfuck at the moment for everyone, but it's a bit more complicated if you add TS to the mix.

It's improved immensely though in the past months/year.

This would be a little offtopic for this thread, but anyone knows if there is an example of using TypeScript with Node only as a typechecker (like flow)? Recently it was in news that TypeScript can understand JSDoc annotations - so I was wondering if I could use TypeScript as a typechecker for my code which is all 100% pure JS with JSDoc style type annotations.

I tried flow, but flow's comment syntax for type annotations is not compatible with JSDoc, and flow really needs a lot of work still. I am hopeful it will improve, but I feel presently it isn't ready for primetime for large codebases on the server side. (I guess it works great for React though).

Pretty new to TS but I like TS a lot as well!

The TS compiler is usually configured to disregard most type errors in JS (even if it does infer a bunch types from JSDoc comments); if this would be super super useful for you, you should consider making an issue or upvoting an existing issue for it on the TS repo!

I've found https://www.npmjs.com/package/documentation to handle JSDoc + Flow annotations reasonably well.

Did anyone else chuckle at the bug labels (I often find weird things funny)?

Wow. I feel like the only person who doesn't especially like static typing, traditional OO, and typescript.

Many people like myself like static typing and don't particularly care for "traditional OO". I wouldn't put them all in the same bag.

Heljsberg himself (the creator of TypeScript) likes functional programming a lot and brings the best features to his languages.

I haven't tried TypeScript yet, but I look forward to it :)

http://www.itwriting.com/blog/2443-anders-hejlsberg-on-funct...

I put it in because TS added 'class' to the language

What are some reasons to switch from flow to ts?

I see a lot if ts hype, but flow has been getting the job done for me. When non-nullable types come to ts via 2.0, I could see myself switching if there are viable reasons.

basically, on paper flow is better. However, lack of Windows support and poor tooling, plus the fact that it was second to market, slowed down its adoption. Now you have the issue where TypeScript has thousands of type definition for a lot of libraries, and Flow only has a few. Facebook keeps underestimating Windows (eg: there was a survey out for a while asking people if they should just stop working on Windows support for Jest and depend on Windows 10's linux userland support instead).

That, coupled with Flow being harder to get up and running, makes TypeScript much more popular for the average developers. I still prefer Flow though :(

How is Dart doing comparing to TypeScript? I mean what are significant differences?

Sorry, but unless browsers srart interpreting typescript directly, I won't be using it. I'm done with flavor of the month preprocessors. I'll code in the base language and focus on developing my skills there.

I totally get your point and I would think the same if all browsers supported ES6. But right now I would transpile just to use ES6, and TS adds a lot of goodies on top of that. Also, TS is pretty stable and proved its value, it isn't a flavor of the month transpiler.

Maybe it could be better to just learn JavaScript?

TS was developed to avoid replacement of JS(i.e by something like Dart) so I doubt better JS training could help it.

TypeScript doesn't let you avoid learning JavaScript fundamentals. The same basic rules still apply.

The difference is having a compiler and a type system that tells you when you've broken things. Most people that have actually used TypeScript for any length of time understand the type system to be invaluable.

FYI -> https://medium.com/javascript-scene/the-shocking-secret-abou...

Not a strong argument. Static typing prevents a certain class of bugs. There are a ton of bugs that it does nothing for, which is why tests are still useful.

Using Eric Elliott articles as a source is never a good idea. The guy is way too dogmatic and even crazy/harmful.

Reply on news.ycombinator.com