From a talk at Javascript Israel:
An overview of the TC39 process, ECMA, and two proposals that are currently being considered: Pipeline Operators and Private Class Members.
6. ACTIVE PROPOSALS - IN PRACTICE
● Private methods and fields
● Pipeline operators
ABOUT TC39
GET INVOLVED!
How to write Javascript?How to make Javascript?
7. Why you should care about TC39?
● Learn a TON
● Be first
● Meta open-source
10. Private Fields / Methods (Stage 3)
WHAT
Class members only avail. in-class
WHY
Currently:
Class members are always public
Unwanted use of your class
Easier breaking changes
15. WHY # - the real reason
It needs to be currently invalid syntax
Won’t break any previously-written code
16. Pipeline Operators (Stage 1)
WHAT
Allowing infix operator to handle piping
of value through multiple methods.
WHY
Current way is difficult to read and
reason about
44. Candidate
Stage 3
● Approval on Spec
● Any further changes will now
require feedback from
implementations and users
Strawperson Proposal Draft Candidate Finish
0 1 2 3 4
46. Finished
Stage 4
● Ready to be shipped!
● Tests are written and pass
● Implementation exists x2
● No changes expected
● See you next July!
Strawperson Proposal Draft Candidate Finish
0 1 2 3 4
John F Kennedy once said “Ask not what your country can do for you, but what you can do for your country!”
JFK was calling for all citizens to contribute in some kind of way to the social good of the country.
Tonight, I hope to get Javascript developers to become interested in contributing their time to making the language better.
A little bit about me
I’m a software engineer at Lemonade
My fav open source project to contribute to is vscode
I love playing basketball
Hanging out w my family
Where I mostly tweet complete nonsense.
This is Eevee - we adopted her a week ago, and she’s a vicious killer
Creating methods and fields on classes that can be accessed only from inside the class.
*NEXT* Previously, methods and fields declared on a class were always public. *NEXT*
Anyone can access them - and potentially manipulate them at will.
A HUGE disadvantage.
Could lead to misuse of methods that are only meant for internal use in the class.
*NEXT*
As you can see - we have a standard class definition here. And id is accessible easily outside of the actual class.
Once we make the field private, it’s no longer accessible outside the class.
* NEXT *
A few people have raised concerns about this - but not very valid concerns.
Hash isn’t very javascripty?
Using _ instead of #
How many people here already use that in their code?
*NEXT*
So much would break if that was adopted
Also, nothing is very javascripty until it is.
Then there are some silly responses - like: We already have those kinds of private fields - they’re called underscore properties.
*NEXT*
Which, I hope this person isn’t actually doing.
Their method is as public as the ending of Game of Thrones.
The real reason we are going toward # is because it needs to be invalid
That way we don’t break previously written code, and don’t have accidental conflicts.
Previously, you would have to wrap each value and resulting value of previous operation in the next function.
So as an example, we’ll take a cc number as a string and obscure all but the last four digits.
I know there are simpler ways to do this - but I broke the process up into three methods on purpose.
* NEXT *
This is of course extremely hard to read.
You need to carry the mental load of finding the innermost function, and then following the logic outward.
And that’s assuming you can remember what each function does.
WAY TOO MUCH WRAPPING
* NEXT *
This is of course extremely hard to read.
You need to carry the mental load of finding the innermost function, and then following the logic outward.
And that’s assuming you can remember what each function does.
WAY TOO MUCH WRAPPING
* NEXT *
This is of course extremely hard to read.
You need to carry the mental load of finding the innermost function, and then following the logic outward.
And that’s assuming you can remember what each function does.
* NEXT *
As you can see - we have a standard class definition here. And id is accessible easily outside of the actual class.
Once we make the field private, it’s no longer accessible outside the class.
* NEXT *
For this feature, there’s been some really interesting discussion on things like how much partial application can be allowed, and there are even 2 different approaches being considered. But just like with private methods - there’s concern that the syntax was a bit
* NEXT *
homely.
TC39 is a part of ECMA International. TC39 standardizes what will go into the ECMAScript standard.
Standardization of the language syntax, semantics, and libraries and complementary technologies that support the language.
TC39’s committee, and the decisions they make are
Vendor neutral - they are not partial to any one manufacturer of a browser (chrome, firefox, Edge, Edge on Mac for some reason)
Cross-platform - they are not restricted to specific platforms like server-side only, or client-side.
General purpose - it doesn’t make assumptions on how you’ll use it. Making a simon game, etc.
By the way, I checked - and TC38 is in charge of Environmental impact of consumer electronics.
*NEXT*
Hippies
And TC45 is in charge of Open Office XML Formats
*NEXT*
Nerds
Anyway - TC39 looks a bit more like this. Might seem a bit more familiar to us. So who exactly are these
*NEXT*
Masters of the Javascript universe who literally decide how we work every day?
ECMA Itself is made up of companies The membership of ECMA’s TC39 is made up of Ordinary members - Companies that are voting members of ECMA
Large members that have experience and interest in shaping the web
Lots of non-profits including universities, the library of congress, and somehow Ben Gurion University?
And small and medium size organizations who are interested in taking an active role in building out the ECMAScript standard
TC39 meetings are attended by delegates of the companies we mentioned earlier.
They represent these companies in matters relating to evaluating different proposals, and deciding which proposals get moved to the next stage.
So the members of TC39 are companies - and each of them sends delegates.
Every few months, TC39 gets together and discusses the proposals that have come up, and which proposals qualify to move from one stage to another.
July of each year - a new version of ECMAScript is approved by the General Assembly
Stage 0 is called the “strawman” phase
It just means a proposal exists.
Your proposal might end up in the form of a
At stage 1, you need to find someone who is a delegate to TC39 to take your proposal forward.
This means you need to make a good enough point that your proposal solves a big enough need in the community.
You need to provide a written description of the problem and solution
You’ll need to show actual use-cases, and the syntax of the proposal itself.
You also need to provide details of high-level API
At this point, expect major changes to the way the API is shaped and the logic behind the implementation details.
There can definitely be polyfills that exist at this stage - meaning you can theoretically start using even stage 1 features in your apps but with caution.
SHOW POLYFILL
Stage 2 means that the committee has spent time defining and discussing the API you described and the solution you suggested in Stage 1.
If your proposal is accepted, it’s considered experimental and could be included in implementations.
Still considered experimental. So you’re still going to need to use babel for it, and changes are expected.
Stage 3 means changes are expected to be very minor and only based on actual real-life experience of users and implementations.
SANDBOXING IS HARD. You can’t really soft-launch a feature once it exists and is known.
But ECMA stages give you the ability to define maturity levels so the onus is on the user to treat their builds accordingly.
Stage 4 means all tests are written for the spec, it exists in at least two major implementations.
At this point no changes are expected. If they want to change
Stage 4 means all tests are written for the spec, it exists in at least two major implementations.
At this point no changes are expected. If they want to change
I feel like people have this concept of Javascript that it’s something that just happens,
Or that it’s a high ivory tower that is not approachable by others.
You might even run into some names you recognize on there.
And some that are complex and would require a ton of work.
When in reality there are tons of vibrant discussions happening about the proposals - sometimes they’re requests to add functionality to proposals.
Like this one, which requests that @final be added as a decorator so that a user can define that a field can not be overridden once defined in a class.
When in reality there are tons of vibrant discussions happening about the proposals - sometimes they’re requests to add functionality to proposals.
Like this one, which requests that @final be added as a decorator so that a user can define that a field can not be overridden once defined in a class.
Some proposals are really simple and straightforward
And some that are complex and would require a ton of work.
