├── .npmrc ├── .gitignore ├── .markdownlint.yml ├── package.json ├── .github └── workflows │ └── lint.yml └── README.md /.npmrc: -------------------------------------------------------------------------------- 1 | package-lock=false 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # gitignore 2 | 3 | node_modules 4 | 5 | npm-shrinkwrap.json 6 | package-lock.json 7 | yarn.lock 8 | 9 | .DS_Store 10 | -------------------------------------------------------------------------------- /.markdownlint.yml: -------------------------------------------------------------------------------- 1 | # for reference, see https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml 2 | 3 | # Default state for all rules 4 | default: true 5 | 6 | # MD013/line-length - Line length 7 | MD013: false 8 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "private": true, 3 | "scripts": { 4 | "lint": "markdownlint-cli2 '**/*.md' '#node_modules'", 5 | "lint:fix": "markdownlint-cli2-fix '**/*.md' '#node_modules'", 6 | "test": "npm run lint" 7 | }, 8 | "devDependencies": { 9 | "markdownlint-cli2": "^0.10.0" 10 | } 11 | } 12 | -------------------------------------------------------------------------------- /.github/workflows/lint.yml: -------------------------------------------------------------------------------- 1 | name: 'Lint Markdown' 2 | 3 | on: [pull_request, push] 4 | 5 | permissions: 6 | contents: read 7 | 8 | jobs: 9 | lint: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/checkout@v3 13 | - uses: ljharb/actions/node/install@main 14 | name: 'nvm install lts/* && npm install' 15 | - run: npm test 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Frequently Asked Questions 2 | 3 | This document contains typical responses to questions that are commonly raised about JavaScript language development, both within the community and to the committee via our various discussion platforms. 4 | 5 | Anyone may suggest new topics by [opening an issue](https://github.com/tc39/faq/issues/new). Delegates may add new topics by creating a Pull Request. If a delegate disagrees with one of these topics, it should be removed. It can be re-added if they and the original topic suggester are able to come to agreement on wording. 6 | 7 | ## Disclaimer 8 | 9 | The information in this document is curated by individual TC39 delegates with minimal review and may reflect personal biases; it is not authoritative and has not been endorsed by TC39. Regardless, it may be helpful for those with questions, or at least a handy reference for delegates or anyone else fielding these questions. 10 | 11 | ## Questions 12 | 13 | ### Why not just add a new version and fix all the mistakes? 14 | 15 | [Disclaimer: FAQ answers are not endorsed by TC39][] 16 | 17 | Having to maintain multiple versions of the language forever wouldn't actually make the world better, and we can't ever stop supporting the existing version. Many of the mistakes are in standard library functions, and those can't realistically be versioned. We'd just have to add new ones and keep the old ones around. 18 | 19 | ### Why don't we just break the web? 20 | 21 | [Disclaimer: FAQ answers are not endorsed by TC39][] 22 | 23 | Browsers are [unwilling to break web pages](https://developer.chrome.com/blog/smooshgate/#why-dont-we-just-keep-the-existing-name-and-break-the-web) for their users, no matter how much you think the developers of those websites deserve it. However, "not breaking the web" does not mean 100% backward compatibility. Backward-incompatible changes *can* be made when the undesirable behaviour is not being relied upon, but the web is very large, which makes it both hard to confidently determine this and unlikely except for very minor or very strange behaviours. 24 | 25 | ### Will WebAssembly replace JS? 26 | 27 | [Disclaimer: FAQ answers are not endorsed by TC39][] 28 | 29 | In the short term, you'll continue to need JS glue code to do many things like interacting with the DOM. In the long term, maybe you will be able to skip the glue code, though some people will continue to write JS, and JS engines will not be implemented in WebAssembly. 30 | 31 | ### Why do numbers sometimes behave unintuitively? 32 | 33 | [Disclaimer: FAQ answers are not endorsed by TC39][] 34 | 35 | JavaScript numbers and arithmetic are specified in IEEE-754. See . 36 | 37 | ### Will JavaScript ever add JSX notation? 38 | 39 | [Disclaimer: FAQ answers are not endorsed by TC39][] 40 | 41 | JSX as it is today can't be added because it conflicts with existing syntax, but a variant could be done, in principle. It's a hard problem because you don't want to tie it to any particular framework. 42 | 43 | ### Can we change the way this language feature or API works? 44 | 45 | [Disclaimer: FAQ answers are not endorsed by TC39][] 46 | 47 | This is always very unlikely due to web compatibility difficulties. It would have to be very well motivated to even attempt. See [*Why don't we just break the web?*](#why-dont-we-just-break-the-web). 48 | 49 | ### Can we change JSON? 50 | 51 | [Disclaimer: FAQ answers are not endorsed by TC39][] 52 | 53 | No chance. Because it is an interchange format with implementations in nearly every computing environment, JSON is set in stone forever. 54 | 55 | ### What's up with PTCs? Does JS have them or not? 56 | 57 | [Disclaimer: FAQ answers are not endorsed by TC39][] 58 | 59 | Proper tail calls (PTCs) are [defined in the specification](https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-preparefortailcall), but are currently only implemented by JavaScriptCore, the JavaScript engine used in the Safari browser. Other engines have no plans to implement PTCs at the moment. PTCs predate [our current process](https://tc39.es/process-document/), which would have prevented a situation like this from happening, and will prevent any others from happening in the future. 60 | 61 | ### Why are some things specified in ECMA-262 and others are in WHATWG/W3C specs? How do I know what is where? 62 | 63 | [Disclaimer: FAQ answers are not endorsed by TC39][] 64 | 65 | ECMA-262 defines a general-purpose programming language which is meant to run in many environments, not just the web. So features that are only relevant to the web will not live in ECMA-262. Additionally, any I/O (including DOM APIs) will not be in ECMA-262. Unfortunately, for general-purpose features that you may be familar with on the web, there is not a good way to know what feature lives in what spec ahead of time. Many of these distinctions are due to outside circumstances, not careful planning. 66 | 67 | [Disclaimer: FAQ answers are not endorsed by TC39]: #disclaimer 68 | --------------------------------------------------------------------------------