# I said, you really don't need all that JavaScript, I promise.

# The web is HTML, CSS, and JavaScript. But most of a page is HTML, and most of the web is pages. You need the words and the pictures more than you need the colours and the buttons. That's why you were hopefully taught HTML first, then CSS, then JavaScript.

# Some people are taught this the wrong way around; they're taught JavaScript first. Or they reach for javascript first when building the web.

# sometimes this ends up with javascript completely taking over!

# but the three are designed to be in balance. If you let JavaScript lead, then it takes over. Let's look at why that might not be a great idea.

# Zach Leatherman tested a client-rendered React site displaying a tweet against a plain HTML file rendering a tweet.

# Ah, I read that wrong; he tested a React site rendering a SINGLE tweet against an HTML file containing every single one of his 27,000 tweets. 8.5MB of HTML. Which was faster?

# Let's let Zach speak for himself.

# Let's take a look at another example: Remy Sharp looked into doing syntax highlighting on server and client.

# This is because SSR is not sending the two JavaScript prism.js files (prism itself and the additional syntax highlighter).

# It is tempting to outsource a bunch of the work from your computer, which you have to pay for and wait for, to the world's largest distributed supercomputer: the web. But the work doesn't go away; you're just making everyone do it instead of you.

# And their computers are not as good as yours. Phones are mostly rubbish.

# I have heard people say: serve less JS and then everything works faster! Fortunately you have a willing partner in this...

#

# The network hates you and wants you to suffer.

#

#

# And then you think, well, 1%, that isn't a big deal. And to be honest, that 1%, I feel sorry for them, but they're not really our target audience anyway. It's lots of effort to make our web app available to everybody, and it's just not worth it. Good idea, but we've got priorities and a backlog. Maybe we'll do it next time.

#

# Most of the people who didn't get your JS should have done.

# talk through all the ways JS can fail to arrive

# It's not 1% of people who always can't see your site and 99% of people who always can. It's 1% of visits. Almost all the people who don't get your site correctly actually should have been able to. They don't have JavaScript turned off. They're not browsing on a WAP phone over a 2g connection from a shanty town. They're you, in a cellar bar or a hotel room or waiting for the phone network to wake back up.

# What if they bailed after a few failures? If you're using a web app and it doesn't work, maybe you'll shrug and hit refresh, or toggle your phone into airplane mode and back out again. But when that happens a second time? A third? A fourth? Will you think "huh, native apps don't do this!" and be annoyed? Maybe you won't, because you're a web developer and you understand the difference between the network failing, the browser failing, and the site failing. You understand the technology.

# But here's the other thing about the supposedly "modern" web. It's really difficult.

# Can you keep up with all this stuff? It's not just me saying this.

#

#

#

# That's the key point here. There are two arguments given: that all this stuff makes better sites for users, and that it saves developer time and so means more stuff can be developed. Are either true?

# I'm not trying to overwhelm you with similar quotations. The thing here is, these are all notable, smart, motivated people who work professionally on and with and for the web, and they're the ones getting overwhelmed. I bet you feel the same.

# this is a link

# this? don't do this. Use HTML when you can. When you can't... well, we'll get to that.

# Why are we doing all this? Let's take a step back.

# There are reasons. And these are good reasons. This stuff is important.

# But these seem like after-the-fact rationalisation to me. Given that we've decided as an industry to use these things, what do we get out of it?

# I think the reason people started inventing client-side frameworks is this: page -> click link -> white screen (or existing screen) -> new page browsers don't do the white screen thing any more (it's called "paint holding"). The way it used to work is that if the new page started loading, the browser would wipe the screen, even if it was taking a long time. Now, the existing page isn't removed until the new page actually sends content.

# So you lose control over the user experience. And we don't like that, and we are right to not like it. so people wanted to keep control over that, to give their users a good experience, not this blank screen while they were waiting. Page loads are terrible, right? They must be avoided.

# so you say, what if instead of the browser loading the new HTML page, what if I did it? that's easy right? just fetch() the html off the server, then put it in the page myself; no white flash. And then you say, but if some of my HTML is the same... and you invent the virtual DOM. And then you say, but now the URL is different... and you invent client side routing. all because the flash of no content is bad.

# It's a pyramid, one thing built on another.

# But it's a pyramid balanced on one tiny point.

# What if you could control the experience of new page loads WITHOUT having to reimplement page loading yourself? This is what Shared Element Transitions are for.

# The demo at this point is available in three steps: see the first step. The "demo" links along the top move between the three stages. Note that, at time of writing in June 2022, the shared element transition API, which this demo uses, only works in Chrome Dev/Canary. Click the "Stuart Langridge" link to show a transition, in each step of the demo.

# transition.start TAKES A PICTURE of the screen and shows it! It freezes the page.

# This is like how in a 9am Zoom meeting you can set a picture of yourself to show as your camera, and then everyone thinks you're there and really you're making a cup of tea and you've still got a dressing gown on. If any of my clients are here, I have never done that.

# Really think of this like the curtain on a stage. It takes a screenshot of the page, and displays that screenshot. You can then do whatever you like to the page behind the scenes, like load a new page, or change the DOM in this one, and then when you're done, you use CSS animations like you normally would to remove the screenshot and show the new look.

# by default you don't have to do ANYTHING. You get a free "fade" from one to the other. That was the first demo I showed, when one page faded into the next. Create a transition and that's it!

# but because it's CSS you already know how to change how the animation works. here page-transition-outgoing-image is the screenshot of the page before the transition. So you can animate it how you want: this is how I made the fade go slower.

# and if you wanted the page to slide to the side, you'd use css to do that instead! this is all stuff you already know how to do! different animations, media queries so it works differently on mobile screens, you already know this!

# and then the other demo, where the image animated separately... what you do is add a page-transition-tag, and then all the stuff with that tag gets a SEPARATE animation. And by default that separate one animates position and size, so the image moved and I didn't have to do ANYTHING.

# see the explainer on github; watch Jake Archibald's talk at IO 2022.

# unfortunately now we have to look at the truth. It's Chrome only, and it's SPA only. For now.

but this solves a real problem.

# Most of the time, perhaps, you only want to add some “sprinkles of interactivity” to an existing page. The majority of websites aren’t, and don’t need to be, single-page apps. It's not me saying that, it's REACT saying that. "React has been designed from the start for gradual adoption, and you can use as little or as much React as you need."

# A page which uses Vue components (don't want to go on about just React). Vue doesn't control the page, it just augments it.

#

# And HTML on its own does a lot of stuff now that used to have to be built by hand as components. Beware that some people who've been in web development for a little while may remember days when HTML could not do this, and not have learned that now it can, so they may reach for JavaScript components that aren't needed, and then try to justify that afterwards.

#

#

# It's not that these are super-revolutionary. It's that each of these things would have a while back required a bunch of JS enhancement and now they don't. But I am not saying to not use JavaScript!

# Be sensible! I'm not saying don't use JS! JS is the programming language of the web. It's great. I love it. Don't avoid it! Just don't necessarily let it run everything.

# it's good to stay in touch with the latest tricks. we are in a fast moving industry. but stay in touch with all the ones that are relevant to your job. HTML, and CSS, and JavaScript.

# or don't.

# don't fight against the web. There's so much in our industry and in the rest of the world that needs fighting. So many ways we need to stand in solidarity with one another and the world. So many people who need your help. If you want to fight, great. Don't fight the web.

# frameworks are a great thing to prototype stuff before the web gets it takes a long time to standardise; they make sure that everyone's included, accessibility is good, performance is good. That takes time.

# so use extra stuff if you need things that aren't in the web platform yet but if you're ALWAYS doing stuff that isn't in the web platform yet, is that really right? are you honestly always on the bleeding edge? to make a login form? seriously?

#

# let's keep it that way, all of us.