Hello, Jazz Contra wiii Before we get started, I want to talk a little bit of how amazing this conference has been, right?

I mean, he was just talking about Hawaii, but how about like, the variety that we've seen on stage?

We have seen, but what we have seen natural hair we have seen time ago, Cheese.

Ah.

I mean, let's give it up for the organizer's a little bit for putting this thing together, right?

So for those who are not from actually show of hands, who knows what jazz party is?

A few of you.

All right, So J s party is a podcast.

But more than that, it is a weekly celebration of JavaScript and the web.

We get together every week and talk about cutting edge content.

What's going on with JavaScript?

What's going on with related topics?

I've heard Conference is described as the place you go to learn what you should be learning about.

Well, if you can't make it out to conferences every week, you can get that anyway.

By listening to Jazz party.

We do come to conferences today.

We're here.

We're gonna do a live episode.

This is ur live with us.

Typically, when we do an episode, we broadcast it live as we do it, there's a slack channel.

You can come and slack with us as we do it here.

We don't have the slack channel.

So I'm relying on you all to give us that live feel.

But we are going to be digging in with our some of our amazing speakers from yesterday and kind of going a little deeper and trying to make me make them uncomfortable and ask questions that they hadn't thought about.

Um so before we again, I'm cable.

I'm one of the hosts.

I'm a regular on Jack's party.

If you want to find J s party, go to any podcast app search for J s party, you'll find it.

Last night, somebody was trying to do that on Spotify and it didn't work.

And so it's frantically slacking, people, What's going on?

It turns out the search term was not matched properly, so we fix that, but search for Jack's party.

Wherever you do podcasts, you will find us.

All right.

So I am joined today with four amazing speakers.

Uh, they spoke yesterday, but I'm gonna introduce them anyway.

Uh, William spoke about T c 39.

The future of JavaScript.

Sean spoke about babble on some amazing things you can do with that with the language.

I don't know if I even need to introduce you to You're so famous.

But we have Lynn until who both spoke about Web assembly and what we're going to dig a little deeper on today is this idea of the future of JavaScript of Web development?

Where is this going?

You know, how can we take all of these talks that happened independently and sort of try to weave a picture together of where this is going in the future?

Um, so we'll just start.

I prepared a few questions.

If you all get a burning need to ask questions, you can raise your hand, and I'll probably call out to you.

But we got plenty.

So don't stress.

Um, so I want to start actually talking about the JavaScript language itself.

William introduced us to some of the proposals that are there for advancing the language.

And I noticed that there were a lot of operators involved in the ah pattern matching.

There was a new arrow operator it wasn't the fatter we're used to with aero functions.

It was the thin arrow with the piping.

There was a pipeline operator, and I'm kind of wondering I'm gonna throw this to William first.

But any of the Panelists you're welcome to answer are we gonna run out of syntax and operators like, is there room for a Tamagotchi operator?

Where we going?

I think this is a question for two.

Right.

So I think they're two different access to this.

Um, one is we can in theory, we invent an arbitrary amount off additional operators and make them work somehow.

Just put two, um, quitters next to each other that currently would be invalid and say, Listen, you up, waiter, Um, and thin Echo is actually an example where we could have done that when we introduced the fat approve.

Um, they're the committee was pretty close to also introducing a thin acro valiant that didn't capture this the this value, but otherwise what if we actually operated executive?

Same.

And the reason this is not done, waas um, mention complexity, budget.

Um, and that is really what a lot of this is about.

That and operator has to, Can't we?

It's wait.

It has to be specialized in a way that allows people to use it as a an efficient mental abstraction instead off just some weird creatures on the page that make things unreadable.

And if we didn't keep that in mind, then the language would be Maur andMe or just sort of this weird stuff on the page that nobody can clock.

And so, yes, we will.

Over time, it would use new upgrade Earth.

But we have to be extremely careful about which ones and make sure that they are actually useful enough.

That leads into kind of a question about the process of deciding what goes into this language.

You know, we talked about T C 39 the stage one that was going on there.

But maybe can one of the Panelists spell out the stage is that things go through as they advance in the JavaScript language.

Okay, I can try that one.

Okay.

We have, like, five stage and doro like that.

It's the Strom.

Oh, it's like have a conversation, the bar, and we're kind of drink and say Yeah, what were you with those days and job escape.

That's try and you try to present it to the committee.

And then if they find a champion and this proposal, it's a tried to solve the problem.

You should shape the problem first.

And then if I have ah, shape of for championing this and you, you and the committee decides that this is like something that worth more investigation.

So they goes to the stage one.

So then they tried to do on your bit more research on that and shaped like if syntax like shape, that syntax or in the semantics off the proposal and then goes to the draft, which is the stage two.

So then they start to write the draft off the off the specification, and then sometimes they they have some limitation bobble on DDE and sent to the to the developers tried it out and then on after after they find some consensus on see Paxson in sin makes up the proposal eagles.

That's because it goes to the go, uh, Stage three, which is the time that they wait for some limitation that grocers and and I think like then you see this implementation come into the, um on nightly version of five forks or chrome canary and so on.

And then, after everything's done on, they find out insensible sent to state for which is the less stage.

And then they have a cohort.

I think, in March, right, and then on this goes to the next back, which is in July.

Lynn.

You talked about similar feature advancement.

Happening in Web assembly is the process.

They're similar.

How does the Web assembly, working group deal with this?

There are a lot of similarities and a couple of differences.

Um, so for Web assembly, you do have also four stages that look pretty similar.

Um, there is a difference in advancing between the stage is, um which is that with t c 39?

You need really full consensus.

That happens at a meeting.

Um, individuals from different companies can object.

Um, whereas with web assembly, um, it's Maur the different implementers.

Um, really, it's what they do is technically they take a vote, and people can say I strongly disagree.

I disagree.

I'm neutral.

I agree.

Strong agree in practice.

Um, really, as long as the engines as a whole all agree things will advance.

Um, So there's um, some technical differences, but it really is fairly similar.

Nice digging into one of those proposals that William talked about.

There's this concept of binary STS and essentially having a much easier to parse version of Java script.

What's that going to do to the demand for Web assembly, where one of at least the initial value propositions was, Hey, this stuff can be compiled so fast that we don't need to worry about that initial start up phase.

So, um, I'd say that it's actually pretty useful to look at the different kinds of use cases that these two that inspired work on these toe.

So for Web assembly, Ah, lot of the use cases were around desktop applications and games.

At least the first inspired it.

We're seeing a lot of other use cases now, but, um, and what needed to happen there was actually a start up.

Time is important, but that wasn't the critical thing.

There it was execution.

How fast the code is running rather than how fast it starts up.

Um, and for so it was really at the time about bringing new things to the Web that weren't already on the Web, Now we're seeing that you can actually speed up things that are on the Web.

Like the part sir that I mentioned that is used in Web packet and our Deb tools, um, or the Gutenberg parts of which is 86 times faster.

But that's really a different use case than taking something like Facebook or Gmail and trying to make it start up faster.

Um, binary s t is really specifically targeted at the problem of startup costs.

And so with binary is tea we take This process is really complicated and manual today where you have to do, um, all of these things to improve your startup times like code splitting.

And we automate a lot of that to make it so that, um you don't have to think so much about how to design your system to optimize for start up costs.

You can just automate this process of getting ah, quick start up, Justo.

Put a bit more on top of that like they're trying to.

It's different problems like, um, for a vine, Erased sees something that targets the cold.

Start off a job script application so it tries to make the complaint face start, thruster and Web assume is more about, like, run time.

So how fast your how performing your coat could be?

So it's it's, uh, different kind of things.

And there, I think, a smart as I know that the committee is not even sure if by nearest ae is something that needs to proceed.

Because, for example, V eight has a different way to parse the job they have, like they're part of the Oscar and streamlined way so on and on The P.

L.

C.

They did so far is it was only in Spider Monkey, so they need to try to assist.

If this solution's even true, it's a performance wing for the other browser vendors as well.

So okay, wait, we are in five weeks.

We're working on proving this out, and I think it is bright for other vendors to say, Well, show us their numbers before we go and duplicate the effort here.

And the good thing is, finally is T.

It's a form of weather is a proposal where this is possible.

If we were shipping a language feature and then at some points on Ah, no, we changed our mind and stopped shipping it.

Who would quake code?

That depends on it.

That's not the case with beina B a S T.

It's really much like, um, women ification Step where nobody would only ship, by the way, is key, at least for the foreseeable future.

So if we had some point, stop sending the Hatter thing.

We understand, by the way, is to you.

Then we'll just instead get a jazz file and nothing quakes.

So that's good.

Um, I don't want to say something more about the motivation here.

I think it's really important to look at this holistically.

We want the Web to be a platform where you can ship, um, or do you deploy applications of all sizes, too?

And to make that work, we need to pull all the levers that we have access to.

We can't just say, Well, this seems kind of good enough, So let's let's not continue working in this direction.

We need to do what we can for start of performance in all kinds of ways.

We need to optimize one time performance, using the right language for the job, for individual modules, and going forward will eventually also want to look at similar things for the other parts of the platform.

Like edged a melon CIA's s, um, and stopping at some point because we feel like this is fast enough for what people are doing now is setting the platform short.

So in Shawn's talk me in Sean stock, you talked a lot about compile time optimization tze and I think this is something that clearly lends itself well in the web assembly world What you were talking about with treating binary s teases essentially, um, unification or compiled step Uh, where do you all feel?

We are in the sort of build systems around web development.

You know, it feels like we've come a long way in the last few years, but does that mean that we're at about as good as it's gonna get or were at step one of 10?

Or how far is this stuff gonna go?

It's very broad question.

I am far from an authority on this, but I think I think we're definitely at the beginning of bill system innovation.

In fact, like a lot of these pieces were Kabul together and invented separately.

And that's why people complain that there's no integrated into anything from from, you know, MPM installed to whip Acto babble and having conflicts between all this, all these different parts of the system make on boarding toe with home and difficult.

I think there is some very some struggle against like, uh, you know, having such a complicated build system is against the original spirit of the Web.

You know, like you used to be able to just drop some Js on today she male on.

That's true.

But the same time, the way we use the Web has also changed a lot.

And so are tools should evolve accordingly.

Um, and there should be there should be more innovation.