(upbeat instrumental music) - Hey everyone.
So I am here to talk about where JavaScript is now and mostly where it's hopefully going.
And my main goal for speaking here today is to hopefully inspire as many of you as possible to get involved in the development of JavaScript the language.
It turns out that the more people are involved, the more diverse perspectives that we can collect. The more different types of developers we can talk to. And more people that are just offering their perspectives, the better the language can be.
So I hope to inspire you to try and do that. So I'm gonna give you.
This talk just goes at a sort of high level on some of the things that the committee is working on and is just filled with links for where you can go to participate.
So if you see something here that you like, hopefully you can get involved and turn it into something real.
Full disclosure, I'm a super language nerd. So that will probably come through on the slides. I also love JavaScript.
It's kind of progressed.
Started with a love hate relationship.
Now it's kind of more on the love side.
But it's got its things and we're well aware of that, I guess.
So I have to start with some context.
How many people have heard about TC39 before today? Just a handful, right? This is actually the group of people that is responsible for designing this language that you use. Many of you, every single day.
And it's kind of a opaque group and an opaque process, but it's getting better. So TC39 is just the 39th Technical Committee in the ECMA Standards Organisation.
That's not a helpful definition.
ECMA is a standards organisation that has other languages in it, like C Sharp and the Dart language is also there. There's also, I think they got their start with like floppy drive standards.
Like one of the floppies that we used back in the day was an ECMA standard as well.
But really, ECMA, TC39 is just a bunch of people that sit in a room together.
So you've got people from ECMA Member organisations. These are big companies, small companies.
Companies that have a vested interest in where the web platform goes.
Obviously the big players here are the companies that have big JavaScript engines like Microsoft and Google and Apple and Mozilla.
But there's also companies that have big web properties like Netflix and Facebook, PayPal and smaller companies, consultancies, that kind of thing. There's also academic members and teachers and that kind of thing.
It's really helpful to get the perspective of teachers when you're trying to design a new thing.
Like is it even gonna be possible to teach people how to use this thing? Hopefully it is.
There's also community projects and invited experts. A lot of times there isn't expertise in the room on a particular feature area.
So it's helpful to bring in people from the community. People like yourselves that have domain expertise in something.
So we'll bring those people in to TC39 to help us work on JavaScript the language. So a 3,048 metre view of TC39's work.
That's 10,000 foot view, it's a saying.
I had to convert it since we're in a different place. ECMA262, that's the fancy name for just ECMAScript that's JavaScript, that's what we all know and love. The committee also works on ECMA402 which is a huge area of investigation and a huge area of work.
That's the internationalisation APIs for JavaScript. That's the Intal object that right now let's you format dates and times and numbers in a locale sensitive way.
I'm not gonna talk much about internationalisation. But if you are knowledgeable in this space. There's a tonne of opportunity for you to help us design this API.
So while I'm not talking about it, please do try to get involved there.
Also ECMA404 spec not found, that's the JSON spec. (audience laughing) So that's actually a separate thing within ECMA TC39 as well.
So I want to get into how this sausage is made. I want to try and make the process less opaque so that we can all have a shared understanding of how a idea turns into a proposal that actually ends up in standard and then implemented on all of the big browsers in a node. And in order to do that, I want to give you a little bit of history because it helps to understand where we were so that you can appreciate, hopefully the kind of work that we're doing now.
So JavaScript actually got its start with the language called Mocha and it was built in 10 days. Basically management told Brendan Eich, we need a language, you have 10 days to do it. And miraculously he delivered.
It turns out, a lot of the kind of wattness of JavaScript is directly from this 10 day period.
So you kind of have to forgive it a little bit for that, right? So it was in '97, the first edition of ECMAScript was standardised. And then pretty rapidly after that we got to Edition Three in December of 1999. So just to put this into context.
ES3 is kind of like the IE6 era of web development. So pretty basic language.
Edition, not too many changes from Editions One and Two. After '99, we entered this period where not much was happening.
The committee was sort of dark, working on this ES4 language and it didn't really turn out.
A lot of things were considered.
There was even investigations into static typing. The language at one point, looked very similar to what ActionScript Three looks like.
For those of you who have done Flash development. So it took actually 10 years to get ES5 and ES5 was really small.
It had its Strict Mode, Getters and Setters. JSON finally was a thing.
And there's some Object.defineProperty stuff and a few other objects on methods or methods on object. But it really wasn't that big.
It took 10 years to get Getters and Setters. It was kind of sad.
(audience laughing) And then it took another six more years to get the next version of JavaScript.
This is ES6 or ES20115.
Now this is actually the biggest update to JavaScript ever and likely the biggest that will ever happen again. And part of the reason there actually is that this specification is really the culmination of 15 years of effort.
A bunch of that stuff that failed trying to get ES4 working was actually brought forward into ES6 and so ES6 introduced Promises, Classes and Modules. Interesting thing about Classes is that the design of Classes was called within the committee, maximally minimal which was a term that basically meant the proposal was paired down to as small as possible to get the broadest consensus possible on including the features.
The idea for Classes at least was, yeah it works but there's more work to do.
And I'll talk about some of that work that's happening later.
Iterators and Generators and the For-of Loop were a pretty big improvement as well.
Typed Arrays, Maps and Sets, Arrow Functions, Proxies. Has anyone used a proxy yet for anything cool? A couple of people, alright.
They're awesome.
Bad for performance but they're pretty amazing. Maybe one day they'll be really fast but not yet. Destructuring and just boat loads of new libraries. It also turns out that libraries are really hard to add to the Web platform. So that was kind of a learning experience.
So it took 15 years basically to get a decent language. And the committee kind of decided well, we don't want to go dark for a decade and then come out with the next version when most of us have retired.
So there is a new process.
The new process was a train model where proposals kind of work through the committee and go through various stages, and I'll talk about those stages later.
But the gist is there's a spec that comes out every single year.
And as part of this, that's why the standards are now labelled with the year.
In hindsight, it was kind of a mistake because there's sort of an off by one error. ES6 was ES2015, E7 is 2016.
Sorry about that.
You can still call it by its number, that's fine. But anyway this new process meant that there was a much smoother cadence of features coming out from the committee.
JavaScript was improving incrementally every year. And it also made it easier for implementations to follow along and really deliver these features sort of in-step with the specification.
So you'll notice like these ES2016 features. The Exponentiation Operator and Array.prototype.includes, these are supported pretty much everywhere. So in a large sense, this process is kind of working. Interesting note about array.prototype.includes. I mentioned that it's really hard to add new APIs to the web oftentimes.
We wanted to call this array.prototype.contains. So this is a method that just returns true or false whether the array has an item in it.
And if you've used Class lists in the dom for adding and removing classes on dom elements. It's not includes, it's contains.
So we thought, yeah we'll just do the same thing. But it turns out that there is some older versions of libraries on the web, that added this array.prototype.contains and by implementing it in the browser it broke some number of websites.
So unfortunately, we had to call it includes. That story kind of plays out quite a bit.
So we got ES2017 just recently.
It was just recently ratified.
Finally got Async Functions.
Very similar to Async Awaits in C Sharp.
Is anyone using Async functions already? Either with transplation or natively.
How many people are using promises to do Async code? Okay, so about half of you are using Promises. I expect in the next few years, all of you using Promises will be using Async functions because they're pretty awesome.
Shared memory and atomics were also added.
This actually made it possible to write parallel algorithms in JavaScript in a performing way.
Previously the only way that you could have multi-threaded applications would be to have either your state, your application state duplicated in each thread or you had to pass it back and forth.
So you both couldn't be working, each thread couldn't be working on the same data at the same time.
Shared memory fixes that problem.
So you can actually have multiple threads working on the same, underlying data.
And the Atomics object gives you some really confusing to JavaScript developers but probably really natural to native developers. Some low level functionality to make sure that when multiple threads are trying to access the same data or change the same data that it stays in sync and you get predictable behaviour.
Object.values and object.entries were also added. These are super handy and I use them all the time. So that's where we're at now.
It's a pretty nice language but there's still more work to do.
So the question is.
Now what, what's next? Often people ask me that but I'm here kind of to, ask you that.
And hopefully that I inspire you to come and tell us what you think.
Do you want to help? So these are a couple places to get involved. GitHub, everything that TC39 now does, is on GitHub. Up to ES6, ECMAScript was actually a Word document lovingly maintained by the editor all the way from ES1 in '97.
It was good for some reasons like writing in a Word document makes a really nice printable thing, for example for people who like to print specs.
But it turns out that really only one person can work on a Word document at any given time. And there's really no notion of a pull request or really collaboration was really lacking. And you know, that as a result meant that the process was really quite opaque. Now all of the stuff is on GitHub.
The spec is in a plain text format.
It's basically a sort of mashup of HTML and markdowns. So anyone can go and read and contribute, fix typos or give examples or documentation, or improve wording or fix bugs, or even contribute features.
There's a mailing list.
And it has a nice website.
So I give you the website here that will give you links if you actually want to do the email thing. And for those of you who are IRC.
I'm just curious.
How many people even know what IRC is? It's actually only about half so I understand that's a problem.
But it's like Slack, but.
(audience erupts in laughter) It's a chat protocol basically.
But it turns out, actually a lot of standards work happens on IRCs, so if you want to get involved in standards it's a good thing to do, and it's free.
So TC39 on the free node network.
If you just google that, you can get some.
Or Bing, sorry, you get some instructions.
I work at Microsoft by the way.
(audience laughs) So there is a Code of Conduct proposal.
It's not enforced technically yet but I bring it up because I know it's an important thing and we're working on it.
The link to the Code of Conduct is here.
If you have expertise in this area and you want to give us feedback, it would everybody very much appreciated.
But even without the Code of Conduct enforced technically speaking, everyone on the committee is committed to having an inclusive and respectful environment, so just keep that in mind. So if you're looking for a good place to sort of introduce yourself to the world that is ECMAScript and Standards Test262 is a really great place to do that. There's actually a number of people on the committee, myself included, that got started in this space just writing Test262 tests.
This is the official test suite for ECMAScript. There is right now 50,000 tests in there.
There'll be more coming online.
Basically every day, there is another big bundle of tests coming in.
And this is actually used by all JavaScript engines to validate the conformance with the specifications. So the V8 and Chakra and SpiderMonkey and JSC we're all contributing to this shared test suite to make sure that we're all inter-operable. That we all are implementing the same thing. That's really kind of beautiful.
And it also means if you find a bug.
You know, yeah you can go their bug tracker but you could also make a TEST262 test for it and they'll notice that it's failing.
So this is a great way to get involved and to sort of learn the skills of standards participation and ECMAScript.
In order to write a test for something you really have to understand a lot of detail about how the spec works and about how JavaScript works. So, I think this is really a great way to get started. So this repo right here, this is ECMA262.
This is the main repository of ECMAScript.
This is where most of my work as editor happens. At this repo, you can file specification bugs. That might be things that are just don't happen to, like the spec says something that browsers don't do, for example.
That happens pretty common, pretty frequently. You can contribute spec fixes or clarifications . It turns out that when you're deep in the spec it's often easy to write some prose, some text that reads nice to you but is just totally incomprehensible to anyone else. A bunch of that stuff exists in the spec and you can help fix it.
So send a pull request for that kind of thing. The only thing that I would note about this repository is that proposals don't use this repository. So if you have an idea or if you have a comment on an upcoming proposal, that's not here, that is here.
This I think is the most fun repository.
If you're gonna watch one repository of any that I talk about today, I think it should be this one.
This is a list of all of the active proposals, inactive proposals and withdrawn proposals in ECMAScript. So each proposal is its own GitHub repository that has its own spec text.
Or maybe if it's early stage, it might just have a strawman or just a basic description of how it should work. But most importantly, here is where all the discussion happens and issues and pull requests.
So if you want to impact the direction of ECMAScript, these proposal repositories are where to do that. Here you'll also find FAQs and use cases and other things that will help you understand what these features are, what they're trying to do and what the goals are.
So I mentioned that there's this process, this new process. And this is basically what it looks like, it's a pipeline. It's five stages, zero indexed as is natural. And at Stage Zero, pretty much anything is a valid Stage Zero proposal.
But the only requirement that a delegate of TC39 has to actually champion the feature in the committee.
Championing just means that they're there in committee. They're bringing up the proposal, talking about it, responding to feedback, collecting notes and sort of creating action items and doing all that sort of administrative of pushing a proposal through the committee. And then as the proposal advances it sort of gets more and more stable.
At Stage One, that's basically committee saying, okay this seems like a good area of investigation. We don't yet know if this is something that's gonna make it into the language but seems good, go ahead and figure it out. At Stage Two, this is when if you see a proposal at Stage Two that's the committee saying, this'll probably be in a future version of ECMAScript. Doesn't mean in a year or two years or even a decade but there is intention there that it will probably make it in. Stage Three is when implementations typically start working on features because at Stage Three the spec text is complete. Cross-cutting concerns are usually identified and now the committee needs to know.
Can this actually be implemented in browsers? Stage Three was missing for ES6.
It was kind of, you know you have this massive, massive, massive document with all of these features.
And actually it wasn't implemented anywhere. It took years for implementations to catch up to the spec. And as a result, a bunch of the stuff in ES6 turned out to not be implementable or may be buggy, or in some cases just wrong. So Stage Three is a really important stage where implementations, including transpilers can provide feedback into the process and hopefully find problems with the spec before it actually gets into a ratified document. And any proposal at Stage Four is a proposal that's on the train.
So a Stage Four proposal will be integrated into the next year of the release of ECMAScript. So that processes repository has all of the stages for all of the proposals. So hopefully with this table you can kind of look at that and see what the state of things are.
Okay, so.
The exciting part.
ECMAScript proposals.
If you've gone to that repository you see there are a lot of proposals.
And this is not even all of them.
These are just the Stage One plus proposals. There's another list of at least this long with Stage Zero proposals.
So there's a lot, a lot of work happening.
And I want to talk about a few of them that I think are most important, or most exciting or actually things that I think are cool.
So first thing is Classes.
I mentioned that ES6 Classes were maximally minimal. The intention was always to come back and add additional capabilities to Classes that developers have been pushing for.
So one of them is decorators.
And these are similar to decorators in well, I'll get into that later.
But decorators, public fields.
How many people are using TypeScript or Flow or Babble? Are you using public fields that equals syntax like public prop equals two? This, I can't deal without it almost.
It's a big reason to use Babble in my opinion because it's really, really convenient.
So decorators actually they're all about sort of changing the shape of things in a declarative way. So this at decorated class Person at this at decorated thing, that's the decorator. It might take the class and register it with a test framework.
It might add some meta data to the class so that you can inspect it in Dev tools and do something interesting with it.
It might add some properties or methods.
It's just a really nice way to encapsulate behaviour and add some behaviours to a class.
You can also add decorators to methods and properties. So those are useful for changing the enumerability or configurability or writability of properties. This is something that JavaScript developers often don't do because it's really a pain.
You have to use object.define.property and give it a property descriptor.
I think decorators will make this a lot more friendly. Another really common use case for this in existing usage of decorators is taking a property like public prop and making it observable.
So you could put at observable before a property and now that thing is an observable that you can be notified of changes to whenever the property changes.
Also common to do, deprecation warnings and that kind of thing, using decorators.
By the way, most of these slides have the link to the proposal at the bottom. So that's where you would go if you want to you know, give feedback.
So public fields.
Very, very simple thing actually but really, really handy. It lets you create properties on instances and on the class, inside of the class body. So you don't often times have to implement a constructor. This has been implemented in TypeScript for a long time and Flow for a long time.
And actually a lot of the developers that I talk to aren't even aware that this isn't a thing in JavaScript. Finally it is.
Private fields are also coming.
These are actually truly private fields.
Before private fields, JavaScript developers we have kind of a convention where if you see an underscore, you should think carefully about what you're doing. Maybe not poke at it.
But often times developers think carefully and decide yeah, I'm gonna do that.
(audience laughs) You can even name it something like, Don't use this ever. And developers will still take a dependency on it. I've seen it.
And so library authors are kind of put in a tough place there because if they have these private properties there's nothing they can really do to cordon them off so that people don't take dependencies on them. And library authors aren't very receptive to just breaking their users.
Even if they did, a quote unquote bad thing. So private fields are a great way for library developers especially to truly encapsulate private data and eventually private methods as well.
And so they can actually upgrade libraries and know for sure that users aren't taking dependencies on their private state.
They never conflict with other fields so you don't have to worry at naming.
If you just make your own private slot in a class you're guaranteed that it's just gonna be your own thing. It doesn't matter if any super classes or subclasses have the same name thing, it's different.
And the biggest point of feedback I often hear about this proposal is the syntax is weird, like hashtag x doesn't read right to me.
I'm very sympathetic to that.
But there's a very good reason.
And actually much of this proposal is sort of set in stone, just based on the constraints that are in play.
The FAQ on this repository is amazing.
So I really recommend checking it out.
It'll give you a really nice perspective, I guess on the kinds of problems that you have to consider when you're working on a new language feature. Okay, RegEx.
How many people actually know RegEx and write RegEx? How many people are the RegEx person? Like, the person that has to write the RegEx for your team. I'm that person.
It's fun and not fun at the same time.
But I actually really love RegEx.
I don't usually admit that but I feel like I'm in a happy place to say that. But RegEx, if you've used REgEx in other languages they have a lot of capabilities that ECMAScript is lacking. Actually RegExes haven't really changed much in capabilities since the early days of '97.
And so finally there's movement on bringing some modern features to RegEx that for those of you that actually have to write RegExes I think will really appreciate.
The first is Look-behinds.
This one is the one that I'm most excited about. You can kind of get away without look-behinds by adding it as part of your pattern.
But it, when you're doing replacements it really is helpful to be able to say, hey this, only replace this string if it's preceded by this string.
And previous to look-behinds, that was actually really difficult to do.
Another feature that, as someone who writes parcers for a living basically, that I really like is Unicode property escapes.
Unicode defines, Unicode is basically a giant table of all of the characters that you could ever write. And in that table is a bunch of meta data about what each character is.
Is it white space? Is it a number? Is it part of this language? Is it a controlled character? That kind of stuff.
So Unicode property escapes lets you match directly against basically the Unicode property database.
And say hey, match anything that's a white space. There's like dozens of things that are potentially white space.
Or match anything that's a number.
Zero through nine have, there's like ten different zeros in Unicode.
So matching all of them is often really difficult. So finally that's gonna become easy.
Named capture groups, I think are gonna be really nice but mostly for readability.
I like the usability, I guess of having the groups object and being able to pull off the pieces.
But it's also, I kind of see it as sort of a documentation. So you can name your capture group.
And then when someone else is trying to understand what this RegEx is. The time to understand it drops from maybe ten hours to something more reasonable like five hours. (audience laughing) And also the dotAll flag slash s.
This is kind of a bug fix.
How many people are aware of the fact that dot in JavaScript doesn't match everything? And that's because you were bit by it, right? So dot actually doesn't match line breaks, some line breaks. Some line breaks it does.
So there's weird sort of hacks around this. You can make a character class that is like backslash capital S and backslash lower case s. Actually my favourite is just the empty character class with the caret in it.
Square bracket, caret, closed square bracket. That one's really good.
But again, like extremely opaque ad I have no idea how you would Google that if you didn't know what it was doing.
But anyway, I think eventually once implementations implement this you'll probably just want to put backslash s on every RegEx ever because why would you not want dot to be reasonable, right? I've given some versions of this talk before and I had all kinds of slides about RegEx and then afterwards, people's takeaway of my talk was Oh, you're the RegEx guy, you know everything about RegEx and I'm excited about RegEx.
And sort of everything else got lost.
So I'm forcing myself to move on from RegEx now. (audience laughs) It's not all about RegEx.
Incidentally I'm really sad that my PowerPoints don't get coloured emoji. The donut especially is kind of sad in black and white. And that's a cookie, not like a planet or the moon. (audience laughs) Syntax sugar is something that developers really appreciate. It's just a term for a syntactic feature that doesn't add new capabilities to the platform but it makes your code more straightforward, potentially easier to write, easier to read, that kind of thing.
So rest and spread properties let you spread out the properties of object literals or the properties of objects.
So you can combine objects using this spread operator. It works the same as arrays.
So inside of an array, you can spread in there. With rest and spread for properties you can spread inside of object literals as well. Optional catch parameter is pretty handy.
If you're using ES lint especially, it's really annoying when you don't care what the exception is because if you don't touch E, ES lint will yell at you that you've got a variable that you're not using. And so what do you do? You have to put a comment there or do something with it uselessly.
So this idea is hey, maybe we just have a form of catch where you don't actually bind the error.
So you can handle errors without actually caring what the exception is.
This proposal was actually brought up for the first time in Redmond last week and went immediately to Stage Three as everyone thought yeah, this is good.
(audience laughs) Numeric separators.
It makes it a lot easier to write giant numbers especially if you're doing hex.
You can separate each segment into bytes.
It makes numbers a lot easier to read, in my opinion. Optional chaining is another proposal that if you've used C Sharp it's very similar to the C Sharp semantics. But the idea is, if you say o dot x and o is null or undefined, you get an error. Sometimes, actually frequently hat you want is, if o is undefined then give me undefined.
But if o is a thing then give me it's x property. And that's what this optional chaining proposal lets you do in a really simple syntax.
That should be familiar to people coming from other languages.
There's a lot of actual, there's a lot of contentious design decisions actually in this proposal.
So if you're looking to get super pedantic and get involved in a bunch of issues, this is a good one. This is a really good one.
Another proposal that I'm really excited about is big integers.
Yes, big integers.
Floats are the only number type in JavaScript excluding typed arrays.
And I agree, if I had to pick one number type I'd pick floats, they're really flexible.
But they are not for everyone or everything. I learned that as a lesson early on in my career when I implemented a shopping cart system where currency was represented in a floating point number of dollars.
And if anyone's ever tried this, the accountants will hate you.
They will yell at you every single day as pennies are missing here and there.
Ad you think it's not a big deal, it's just a penny. But it's a really big deal, it's a really big deal trust me. So big integers are arbitrary sized.
They can be as big or as small as you want. There are only integers.
So there's no complexity with decimals there. The trick to do this, if you wanted to write a shopping cart or something with big integers is you just represent number of cents or number of milli cents or whatever is necessary for your, whatever precision is necessary for your application. Floats have a max integer. It's to the 53 minus one.
And a lot of developers actually aren't aware of that until they get bitten by it.
And in fact, like this example here you can actually create a giant number and it'll store it in a float for you.
But you won't get an error telling you that you've lost precision and you won't necessarily notice it until you get it out. So the bigger the number floats start losing integers in between.
That's not a problem with BigNum.
One of the limitations of this proposal is that there is no operator overloading and no mixed operands for math operations.
So you cannot add a float and an integer.
That is intentional at this stage.
For one thing, it's often times a source of bugs because you have to think really hard about precision loss. So the idea is well for now, we'll make you sort of do the explicit conversion so that you have to sort of opt in to your precision loss or lack thereof.
But eventually I hope we'll end up with a more general framework for these primitives and end up even with more number types like complex and rational and decimal.
Sometimes when I say decimal I get boos but I think decimal is awesome.
And then as part of that work I hope that we can also figure out operator overloading in a way that will make big integers much easier to use. I've started working on F Sharp a little bit a few years ago and as part of that I sort of became addicted to functional programming.
And there was some features that F Sharp had that I really liked and really wanted to bring to JavaScript. And this proposal was actually written by some developer in the community.
He put his proposal on GitHub and now it's an official thing in the process. The idea is to let you do functional chaining in this sort of pipeline form.
So all it does is it takes the thing that's on the left-hand-side of that pipe greater than and pass it as the first argument to the function on the right-hand-side of that thing. So that works really naturally with lodash where you call map with an array and then your mapper function.
You can just pop that in to this pipeline without any changes, and it works really nice and it's nice and readable.
Another thing that I think is really important is supporting pipelining through arbitrary positions in your function.
A lot of people use ramdaj and it takes its data that it operates on as its last parameter rather than its first. That's because it works better with partial application. So with this question mark syntax you can basically define the spot in your function where you want that data on the left-hand-side to flow into. And I actually think partial application makes sense outside of pipelining.
And I haven't quite gotten consensus on this point yet but I would like to see something kind of like that bottom example where if you want to do partial application you can just pop a question mark in the signature and rather than calling a function it will return you a function that will fill in the placeholders when you call that function.
So that is pipeline and actually in general I think JavaScript has a lot of room to grow in terms of functional programming.
There's a whole bunch of awesome proposals that are waiting for feedback.
You saw the list, that's not even the whole list. There's also Stage Zero, Realms, Frozen Realms and Realm Snapshots.
That probably doesn't mean anything to anyone but it's exciting, trust me.
"Do" expressions are all about wrapping a statement or a number of statements in an expression form. I have a question.
How many people are happy with dates in JavaScript? There are no hands, there are never any hands. No one is happy.
So there's actually a proposal to fix dates. It's kind of a similar model to the latest Java APIs. Definitely trending more towards the JavaScript side of things.
But I have faith that soon we will have a date library that is capable of actually representing times faithfully. Doing date arithmetic without doing things that you don't want and giving you invalid values and throwing NANS at you for reasons.
So dates, hopefully will be fixed.
This is a huge area of investigation.
And if you're an expert in dates I really encourage you to check out the temporal proposal and offer feedback.
Something the committee is also looking at is creating expression forms from various statements. I think throw and return expressions would be very helpful at the least.
But I've also heard people talk about maybe if should be an expression.
If you come from Ruby like I do, that feels really nice. There's a bunch of libraries on the horizon as well. Flat map and flatten are a couple new array APIs that I hope we can add.
But it might break the web, we'll have to see. So with that, I am done.
These are the links that I think are most important. So please, please, please participate.
Really would like to see you out there.
And you can follow me on Twitter if you like. And I'll be around the rest of the day today as well. So please ask me any questions.
Thank you.
(audience clapping) (upbeat instrumental music)
