Repository navigation
Start using ES5 functionality in tsc #10125
Description
Activity
- changed the title
[-]Consider requiring an ES5 runtime for TypeScript[/-][+]Consider requiring an ES5 runtime for running tsc[/+]on Aug 3, 2016 - changed the title
[-]Consider requiring an ES5 runtime for running tsc[/-][+]Start using ES5 functionality in tsc[/+]on Aug 3, 2016 Gotta make the title less scary-sounding. 😃
/cc mihailik who we remember was doing something with TS on ES3
Reacted by mihailikThanks Ryan Cavanaugh (@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,forEachare 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:
forEachandmapare 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.
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)
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 :-(
We're doing this already with
Object.create(null). ES3 support is now effectively dropped.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.
Tom Longson (@nym) we are not dropping support for
ES3as 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 noVladimir Matveev (@vladima) thanks for the clarification.
- locked and limited conversation to collaborators
on Jun 19, 2018
Note that this issue is not about dropping support for
--target es3.This came up in a meeting today. Given that
tsc.exenow uses ChakraCore to runtsc.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
map,filter,reduceLeft,some, andevery.Object.create(null)to avoidhasOwnPropertycalls for every lookup.JSON.stringify.