Q&A: JavaScript Standardization

[00:00:00]
>> Jafar Husain: So we've covered subjects, we've covered Observables, we've covered subscriptions, we've covered schedulers, we've pretty much covered the gamut. Is there any other questions you guys had? By all means, yeah.
>> Speaker 2: What do we have to do to get the observable into JavaScript, write our local TC39 representative?

[00:00:19]
>> Jafar Husain: I don't think that'll work. Realistically, I mean, I gotta be honest with you. Observable in JavaScript is not really gonna make much of a difference to your day-to-day lives. So let's say tomorrow the committee said, and I think this is a long shot, they said, Observable's the best thing ever, we need to get it into JavaScript right now.

[00:00:37]
Ask yourself this, how would it change the way in which you coded?
>> Jafar Husain: At least the current observable proposal has no methods. It doesn't have map, it doesn't have filter. Now maybe six months from now, at the rate the committee works, it'll have a map and a filter method.

[00:00:53]
How's that gonna change the way in which you code? You're still gonna have to take the observable in the framework. And adapt it into the RX observable to get access to the galaxy of methods that are on the RX observable. And so frankly, that's one of the reasons why a lot of people have questioned whether observable in the standard is actually valuable or not.

[00:01:09]
One of the reasons why we were pursuing it was to get it into the browser so that the browser could take event targets and implement them as observables instead. Sorry, event targets are the things with the add event list or remove event list or. Add event list or remove event list unless there's a well-known crappy API.

[00:01:24]
It's a terrible API and it's really unergonomic to use. It also doesn't really compose well. You've seen how awkward, remember all that awkwardness where we had to store the handler to the event and then put it in? If you try and compose event targets, you realize that you actually need to create a map where you're associating event names with handlers, and it's actually very expensive.

[00:01:45]
So that's one of the reasons why event targets are just not a very well designed type. They're very expensive to compose, vis a vis the observables which can just return these little subscription objects. And if you notice what's going on with Observable or composing observables, or composing observers and we're composing subscriptions all at the same time.

[00:02:02]
And that's what makes the whole thing work. It's actually a beautiful composition of three different types that are all composable at the same time. It's very much more awkward to do that with event target. And if you had an event target, I think with add event list or remove event list and you map something, what would you be mapping, which event?

[00:02:18]
Remember, cuz it publishes a whole bunch of different events. So we were interested in Observable, we still are interested in Observable as a better event target, but at the moment, the web platform guys are not entirely convinced that it's a great thing. I disagree with them, I think it's a great thing, but that's why I think the standardization process is moving really slowly in this area.

[00:02:38]
Honestly, it's more a thing that we're doing for the browser. You folks, you got MPM, so it's really just a couple of keys away for you to be able to get the full galaxy of RX operators. I'm always surprised when developers really care about this because I don't think it really much matters to you.

[00:02:57]
>> Jafar Husain: Even if in like five years we had all the operators in our switches all stretched it would be hard to get all those approved through the committee. Even if we were missing one you'd still end up having to adapt the Observable. So I wouldn't worry so much about standardization.

[00:03:10]
>> Speaker 2: Wouldn't a big benefit of standardization be that we would have a set standard where different libraries could then take advantage of having-
>> Jafar Husain: For interoperability?
>> Speaker 2: Contracts email.
>> Jafar Husain: Yeah, yeah, I mean, but promises, before they were standardized, they had the interoperability spec. And that, honestly did just as good a job for libraries being able to interoperate.

[00:03:34]
And realistically, if we don't get the through standardization process, I imagine that that's exactly what we'll end up doing with the Observable. We'll come up with an interoperability spec to make sure all the different libraries can interoperate.
>> Speaker 3: Well, isn't that, so another benefit though is just less bits having to be sent across?

[00:03:51]
>> Jafar Husain: Yeah, but realistically look at Blue Bird and how many different methods are on Blue Bird, for example, or the other common errors. It's gonna be really hard to get all those methods on JavaScript, and there's always a trade-off between keeping the language minimal, right? And because JavaScript runs in some pretty resource constrained places where, I think, people never thought it would run.

[00:04:13]
Embedded devices, and so putting more and more of the standard library makes that difficult, especially with how incredibly useful and effective NPM is. And so that's the trade-off that the committee is thinking about. It's a constant thing that standards committees have to think about. What belongs in a language and what doesn't belong in a language?

[00:04:30]
It's a hard problem.