Invisible Code: Building JavaScript Libraries For Non-Technical People
[Applause] JOHN: So everybody in this room, it's probably
their domain to add new functionality to the website but what about the majority of website
owners, what about that salon daughter who has his daughter hack together a website for
him?
It starts off simple and then he has a script tag added here, a widget, an image gallery,
a couple of analytics tracking tools for some reason, so over time the small, simple website
turns into this multimegabyte monstrosity.
It's not really his fault.
He doesn't know exactly what he is doing, he doesn't know the end result is going to
make his website cooler, so how can we as developers of this third party embedded code
make this situation a little better?
Before we get started my name is John Fawcett, I have been building out our AMP experience,
you may know Google AMP.
Also been helping out on our apps team so I have been writing quite a bit of embedded
JavaScript lately and it has been fun.
So before we get started into the main thing, let's take a look at some presumably reputable
survey, so according to Netcraft back in 2016 we hit over 1 billion unique host names and
that's Carl up there just for effect, right, he has nothing to do with this and also I
added an emoji about an hour ago because everybody else seems to have them, so a billion host
names, and 72% of these pages make more than 51 requests and we can imagine that seems
a little high and, of course, there is a bunch that make way too many requests, right, so
the reason I'm showing you this is just to give you perspective.
We are developers and we kind of know what we are doing maybe, and the rest of the people
that maybe own the rest of the billion host names on the Internet probably don't know
as much.
We should get inside their head, how are they even adding this functionality to their website?
There's really three sort of scenarios they go through.
They either know enough to be a little bit dangerous.
They find a script tag on the Internet and then just paste it into their site and then
tweet things until it works.
Then there's CMS plugins like Wix and Squarespace, but maybe just ask a developer, or they copy
and paste as well, but we are going to focus on these first two because at the end of the
day these are pretty much exactly the same.
Maybe in WordPress you have a few extra APIs but these pretty much have the same constraints.
What are the constraints?
The first thing is environment.
This is a huge umbrella term, I know, but when writing a web app we have a very well-defined
audience that we can actually develop for.
And for building embedded code we actually have two different kinds of users.
We have the person that's going to be consuming the code and pasting it on their website one
way or the other, and we have the end users, and we can't make assumptions about what those
end users really are.
We want our code to be basically run everywhere and that's pretty difficult, right?
So yeah, it's weird.
Next thing is file size.
We really need to respect the end user's bandwidth and capacity to parse JavaScript.
We also need to respect the website owner so these are no-brainer things but we really
have to keep them in mind when running or making third party code to be embedded.
And browser compatibility, again if you can define your audience you know, but we can't
really define that, it's their audience, so browser compatibility is more about global
trends so you are going to have to support older versions of IE than you want to.
And the user is an excuse for poor developer ergonomics so they are creating a single JavaScript
that is hand-rolled to be ES5 compliant and it's not maintainable, and it gets worse and
worse over time.
So network: you are likely being embedded in a page where there's a ton of network requests
because they have three different analytics libraries that are all tracking clicks and
the mouse movements, so something you need to keep in mind is you may be trying to perform
a network request when there's a bunch of other network requests going on, so maybe
we can do something, maybe we can check to see how many network requests are going on
and try to push our pay load at a time when it's less chatty.
So you are thinking you are going to write a little widget for general consumption, maybe
an image gallery or anything, and let's just - basic stuff, I know you guys know this.
You don't need fonts, okay?
Just use the host environment.
Fonts are crazy.
You don't need them.
No global rules; compress your images if you have them.
Maybe even [sound problem] ... okay, back to what we are talking about.
You may be asking: okay, we are going to write some isolated DOM stuff and we are going to
style it.
The question is do I have an external sheet or do I go with inline styles?
Okay.
It actually doesn't matter so much because the problems you are going to run up against
are pretty much exactly the same.
You are being sane, you are prefixing your styles, you are doing inline and then you
run across a global style, like this is going to happen pretty much at least 20% of the
pages you are embedded on, somebody is overwriting it dev style, okay, and you are like: okay,
maybe I can be very specific about my style sheets and only - I will check for all these
things.
Then some reset comes along and has an important tag, and you are like: oh!
Okay, what can we do about this.
What can we do about the global styles that resets are putting important on, and one of
the things you can do is custom tags.
This works in IE9 and up and everything else for the most part.
It's not compliant with the HTML5 spec but it's one way to get style isolation.
In IE9 you need to create an element of the name before you use it so here we have a custom
element called my widget and we have got style isolation for the most part, so we solve that
and then somebody has got an all elements select over and it's adding a border radius
to your newly designed and styled widget, and you are like: okay, let's figure this
out.
So anyway, so we've got this and what do we do about this situation?
There's one thing that we can do and it's to use iframes.
That's the only way you are going to achieve true style isolation and it's a good idea
to run your widget inside the iframe anyway because it's a little more respectful of the
host's environment.
Yes, I guess we are having some interface problems but I will go on.
So iframes, if you run a little bit of code on the host environment that puts an iframe
on the page that's going to run maybe more code in the background, some of that code
can be prioritised and not pretty much overtake the page.
Let's find out what's going on with this slide situation, and then I will continue.
This is the part of the talk where I say, "How's everybody feeling?
Get up and take a stretch".
Well, you've maybe been seeing this crazy scrolling thing, and there's like a bunch
of JavaScript CSS properties in there, so what we can do with the iframe if we embed
it and we do this for some isolation is to put the iframe in the DOM and then apply our
own defaults to it, and we take pretty much every single CSS property and put it on that
iframe so we can have an expected behaviour locally and on anybody else's page.
Of course, there's still edge cases but this does cover some of them.
The iframe brings us to JavaScript, right, we are creating the iframe and adding all
those CSS properties, so what are the pitfalls and crazy stories?
Well, first off let's get the basics out of the way - and keep flashing my slides.
Well, all right.
I could just turn my computer around and everybody can come closer.
[Laughter] >> It was flashing all of yesterday as well.
JOHN: Yes, I will just go through it, and we will just deal with it.
So anyway, let's get the basics out of the way.
There is some really simple stuff that I know everybody knows: don't use globals, of course.
We've known this for a while.
Please, for the love of God, don't, don't mess with the prototype, don't depend on a
library that messes with the prototype.
Minify your code.
Don't make a bunch of requests.
If you have something you need to phone home with, create a route that you can batch request
to so you are only sending one, so if somebody is on a mobile phone the biggest problem is
latency and if you are making a bunch of requests phoning home just at least make a route that's
going to be able to accept multiple of those requests, it's not too hard.
And of course profile your code.
The biggest problem I feel on a lot of these sites is they've can included 47 jQuery plugins
and not all of them were very considerate of performance.
If you are going to be having a copy and paste script tag consider within the script tag
itself - I saw it and was, "Holy crap", this is a great idea, and got a lot of feedback
from non-technical people, saying, "That's all you have to do?"
Yes, that's all you have to do.
A little story about building the AMP viewer.
If you can imagine a block of code here and then imagine a scenario I put myself in, we
will be in good shape here, so we are reason the AMP viewer and the AMP viewer - actually,
how many people are familiar with AMP from Google?
So you know when you search for Donald Trump and you are wondering why I'm searching for
Donald Trump, and you go to the search results, it has the little carousel - oh, look at that,
Cloudflare!
Hmm, that seems to be extending my desktop now.
You want to check that out?
I guess it's in Preferences.
We can maybe move it over.
Let's check out Preferences.
Display.
There we go.
Perfect.
Okay, so I will go back talking about AMP viewer real quick, so you click on a miniature
carousel in a search result, it has that little lightning bolt and you instantly load the
page.
Google does this by pre-rendering the document or pre-rendering the document they loaded
in an iframe in the background.
They've got it in a Google CDM and when you click the article it flashes in the view and
tells the AMP document: hey, you are now visible, you are now allowed to download images and
to download your analytics tracking tools and actually start tracking so that's kind
of what the AMP viewer does.
So anyway, I had some similar code as this and we had already deployed it to thousands
of sites, and we've started collecting data and one of the pieces of data we collected
was that this list was undefined.
If you - you don't really have to understand the code but the iterator function to the
enumeration methods like map and filter receive three arguments, and the third is list.
It's the original list that you are iterating on.
So why, in what scenario is list actually undefined?
The answer is: when somebody overrides your prototype with an implementation of map that
does not include list.
And who does this?
Well, prototype.js actually did it before 2012 and they realised their folly in 2012
and released a new version but there's still a ton of websites that use pre-2012 prototype.js.
What do you even do about that?
How far do you go in not trusting JavaScript?
The answer is for us, you know, we went ahead and fixed it and said: okay, let's not rely
on that variable because there's too many people that are relying on Prototype.js, pre-2012
I might add.
So it's up to you.
You really need to be collecting that data though, that's the important part.
How do you do it?
Well, we used Sentry.
If you haven't used Sentry, it's really awesome, okay?
I'm just going to zoom in here.
I mean, you get all kinds of great information, you get the browser and all, the device and
the breakdown of browser and the errors that are occurring and you will see here the stack
trace comes in, and we are running completely uglified code and yet when the error comes
in we can actually see the line that had the error and you see this is a TypeScript file
which we will talk about a little bit later in developer ergonomics, so yes, we have TypeScript
or we have Sentry error reporting.
Now, we only run this for a sample of our users so not everybody is going to be reporting
errors to us, and it's a pretty easy thing to do.
You just say: hey, script actually report errors to Sentry; or don't report errors to
Sentry.
So that's another thing about being a little bit responsible.
You don't want every single one of your pieces of code phoning home for whatever reason,
but there's a problem.
If you've ever used Sentry you know there's a line called Raven.js which is a sort of
embedded library of sorts as well and they follow the pattern of a massive JavaScript
file that is about 2400 lines of code at the end of the day and it's 24 kilobytes minified
and you have to wonder how many SHR wrappers there are on any given website so Raven.js
is great, it does a lot of stuff for you, but it was too much for us.
So what we did is we already had our own SHR wrapper, we already had the ability to parse
stack traces.
We just used the API, right?
If we have access to the API, we can go ahead and push all that error information and we
don't have that insane amount of code in our build.
What this really looks like is you are just hooking into the on air function on window
and you can't use at event listener, Air, I've already tried, but you can override this
function and hopes nobody else does as well.
You also need to check that the file name coming through is actually your file because
there's going to be a ton of errors on the page and you don't want to be reporting them
all to your Sentry incidents.
So how do you get rid of those SHR wrappers and one of the things we came up with is API
fingerprinting.
We live in a world where jQuery of us this dominant library and still is, even though
we rarely use it anymore as developers in this room, so - well, let's just look.
According to some survey 89.5% of their top websites use jQuery and then estimates for
the entire Internet is just under 20% so you have a very high likelihood that $.AJAX exists
already.
So we should start building little abstractions that make it look like Fetch exists for everybody,
even if they don't have Fetch and maybe they have jQuery, and yes, it's a pretty good chance
had a they do have jQuery.
What if they don't?
Object query?
Try something else.
These are really cheap and then you have a really nice interface.
So what if this embedded code is still running and relying on the Fetch API?
You need to download it.
Or you could say this code is not going to work and I'm going to error out and you are
like: oh, I have a 80% likelihood that my code will work.
No, we can do better.
We can actually just dynamically fetch polyfill or jQuery even because maybe they have it
cached.
A problem: we are seeing if some code exists and then if it doesn't we have some asynchronous
step that must occur and in reality we would want an interface that just works.
You pull in a module statistically from your bundle and you say: get me this resource and
you want to be able to just check the body, right?
You want this.
But in a situation where dependencies may not have even been loaded yet, we need to
queue up these requests and once the dependencies are satisfied and the API has been defined,
then we can go ahead and resume those requests but to a developer it should feel just like
this.
So we created a little library.
It's essentially dependency injection, right, but it's a little bit different.
So we just had these little decorators and of course the decorators are a little bit
of fluff, they are not that much code to add in, but you could use the non-decorator API
just as well.
So we let these functions though that we need the fetch API and whatever the fetch API that
will be defined by us, and we also want to let it know that any call to these functions
should be queued up until the fetch API actually exists and has been resolved.
So what does defining the fetch API look like for this?
The first thing, the same little library we build, we are going to pull in a definer option
where we set up the dependencies, let it know what they mean.
We pull in some strategies from the other part of the library and we only pull in the
things that we are actually looking for because our module bundler is going to do some tree
shaking, right, and we are going to have as little code as possible so we pull in these
different strategies and then we go ahead and define what Fetch would be and it's just
a chain of these strategies.
We are going to look for the built in global fetch, then look for jQueries and wrap it,
then build an external resource, wait for it to load and then apply the jQuery strategy.
I say jQuery because probably others are cached just from their travels.
That takes care of that.
Let's keep our bundle size down.
Performance tips: I can't really say a whole lot - many have already said, and maybe Jason,
but we will go over a little bit of stuff.
The main thing we found is we don't want to negatively affect performance on the page
and we don't want necessarily the best performance but we should probably queue our expensive
actions so with the AMP viewer for a lot of our customers there is this discovery step,
right?
And we are going to take all the links on the page and then check an external service
to see if any of those links are AMP.
And then we are going to modify the DOM with little icons that say: this is an AMP link.
If you click on it, it's going to be really fast.
And that's an expensive operation because we are calling up to a service and then modifying
the DOM so what can we do about that?
The thing we came up with to non-effect performance on initial load is a measure of FPS and you
can do that by using request animation and counting the frames.
So the measure XHR is not super-reliable and I'm not even going to talk about it.
Some expensive operation just needs to be put on a queue and be deferred until later
and we can go ahead and just tell it: hey, when the FPS is at least 30, then maybe it's
a safe time to go ahead and do this.
We will probably want to wait until other libraries have done their thing and this will
probably work.
So developer ergonomics, earlier I said a lot of these embedded JavaScript libraries,
they sacrifice a lot of the modern development practices that we've learned over the past
few years in favour of creating a very small, tight, single JavaScript file, and I'm arguing
that that will result in crappier code that will not be maintained properly, so just think
about it.
So for AMP viewer reading TypeScript as I said before, it's really great, it produces
fairly small type code that's ES5 compliant and we have a really great developer experience
from it.
So what does the AMP viewer do?
This is what I was explaining before.
A little BMW cable, that's not going to work.
That is cool.
Let's try to go back and see if it does it.
Whatever, you guys know what I was talking about.
It handles push state history API, it has got very smooth animations and we are actually
using a library called Preact and Jason Miller is giving a talk right now about it and it's
a 3.5 version of React so it works really well, we've got it on thousands of websites
right now and some of the builds are under 15 kilobytes which to me still seems too much.
3.5 of those kilobytes is Preact.
I am pretty sure we can get this down, all the components, everything, and once I figure
out how to properly mangle all my props using Closure Compiler I think we will be in a pretty
good state.
So anyway, like I said, we've got this really beautiful component-based architecture using
TypeScript so everything is checked statically at compile time and we didn't really have
to sacrifice the code in order to have a small file size.
Also, you know, module bundlers these days roll up in webpack, they can export things
to globals and just use function closures so you are having really tight code that is
just wrapped by functions rather than something like browser - little header file or a little
header part that helps load the module at run time so you don't have a whole lot of
overhead and you can also export to multiple targets, right?
The general consumption target is going to be to global.
Something they are going to copy and paste that needs to self-register under the page
is going to be text supported, right?
But so many times I have downloaded or tried to use an analytics tool and they say the
way to install this is you copy and paste this chunk of minified onto your page, and
I end up copying and pasting that into its own little module so it's all in my bundle,
right?
So it's so easy to just have a different target for your developers.
You have an ES6 target and you say in your package data: here is my ES next entry point
and here is my main entry point, my widget.
It's really easy to do so use rollup or webpack please and also export to global for the non-techies.
So we've kind of gone all over the place and I hope that you maybe learned a little bit
from my travels.
So please responsibly code and maybe try out the fingerprinting API.
That should be open source pretty soon.
And queue your expensive operations because, yes, it's good for the world.
So thanks.
[Applause]
For more infomation >> 3 simple hack for fidget spinner !!! - Duration: 2:57. 
Không có nhận xét nào:
Đăng nhận xét