BILL LUAN: Shanghai GDG is a very
interesting developer community.
FEMALE SPEAKER: I'm glad somebody
has asked this question.
MALE SPEAKER: This is where the magic happens.
FEMALE SPEAKER: This is primarily a question and
answer show, so if any of you out there would like to ask
questions--
BILL LUAN: Hello and welcome to another
episode GDL-IL, GDL Israel.
Today we are going to speak about HTML5, some cool new
things that we see today.
And of course, we're going to deep dive into web workers and
why this HTML5 API lets you use multi-thread in the
browsers is very great way to actually improve your
performance and make sure that your web apps and websites are
working better and utilized quad-core, 8-core, or any
other number of cores that the devices that your browsers is
running on.
So without further ado, let's jump and see some code.
Let me share my screen with you.
And we are hopefully if I'm jumping-- yeah.
So for the ones that don't know, let me just open it and
make it a bit bigger but on this spot.
So it will be here, right here.
Let's make it bigger.
So at ido-green.appspot.com, you could see all the sources
and everything that we will cover today.
And as you saw probably, the first screen that I shared
with you was a post that I wrote actually almost now a
year ago about big data and web workers.
And the promise of the big thing there is that today in
modern browsers--
and more and more browsers are actually implementing this
important HTML5 feature--
allowing us to work with big data.
And when I'm saying big data, it's with half a smile because
it's not teras, but still few megs that up to now, when we
wanted to move them, we postMessage to the window
object or to the worker object.
It was quite hard.
Luckily, today with HTML5, we could use transferable object
and do that very, very quickly.
This is a good link to start with, which is the spec of
transferable object.
And basically, from a macro level what we have here is
that just a moving and not a copy operation.
So I'm going to be moving a pointer, and we're getting a
boost in our performances.
In this specific case, our specific example, you can see
that basically what we have here is a way to use
transferable object or not to use them, and then we're just
seeing what huge difference it's bringing in terms of the
amount of seconds that it will cause our worker to get a
data, crunch it, and return it back.
This is the example page.
And as you can see here on ido-green.appspo
t.com/HTML5webcom, this is part of a presentation.
And basically when we're running the test, you can see
here that it's taking it two milliseconds on average, maybe
three, four.
Let me make it a bit bigger so it will be easier to see.
Now if you will take the exact URL here and basically copy to
an older browsers that are not supporting transferable
objects, you'll see a number here that is at
least 50 times higher.
In most of the cases that I've checked, it was around 150,
160 milliseconds.
So it's quite nice to see that today we have a very efficient
way to work with web workers because, of course, the
bottleneck wasn't in the CPU or the work that the worker
itself is doing for us but more in the way that we are
transmitting big data--
again with a half a smile--
to the worker and back to our web app.
Here is another link.
Basically I wrote the book with O'
Reilly about web workers.
But all the examples of the book are, off course, free for
use on GitHub.
And you could see it here and basically get and [INAUDIBLE]
all the different examples.
The ones that we will focus today are just two quite nice
examples that I wanted to share with you.
So let's go here and try now again to
share the example page.
It's right here.
The reason I just switch windows is because I wish to
show you this example in Chrome Canary.
For the web developers here that aren't using Chrome
Canary when they are developing, I highly advise
you to try it.
It's a great way to stay up to date with all the new features
that you have in Chrome and that you will see in the
stable version after six weeks, more or less.
Because as you all know, Chrome is out there every six
weeks with new features and improvements to its speed,
security, and simplicity of course.
And here in Chrome Canary, we have several things that are
new but basically harnessing us with better ability to
debug web workers.
As you could see here-- let me just load this
page from the start--
what we have here is a web worker that we would use in
order to calculate pi.
And as you could see here, I could choose the amount of
cycles that I wish to do and then start the worker.
And, I hope that you could all see now that what I have here
is basically a [INAUDIBLE]
Chrome DevTools.
Yeah, I see that you don't see because you see the main page.
Let me again share with you the right window,
and let's see here.
Yeah, Chrome DevTools.
So the nice thing here is what you see here is basically the
Chrome DevTools that you all know and, I hope, love.
But here, the main difference is that as you could see now,
we are in the example pi.js, which is our worker.
And what I did is that I just checked one check box to make
sure that on the start of everything, our web worker's
DevTool window will be open for us.
And then we'll be able to go step-by-step and just use the
debugger as we like.
As you can see here, I have an event listener.
And I'm getting two messages--
the Start and the Stop buttons.
So in this case, since you are aware that I clicked on the
Start button, if we just release it, you see that I'm
holding now on the postMessage of the Start case.
And now we could go case-by-case and just have our
calculation.
You could see here that I have the right number with me.
And now, basically, I just need to communicate it back to
the parent, which is the index.html5 app.
I just release it, and now let's switch
again to the main window.
Here it is.
And as you could see here nicely--
let me make it a bit bigger.
Not this one, but rather this one.
So I got the messages as you could see here in the
DevTools, and we got the amount of cycles that we are
going to run.
And then we got our answer back.
And as you could all see, we have here the right answer.
Maybe we should step one or two steps back and just let me
share with you--
let's close this one--
when we're talking about web workers, what are the most
basic, fundamental components that we're working with and we
want to see in a web worker?
So let me here just go--
yeah.
So let's do it again, and we'll just load a new screen
that I'll share with you.
And we'll see what are the most basic components of web
workers and how we could work with them.
[INAUDIBLE].
IDO GREEN: If people are joining,
please just put on mute.
It will be great.
[INAUDIBLE].
IDO GREEN: OK.
So, let's take [INAUDIBLE].
[INAUDIBLE].
IDO GREEN: Yes.
So what we have basically--
[INAUDIBLE]
let me take and show you this quick example.
I hope you all see my window.
Yeah, it's going to be quite quick.
We'll reach to the part that we want to show.
Yeah.
So basically, when we are talking about web workers, we
have three elements that we want to take and note.
First is in our one-page app, in our mobile web app, in our
web app, we want to be able to get out of the realm of the
single thread that our JavaScript engine allow us to
do and just start a new thread on the side, crunch some
number there.
It could be 3D metrics calculation.
It could be route calculation on maps.
It could be anything that right now you're doing with
hacks of setTimeout or things like that and you just want to
purely do it off the main thread, so it will not
interfere with the DOM, with the window that you are
showing the user.
So the user won't see any sluggishness, and everything
will work really nice and fast.
So what you need to do in your index HTML5 is just call your
work with this constructor.
And basically you're just pointing to a JavaScript file
that contain all the logic that the
worker itself will run.
After that, the only two other things is to create the
communication channel with the worker.
So one, we'll just create a new event listener and just
hook it, so we'll be able to send some commands, some data,
to the worker and, of course, get back from the worker
information.
In this example, I'm just sending at the
beginning some settings--
so some initial agent settings, and that's it.
In the worker itself, what we need to do is, of course, aid
the event listener, so we'll have the postmaster channel
with our master or parent if you will.
Then, of course, have a main function of doing some work.
And here, I just choose to put as an example JSONP.
So it's quite powerful.
The specification in a worker doesn't allow you to do
everything that you could do today in the window of the
main DOM object.
But it's good enough, and you could do quite a lot
of things with it.
One of them is just leveraging the power of JSONP and just
import scripts from the outside world and just
register a callback to them to handle the work.
And in our case, we just choose this amazing generic
name, handleWork.
And here we'll just do the work when we're getting the
results from the callback and, in this case, post the message
back to the parent.
So here it will get it again, and it will do the right
things with it--
probably communicate it back to the user with some DOM
manipulation that reflect the calculation that
we did in our worker.
Few things that are quite nice to note and are quite
important, actually--
let me first just remove this image that with my big screen
doesn't for work well here.
And now, when we removed it, we could focus better on what
we're doing here.
So first and foremost, you want to use Modernizr.
Modernizr is a great framework that basically allow you to
make sure that you have web worker in the browser.
How you do that?
After you are basically import the Modernizr library, you
just set up a if statement.
And with this if statement, everything that you do after
that-- if it's true, of course, letting you know that
you do have web workers in the specific browsers.
How Modernizr look like?
Well, you can find it on GitHub, and you could check
lot of great things that Paul Irish, Bruce [INAUDIBLE]
and other great contributors are saying about it.
The other big and major thing about it is shared workers.
Shared workers is basically a web worker that could be
shared between several windows or tabs.
So you can think of it as one point of communication with
your local database, your local index DB.
Or maybe if you have a database in the cloud or some
other logic that you want one place to communicate with,
that's the right location to put it.
And the great things about it is that, if you'll see when
I'm opening the Chrome DevTools, very easily I could
go and make sure that I will be able to debug workers.
And how?
With that.
On Source tab--
as you saw what I did.
I just went to the Source tab--
down here, we have workers.
So like we're putting any other break points, we could
just mark this check box, Impose on Start.
And then, as I said, shared workers will be inspected the
Task Manager, but regular workers like the one I showed
will be just stopped here.
And that's basically the example that we start our GDL
today with.
What else we could say about it?
Yeah, of course, we have a link here
to the worker itself.
And when I clicked on it, basically I opened another
window that let me debug it.
And let's close this one.
And of course, you could have a link here with all the
examples that we are going on, and I showed you it's all on
GitHub now for free, of course.
So I think that's it.
I see that we have a few questions.
If someone would like to ask a question, this
is the right time.
Great.
So if there are no more questions, let's see if we
have some more things that I wanted to share today.
Let me share the screen one more time please.
Let's see here.
Yeah, this is the right one.
And this is the example of the transferable object.
This is the location of the web workers examples.
Let me make it a bit bigger.
And the easiest way to do it is just--
yeah.
And of course you could see and read more thoroughly what
we covered today on my blog, greenido.wordpress.com.
Let me put it just here so you'll all see it.
It's right here.
So if you'll search web workers on this blog, you're
probably going to see all the different things that you
could do with web workers.
And until next time, be strong and safe.
And next week, we are going to have here an AngularJS
specialist, [INAUDIBLE]
that will share with us some of his thoughts.
So you are most welcome to join us in our next GDL-IL.
It will be on next week at 2:00 Israel time.
And until then, see you later.
Bye-bye, guys.