PAUL: You see, you've got that look on your face,
because you know you're winding me up.
JAKE: Yes, I do.
PAUL: Yeah.
Yeah, you are.
All your problems are gone.
JAKE: So what's your problem, then, Paul?
PAUL: My problem with this is the page load
time is this proxy for all your performance
problems are sorted.
No, no, and again-- once again, no.
Right?
I've got two major issues right now.
One is to get good page load time, people defer everything
to DOM content loaded.
JAKE: Right.
PAUL: And they-- or body load, or whatever.
And they create-- I like to think of as a 9:00 AM rush hour
problem.
They all go, you know what we should do?
We should make sure the roads are all clear until 8:45,
and then everybody should go on the roads.
JAKE: So what's the effect of this that you're seeing?
It's that as you-- as the page loads, it has a moment of jank?
PAUL: More than a moment, actually.
It's like-- honestly, it can be at least several seconds.
Because we know that when people first hit a page,
the first thing they try and do is tap, or scroll, some kind
of interaction.
And it's the very time that we've all
chosen to do all our work.
JAKE: Yeah.
PAUL: And it drives me mad.
This is not-- you can get a good first paint,
and then completely hose the user's expectation
by doing this.
[MUSIC PLAYING]
And then the other thing that bothers
me is this, kind of, disregard for anything that
happens after the page load.
Like, I've got it on the screen.
It's now the browser's problem if it doesn't scroll well,
if it doesn't transition well, if it
doesn't stick to finger when they're
interacting in some ways.
JAKE: Well, 50% of the answer will be,
have you tried virtual DOM?
PAUL: So vDOM.
All right, fine.
I think vDOM is actually a very clever idea.
Because I think what it's doing is
it's making sure you don't shoot yourself in the foot.
JAKE: This is the key to it.
I don't know.
When people say that to me, it feels like-- I say,
oh, god, my train journey takes quite long.
It's like 40 minutes.
And people say, ah, have you tried
wearing better running shoes?
It's like, well, I'm still going to be there on the train,
with those running shoes.
And so if things like React that do the virtual DOM thing,
they are still going to work with the DOM?
PAUL: Yeah.
JAKE: Like, if you have 100 elements
to create on the page, that will be slower with React.
PAUL: Yeah.
JAKE: Because React is on the top.
PAUL: Yes.
And also, I've seen timeline traces
where all the work was React.
That's not React's fault, but it struck me
that the developer might be thinking, well, essentially all
the work I do in React, or all the work I
do with vDOM is free.
It's only the bit at the end that I have to pay the cost on.
JAKE: But where things like React really come
into their own is where you can just sort of-- you
can create a whole load of new objects to represent the DOM
and say, this is what it should look like.
PAUL: Right.
JAKE: You can write your code really naively,
and React will cater for that.
And rather than create a whole set of corresponding DOM
elements, it will take what's already there,
move that all around, change the order,
and just create the new stuff it needs.
And that's the sort of practical performance benefit.
It's not the DOM that's slow.
It's kind of your use of it.
PAUL: I think-- exactly.
It's very much your use of it.
I think it's very nice to have the headlines,
like, the DOM is slow.
Or always use CSS animations.
But, no.
Because it completely misses the nuance.
JAKE: This is something I've been
kind of exploring more and more recently is that displaying
what looks like a complete interface,
but it's not actually ready.
Is that OK?
Is that something you--
PAUL: Yeah.
Well, so long as the thing that they want to interact with
will work.
JAKE: This is the problem with what Apple recommend
with their-- because they have only
a few dimensions of phones.
You can include essentially screenshots of every device
as your initial render.
The problem with that is that it won't be clickable.
So I think what they recommend is just something that
has the colored bars and stuff?
PAUL: Yeah.
JAKE: I think we should be doing more of that on the web.
But not with bitmaps, because windows can be any size.
But with something with just a very small blob of CSS,
a little bit of HTML and Flexbox,
or whatever it is, just to do your sort of basic--
PAUL: Bare bones.
Yeah.
I think that's absolutely fine.
Like, that has to be part of it.
Perceived performance is a huge part of this whole discussion.
And I think as Service Worker is more widely
used, as we get to this kind of fast bootstrapping
offline-y world, where people are
sort of tapping on things from their home screen,
well, it's all this bit afterwards
that actually is going to shape user expectation.
That's the bit they're going to notice.
They're going to decide whether or not
to use your thing not because of how quickly it loads,
because that would be a fraction of a second, probably.
But it'd be all that other stuff afterwards.
It says, what do they care about?
What do they actually notice?
What do they perceive?
That's the thing to target.
And, of course, on the developer side, this is the idle stuff.
There's that kind of-- what can we actually
give to the user to make them feel
like they're getting the right response in the right time?
But it may be that there's a bit of sleight of hand on our part,
for sure.
JAKE: Hm.
[MUSIC PLAYING]