I'll go out on a limb though and posit that classes are now idiomatic JS when doing OO. Shops are not cutting modern JS with objects built up via direct prototype manipulation.

Dunno, but I hope not. We built a moderate-sized TS codebase with _no objects at all_. Just functions and data types. Roughly functional ... with the caveat that nothing was preventing us from mutating incoming params (though our intent was not to do so).

I'd like to hope many people are using TS in a functional style.

EDIT -- there was one object ... we had to create an exception class for some reason ... don't fully recall the details.

It's a bit wordy, but I think you can do something like:

    function test ({param1, param2}: {readonly param1: string, readonly param2: number}) {
        return
    }

A codebase with no objects... I am guessing you mean no classes.

Seeing how functions are objects in JavaScript and all...

:rollseyes:

Agreed. ES6 class syntax is superior to constructor functions and prototype mutation, because it's declarative and statically analysable.

I think the only legitimate reason left not to use ES6 class syntax is (for perf sensitive code) performance, but that's a negligible and temporary problem as the JS engines will fix that over the next 6 months.

Thank you. I wanted to say almost exactly the same thing, but you worded it much better than I could have.

Point number one in particular bothered me since both languages are transpiled (in both cases that just means types stripped). However, I think MarcusBrutus was talking about Flow type comments which can be added to Javascript files to get type checking, but which will not need to be transpiled at all as all nonstandard stuff is in the comments.

Flow is not a transpiler, there is no concept of "emitting code", only of stripping away the annotations. In contrast, TypeScript is a transpiler. TypeScript being a transpiler means what gets executed at runtime is not what you wrote but some other sources emitted by the TypeScript transpiler. You say that presently (apparently due to the delta between ES6+ and TypeScript being currently very small) what is emitted is not materially (for some definition of "materially") different from the input sources. Even if that's true, this is simply a transient situation that may not hold next year (we're still in the "embrace" stage after all) and certainly didn't hold when I looked at TypeScript circa 2013.

Otherwise, can you please explain why bother implementing a transpiler if the emitted sources are identical to the input sources minus the annotations?

Even the names should give you a hint: "TypeScript" is a language name (the microsoft version of ECMAScript more specifically). "Flow" is not. That's why it's called "Flow" and not "FlowScript".

Realistically, you are going to do the same thing with TypeScript and Flow, except with different tools: with TypeScript, you'll use the transpiler, and with Flow, you'll use Babel. In technical terms they are different, sure, but in reality they're basically the same. Unless you use the comment style Flow types, you will have to run your code through some stage to remove the types.

> TypeScript being a transpiler means what gets executed at runtime is not what you wrote but some other sources emitted by the TypeScript transpiler.

This is also true with Flow, if you want to be technical. What you write with Flow is not valid JavaScript (with the sole exception of comment style types) but some other sources emitted by another program like Babel.

If you haven't looked at TypeScript in 3-4 years, then you can't really make an informed opinion on the subject, because in that timeframe React has gone through 12 versions, Flow did not publicly exist, and TypeScript has changed significantly. It might be worth looking at TypeScript again and seeing how it compares to Flow in 2017.

You can use Babel to only remove the types, and not touch the code in any other way. And that's an important distinction: the code is exactly the same, just without types. I've been unable to use a Babel plugin at least once because of the way Typescript transpiled the code.

> Flow is not a transpiler, there is no concept of "emitting code", only of stripping away the annotations. In contrast, TypeScript is a transpiler.

TypeScript is a transpiler to the extent you want it to be a transpiler. You can use it to remove annotations only with '--target ESNext' - then it works the same as Flow does in your use case and does not add anything.

In the same vein, most people use Flow with babel. Then it's "transpiling" in the same way TypeScript is "transpiling".

You're either severely misinformed or opting to make your argument by misleading. I wonder how much you have actually used TypeScript.