
Glimmer.js: What’s the Deal with TypeScript? - lowonkarma
https://medium.com/@tomdale/glimmer-js-whats-the-deal-with-typescript-f666d1a3aad0
======
YCode
What sold me on TypeScript was that it didn't just add features, it actively
solved a problem I'd been experiencing.

Once a JavaScript project scales beyond what can fit in your head, JS's
initial productivity boost crumbles because you have to constantly double back
and make sure your methods/constructors/etc. are correctly used, which
properties are optional, etc... A lot of the debugging happens in runtime and
god help you if you try to make a breaking change to one of the major
classes/apis in your project.

It's not unbearable, but the main reason for using JS is because of the
productivity it allows.

With TS for the cost of taking the time to explicitly define your data you get
a C#/Java level of debugging that has clear productivity gains and shifts your
debugging from the browser/console to the IDE.

And when something doesn't fit the TS model you can just exclude it or only
type the wrappers that integrate with the rest of your project.

That and async/await is a godsend over promises.

~~~
pryelluw
Have you tried Elm? Id love to know your experiences.

~~~
YCode
I haven't; I haven't tried Flow either which looked promising.

For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm
highlights errors inline(?). The syntax also looks a little foreign, whereas
TS generally still looks like JS with a few exceptions.

I imagine Elm/Flow both have this, but another thing I like that TS does in
VSCode at least with a watching task is collecting errors project-wide in a
"problems" window.

~~~
bpp
Flow gets a good amount of the way there; it doesn't have quite the tooling of
TypeScript but VSCode is actually able to bring a lot of that tooling to a
Flow-typed codebase. Just yesterday I finished a major refactor that I'm not
even sure I'd have attempted if we weren't using Flow. One giant action file
feeding three insane reducers – yet I'm confident (with some testing) that
it'll still work when I deploy today.

------
pfooti
There's two things that really stand out for me on TypeScript. There are other
positive attributes, but these are the two things I liked.

The first is that it made some specific workflows a _lot_ easier. In
particular, I'm working on some pre-alpha libraries where there's movement on
how the API interface is defined. TypeScript made that transition a lot
easier. Yes, my testing would have eventually caught all the method arity
mismatches, but TypeScript made this happen about an order of magnitude
faster.

The second is how unobtrusive the types actually are. I did a fair bit of J2EE
programming in the 00s, and types and interfaces can be really annoying. With
typescript, interfaces are assertions about the shape of an object, rather
than things themselves. That means, if you defined an interface as
HasFirstName: { firstName: string } and function greet(person: HasFirstName),
you don't actually have to put HasFirstName everywhere in the code that uses
that function. You're not required to set up inheritance or anything. You just
have to make sure that all arguments to greet have a firstName property.
That's it. So I can say: const dude = { firstName: 'the' }; greet(dude) just
fine. But if I try to greet(potato), it'll error.

Lexical typing this way gives you a lot of power while still staying out of
your way in a language like javascript where it's super common to create
consts as bags of properties without worrying about what particular interface
they're instantiating. I really like that, as it is precisely the overbearing
types of Java that annoy me.

~~~
DougBTX
For google-ability, TypeScript has structural types, in contrast with Java
which has nominal types.

~~~
pfooti
Ah, thank you - that's a set of names that I need, in order to express my love
for TypeScript.

------
Joeri
I've done a few typescript projects. Some migrating an existing codebase, some
starting from scratch. Every time it has been a nice experience, and with
every release it gets nicer. Two of the projects had very complex
requirements, and typescript was instrumental in being able to refactor them
with confidence.

I think the upsides are quite well known by now. Honesty requires me to admit
that I did run into some downsides:

\- Initially it was difficult to understand the exact mechanics of how
typescript ... types. Definition files seemed like a bit of a black art, and
how to annotate existing code so that it had the proper type wasn't always
obvious, especially when you run into libraries with incomplete or wrong type
definitions and when you want to do tricky stuff like creating typed mocks in
unit tests. The typescript documentation is very good and I haven't needed
much beyond it, but some extra real-world type definition chapters would help.

\- Setting up a complete dev toolchain is challenging. I wanted everything:
source maps, in-IDE debugging with breakpoints, in-IDE unit tests with code
coverage, tslint, gradual introduction into an existing codebase, and robust
integration into the build of the rest of the app (which in my case meant SBT
integration). I still don't have code coverage in my in-IDE unit tests. The
way I see it though, if your javascript has any build step at all you already
have this pain, so this isn't so much a problem with typescript as a problem
with javascript build pipelines in general.

\- Convincing other developers typescript has value and isn't javascript's
weird ugly nephew is an uphill struggle. Once you do a typescript project you
end up understanding the value, even if you might not find it valuable for
yourself personally, so it's only a matter of convincing developers to give it
a go. However, getting to that point is a bit of a chicken and egg problem.

~~~
KurtMueller
> Convincing other developers typescript has value and isn't javascript's
> weird ugly nephew is an uphill struggle.

I feel the same way about Elm, F# and Fable, Facebook's ReasonML, and any
other language that has an ML type system and compiles to javascript. I think
the value becomes more apparent when: a) you work in a large codebase and have
to refactor either a large swath of code and/or a critical piece of logic and
b) you need to make illegal states unrepresentable. In both cases, I have
found having a compiled, ml-typed language extremely helpful.

I think for both Typescript or an ML language, having immutable non-nullable
types by default really cuts down on complexity - instead of having to specify
everything that's immutable with something like a `const` keyword, you instead
have to specifically point out which attritibutes on a type are mutable.
That's a small win but has huge benefits - especially when you're trying to
debug code.

That's just my two cents anyway.

------
gryzzly
Anyone got a link on how to transition existing large webpack/React/babel
project to using Typescript? Googling I only found
[https://medium.com/@clayallsopp/incrementally-migrating-
java...](https://medium.com/@clayallsopp/incrementally-migrating-javascript-
to-typescript-565020e49c88) but it doesn’t use ts-loader and doesn’t go into
details on how to use typings. I tried following ts-loader docs, but things
broke at `import flatten from 'lodash/flatten'` and adding typings for `lodash
` didn’t help. Would be interesting what strategies people use to get it
working in existing project.

~~~
barake
ES2015/commonjs interop currently sucks with TS. This is how you only import
flatten:

    
    
      import flatten = require('lodash/flatten')
    

TS expects any modules imported using ES2015 import to have the shape of a
ES2015 module. This is an issue for many UMD/commonjs modules. In the case of
lodash, it's effectively doing this:

    
    
      module.exports = flatten
    

And then you're importing it like so:

    
    
      import flatten from 'lodash/flatten'
    

and that is being transpiled to something like:

    
    
      var flatten = require('lodash/flatten').default
    

Note the default.

I haven't migrated to webpack 2, but some brief experiments suggest all
modules get massaged in to ES2015 format.

~~~
wagi_ch
I've been using `allowSyntheticDefaultImports` which does some magic behind
the scenes for you to be able to use `import flatten from 'lodash/flatten'`
making it really easy to use modules that don't define default exports.

So far (a bit unexpectedly) I didn't really run into any nasty side-effects or
things that went wrong with it.

See [https://github.com/Microsoft/TypeScript/wiki/What%27s-new-
in...](https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-
TypeScript#support-for-default-import-interop-with-systemjs) for a (short)
explanation.

------
picardo
I have a project that uses Flow. I've had no complaints with it so far, but
I've been craving the IDE support of TypeScript. What's the difference between
the type system of TypeScript and Flow? Would it be worthwhile to switch?

Part of me wants to wait out the Flow team come up with better IntelliSense
support. The `flow ide` command in the release 0.42 is a big step in the right
direction. But it seems like TypeScript already has this, and if the delta
between the two type systems is small, I might just go ahead and switch.

~~~
kej
>What's the difference between the type system of TypeScript and Flow?

This presentation [1] was posted to HN recently and gave a pretty good
overview of the differences between TypeScript and Flow.

[1] [https://djcordhose.github.io/flow-vs-typescript/flow-
typescr...](https://djcordhose.github.io/flow-vs-typescript/flow-
typescript-2.html#/)

~~~
picardo
Awesome prez! Thanks for the link!

------
tabeth
I haven't used TypeScript extensively, but I feel that there should be more of
a push (maybe there is, please correct me if I'm wrong) to introduce whatever
functionality people deem worthy that exists in TypeScript and introduce it to
JavaScript.

You can already see the conflict happening as some people prefer Flow and
others TypeScript. Perhaps later Google will throw their hat into the ring and
introduce GScript. Then, you have three different languages that introduce
similar functionality, that all transpile into JavaScript.

Sound familiar?

~~~
recursive
The flagship feature of TS is static typing. That will never exist in JS.

~~~
Lio
I'd never say never. As I'm sure you're aware, JavaScript has had statically
typed arrays since WebGL was introduced.

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Type...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Typed_arrays)

~~~
recursive
It has _typed_ arrays, but they're still not statically typed. In a statically
typed language, this would not run.

    
    
        console.log("hello");
        typedArr[0] = incompatibleType();
    

In javascript, it will produce "hello" as output, and then a run-time failure.

------
subkamran
TypeScript is amazing, enough said. If you're building any application with
any amount of code that has to be worked on by anyone other than yourself, you
want to use TypeScript (I'd argue even for yourself, use it, it'll catch
enough errors to pay for itself in spades). Coupled with editors like Visual
Studio Code which are cross-plat and have first-class tooling for TS/JS, it
just makes you objectively more productive both as a consumer and writer of
Javascript. Even the most die-hard pessimists I've met love TypeScript once
they try it.

------
finchisko
Ok, when Glimmer's motivation was only typechecking, why not just fb flow
then?

~~~
Etheryte
Having used both extensively, TS is simply the better choice. Flow has
multiple large bugs and issues, which many would consider critical, open and
unsolved on their GitHub repo for more than a year(!) [1][2][3].

[1]
[https://github.com/facebook/flow/issues/245](https://github.com/facebook/flow/issues/245)
[2]
[https://github.com/facebook/flow/issues/869](https://github.com/facebook/flow/issues/869)
[3]
[https://github.com/facebook/flow/issues/1528](https://github.com/facebook/flow/issues/1528)

~~~
lfischer
I struggled with multiple blind spots in Flow in the past, but recently tried
porting the same code to Flow and Typescript and I was surprised that Flow
took less work than TypeScript. Flow 0.43.1 has become very fast and seems to
need less type annotations compared to TypeScript with noImplicitAny enabled.
I wonder whether Flow’s happily infers any without complaining or whether its
program flow analysis remains more sophisticated.

------
tomelders
Am I the only one who thinks typed Javascript, wether it's TypeScript or Flow,
is a really flakey experience?

I really enjoy Swift, so I'm not put off by types. But I find the experience
of working in a real typed language to be very different to working with Flow
or Typescript, where the types are for pretend, and type definitions are wrong
often enough to be a real pain. And I found my self evaluating npm packages
based on their type definitions, and not their suitability for the task, which
seems bonkers to me.

Also, I don't ever recall staying late to track down a bug that types would
have fixed. But I've wasted many an hour tracking down bugs caused by
mutations, and the state of Immutability and Typed Javascript is pretty grim
as far as I can tell, unless I'm missing something.

~~~
rubiquity
Types are pretend in TypeScript and Flow the same way that types are pretend
in any other typed language. Types are used at compile-time and not runtime in
both cases.

~~~
egeozcan
In contrast to many typed languages, currently in Typescript, you can't do any
kind of reflection so runtime really has no access to the type system.

Well, I still love TS though.

~~~
johnfn
There is the possibility of decorators for stuff like this. Angular makes a
lot of use of them.

~~~
egeozcan
But isn't that some sort of repetition? I don't know how Angular does this so
I'm really asking.

~~~
johnfn
Well, it depends on the sort of reflection you want. Decorators get a decent
amount of knowledge about the code.

------
tumblen
Is there a way for typescript to be used as PropTypes in React?

------
edance
Does anyone know when Ember will use TypeScript?

~~~
praxxis
Post TypeScript 2.3 - per
[https://twitter.com/tomdale/status/851924328220381185](https://twitter.com/tomdale/status/851924328220381185)

~~~
edance
Thanks!

------
uranian
>At the end of the day, though, JavaScript is the language of the web.

And when webassembly arrives that will be over, and Typescript will be
deprecated. I can't wait for a better modern language like Haskell, Python,
Livescript, etc.. built on top of webassembly. Then we can finally stop trying
to fix Javascript's flaws with new language features.

~~~
untog
And I can't wait for the rude awakening anti-JS developers have when they
realise the vast majority of issues (particularly, performance) come from the
DOM, not JavaScript. (And the first version of WebAssembly can't touch the DOM
anyway)

If people start writing Python for the web for no other reason than they just
dislike JavaScript we're going to be forcing users to download a dozen
different runtimes, just because of developer preference. This isn't a good
thing.

~~~
pryelluw
What would you replace the DOM with?

~~~
untog
I honestly have no idea. It does so much that I don't know where you'd start -
but I suspect that's also the problem.

I remember seeing a demo of React Canvas a few years ago - basically,
recreating a "DOM" of sorts inside a canvas tag - and the performance was
crazy. Beautiful 60fps touch interactions. But, of course, it only does a tiny
subset of what the DOM does. I'm still waiting for a good reason to use it
myself to try out how the API feels.

~~~
pryelluw
I feel the same. Dunno wth we gonna do but we need something more performant.

------
petre
Well, if we already transpile ES7 to JS then why not tanspile TypeScript
instead because of all the added benefits?

~~~
Achshar
Because eventually in a couple of years you can take your ES7 code and remove
the transpiration and it will all work seamlessly. Not so much with
Typescript.

~~~
vladimir-y
Transpiling is going to stay, currently you transpile es6/7/typescript=>es5,
later you will do es8/9/typescript=>es6/7, and so on, so this point is not
relevant.

~~~
Achshar
I meant it in the code's current state. Suppose the development stops or
stagnates in a month or two. The product is complete. So you can remove the
transpilation. Also we won't have to transpile current features in the future.
That and code can go as is and have the benefit of native execution that it
doesn't currently have.

------
ruleabidinguser
TypeScript provides the same value as intellisense.

E: i didnt mean this as a criticism

~~~
johnfn
It's a bit more than intellisense.

* find definition

* find usages

* auto import (never type "../../../../../dumb.js" manually again)

* er... types

------
arcosdev
What turns me off immediately about TypeScript (and examples in the article
show it) is the use of the class construct. If I could see some examples of
teams writing TypeScript without falling into the use of classes I would feel
a lot better about it. I am in full agreement with Douglas Crockford and
others that adding pseudo-classes to JS was a big mistake.

~~~
zebrafish
I'm curious as to why you don't like the use of classes. Are you against
classes in all languages or just JavaScript?

~~~
arcosdev
I'm not against classes in other languages, especially those that follow a
typical OOP pattern (i.e. Java, C#, etc.). See above for my reason re:
JavaScript.

~~~
valuearb
So appeal to authority?

