TC39 Language Design in the Open Yulia Startsev • Berlin.js 2019
Hi. My name is Yulia. I work at Mozilla. I am also a co-chair on TC39
A bit of history ● Issues from ES4 ● The Proposal Process ● Overview How is JavaScript designed today? ● Current Work ● Getting involved ●
What was JavaScript?
The Requirements A scripting language for web APIs ● Intended to be easy for both professionals and amateurs ● Developed by Brendan Eich in 10 days ● Originally planned as a Scheme-like language[*] ● It should look like Java ● “It was deceptive in intent and effect”
We aimed to provide a “glue language” for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the “component language” used by higher-priced programmers, where the glue programmers—the Web page designers—would assemble components and automate their interactions using [a scripting language]. *
The Timeline A prototype named Mocha Written in 10 days by Brendan Eich, this is the first “JavaScript” ECMAScript 6 ... implementation from netscape ECMAScript 1 ECMAScript 3 1996 1998 2009 1995 1997 1999 2015 Microsoft releases JScript ECMAScript 2 ECMAScript 5 JScript was a reverse engineered version of JavaScript. To keep MicroSoft in check, Netscape moved to standardize JavaScript
TC39 and its structure Part of Ecma International ● Technical Committee 39 of Ecma International ● Takes care of several standards aside from JavaScript, including ● ECMA-402, ECMA-404, ECMA-414 Operates via “consensus” ●
The Timeline ECMAScript 6 ... A prototype named Mocha ECMAScript 1 ECMAScript 3 1996 1998 2009 1995 1997 1999 2015 Microsoft releases JScript ECMAScript 2 ECMAScript 5
Issues with ES4[*] ES4 was a proposed standard that was debated for 10 years ● Proposals were added to the language without implementations ● It became too large, vendors began to wonder how much of it should be ● implemented ES3.1 was introduced as an incremental change that was a subset of ES4 ● These two specifications eventually came into conflict ●
Moving forward with “Harmony” The project codenamed “Harmony” would lead to first to ● ES3.1, then ES5 and ES6[*] Addresses the issue of having working implementations ● for proposals, called the Harmony Process Introduces a structure of champions, using ESDiscuss, ● and advancing proposals in stages
Someone has an idea Committee discusses if Proposal is included in and they write it up this feature “should be the specification in the language” Stage 0 Stage 1 Stage 2 Stage 3 Stage 4 The idea is presented Polyfill and browser to the committee, implementations, final committee makes form of the proposal comments takes shape
Stage 0 Allow input into the specification ●
Example: Pattern matching
Stage 1 Make the case for the addition ● Describe the shape of a solution ● Identify potential challenges ● Requirements Identified “champion” who will advance the addition ● Prose outlining the problem or need and the general shape of a solution ● Illustrative examples of usage ● High-level API ● Discussion of key algorithms, abstractions and semantics ● Identification of potential “cross-cutting” concerns and implementation ● challenges/complexity
Stage 2 Precisely describe the syntax and semantics using formal spec language The committee expects the feature to be developed and eventually included in the standard Requirements Initial spec text ● all major semantics, syntax and API are covered, but TODOs, placeholders ● and editorial issues are expected
Stage 3 Indicate that further refinement will require feedback from implementations and users The solution is complete and no further work is possible without implementation experience, significant usage and external feedback. Requirements Complete spec text ● Designated reviewers have signed off on the current spec text ● All ECMAScript editors have signed off on the current spec text ● All semantics, syntax and API are completed described ●
Stage 4 Indicate that the addition is ready for inclusion in the formal ECMAScript standard Requirements Test262 acceptance tests have been written for mainline usage scenarios, ● and merged Two compatible implementations which pass the acceptance tests ● Significant in-the-field experience with shipping implementations, such as ● that provided by two independent VMs A pull request has been sent to tc39/ecma262 with the integrated spec ● text All ECMAScript editors have signed off on the pull request ●
How is JavaScript Designed Today?
Someone has an idea Committee discusses if Proposal is included in and they write it up this feature “should be the specification in the language” Stage 0 Stage 1 Stage 2 Stage 3 Stage 4 The idea is presented Polyfill and browser to the committee, implementations, final committee makes form of the proposal comments takes shape
TC39 Meetings 6 meetings a year ● 89 delegates from members ● Usual attendance of ~60 ● Proposals are presented followed by debate ● Session ends with a decision ● Everything is recorded and published at ● https://github.com/tc39/tc39-notes
Developers What is Vendors s s d e r a i r d e d o h n B t a O t S at stake? Stakeholders Users
Users Vendors Developers
The Extensible Web Manifesto[*] ● The standards process should focus on adding new low-level capabilities to the web platform that are secure and efficient. ● The web platform should expose low-level capabilities that *** explain existing features ***, such as HTML and CSS, allowing authors to understand and replicate them. ● The web platform should develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a virtuous cycle between standards and developers. ● The standards process should prioritize efforts that follow these recommendations and deprioritize and refocus those which do not.
Backwards Compatibility Many people rely on the web for their livelihood ● Many people rely on services provided by the web ● Not all users have the capability to upgrade their ● operating system or their browsers.
Pure CSS Francine by Diana Smith
Users Vendors Developers
Why not break the web? The costs are impossible to estimate ● It is easy to rename something. ● Array.prototype.contains -> Array.prototype.includes Breaking the Web affects users disproportionately ● compared to developers. Making the web worse for users pushes them away from the web.
WASM and JavaScript ● Class improvements ● Current work Realms ● Lots more! ●
Community groups ● The website ● Getting Involved! Discourse ● Participating on github ● What to watch for news ●
Community Groups Community groups have been organized around tooling, ● frameworks and teaching. Groups meet once a month on average ● We are planning an “open house” community call after ● each plenary If you want to get involved, talk to me ●
The website The website lives at http://tc39.github.io ● You can participate in the work on the website at ● https://github.com/tc39/tc39.github.io You can also check the website for change as the spec ● evolves.
Participating on Github You will need to sign the IPR form ● You can find all of the proposals under ● https://github.com/tc39/proposals You can also work on tests at ● https://github.com/tc39/test-262
News? What to watch The website ● ES discourse ● Proposals directory ● Notes summaries ● Follow committee members, we often post news ●
Upcoming Events in Berlin JSConf EU Panel - June 1-2 ● Ask us Questions! ○ Use the twitter tag #tc39panel ○ We will answer on stage and the session will be recorded ○ Meet the TC39 - June 6th ● At fullstack.js meetup ○ https://t.co/dPrqyrJSzh ○
Seriously. ask us questions #tc39panel
Thank you. Please get in touch ? @ioctaptceb yulia@mozilla.com
Recommend
More recommend
