TC39 Language Design in the Open Yulia Startsev Berlin.js 2019 - - PowerPoint PPT Presentation

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

Overview

• A bit of history
• Issues from ES4
• The Proposal Process
• 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]. *

1995

A prototype named Mocha Written in 10 days by Brendan Eich, this is the first “JavaScript” implementation from netscape

1996

Microsoft releases JScript JScript was a reverse engineered version of JavaScript. To keep MicroSoft in check, Netscape moved to standardize JavaScript

1997

ECMAScript 1

1998

ECMAScript 2

1999

ECMAScript 3

2009

ECMAScript 5

2015

ECMAScript 6 ...

The Timeline

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”

1995

A prototype named Mocha

1996

Microsoft releases JScript

1997

ECMAScript 1

1998

ECMAScript 2

1999

ECMAScript 3

2009

ECMAScript 5

2015

ECMAScript 6 ...

The Timeline

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

Stage 0 Someone has an idea and they write it up Stage 1 The idea is presented to the committee, committee makes comments Stage 2 Committee discusses if this feature “should be in the language” Stage 3 Polyfill and browser implementations, final form of the proposal takes shape Stage 4 Proposal is included in the specification

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?

Stage 0 Someone has an idea and they write it up Stage 1 The idea is presented to the committee, committee makes comments Stage 2 Committee discusses if this feature “should be in the language” Stage 3 Polyfill and browser implementations, final form of the proposal takes shape Stage 4 Proposal is included in the specification

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

Stakeholders

What is at stake?

O t h e r S t a n d a r d s B

• d

i e s

Vendors Users Developers

Users Developers Vendors

• 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.

The Extensible Web Manifesto[*]

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
• perating system or their browsers.

Pure CSS Francine by Diana Smith

Users Developers Vendors

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.

Current work

• WASM and JavaScript
• Class improvements
• Realms
• Lots more!

Getting Involved!

• Community groups
• The website
• 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