Start using ES5 functionality in tsc

[DanielRosenwasser]

Note that this issue is not about dropping support for --target es3.

This came up in a meeting today. Given that tsc.exe now uses ChakraCore to run tsc.js, it's not clear how much value users are getting in being able to run TypeScript on ES3 runtimes.

Reasons we'd do this include

• Being able to use ES5 array methods such as map, filter, reduceLeft, some, and every.
• Being able to create empty objects as maps with Object.create(null) to avoid hasOwnProperty calls for every lookup.
• Using get-accessors for lazily computing position information.
• Being able to use JSON.stringify.

[DanielRosenwasser]

Gotta make the title less scary-sounding. 😃

[RyanCavanaugh]

/cc @mihailik who we remember was doing something with TS on ES3

[mihailik]

Thanks @RyanCavanaugh -- the reasons, costs and benefits suggest this should not be done as of yet. There are two parts to this issue: work to be done and resulting effect.

**THE EFFECT** (just looking at the goals stated) seems to be at least superficial, or may be even negative. How so?

Today operations like map, forEach are funneled through a selective subset of APIs. ES5 opens up more ways to do the same thing (some of them obscure or just bizarre). In practice this will lead to a code quality dip, even if migration is factored out.

You would spend time and cognitive effort finding, explaining and checking the safe ES5 subset is used as an ongoing extra "tax".

There are positives of course: tsc.js size would decrease, performance might improve, in certain parts syntax would be more familiar to the non-core contributors. A bit of marketing boost too, as always with getting new features.

Again, looking at the goals stated, there is no killer feature in ES5 that would simplify or boost code:

• forEach and map are already callable through simple wrappers,
• map operations are wrapped too -- so Object.create can be feature-detected and handled at wrapper level,
• getters are marginally cooler than method calls, but performance/readability-wise are just the same.

**THE COST OF IMPLEMENTATION** depends on the strategy.

Could be a risky big-bang with whole team's work disrupted during widespread changes Lots of upfront cost, tailing over the coming week or two.

Or it could be the same cost spread across months while old and new approaches coexist. This migratory state is likely to mess up debugging experience and performance metrics quite a bit.

[weswigham]

@mihailik That's your evaluation of the upsides and downsides for us.... but would this change affect you? Would us moving to writing our compiler with ES5 functions break you? (It would mean that the compiler could no longer be run on ES3 runtimes)

[mihailik]

Yes, because I cannot polyfill getters on ES3. Everything else is a manageable.

If it comes to that, I'll have to peg TS to a pre-ES5 version, and stick to it :-(

[RyanCavanaugh]

We're doing this already with Object.create(null). ES3 support is now effectively dropped.

[nym]

This affects some companies running ES3 native implementations. It may sound like ES3 is extremely old with ES7 on the horizon, but being able to compile TS to ES3 is a very big deal for some large companies.

[vladima]

@nym we are not dropping support for ES3 as compilation target. Question raised in this thread is whether it is possible to run TypeScript compiler itself in ES3 environment and currently the answer is no

[nym]

@vladima thanks for the clarification.