Frequently Asked Questions
Frequently Asked Questions
- Why don't we remove or fix bad features?
- Why don't we make breaking changes with a language version?
- Why don't we deprecate features?
- How can we use new syntax on old browsers?
- Will we add new restrictions to strict mode?
- Why don't we standardize a bytecode VM?
- How do we avoid design-by-committee?
- Do all those design sketches mean JS will get bloated?
- How can I suggest a feature?
- I'm nervous about posting to es-discuss. Any advice?
If we did, existing web content would break. No browser vendor is willing to be the first to make such changes, because a rational end user perceives them as browser bugs and switches to a different browser.
The only time we can make an incompatible change is if the web happens not to depend on it. There's no way to know for sure whether this is the case except by experimenting. Browser vendors can take a chance by making an incompatible change in alpha or beta versions of their browsers and seeing whether they get any bug reports about breaking content.
Versions or modes may sound appealing, but they have the wrong defaults: an unspecified version (e.g., in a
script tag or an inline attribute) always gets the old version—to get an improved language you always have to specify a version. It's not even possible to specify a language version in an inline HTML attribute. Maybe worst of all, adding modes or versions adds a dimension to the platform matrix for application testing and tracking platform feature availability.
For all these reasons, opt-in versioning faces an uphill adoption battle. It's also a huge implementation and testing burden on platform vendors—it increases their set of sub-platforms exponentially—so browser vendors typically oppose new modes.
Deprecation doesn't work on the web. Since we can't remove bad features, a developer has little incentive to stop using a feature just because somebody somewhere doesn't like it. Labeling features "deprecated" without ever removing them is pointless.
catch, which was introduced in ES3 (1999). It took years before widely-deployed applications could use it, but it's now a full-fledged part of the web platform.
ECMAScript Edition 6 is targeting a 2013 spec release, but browsers are already implementing individual features.
TC39 uses the Harmony process for design work. Small teams work independently on a design sketch and present it to the rest of the committee for discussion. These teams act as the champions for their design. If the committee decides the design has become promising enough to be worth pursuing, the sketch is promoted to an official proposal. The champions of the proposal continue to lead the design work and refinements to the proposal.
Definitely not. Most design sketches are not accepted as official proposals. The design process requires going through many, many ideas before picking the best ones. TC39 makes design sketches public to encourage as much community feedback as possible, as early as possible.
Send an email to es-discuss!
I'm nervous about posting to es-discuss. Any advice?
Just keep it short and constructive. Everyone is welcome to contribute or provide feedback.
If you aren't sure exactly what the solution or design you have in mind should look like, don't worry: just describe the problem you perceive. Feedback from developers about common problems can be particularly valuable.
Also: please trim cited text to only the relevant parts (Gmail users: the UI hides cited text from you but it's still there—please unhide and trim!).