Comment by scrollaway | Hacker News Reader

Comment by scrollaway | Hacker News Reader

Parent Full thread

> I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations.

That's what Typescript is. Type annotations don't change your code, they're stripped away by babel at compile time. In fact, by default, tsc does compile TS code which fails typechecking, into valid JS code (which will likely error when you use it at least in some circumstances, but can run just fine).

Typescript is a clear superset of JS, so there's no actual logical changes or even syntactical changes done by the compiler. However, you may be confused by the often-used "compilation target" features of babel (and tsc), which is that you may write ES2018 code, target ES5, and have your ES2018 syntactical sugar be turned into ES5-compatible code. This is entirely opt-in, and not related to typescript (other than the fact that Typescript is always compatible with the latest ES spec, so you can use any legal ES2018 syntax in it).

Hope that clears it up…

This is where I see a big difference between Flow / TS.

With Flow, the type annotations are just stripped away, none of your Flow code affects runtime code.

This is not so with TS since you have things like Enums, which will be compiled into objects and are part of your runtime code.

If you write type annotations in TS, they're stripped away.

If you write type annotations in Flow, they're stripped away.

There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.

Is there any compiler option or linter config that prevents the use of these extra features?

tslint has no-namespace and no-enum to disallow the two things that create new runtime code

There is no difference if you limit the use of the tool to not use these features.

In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has its own compiler.

When you can implement a tool like this using TS, let me know https://github.com/flowtype/flow-remove-types

Typescript doesn't try to be a different language. It tries to be an exact superset of JS: JS with annotations. And you can absolutely implement what you linked, it exists and it's called tsc: the "compiler" you're somehow upset Typescript has (this + checking types is all it does!). Babel does it natively.

Enums are a fair point, those aren't in the ES specs (though I suspect at some point they will be). However, they're an incredible addition and they really are just syntactic sugar for a more complex type of object.

BTW, typescript supports jsdoc-style annotations, and --allowjs even lets it typecheck javascript code. It also supports more, because nobody actually only wants those things; they're not that great on their own.

Not sure where you got the idea that I'm upset that TS has a compiler, I'm just pointing out my perspective on the differences between the two tools. I use both on a daily basis.

You might not think the differences is a big deal, but affecting runtime code is a pretty major line to cross. Not that there is anything inherently wrong with that, but at that point it becomes a different tool, in my opinion.

No I get you, being able to map the exact code is important. But I think what's happening is you're confused about the ES20XX translation layers. Those aren't at the typescript level, they're at the Babel level … it just so happens that tsc supports that bit, but it's my understanding that this will be going away at some point (eg. typescript will move to only doing the typechecking, and leaving babel to only do the compiling).

enums are a tiny, extremely useful and extremely optional part of the language and they don't warrant this label of "philosophical difference", IMO.

I think Babel does excatly that if only enable the typescript-preset.

Reply on news.ycombinator.com