YUI Library Open RoundTable, 10 Apr 2014

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: YUI Open Roundtable with Juan Dopazo on Promises, ES6 Modules and YUI

Description

YUI Open Roundtables are open discussions about all things YUI and Front End development.

A

All right today is thursday april 10th 2014, and we are in our next installment of the yui open round table um this week. We have uh as our special guest juan de pazzo to talk about promises, es6 modules, and why, uh before I get things started, I want to thank uh and I'm sorry gerard for coming here in person and everyone else who is watching right now. We have one extra viewer on youtube. The nice thing now about youtube streaming is um uh the more people watching the world sure the little counter will pick upward.

A

So, if you are, you have friends or family you want to share into this. Do.

B

It right it's done like now.

A

Anyway, so uh in the news I wanted to mention that uh about 20 minutes ago we released uh 3.16.0, which has a lot of the improvements and changes that juan and the rest of yy team have been working on. It's been a lot of hard work and a lot of a lot of group effort to get that outdoor so encourage you guys to check it out and try out the new features and stuff.

A

So with that in mind,.

B

um Let's go ahead and.

A

Start things off with juan.

B

Hey so um andrew just me to talk a little bit with our promises and I'm hoping to to get something out of this conversation. I guess so. um I first I wanted to ask you what you had in mind and if you had anything in particular that you wanted to wanted me to talk about.

A

Yeah, I mean I think for me uh and personally, but I know a lot of people that are they've been reading about promises, and I know that there are features that have been added to uh like the yui uh code base, but they may not be familiar with how it works and sort of the syntax involved with how it's done. So I think that might be just a good starting point, like sort of maybe what like, how?

A

What? How did promises get started, and why is it useful.

B

Okay, yeah so kind of prepared a few scripts that I'll I share. So we can like follow along all the new api that I've been adding to the yui promises. So um the first thing you'll notice, is that all these examples that I'm using are aren't actually using um yui promises. All I'm using is the native implementation. That's in chrome!

B

You can check it out. It's right now in chrome, stable, I'm using nightly uh chrome canary now because of a tiny little change that I talked about in in a couple minutes. So if you type promise in your debugging tools, you'll see it's bigger, you see you have uh native promises in your chrome, oh wow, that's.

C

B

Deal right, uh yes, this is a very big deal, not not so much because of having the promise api available, but because it opens the door for many native apis to start returning promises like, for instance, you may see in the future. If you do something like uh exit charity well equals new http request at some point you do xhr dot send this might even at some point, return a promise or I don't know, um for instance, uh there's there are many.

B

I think um there are other apis coming up with promises. um The first one that comes to mind is offline. Caching, in something called service workers that are up to you in a bit, but uh so yeah. Let's, let's do a little bit of file so.

A

Tell me the difference.

B

A

Is like basically impressed, you know, synchronous, asynchronous and why promises is like? Is it asynchronous or.

B

What so, uh the basic idea behind promises is to it's the same idea behind node callbacks right having an interface for dealing with asynchronous operations.

B

um The same way, uh node is based on a on a convention that everything that has that it's a synchronous operation takes a callback with two parameters or more uh promises are just uh an another convention in which, instead of prom functions, asynchronous function, taking up a callback, they return an object with certain methods and certain capabilities, but the idea behind it is the same. It's a it's. uh It's an interface, a convention that we will agree on, that we use for uh dealing with asynchronous operations and for combining them in a useful way.

B

So at the very bottom of of how promises work is function, composition, the ability to have a function that returns a center value and based on a certain interface. You know how to interact with the value.

B

um It's uh it's! It's interesting that that actually, that doesn't have to do with uh you know. The the typical selling point for promises is that it helps you uh with something called the callback hell right, um but it actually doesn't really have to do with it.

B

You can very easily end up in called raquel using promises I'll see if I can come up with an example in a couple of minutes, um so, basically uh going to the beginning, a promise is just an object that encapsulates uh an asynchronous operation, the result of that asynchronous operation and whether it had an error or not.

A

Is it also that you can always always feel confident that there's going to be a return value? Is that part of it when you set up value? You don't have to worry about you, don't have to worry about it, returning a value right now, but later on, you'll know when you need to access it.

B

Yes, so, let's think about it a different way. So if you have a some, you know node api, let's, let's hide this and assume. I'm writing something. Node I have like rfs equals, require the file system and you do file system dot with file. You'll, get say: okay, something jason and you'll get a callback.

B

uh So uh in when you're doing this, you're essentially reversing the order in which functions usually work. You usually expect a function to a function, to take parameters and give you something back as a return value right, but in this case you're actually giving them a function and your having the output of the function be instead of on in the return value to be in a parameter which is a little bit weird, if you think about it.

B

So what what promises do is actually give you back the the normal behavior of a function in a way and have that have that function that just some synchro separation returns something. So if you had a like read file promise, I would just give it something that jason and I'll get at least a return value back. But I can do something with it.

A

Right, but you have to worry about it returning right now, you can just go off and do other things and.

B

Yeah, you can go and do other things you can store it somewhere, which is something that's hard to do with callbacks. It's a lot easier to to save that value and deal with later uh using promises that it is using callbacks.

B

I guess I can show an example of that later too, so, let's just go over the the latest changes in the api which have which are not actually like yui inventions, but they come with the with the native api. So um first thing is that we have promise.resolve which takes whatever value you have and gives you a promise for that value, and the interesting thing is that it understand how to deal with other promises. So if you pass it to promise or resolve you pass, another promise.

B

You'll get actually a promise for that value and for the promise which is actually really useful, because if you have a function that maybe takes a.

B

B

You can say: okay, so this parameter may or no may not be a promise. If I don't know I'll just assume it's a promise and force it to be a promise. So I can do maybe a promise promise of resolve may maybe a promise and now I'm sure that maybe a promise is an actual promise.

B

Surely the cross.

A

You can treat it then, like you, can pass it to other promises or do whatever.

B

Yes, so this is essentially like a like a casting operation say uh I may have something that looks like a string: okay and force it to be a string.

B

This is the same kind of operation, but it does have the slight like little edge case, that for performance. If you pass it a promise, it will not return a new promise, but it will return the same promise. So if I run the script, I should get true right, because I'm getting I created a promise called p1 right. I passed it to resolve and got something: that's supposedly b2, but now I because of this inner optimization.

B

I know that p1 equals to p2, so they actually get true.

A

Is that just an assumption for our promises or this native implementation.

B

This is the dynamic implementation using chrome bonuses, but I'm actually using chrome canary, because this change just landed, uh maybe a week or two ago, based on some latest late changes to the ecmascript spec. So if you actually, if you try this same script in chrome, stable, you get a different result.

B

uh But let's assume this, this is how it works for now and because that's the new status of this pack, so I'm gonna try to to go through all the tiny little details and it may be a little boring, but at least there's a video somewhere. That explains all the details in case your someone runs into them.

B

So, oh well, this is out of order. Okay, so we have rechecked. Now let me find oh, my scripts are referred to.

B

B

I'll have to run write this one. um So let's say we: we have also b equals promise the reject which you'll usually give it an error, object.

B

And this is the same. uh This is a quick. This gives you a promise that is rejected, which means it will go through your error handlers.

B

This is just um like a utility function, but it's useful in cases in which you'll normally throw an error in a in a synchronous api like, for instance, you have a function that does something async and inspects a certain argument, and you want it to be a string right.

B

But if that argument is an actual string.

B

uh In us, in a synchronous api, you may do throw new typer right right or string, uh but in an asynchronous api you'll want your interface to always return a promise in order for most people to understand it. So, instead of that, you just can just do promised, reject and just return and reject the promise without actually having to go through creating a promise and calling api. So this is like a shortcut for usually for exiting early in your functions, but another another.

B

Its case is that, uh contrary to what promise that resolve, does it doesn't really understand promises? So, if you have like p3 equals a promise reset to be an error.

B

And you have p4.

B

The promise resective with b3 this actually won't be a prominent respective with this error. Instead, it will be a parameter section with a promise which is super weird. Let's try it before.

A

The converse isn't true, like you did up there, where you have resolve so resolve and reject, don't don't behave. The same.

B

No, so this one, we call.

B

Because the promise is rejected, and here what we'll see is that air is actually b3.

B

All right I get true because there is actually the promise and not the error which pass it along you, you start noticing that this, like uh I don't know like a common theme here, is that you know you. You think the api here is pretty simple in that it only has maybe six methods you have promised that resolve promise that reject then catch all and race, but it's so full of little details that you start realizing. The prime. The the api is actually really complex.

B

um Okay, so we have two functions for now and called reset resolve and we have to have then, which takes two callbacks one for the result, value and one for the error right, uh let's see how those interact with each other so um and see again, okay, so this is an example I just showed and the value actually here is a problem.

B

B

Another way of creating promises is using like new promise and we're going to create a promise, object and you'll take a function in which you can do something inside and it takes two which takes two parameters which are also functions that allow you to resolve the the problems in a certain way, either. What oh, by resolving to a certain value by resecting it there.

A

We go all right. That's one thing that I had to catch up recently is those arguments uh are always the first one's always the resolve and the other one's the error case right.

B

Yeah so, um as you start writing code, that depends on promises. You'll notice that the more you write new promise you'll realize the more complicated your code. It turns turns out to be it's uh it's. Actually, it's actually a trap in a way, because you're sort of thinking that you, your method, has have to return promises instead of modifying other synchronous values. So my recommendation here is always to avoid this form of creating promises and always use it as a map operation.

B

So you can think of promises. The same way, you think of race that you, if you have an array which is like one two three you can do. Oh I'm sorry.

B

Just there we are one two three: you have a map operation which gives you.

B

A way to change the value of all the items in the array- and we can say, item plus one so instead of one two three you'll get a transform value of two through four.

A

Yeah we're not seeing the bottom of your screen. I think if you look.

C

A

B

Like outputting this to the console or something uh no, I'm just I'm like hitting alert, but you may not see it yeah we're.

C

Not seeing the word.

B

Okay, our system is in the console.

B

Can you see the console yeah? I can see that yeah? Okay, so you have red you get two three four there you go. That's much better. Okay um promises actually work in a very similar way. You have then, which changes the value of a promise and gives you a new promise with a different value. So if I have b, which was actually.

B

The value of p was full. I can change it the same way. I did map.

B

And I can return new value.

B

And I can now load the new value.

B

And I get two fulls.

B

B

So my recommendation is to always use it uh the same way as you would be mapping an array instead of going around creating arrays and assigning values to it. Just change the values of other arrays in this case change the value of promise that you always get that you get from other apis.

B

Okay, so, um but the one thing that's useful here in creating your promises, new promise is that errors thrown here, which is a change that I just uploaded to yui 3.16, uh is that errors here actually turn your promise into a rejected promise, which is useful, for you know having your api always return, something consistent instead of some sometimes throwing errors, and sometimes returning rejected promises.

B

um Okay, so one more part of the api you have promise.o, which takes an array promise of promises and gives you just an array with all the results of the pharmacies. So if I do.

B

Console the look here and get an array of actually well hello world concatenated with join here.

A

What, if, like one of those, is taking a while to resolve or.

B

It hasn't resolved, yet this one will wait for all the promises to to be resolved. Okay and as long as as long as they take. If one of them is rejected, the resulting problem will be rejected. So if, if this is like equivalent of saying okay, I want to wait for all these files to load and if one fail, then all my program probably fails. So I need to notify the user in a way. What's.

A

The return value is it an array or what what is it.

B

uh It's an array.

B

B

This time you get an array with all the values okay, so this is pretty simple, and this is probably the number one reason you'll want to use promises nowadays is that it's really simple to say: okay, I have all these um asynchronous operations, and I want just to wait for all of them. It's super simple to write, but that's something that can actually be done with in other ways, with uh callbacks or or other ways of doing sync operations.

B

uh So you, you start seeing that um promises are just um more powerful in certain different ways. So, okay, um this is one thing that I found that people have a hard time understanding. So, if you don't understand it, just stop me and ask me: ask questions so this is like typical.

B

I use the console again typical uh synchronous code. You have a function that maybe throws an error and you want to use, try catch to handle that error differently right, so I'll change. Both these two console.

A

So, marco, while you're talking marco on irc, saying that there needs to be a function that resolves even if one of the promises rejects is that right.

B

uh So yeah, it will be something like, um like a fault resistant uh promise at all right. um So I I think it's the the standard api is fine with having a very small api and that premise libraries will eventually become just these libraries that consume the native promises and do useful stuff with them like, for instance, taking a bunch of them and maybe allowing them some of them to fail while you're waiting for of them.

B

So I think we'll probably start most of the innovation. Around promises have been around performance lately, at least from the community and uh as we get uh native support, we'll probably see less interest in performance and most more interest in all these utility functions that help with uh fault tolerance and like stuff, like I don't know, retrying after a failure.

B

uh So yeah, I hope hopefully marco, that said something to you and if not, you can join the hangout and ask questions.

A

So you're talking about this, the synchronous thing.

B

Says do something try catch yeah, so let's say you have a function that may fail some some in some cases and throw an error right and you want to use try catch to handle that error grades with what you do is like wrap the call of that function and try and do something in the error message. So I get sometimes an error and sometimes not so how do I do that with uh in an asynchronous api that becomes a little bit harder to do because try catch doesn't work.

B

So what you do is, let's say I have a function that, instead of sometimes throwing an error, it returns a promise that it's sometimes rejected and sometimes resolved. So I have, it maybe throws async. Does that and so here we promise now have a catch method. That's simply equivalent to doing this, calling them with the first parameter undefined and just registering an error callback.

B

So um this sounds like it's just a utility function, but you'll notice that when you try to use it, it really looks very much like using try catch. You do return the value of this function that may or may not return a rejected promise and you catch the result. The cuts, the error and, if you get an error, you return successfully right.

B

This is exactly what we were doing here. I have if I got a current error, just return the message and if I change all this again to.

B

B

You'll see that I don't get errors, but instead I get a bunch of results.

B

Okay, so the idea behind catch is simulating the same thing. You do with try catch, and this is where it gets weird, because uh most people just look at it. From this perspective, right we have from the perspective. This is an error callback.

B

So the question is: what happens when I return from this callback? This is the a very common question and the answer is that you get a result. Promise you get a promise that is actually successfully resolved. You don't get another rejected promise, because it's the same as you did here right, do something never throws an error.

B

It always returns valid value. Does that make sense to you guys.

B

um Instead, people uh expect it to return a receptive promise, but the way to do that would be to actually okay. So if you, if I want my function, synchronous function to throw an error if it cut an error, you do something like this right. You would re-throw the error in synchronous code and that's exactly what you need to do in asynchronous code.

B

Instead of returning something from your catch callback, you throw an error again, and in that case then, yes, I will not get any of this as success. Callbacks.

B

I got well, I got some of them because somewhere to solve instead I'll get rejected, so it's pretty much.

B

It's trying to replicate your uh imperative style of of handling errors.

B

um Does that do you have any questions about this? Does this make sense.

A

B

A

B

Cool so yeah. This is the like the the most typical gotcha that I've seen with pharmacists so far, uh and it's something that probably isn't very well explained in the yui docs. So I probably have to go back and and take a look at it and write it again.

A

That was some feedback from the the channel saying that they think that some of the the docs are not out of date or flow out of date, with the release like the newest changes.

B

uh It is out of date, it just doesn't cover all these details.

B

Right, okay, so.

B

Again, um this is how you do this in with a note api, you you, you know. Instead of calling return a value, you call it callback with the value.

B

Okay, let's move on so here's um something that actually in in my opinions makes the whole the cost of using promise the story value- and this is what I'm showing you here- is how to use uh generators, which is a new es6 feature, there's actually uh designed to be used with lists, but it's it can be used with promises to simulate uh synchronous, looking code when things are actually synchronous.

B

So again, let's say I have a promise, a function that returns a promise after some time like 100 milliseconds. This one just returns a num, uh a random number between zero and the value that requested.

B

uh I have this tax function that that's something under hood to handle promises and it takes a generator function, which is a special kind of function that can, on top of returning a value it can yield values which is essentially stopping the execution until the next time. You call the function um and giving you like an intermediate result.

B

You can use generators to basically do stuff like uh populate lists. You can use it to simulate infinite lists if you want, because each time you call yield, it's essentially doing something like a linked list, which the next value depends on the previous value and so on.

B

um But in this case I'm just abusing the yield syntax to have. It understand promises in a way that they look like synchronous code.

B

So when I do this, the value of n1, instead of being a promise as it would be, if I would do this like, if I just assign the return value instead, the generator will wait for the promise to be resolved and assigned to n1 the value of the params.

B

So this is doing this twice and if I run it, I will get first change this to console.log.

B

I'll get uh two number values I mean five, which I got randomly and then the sum of those that is the return value of the function.

B

So you can see how how you this can be useful for you know, reading stuff from a file instead of going through a bunch of callbacks, you don't have any callbacks here. Just you know. Typical function calls.

B

And the second interesting thing here: oh well, um here's another example. So, instead of uh yielding the the value of the promise here, I'm using it later and what it does is, since this was waiting for this promise to be resolved and then waiting for this promise to resolve.

B

So if you, this is essentially doing uh stuff seriously right waiting for the first to finish, then doing the second one right in this case, I'm just telling okay, yes, start this synchronous operation and then I'm waiting for the values later on. So this is actually a promise.

B

It'll return right away, right, uh it'll, return, a promise right away and your weight at the end for all of those two to be done. So this is uh pretty much like uh doing promise that all on those two functions and then concatenating the results for summing, then up in this case the certain numbers.

B

uh But again I'm just writing. You know imperative code that says to this and I'm not using any functions inside this block right.

A

Right so you just have not having to wait for callbacks.

B

Yeah, it's um pretty much the same as upgrading synchronous code, but it's actually async under code.

B

A

B

Yeah, um the last interesting interesting part is that you can actually use try catch here, uh so you have a function that maybe returns check the promise and I can wrap my yield statement with try and maybe I'll get an error, and this is exactly the same that I wrote in synchronous code a while ago, and I actually in my asynchronous example of this I actually had to go and write. uh This is the node version.

B

This is the one I wanted. I had to go right then and then print all the results in this one. I can just go ahead and since these are all promises just yield to the value of that promise and I'll just throw that uh you know log this result or bring the result.

A

So if you don't have this uh canary, though, what do you need to do to be able to get this to work? You have to have some implementation of promises right.

B

uh Yes, you need to have some implementation promises and in order to do this thing with generators, you need either your runtime to support generators or you need a transpiler that understand generators and uh and generates uh es free code from that uh desktop.

A

Do you have any examples with promises in a y environment.

B

um I could, but honestly I don't want to.

B

Yes, the syntax is saying it's just.

A

Like why that promise, or something.

B

uh The idea is that uh yui promises won't be a special kind of promise or anything like that. uh They'll be just a polyfill and for you is 3.17 or wherever we decide that an expression will be it'll, probably just register itself on the global object, and so you'll just add promise after your dependency and use it as you would a native promise.

B

So the idea is not to is to to start treating us as a native thing and not a while, specifically a specific thing.

A

Wait, the main thing is you're, saying that in the future, we'll, if promise is not there, we'll add it to the global scope.

B

uh Yeah, definitely uh that's what we want to do for for most of the positives that we're working on like promises are internationalization. What libraries like prototype.

A

Used to do and.

B

That was kind of dangerous.

B

uh Well, the difference with prototype is that prototype just went ahead and added the features that we wanted to to all those global objects, and what we're doing is just patching the random saying we have. I have this environment and I want it to actually conform to what this text says. It needs to so we're basing ourselves on standards that are already written.

A

So the idea is that you could write the same promises code with or without the native implementation, and you wouldn't have to change anything.

B

Yeah, that's exactly the idea, and eventually you won't need the polyfill. Eventually you can just remove it and have the the browser deal with it or in node.js. uh Hopefully, in a few months, we'll we'll get native promises too, is.

A

There any danger that some other helpful library that you happen to be, including would have also done that, and you have to check for that.

B

uh Yes, there is that danger uh as long as that library conforms with the standard, you should be okay with it. If you happen to find that it doesn't, you can always force it to use your polyfill right, you can always go ahead and modify the glowed scope. Yes,.

A

My question say that you don't have the native implementation and it's another one there. Would our code try to clobber that or would we just let it stay there.

B

We're doing two things right now. This is something that we're doing in our standalone promise implementation, uh which is called white promise on github.

B

What we're doing is we're leaving along uh the the promised object if it is there, even if it is a non-native implementation and we're also adding another global variable called promised polyfill, which contains our pro our polyfill.

B

So if you find that you run into something, you can actually go ahead and overwrite promise the global promise variable with promise polyfill. So we leave it up to you to decide how to.

B

A

You want to override.

B

A

Marco said he'd like to join, but he doesn't have a camera so he's chickening out today, yeah yeah.

B

Yeah, marco, you can join and and just talk if you want.

A

He says about perhaps to mention that when js errors appear inside of promise, the promise gets rejected, so you should always catch the chain whatever. What does that mean.

A

That's impound.

C

B

Yeah so yeah, I guess I I kind of uh went through that a bit quickly. So yes, every time that you, an error, gets thrown inside a promised callback, the next, the the promise that you know that, then return gets rejected, which is um the way this is set up this way, for example, this reason right, so we want promises to model synchronous, error handling.

B

So if you throw an error somewhere, even if you're inside the tri-catch, you want it to.

B

I'm getting a lot of noise from who do you just join the hangout, with whoever just trying to hang up.

C

A

I think that there's a new supposed feature where um hangouts like this get publicized, but um it shouldn't have not interesting.

B

uh Okay, so I hope I clarified more than I than I observed yeah I I don't know if I was successful so.

A

Like a rule of thumb, what, when would you want to use promises versus like callbacks? Just because you have like a bunch of synchronous stuff and you? You want to be able to wrap everything over and over again with callbacks.

B

uh No so, like I said, I think you can very easily end up with a lot of callbacks, even right when writing promises right, because the then and new promise actually take a callback right. uh Let me show it to you here, so let me have another I'll, just modify this so yeah new promise takes a it, takes a function here and then also like if our p equals so foo p. Dot den also takes a callback.

B

So uh if you're not following this idea of transforming values into another, you can basically start thinking in terms of callbacks. Here you can do b to the then or call back and be free that then callback and depending on your coding style, you can very easily end in a pyramid of doom, even with promises.

B

So that shouldn't be your motivation, your motivations should be um having the same interface for all your asynchronous operations in your system, so my rules thumb is to choose between callbacks and promises and be consistent throughout throughout your whole project.

B

uh I've seen when writing code of my own and from from a project that yahoo that kind of trying to have both at the same time really hurts your your code base. It becomes really hard to to follow so.

A

The sum is worse than the parts.

B

Yes, um so my recommendation is that you know if you're going with promises, it should be the common way of handling some kind of separation in your project, otherwise, just speak with callbacks.

A

So I wanted to, while we have time to switch gears to the es6 side of things, did you want to talk.

B

A little bit about that um yeah, so we've been doing a lot of work on this area in the last couple of months.

B

This is something that's still in the words in the language, um so there's still a lot of stuff. That's changing as uh at the same time we're developing our extensions and like uh today about like three or four hours ago, um both carrie and eric were attending a tc 39 meeting, which is the comedy that designs, the javascript language and they were actually giving feedback based on what we we've been working on to to language designers.

B

So, like people from microsoft did the same today and we got a little a couple of tweaks in into the language.

B

um So it means that whatever I'll show you now can definitely change in the next couple of months. It would change radically because we're approaching the date that was set for the release of the new language, which should be in november or december this year, so you're saying one way that it's going to get locked in at that time. Yes, um it's already locked in as far as features go but they're still like they're still polishing.

B

uh Several details inside each feature, so I'll just show you uh very quickly.

A

What are you doing.

B

I just want to iterate tonight.

A

It's like this is probably one of the biggest deals in javascript in a very long time. This is like the thing that's going to take us from this code suit that we have with all these. You know library.js sites, and it's going to make it this, like this unified framework right.

B

Definitely uh at least it will force us to be consistent in the way we develop modules uh and you may it. Basically, you tear down this barrier of entry. We have for many many communities like we have the known community, that has tens of thousands of modules, but in order to use them in their browser, you have to go and do weird things with them, and you have. We have this amt community that writes in a slightly different format.

B

That also takes quite a bit of effort to get to work on nodes, and then we have, you know like yui modules and who uses those. uh um So yes, this will force us to use uh a convention that we all follow.

A

Well, the point being that you can then mix and match a lot more easily than you could before right.

B

Yes, definitely so, uh this is the basic syntax for friday module. If I have a module that I.

A

Don't see on your screen.

B

No, maybe throw async. Oh I shared the wrong thing.

C

B

B

I've just started my whole screen. Okay, there we are, there, you go so you can. You have the export keyword which in uh which has been a reserved word for quite a lot of time in in javascript, and it allows you to support something from a module that could be like a variable like here or you can export a name function or you can export something that's already defined in the scope of your module.

B

Can you explain.

A

B

A

Does what does it mean in terms of.

B

Right, so um the module is basically, um how do you call it like a unit of code that exposes some parts of an api and the way to expose the parties by actually supporting things. The opportunity operation is to import them and to bring in to your module or to your own code, and you do that with the import keyword.

B

So it's a two-sided, syntax right. You have the export side and the import side. This is how you export things from from a module, and the main difference with what's been doing in yui is that in yy, what we've been doing is add stuff to a common object, which is the y. We did why the foo equals foo.

B

The main difference is that we actually have separate uh objects, separate places in which we to which we export stuff. So you won't have other modules modifying the values in your modules, as we can, as we do in yui like, for instance, we have modules that go and modify the node class or the dom class, or you know add extra apis to why dot array. This is where they read variables.

B

That's the the biggest difference with what we've been doing so far and on the import side. You have very similar syntax. You import something from a certain module which is a string that identifies that module pretty much the same as in yui. We have we assign name to modules and you can change the value of of the name of the thing. Where does the module get named at?

B

So that's uh that's a good question. um Basically, you have module loaders, which are equivalent to the yui instance or the yui loader, actually, which have which act as a dictionary and those modules are stored in those loaders as and the names are, the keys in the dictionary, um but essentially browsers come with.

B

Well, essentially, you'll want to, at first at least avoid this, the notion of a loader and all the things and just focus on the declarative side of modules right.

B

uh This is giving us a total new way to to deal with units of code that just allows us to declare those instead of going through imperative apis like yy.use and we'll be able to do the same in the browser like we'll, have a module tag that allows you to allows us to give it a name and export something from there, and we essentially just declare the module in the browser and then from another module tag. We can actually import it.

B

So this in the future. This will be our point of entry to our to our applications. Instead of having something like creating an instance of a loader and call it to go, fetch a module, we'll just write module tags also, the javascript will be inside that module, or that I mean.

B

Essentially, we'll write everything in modules, just as we do in the yui world, but we we want actually for most cases we won't go in and handle and use an impervio api for this we'll just you know, declare stuff.

A

Is this similar to like, um for instance, like firefox os and like uh google web, they have like files that look like this right um like web apps, there's like a manifest.

B

Something like uh like manifest file.

B

You know, I guess in a way it it kind of is because the manifest file allows you to to like point to to several uh external resources, so in a way yeah, the modules are here, allows you to just create a module pointing to uh to a javascript file, and so but the thing that actually makes this really powerful is oh well, let me get something first, so this is a really weird example that today was brought up from the guys from microsoft brought up at the tc79 meeting, and it's um something that's totally unexpected from the from our experience today, right modules.

B

So let's say I have a full module that has a counter and exports a function called increment. That increases that counter, uh when you do export bar you're, actually creating a variable in this scope. So uh when you do counter plus plus it will actually go and change the value of counter. So the question is: if I call increment when I import those values, will it change the value of counter or will uh will remain the same?

B

And the answer is that it actually does change, because even if you have a ref, a local reference, when you do an import you'll get like a live binding to that value, which is super super different from what you will be used to.

A

Can you do that one more time I I I heard what you were saying, but the words didn't.

B

Yeah um so, um okay: let's do you understand the yes? Okay, this one kind of makes sense, so I have a second module that imports this first module.

B

Okay, uh I'll write it in the html, so it makes more sense. I have.

B

B

And this here so I have a module named bar that has a counter and a function called incurrent.

B

And I go ahead and import those two values. I get a number which is one at the at the beginning and get a function that I can call.

B

So if I log the first value I'll get one because that's the initial value of cancer.

B

But what happens when I call increment? Will it change the value of this local variable or will it not change the value.

B

It actually does go ahead and change it, because this is actually kind of a weird reference to the export value. It's not an actual local variable.

A

B

It happened at.

A

Export time right when we ran export it it locked it in at that point right.

B

uh But it doesn't lock it to the current value. It actually locks it to wearable value. It's like a reference too right, yeah, it's it's a live reference to it.

A

But you could have worked around that by just doing a var inside that function.

B

uh Yes, you can walk around it that way, so they were discussing it today. I don't know what the conclusion was. Are they considering that a problem.

A

Or are they just saying it's just a weird circumstance.

B

um I don't know I kind of like it that way, but I am I I'm totally aware that this is something totally different from what we're used to and that will probably surprise a lot of people.

A

So, what's the state of the important exporting in yui right now.

B

Working okay, yeah, so we've been using a project called the es6 module transpiler, which is on github. You can look it up and what it does is take a javascript code that has import and it will export keywords and if we have a mode for it that we uh that we contributed that transpiles that code into y and yy module, but it's a very specific yui module. That has certain uh that looks a little bit different from normal, wi-fi modules. So this is how it looks like it has.

B

It has a wi-fi statement with a module name like any other. It takes a function with a y, so so far it's the same as any other yy module. This is my transparent right. This is what the transpiler, with normal, give you like dependency.

B

So so far the same as in a normal yy module difference start starts with this one. So first we get an es, true flag, which allows the yui loader to know that it needs to do something. A little different with this kind of module, and then we get okay name is something that yui already gives you and you get two extra parameters, imports and exports.

B

And imports will contain all the dependencies like, for instance, you will do something like some dependency equals imports.

B

Some dependency and the return.

B

Value whatever you return from here will be the actual exports of the module, uh so ex this exports variable that you have here just uh it's just useful for the transpiler to to add stuff to so, um essentially what it will do is, instead of, if you have code that looks like export bar equals, two will transform it into.

B

Something that looks like.

B

C

How would you use that module now you just treated like a typical module. I thought that you had to do something different.

B

uh Yes, you have to do something slightly different, which is why we have it well, you can use it from any other module, that's also compile of cs6. You know just declare it as a dependency, and so, if you have a third module that does import foo from foo you'll get a yui code that behaves the same, but if you want to, for instance, start your application and do something from an html file in which you have a script type and you have yui there and you want to start your application.

B

You do something like yui dot require, instead of you, I don't use so yeah. I want the full module- or in this case again.

B

And you pass in a callback and you'll get the y object the same as in you, I did use, but then you'll get also imports here.

B

Which is different from why I did use and from imports you'll get like foo equals imports, dot food.

A

The point, though, is that people should be writing stuff with in es6 format and then transpiling.

B

Yes, um we're expecting. uh I want to start writing well everyone, but we expect people to that already have like a build step to slowly start adopting esc modules because of all the you know, the nice perks of dealing with syntax instead of with functions and be able to share it with others and well. This is uh just one way to use the yui loader to load these modules and have them you know, load in your application. The same way you do it with y.

B

You can do combo loading with this. You can set up conditional loading the same way that it works in y right now, uh there's just a tiny little difference in how monitors are declared, but those are handled for you by the es6 module transpiler.

B

um But the there's an another site to this: it's like okay, so we want to if you're, writing, uh es6 modules and eventually the browser will support this um by default. So what we want to do now, let me bring my okay, so I'm back um eventually browser will support this by default. So we want to take advantage of that time how and still bring all the values of the yui loader into the standard loader. So we want we'll want uh the native loader to do combo loading. We wanted to do conditional loading.

B

So that's what we've been working with with carly and eric the last couple of months to get up to to speed with the spec and start writing ways to modify this loader uh to do all the things that we know that are really good for performance in that that we've developed for the y loader and so uh I'll just leave it.

B

I don't want to stand too much, but I live with a final note in terms of terms of performance, so the.

B

The way that we develop right now, application right now with yui is, you know we have a web page and we insert the yui seed file and after that we do wifi.use and we get a couple of modules and we start our application from there.

B

That means that we have a cascade in which we first loaded the page. Then we loaded the seed and then with our all of our modules.

B

Having um a native loader of modules means that we don't actually have to go and fetch javascript code. That knows how to load modules. We don't have to go and fetch something like the wire ic right.

A

B

A

So, instead of two hops two round trips, you only have one round trip.

B

We only have one yeah, so what we're working on is um adding these small extensions to the native loader uh for doing stuff like conditional loading or or combo handling, and we want them to be as small as possible, so you can sending send it alongside with the html.

B

So you don't have to go and do another round trip so essentially, we've eliminated, uh maybe 150 milliseconds of all the of the usual time that it takes a page to load which is quite a bit for well, especially if you're, if you're yahoo right, but but also for any other webpage that you want to be interactive really fast.

A

I wanted before you before we closed down. I wanted to make sure I gave opportunity for anybody here had questions about anything you had anything. No people were basically curious about how promises worked and then the es6 stuff. What what's what's coming down the pipe? What's what's still rebuilt,.

B

um We are mostly ironing out the all the details in the es6 loader and we are writing these extensions. uh I suggest that you follow a project called system.js.

B

Yeah, it's uh it shares a couple of our goals in terms of what we want to bring on top of the es6 loader we're trying to align with it in in in most of what we can and share as much code. Everyone like, for instance, system.js, allows you to load amd modules using the native loader or common js modules too, and we're adding to that yy modules so eventually you'll be able to load all these legacy.

B

Yui modules on top of the es explorer, which will help you, you know, transition your your application to using what comes with the native implementation in the.

A

A

Seeing if there's anything anything, that's.

B

I think tracebacks, oh yeah, yeah um yeah. That's um there are a couple of good good good points there. uh You know if hatch and anyone wants to discuss those, they can just pick me and yeah and we can have another hangout.

A

Awesome well, thank you so much juan for for updating us on on state of promises on esx modules. It sounds like we're getting ready and we're sort of you're going to be like uh really prepared for when the spec is finalized and people start writing tons of modules and be able to use them within yy or use.

B

A

Modules outside in other environments, as well.

B

Yeah, so our goal right now is mostly to be able to fill the gaps that are missing in the rouster, so you we're working mostly on polyfills, getting those polyfills in good shape and getting now the basic base value adds of yui into the landscape. uh Once we have that, we can start actually start innovating and.

C

B

Okay, what what's the next thing we can do.

A

Do we have any like um links? You know, connections with, let's say like the google chrome team and firefox team like to get updates about the status of their side of things. uh We have.

B

Something that changed a lot in the way the standard in design in the last year, maybe, is that a lot of conversations have been having happening in github. You can actually follow a lot of the design work behind javascript. By going to certain repositories, they haven't been super publicized.

B

uh They don't have like very, very good names, so it's not like you can google and run into them right, but if you're at least aware of, what's going on, you can run into them and participate in the conversation, and you can always if you're anyone in the community is interested. They can, you know, ask me or eric um we'll give you the the urls to the repository so yeah. um There's a there's been a lot of direct communication with the language designers in github, which has been amazing. That's.

A

Awesome right: well, if there's no more questions, then I think we can close things up. Let me check with.

A

So there was one question from from kyla.

A

I k-l-y-e-d always say it kyle ed. I know it's not kyle. It's kiehad. It says I'm curious with you guys on applications with why? Why? How crazy do you get with system testing? On the client side, we have different stuff hiding and showing, based on certain conditions, maybe prompts popping up really important to them.

B

uh Who is system testing, so we don't have much in terms of integration, integration, testing right. We mostly have functional and unit tests.

B

I guess our high level components are actually using a lot of the lower level components there in a way, in a way, they're testing, an integration between all those.

A

Yeah, I think we could.

B

B

There are teams that yahoo use selenium and and have more like system tests right yeah. You can probably uh talk a little bit about those a lot more than I can do.

A

Well, for every there's, like 9 000 tests that get run across the entire framework from you know, low level to high level widgets in our rci system, and uh we also do things like, um like you said, and functional tests and unit tests that give a good idea. They're, not you know, they're, not bulletproof, but they give a good idea when when something starts breaking uh basically, since it's run on every commit, we have a good idea, um at least in that scope of what happened.

A

But then we get strange things like um in this past release. Someone was changing the way we did logging and you notice how that had a a unexpected side effect where all the tests would go. Oh.

B

A

Yeah your past, you know you didn't you didn't, send me a custom log message. So so you always get weird things like that that have unintended side effects and that I think, would be resolved with like system testing yeah totally cool. Again thanks thanks juan for for coming- and uh I appreciate you having a chance to tell us about this stuff. So.

B

A

B

A

B

It could I could come to rentable uh more frequently. Fortunately, it's uh just off my usual work schedule like um I usually leave work an hour ago, uh because I'm ahead of you four.

A

Hours is maybe having a round table on the flip side of time, where uh folks, who are on the other side of the globe, maybe you could host one um for the southern hemisphere. Definitely try something like that. Maybe in uh I know there.

B

Are a lot of people.

A

Who say that they'd like to come but they're either like asleep or you know it's.

B

Like I guess, anyway, think about that yeah.

A

Cool all right, we'll talk about that later. All right! Thanks everybody for coming today and uh um stay tuned for the next uh open round table next week, see you then bye, good.

B