[MUSIC]

>> Hey, welcome. It's another episode of Svelte Radio.

Hello everyone.

Hi, Brittany. Hi, Jeff. How are you guys doing?

>> Good to be back.

>> We're missing Anthony and Sean today.

Anthony couldn't be here, Sean couldn't be here.

I don't know why, probably busy or sleeping.

Who knows? But we are joined by Jeff.

Hi, how are you doing?

>> Hey, I'm doing good. We just started getting a lot of rain where I am.

So I've been staying inside.

>> Yeah.

>> Good podcast weather.

>> You live on the West Coast, right?

>> Yeah, Washington State.

>> Washington.

>> Okay.

>> Washington. I worked for Alaska Airlines,

but they're also headquartered in Washington.

>> The person I work closely with also lives in,

well, actually he lives in Oregon,

but he just said the same thing yesterday,

that it just started raining and it's like rainy season.

>> Yeah, it's been dumping. It's good. Rain is good.

>> All right. So Brittany,

what have you been up to lately?

>> Just started building components,

which I'm really excited about.

So finally out of the carousel,

I don't know if I mentioned any of that on air,

but we were talking about the carousel the last couple of times we recorded,

and that finally got shipped this week and I'm done with that.

On to actually building the design system that we're going to do.

So I'm very excited to be building components again and not in

the app building with that crazy carousel.

>> Yeah. Now that makes sense.

>> Yeah, you said carousel and I'm just like, "Oh, yeah."

Those are tricky. No, thank you.

Better you than me.

>> I just try to avoid them.

Whenever someone wants the carousel, I'm like, "No,

maybe there's some other way we can do this."

>> Are you sure?

>> Are you really sure you want us to spend 600 developer hours on this?

>> Right after this,

we did a rollout meeting yesterday and our designer showed on

mobile a drop-down with a carousel inside of it.

I was like, "Am I implementing this?

Can we not do that?"

>> Yeah, that doesn't sound like a good idea.

>> Yeah. All right.

So like I said, we're joined by Jeff.

You are known in this community for

talking a lot about the view transitions API lately.

So maybe you can give us a background on who you are.

You've been on the podcast before,

but it's always nice to get a little refresher.

>> Yeah, true Svelte radio fans and Svelte Summit watchers.

But no, so yeah, my name is Jeff.

I'm one of the current Svelte maintainers.

Like Kev said, I've been playing a lot with view transitions.

I think I did my first article about them about a year ago,

them being a new and upcoming browser API,

and I just really want to play around with it in SvelteKit.

So I've been using them a lot.

Whenever I tweet about view transitions,

it does very well on Twitter

because people just love seeing them in action.

>> Yeah, it's too bad this is an audio thing.

Where you can't really show the concept.

>> Yeah, hopefully it can convey how cool it is.

But we'll definitely be able to point to

some resources to see them in action,

because yeah, it's a very visual API.

>> Yeah. Cool.

>> Aren't we like recording screens now and showing video?

>> We are. But like most of the people

are realistically going to listen to this, right?

>> It is still a podcast.

>> It is a podcast.

>> Good audio content.

>> Yeah.

>> That's the goal.

>> Yeah. So let's get into it.

What are view transitions?

>> Yeah. So I guess it's important to start out by saying,

so we're going to be talking about the view transitions API,

and this is a browser API.

It's nothing Svelte specific.

So most of what we're going to be talking about today

is the browser API and then also how you can use it

in Svelte and SvelteKit.

But this is a transferable,

you can use this in Vue or React or without a framework at all.

It's going to be just JavaScript and CSS.

So yeah, the view transitions API,

it's a newer API right now only implemented in Chrome-based browsers,

but other browsers have expressed interest.

It essentially simplifies the process of

transitioning between two page states,

which you could do before, but it was tricky.

So if you imagine, I don't know,

if you looked at page transition tutorials and SvelteKit before,

it's like, when I navigate,

I want to fade out the old page and fade in the new page.

You can get this with Svelte transitions or CSS transitions,

but you have to position the old and new pages on

top of each other to make sure it's a smooth fade out.

>> Yeah. I think that's one of the common pitfall.

I think a lot of people end up in,

like they forget that they have to position the page,

the actual page component inside of the same element,

and do a position absolute,

or I guess you could also do grid 1/1 or whatever it's called to do that.

>> Yeah, because it's not very intuitive because you're essentially,

Svelte is holding the old and new pages on the page at the same time,

and you're having to hack around it to force them.

This gets also trickier if you're shared element on the page.

Let's say you have an avatar that you

want to transition to its spot on the new page.

That starts to get tricky,

especially if they're separate elements.

What the View Transitions API aims to do is simplify a lot of this.

Give you a way to tell the browser like,

"Hey, I'm about to do a transition,

capture this old page state,

and then smoothly transition it to the new page state."

By doing that, you just get to remove a lot of code,

doing this yourself or code from a dependency to help coordinate all this.

Just the browser is figuring out how to transition between these two states.

This is obviously, it sounds more powerful than

just CSS animations or CSS transitions.

But also, I guess they're not really aiming to do the same thing.

You would use animations for something else, transitions for,

well, CSS transitions, I guess, they'd be pretty close.

>> Yeah, there's a lot of overlap.

I think one of the cool things about this API is how much it does use CSS.

I believe when they were first working on it,

there was a different way to customize the animations.

Eventually, they were like, "No.

To customize these view transitions,

you just write regular CSS animations."

There's overlap. But yeah,

I would say CSS transitions still have their place on individual elements.

Especially page transitions are really good for

view transitions because of those coordination problems I talked with.

Then also just anything,

if you're familiar with the term flip animation,

or you're moving an element from one place to another,

view transitions also fit really well with that.

You don't have to, because that would be hard to write as a pure CSS animation.

If you're doing something more complicated,

view transitions, you can just,

here's the element, it moved from here to here,

and the browser can figure out how to move it to the new spot.

>> Probably way more efficient as well.

>> Yeah, because you're not having to write.

It's implemented in the browser.

The browser is able to use its lower-level code to make this happen.

It's amazing how we're moving more and more away from using JavaScript for

these things that we've forever really used,

forever really written to do these app-like things.

View transitions allow you to basically write apps that look more native.

>> Yeah, you can recreate some of those native,

going to a new screen, having things move over and out,

those more app-like animations can be possible with view transitions.

Then I guess the other thing,

I think if you've been plugged into the web dev community,

you've noticed Astro recently released some support for

page transitions I was getting a lot of hype to.

I think bringing this page animation stuff to

MPAs that don't use JavaScript for client-side navigation,

is also a huge win,

unlocking these animations regardless of what kind of tech stack you're on.

>> Yeah. How does it work on a more technical level when you implement this?

Do you need support for JavaScript or can you do this without?

>> Right now, you need JavaScript.

The only shipped version of this API is the,

basically you call a document.startViewTransition

to trigger the transition in JavaScript.

You do need JavaScript to use this right now.

They are working on a spec like what does this look like?

If you're doing a full page reload,

I believe something involving meta tags.

>> Interesting.

>> Essentially what it looks like, how you use this is,

when you want to start a transition,

you call document.startViewTransition and you pass it a callback.

Inside that callback, you actually update the page.

If you're in vanilla JavaScript,

maybe you add an element here,

remove an element here,

change these properties all inside the callback.

Then when the callback returns,

the browser will be like, "Okay,

we started in this state,

we're now in this state and I will just

perform the animation between the two states."

>> It doesn't sound-

>> How it actually works is really cool.

Behind the scenes, it's actually taking

essentially a snapshot of the old state and the new state.

Then it's able to use that to animate between them.

That solves the problem we were talking about earlier,

where it's like you have to hack around to have

both page states around and able to mess with it at the same time.

This is the browser, you have

two layers of the old and the new states,

and that's how you're able to animate between them.

It really sounds like a cool API.

I haven't played around with it a lot.

>> It's really cool. It's fun.

It's also very easy to abuse.

I think we're probably going to enter an era of people

just doing these ridiculous time-wasting animations.

>> Just ignoring-

>> But they look really cool.

>> Yeah. Just ignoring reduced motion.

>> Yeah, reduced motion. But even beyond that,

just like, wouldn't it be cool if this animation took

like 600 milliseconds to go to

the new page and got to move all these elements in?

I think there's definitely an experimentation phase

happening right now to try to figure out

what a good view transition is.

But it's very fun. It's very flashy to

show off when you play around with it.

>> How would different routers and

then different rendering affect this?

Can you do this from a server-side rendered route?

>> Yeah. I guess are you asking

more in general or like Spelt Kit specifically?

>> I guess Spelt Kit specifically,

but even if you were running just a node server, I guess.

>> Yeah. Right now, essentially all you need,

remember you call start view transition.

>> Yeah.

>> I need some way of actually

updating the page inside that callback,

or at least some way of waiting for the page to update.

Spelt Kit, we can get into this in a bit,

but Spelt Kit has a new lifecycle hook that lets you say,

you can start the view transition in there and

then await the navigation to complete.

That updates the page and then it completes.

You can start with a server rendered page as long as you have

some way of updating the page client-side

and passing that function into the view transition.

>> You can stick on to the state with something.

>> Yeah. You can do this.

I recommend if you haven't heard about this before,

I had a Svelte Summit talk on this.

You can do this in regular Svelte.

In Svelte, I built a card demo where I was moving

cards between the two different rows.

Whenever I clicked a button to move a card to a new row,

that click handler would call startViewTransition.

Inside the callback, it would update the state,

row2.appendCard, and then it would call awaitTick,

which is Svelte's lifecycle method to say,

"Hey, wait for the DOM to be updated."

That would trigger the view transition because you have a way

to start it before the page has changed,

make the change, wait for it to complete,

and then the view transition ends and the browser

would swap the card from one row to the other.

>> That's a really nice talk, by the way. I liked it.

It's very visual, unlike this podcast.

>> I'm definitely moving my hands all around,

showing where things are positioned,

and it's like right, audio medium.

>> Yeah. It's tough.

When would you not use view transitions?

>> Yeah. This is, again,

a plug for my talk where I compared between,

because if you've gotten this far into the podcast,

you're like, "Wait, we already have Svelte transitions.

How do those compare?

Should I use view transitions for everything?

What's the deal?" I'd say view transitions,

as I mentioned, make a lot of sense for page transitions,

just because those are tricky to do with our current tools.

Then you can also use them for those more flip animations

if you're moving elements around a page,

like in my demo, I was moving a card from one row to the other.

You can use view transitions for that too.

I think they're just trade-offs because you're just going

to be writing these things slightly differently.

For example, with view transitions,

you have to wrap each state update and start view transition.

If you're using a Svelte transition,

it's just like you apply it to the element specifically,

animate flip, and then that will just apply anytime it moves around.

>> That makes sense.

>> View transitions are easier to customize with

CSS media queries because you're

writing your view transition customizations in CSS.

It's really easy to just like-

>> That's a good point.

>> -different screen sizes,

reduced motion, that kind of thing.

>> Yeah. I hadn't thought about that because maybe I

haven't written complicated enough Svelte transitions

to actually run into something like this,

but you could conceivably imagine that you

would need to fly something in from the left if it's on

a mobile screen and then from the top if it's on a desktop or whatever.

>> Right. I think I've also seen some animation best practices.

If you have a really big screen,

if you're moving an element across

that really big screen, that can be really disorienting.

Maybe you do most of your view transitions on

a mobile device when things are going to be moving a lot less.

>> Yeah.

>> Then of course, the headline media query I think would be like

reduced motion is a lot easier to check with this as a media query.

>> Yeah. All right.

Are there other things that we should talk

about when it comes to view transitions in general?

>> I think one thing that I definitely run into as I've played with them.

Let's take a step back with view transitions.

You apply a view transition name if you want that flip animation.

Like I said, let's say you have an avatar on one page.

In CSS, you apply a view transition name avatar.

Then when you start that view transition,

the browser will see, is there something on this new page with

view transition name avatar and know to animate that between the two positions.

Where that gets tricky is like,

let's say my card example where I have a bunch of cards,

they're all doing very similar animations.

However, view transition names need to be unique.

You can't just say view transition name card.

Because then the browser is like, "Okay, I'm in this new state.

There's 10 things with the name card.

I don't know what to move where."

That's where you have to start giving them unique names,

which I have an article about how to do this, it's not too bad.

Where you run into issues if you want to customize.

I want to customize the animation for all the cards,

but there's 52 different unique names for each of those cards.

I have to target all of those in CSS.

>> Yeah.

>> Oh, you have to do it in CSS.

You can't do it in with spell IDs and each loop or something nice.

>> I mean, you essentially can't.

In one of my articles,

I've passed that ID through a CSS variable and then use that to form a transition name.

But the issue there is then you have this dynamic name.

If I want to say, actually,

all these animations should take half a second.

I have to target all of

those view transition pseudo elements essentially individually.

This is another thing where it may make more sense to use spell transitions,

or there's trickier things you can do to

apply the view transition name just in time.

Only one thing has that name.

>> Yeah.

>> But this is where view transitions have their downsides.

There's proposals to iterate on this,

but it's definitely not something you use for every kind of animation in your app.

>> Yeah. One thing to note as well is probably that we can use view transitions today.

>> Yes.

>> Because they're progressively enhanced.

Well, it is a progressive enhancement.

That's probably how you would say it, I guess.

>> Yeah. I think this is a big thing because I feel like every time I post about these,

people are like, "Oh, yeah,

but it's only Chrome, so call me in two years."

>> But that doesn't matter because the page is still going to work just fine with-

>> You can get it.

>> -in the other browsers.

>> Support it.

>> I think it depends on what you're using them for too.

I think definitely a page animation transition, that's newer.

Not everyone needs that.

Actually, I would like to show this to everyone.

>> Right.

>> In that case, maybe view transitions aren't a good fit.

>> Yeah.

>> I wish everything was progressively enhanced.

>> Yeah.

>> Yeah.

>> I want access to so many CSS features that I can't use.

>> Yeah, for sure.

>> At least CSS has been-

>> Oh, it's so much better.

>> -getting a lot better.

>> Yeah.

>> I mean, yeah, for sure.

>> Well, you'll blink and you'll be like,

two years passes like that and it's like,

"Oh, right, I can use this now."

>> Yeah.

>> I don't know, sometimes I still get blindsided by-

>> Container queries?

>> I mean, container queries, yeah.

>> We can use these today.

>> Container queries are one of the things that's like,

it's just not quite there for full support.

>> Yeah.

>> But yeah, just wait a little bit longer, I guess.

>> Yeah.

>> It is very penalizing.

>> Okay. View transitions in a SvelteKit context.

What do you have to do? I think you mentioned it briefly earlier,

but maybe we can go over it again.

>> I covered it at a high level.

But yeah, I guess. There's a new lifecycle method.

Maybe in a bit we can talk about why we

needed a new lifecycle method.

It's called onNavigate.

It's going to fire essentially just before the navigation completes.

Today we have beforeNavigate,

which fires before the navigation even starts.

We have afterNavigate to fire after it's done.

onNavigate will fire after all the data loading for the page has happened,

but before the new page is actually swapped into the DOM.

This, for reasons we can get into,

is a great place to put your startViewTransition callback.

Inside there, you can do document.startViewTransition.

This is where it gets a little tricky to mouth code because you have to return

a promise that resolves and call that inside your view transition callback,

and then wait for the navigation to complete.

Go check out my post on the Svelte blog to see exactly what this is.

>> Yeah, that's hard to describe in words.

>> It is. But essentially you copy-paste this into your root layout,

so it plays on every navigation,

and then you'll get a view transition on

every navigation and you can customize it however you want to.

>> I think I saw a library by,

I think it was Paolo.

>> Yes.

>> He did a library called,

what was it called? SvelteKitViewTransition or something.

I haven't checked it out yet.

>> Something like that.

>> Yeah.

>> Yeah, that's a good call out.

>> I think it's supposed to make this a bit simpler.

But yeah, like I said, I haven't checked it out.

>> Yeah, because I guess we've

intentionally not abstracted this further right away.

We just don't want, it's harder to remove API than to add it.

So we didn't want to rush into,

this is how you interact with view transitions,

leaning on the community to figure out how they want to abstract it.

Yeah, Paolo's library is a great place to start,

adds a lot of helpers for both for

adding this snippet I just tried to talk about.

>> Yeah.

>> But also as I made more complicated view transition demos,

there's things you have to do like adding

view transition names at certain times,

adding classes to the root of the DOM so that you can,

for instance, show a different animation when you're navigating back.

His library just gives you all these hooks to do what you need to

do that you would have to implement yourself without this library.

So definitely worth looking into if you're going

to be doing stuff with view transitions.

>> Yeah. So we'll put that in the show notes, of course.

So yeah, that's all you have to do in Kit,

I guess, to actually get it working.

>> Yeah, just one snippet and then,

like you said, no abstraction,

then the API you need to learn is the view transitions API.

I feel like I bring this up every time I talk about this,

but Jake Archibald's explainer on the Chrome developers,

we can add that link to the show notes,

but that is very thorough link at everything you can do with view transitions.

Because SvelteKit is not wrapping this in any way,

you have raw access to the view transition,

you can do whatever you need to do.

So any of those techniques,

you should be able to figure out how you want to tackle them.

>> You get the building blocks,

like with this new Svelte 5 thing that they released,

the ruins, also the building blocks, right?

>> Yeah. Or I guess maybe a closer analogy is like SvelteKit forms,

we provide some helpers on top of that,

but it's like you're using forms.

How do you submit this data?

You put in input, hidden inputs,

you can attach things to the submit button,

you're learning the browser as you work with SvelteKit.

>> Now, that's a way better comparison.

>> Yeah. I don't really want to get sucked into a ruins discussion.

I'm sure you need a whole episode about that.

>> Yeah. Definitely.

>> I guess one thing I want to touch on,

like I mentioned, is why this was

only really possible because we had a new SvelteKit lifecycle method.

It gets a little bit into the weeds,

but personally, I've been doing

these experiments since before that method landed,

and there were some limitations.

I think the biggest one is

that when you only had before and after navigate,

you could kick off the view transition and before navigate.

But one thing I didn't mention about view transitions is when you

start it, it freezes the page essentially.

Because all of a sudden your page is like a static view.

>> Right.

>> That's why the recommendation is finish

the view transition as quickly as possible.

>> Yeah.

>> Well, if you kick it off and before

navigate and data loading still needs to happen,

and your API is taking a second or two,

you're essentially leaving the user with

a non-responsive page for a couple of seconds.

>> Right.

>> With onNavigate, because it fires right after data loading has finished,

we can resolve the view transition as quickly as

possible and essentially fire it just in time.

>> That's good.

>> Then the other thing is I ran into tons of race conditions

because the view transitions API is asynchronous,

and before and after navigate need to run synchronously.

You're just running some code.

Even kicking it off and before navigate without the data loading issue,

sometimes it wouldn't start soon enough

and SpeltKit would have already transitioned the page.

I ran into some weird stuff with preloading.

>> It's pretty hairy.

>> We're actually able to tell SpeltKit,

"Hey, wait to finish the navigation.

We're starting a view transition."

I haven't run into any race conditions after that.

It's just a lot more stable foundation to integrate on.

>> Yeah. This new lifecycle method onNavigate,

can it be used for anything else or is it just for-

>> Theoretically, I think it's very much a target.

It's written onNavigate.

It's not like kickoff view transition.

It's very intentionally written as a generic entry point.

I think there is one other issue linked that it could have been useful for.

I forget what it was.

>> Yeah. I was like, what else would you want to do on navigation?

>> I don't know.

>> There was something it links.

>> Send off some events for tracking people.

But you can do that anywhere else.

>> Analytics. There's got to be authentication.

But you would do all of that on the server.

>> Okay. There's an open issue around access to history state

linked in the view transitions issue.

I can just post it in the chat.

But the user might scroll or interact

with form elements while the navigation is in progress.

Maybe we need a way to write to

state immediately before the navigation is committed.

I don't know what that's about.

I haven't re-read this issue.

But there are theoretically other uses for

doing something right before the navigation finishes.

>> Yeah.

>> But the headline feature of this lifecycle is view transitions.

>> View transitions. Yeah.

>> I think it's unique. I think other frameworks are having to add similar hooks.

It's not just felt kit that had to add something directly into this place.

>> Yeah.

>> It's like I think next needs something similar for instance.

>> Astro probably has some wrapper around their version.

>> Yeah. Well, I think Astro had to implement some basic

client-side routing to get this in the first place.

>> That makes sense. Yeah.

>> Because it's SPA only right now.

Eventually, it'll be MPA as well.

>> Yeah. With the meta tags thing that you mentioned.

>> Yeah. That'd be cool to get that for non-JavaScript pages as well.

That'd be really cool.

>> Yeah. It'd be really impactful.

I know a lot of people are being like,

"This will finally kill SPAs."

That part is probably overblown.

It is cool when you can enable capabilities for, again,

regardless of your tech stack,

you're able to use this because it is something a lot of people want.

>> Yeah. Then last, I think we all had the question,

but I think you already answered it.

You can use it in Svelte,

regular Svelte as well.

You had to talk about that.

What kind of stuff did you run into in just using it for Svelte?

Did you use a router or did you just bring in some random router?

What was the-

>> Well, because the demo I used didn't involve routing.

I think that's the other thing I think I've mentioned,

but to highlight about this API is,

you don't need to route, it's any page change.

In Svelte, I built a card demo and I was just swapping

cards between positions.

I think the one thing I ran into Svelte that wasn't quite as nice is

every state update has to be wrapped and start view transition.

If you want it to trigger a transition.

>> Okay.

>> Part of that is because there's not as nice a spot

to like SvelteKit has onNavigate.

Svelte doesn't have a spot where you can say,

every time state changes, start a view transition.

I don't know for sure you'd want that,

but that would simplify demos like that.

You can create a little helper and be like,

view transition and wrap that around all your event handlers.

But that's where it's a little bit more verbose

than the Svelte transition version of that demo would have been.

>> Yeah. That makes sense.

>> But you guys are probably familiar with Jay on

Twitter who does all these code pens.

He's been playing around with the view transitions API.

First, very similar things where you want-

>> Who is this? Jay?

>> It's Jay H3Y or might be-

>> Jay H3Y.

>> It might be two Ys.

>> Two Ys.

>> Sometimes.

>> I'll put it in the chat.

He's been doing a very similar thing where like

playing around with the view transitions API,

but for these, you're not navigating anywhere.

You're just adding animation to a single page demo.

I think that's going to be just fun to see people play around with.

It's nice that you don't have to bring in a heavy animation library.

If you just want to do a vanilla JavaScript thing like this,

you can just use tools.

>> This is Jay Bear right here.

>> You probably can't see that.

>> No.

>> It's like a holographic Jay Bear.

>> Well, it's okay. The listeners can't see anyway.

>> Any other things that you want to mention with view transitions

or should we move on to the scariest section of the show?

>> Yeah. I mean, I guess the last.

I'm actually prepared for the scary section.

>> Nobody's going to have one today.

>> No, I'm good. I guess to reiterate,

not everyone can view animation.

It can trigger some nausea in people.

If you're building with this API, be very careful.

If you're moving things around the screen a lot,

look into prefers reduced motion,

maybe disable the animation in that case.

But as people are fond of saying,

reduced motion does not mean no motion.

In the SvelteKit announcement blog post,

I actually had a little snippet showing,

reduced motion is enabled just to

a crossfade between pages because that's not any motion.

Instead of the slide we get when reduced motion is not asked for.

I just want to reiterate and use this responsibly.

Especially if you're shipping it to production,

demos can go as crazy as you want,

but make sure you're making a good user experience.

>> Good user experience doesn't

mean just things flying all over the screen.

>> I mean, I always thought too, it's like,

we can make things fly now?

That's so cool. Let me make everything fly.

>> Does it mean drop downs with carousels inside of them?

>> View transition powered carousel.

>> I say drop down, it was like an accordion.

At least it stayed open.

Honestly, it didn't look bad.

It looked good and functional,

but implementing that would be a nightmare.

>> If only you could use view transitions for this.

I wonder if you could.

>> I think I can use regular transitions for that,

because it's not changing a page.

>> Yeah, but I wonder if you could apply

the view transitions API to components or switchers somehow.

But you would have to,

do you need the browser history or is this completely separate?

Well, I mean, since it's taking a screenshot

of the page before and after,

is there something the browser needs to know

that it's on a new page or a new view,

or is that all done in JavaScript?

I'm just confused with how other browsers.

>> Yeah, you might be confused.

>> Probably. I just feel like the browser needs to track it somehow.

>> I mean, just whatever interaction you want to trigger it,

you just call start view transition and it updates that.

>> Right. Yeah.

>> I'm just confused.

>> If your component or whatever you want the transition to be on,

is on the same page and not leaving that page state,

you would just use a normal Svelte transition or

CSS animation transition like anything that's built in.

Because you don't need that state.

>> But couldn't the Svelte transitions at

some point be remade into view transitions?

>> I've actually thought about that.

>> Yeah. Let's hear it.

>> I think there's something to do there.

I think there's something you could do with

view transitions as an action that would be

interesting to automatically generate those view transition names and stuff like that.

>> Yeah.

>> I'm not sure transitions can be replaced with them.

>> Just add it to Paolo's library.

>> I think he actually has an action called transition.

Yeah. So you just put use transition and then header.

>> But yeah, I think again, another limitation,

you only have one view transition happening at once,

whereas that's not really true for Svelte transitions.

>> But I guess you could still do multiple things at the same time, right?

Like move multiple things.

>> I click on the page, five different buttons.

Those all start a Reuven element triggering a Svelte transition.

>> Yeah.

>> That wouldn't work with view transitions.

>> Yeah. Okay. Got you.

>> I think another tool in your toolbox,

where web devs we like to be like,

what can I use this on?

Can I use this on everything?

>> Yes. The answer is always yes.

Always, yeah. Trade-offs and right tool for the job.

>> Yeah. Cool. You had something prepared here for this next session.

We're moving on to the unpopular opinions section.

Anthony isn't here. He always has an unpopular opinion.

>> He's always ready.

>> I don't have one. I almost never have one.

I'm bad at the unpopular.

Actually, I might have one today.

But let's hear it from you first, Jeff.

What's your opinion?

>> My unpopular opinion is you shouldn't be writing

ARIA attributes if you aren't testing with a screen reader.

>> Interesting.

>> I think there's probably caveats to that.

>> What is your recommended screen reader?

>> What operating system are you on?

>> Mac at work.

>> I probably start with VoiceOver.

>> The VoiceOver? Then what would you use on Windows?

>> Windows NVDA.

>> N-V-D-A.

>> N as in night, V-D-A.

I guess that's not confusing.

>> It's NVIDIA with a healthy I.

>> Yeah. It's NVIDIA's stock ticket.

>> Yes.

>> NVDA.

>> Okay.

>> But I guess let me give some background on this.

If you don't know ARIA attributes are used

to expose additional information

to screen readers and other assistive technology,

maybe a common one is like ARIA label.

If you have a button with an icon in it,

that button needs some text associated with it.

If a screen reader comes to it,

it knows, "Oh, this means remove."

One way of exposing that information to the screen reader if

that text is not inside the button is adding an ARIA label equals remove.

But the reason I think you should be testing with

the screen reader if you're writing these attributes is because it's

way too easy to either misuse them or make

assumptions about how they work and then not test them and be like,

"Oh, this is actually either not doing anything,

best case or worst case,

making things worse and confusing."

I think the analogy I draw,

you wouldn't write a bunch of JavaScript code and just ship it.

Well, maybe you would.

>> Wouldn't you though?

>> But write interactions on a web page and be like, "Yeah,

I don't need to test that out. It probably works fine."

>> Right. Yeah.

>> Similar with you're writing all these attributes that are only for

screen readers and be like, "Yeah,

that's probably fine," without verifying that yourself.

Once you get good enough,

I've tested with screen readers before,

I'm pretty sure I know where an ARIA label is valid and what it's going to do.

In that case, yeah, I'll just throw the song because I know it works.

But if you're starting out,

making sure that you know what you're doing.

>> Yeah. Don't stick it on everything.

>> Yeah. One of the rules is no ARIA is better than bad ARIA.

>> Yeah.

>> Don't stick it on if you're not willing to do the work to figure out,

is this actually doing what I think it's going to do?

>> I also find ARIA in general can be confusing.

There are confusing documentation out there.

Even if you go to the W3C and look at

what you're supposed to do for accessibility for some things,

it's not always straightforward and it's not always explicit,

like this is the right thing to do.

>> There's a lot of nuance.

>> Yes and no, like this case and this case.

It's very hard.

>> I bet you're especially running into a lot of that with building components.

>> Yeah.

>> Like building a design system.

It's like, "Oh, I'm the one who has to make

an accessible drop-down carousel."

>> Yeah.

>> I have a question about this because I haven't really tried this,

but I've heard and read that different screen readers do things differently.

So how do you actually make sure that they work for all of them?

Is that possible or do they differ so little that it's just small things that don't work?

>> There are significant differences.

>> How fun.

>> But I think that's where I try not to start with,

and you should be testing in multiple screen readers.

Because a lot of time just getting people to use one really helps.

>> Makes sense.

>> I think it is a good call and you should recognize,

try not to over-optimize.

You start with voiceover.

I'm going to make this exactly tuned to voiceover's quirks.

>> Right.

>> Might get you into trouble.

But yeah, I don't know. You can find a lot of,

there are some very dedicated accessibility testers who are like,

"Here's all the differences.

I tested the screen reader and

browser combinations and here's how these ARIA attributes behave."

>> I tried to vouch to get somebody that was just specifically for accessibility on my team.

I'm the only engineer.

I have one designer and I'm the only engineer.

It's just accessibility is a full-time job, I feel like.

>> Yeah.

>> You need somebody that can just test and do that kind of stuff.

We are using an open-source library that has accessibility testing built-in.

I don't know that I trust them to fully do all of that perfectly,

but I at least feel like the burden is not fully on me.

But I still like make sure that things work correctly to the best of my ability,

and look them up, and make sure things are done correctly according to W3C.

But I watched a video last night and they're like,

"We always get it wrong.

Is it WC3 or W3C?

We always mix up. Which one is W3C?"

>> I think it's W3C.

>> Okay. I was saying it right.

Now I think the video has made me say it.

It's funny.

>> I think definitely if you're able to get

the resources to have someone dedicated to testing this stuff,

especially, there's so far down the rabbit hole you can go.

So it's a balance because I think also accessibility is everyone's responsibility,

but competing priorities,

and you can go really deep.

It's hard to know if we built something more accessible,

maybe we would get more users because they're actually

able to do the things they want to do.

Who are we excluding unintentionally?

>> Yeah. I think that's absolutely correct.

>> But yeah, don't use ARIA attributes if you're not using the screen reader.

Like I've said before, if you know nothing about accessibility,

start by running like AXE DevTools on your page that will catch low-hanging fruit.

Make sure you can tap around and use the page without a mouse,

and then learn how to use a screen reader.

Those will just get you so far,

just getting some baseline accessibility in there.

>> I feel like for a lot of pages that are just content-based,

it's not super tricky to get it working.

It's mostly for more interactive SPA style applications.

That's when it gets really,

really hard I think.

>> Yeah. I think there's definitely types of applications,

but I don't know how I'd make that accessible.

I'm sure there's people who've done it.

>> Right.

>> I'm sure there's ways to do it,

but it's outside of what I focused on before.

Stuff like, I don't know, if you've used

Excalidraw where you're drawing flow charts and stuff.

>> Okay. Brittany, do you have an unpopular opinion?

>> No.

>> I don't think so.

>> Okay.

>> Only popular opinions.

>> I have one. Maybe it's not unpopular,

but I'm going to say this.

Limitations are probably good in

the sense that you don't

want multiple ways of doing the same thing.

I think that can result in fractures in,

for example, a framework,

not a community, but like an ecosystem.

I'm just talking generally.

>> I'm not talking about anything specific at all.

>> No, I'm really not though.

Just like if you have six or 10 different ways of doing

something then everyone has to know all of

these six to 10 different ways

because you can always encounter them.

So I feel like that limitations are good.

Maybe that's not unpopular though.

>> Limitations to doing things inside frameworks?

>> Yeah. It could be, for example,

like the Vue 3 is an example

where you can do things in a lot of different ways.

I'm not an expert on Vue,

but this is from what I've heard.

It's not weird that they ended up in

this place where you can do things in multiple ways,

but it's created this split between Vue 2 and Vue 3.

So I don't know.

I feel like that's not good in the long run.

But then how would you make changes?

>> It's a trade-off, right?

>> Oh, of course.

>> I'm reading the trade-off.

>> Yeah.

>> But yeah.

>> But yeah, I prefer to

only have the one blessed way of doing something.

You can have the other ways,

but only if you have to go through multiple hoops,

making it really cumbersome and tiring to do it.

That's my unpopular opinion.

>> Yeah, I think it's a balance, right?

Because only one way to do things,

great for learning, great for consistency,

like you can jump into a project.

I know how this works because it's how you do things.

I mean, I have a React code base at work.

>> How fun.

>> Yeah. I mean, I don't mind React.

That's a different, maybe unpopular opinion.

>> At least here.

>> They are very devoted to backwards compatibility,

which has been great for them

because you're able to keep upgrading your application and not be like,

"Oh, we have to rewrite all our class code to hooks."

But then at the cost of consistency,

and you might have one code written one way and one code written another,

and especially as people are coming up,

if they're only taught to use a certain API,

and it's like, "How does this work?"

>> We have a whole app still on classes.

>> Yeah.

>> I think they're pretty common.

>> But like if React did a full break to just hooks is the only thing supported,

that app would probably still be on classes and they just wouldn't.

>> No, because we also still have AngularJS in our code base.

>> Yeah, so do we. I think this thing is probably more common.

>> Yeah. I mean, you can go both ways with it.

I don't think it matters. They're just trade-offs.

>> I think it is good when a framework has an opinion.

>> That's the point of a framework, their opinion.

>> But of course, any framework gets to a point where it's like, "Okay,

do we change our opinion or do we have two opinions?"

>> React is a framework, not a library.

There's my unpopular opinion.

>> Uh-oh.

>> I'm not even going to put that in the show notes.

>> I don't think you're going to get much pushback on this podcast.

>> Maybe this segment should just be opinions.

>> Probably.

>> Just opinions.

>> Yeah.

>> Give me an opinion.

>> They're not very unpopular anymore.

>> Well, Brittany, since you didn't have an opinion, let's do a pick.

Do you have one?

>> Are there picks?

>> Did I put you on the spot here?

>> I don't know.

>> I think so.

>> I've been using Flowbyte as the open-source library that we've been using.

I really like Flowbyte,

but its underlying thing is Tailwind,

which people love to love or hate.

I don't know, it has made the developer experience

so much better compared to what we had before.

There's also this thing that I did not know about,

and maybe one of you know what it is.

You can put a comment in your Svelte markup or wherever in

your Svelte component and do @component,

and then start writing documentation,

and it gives you intellisense for that.

What parses that and does that?

>> I think that's built into the Svelte language tools or the extension.

>> Is that the Svelte extension?

>> I think so.

>> I just never knew about it because I like-

>> Yeah.

>> It is incredible.

>> I found the FAQ entry.

It's not super well documented.

>> Maybe we should do a stream about it,

so more people can learn about it because it is nice.

I rarely use it.

>> I have a front-end guild that we do for the design system,

and I showed them this today,

and they're like, "Oh, can we start using that in our code base?"

I'm like, "I actually don't know what parses is,"

because I'm like, "That's markdown.

Why is there markdown?"

I'm like, "We don't have a markdown thing in Svelte.

What is reading this?"

Then I started thinking about it.

I'm like, "Wait a minute."

>> Yeah. It looks like it's any editors that use

the Svelte language server should be able to interpret it.

>> Yeah, that's right.

>> So VS Code, obviously.

>> Okay. So the Svelte language server

and the extension is what does it?

>> No extension.

>> The extension is what integrates with the language server.

>> Okay.

>> So I think there's other editors that have

their own extensions that also use the language server.

>> It is so cool. That's my pick.

>> It's really nice.

>> That's a good pick.

>> That's a super good pick.

I don't know if I can even compete.

>> Sorry.

>> Jeff, go ahead.

>> Okay. My pick is the Wheel of Time Season 2.

>> I just picked that.

>> Maybe it's not out yet.

Your episode wasn't out yet.

>> No, you picked Silo.

>> I've watched the whole thing now.

I think I picked it a couple of episodes ago.

>> Season 2 is still airing.

>> Yeah. I think, aren't you talking about Silo?

>> I was talking about Silo too,

but did I not pick Wheel of Time?

Maybe it was on Coding Cat. I do too many podcasts.

>> Could have been.

>> I don't know.

>> Too many podcasts.

>> Yeah. Okay.

>> But yeah, so the Wheel of Time Season 2,

Amazon Fantasy show,

I enjoyed Season 1,

but I think the ending got a little screwed up,

especially with COVID stuff and they lost an actor.

>> Yeah.

>> But I've been really enjoying Season 2.

I think just everything stepped up a level.

>> To me, this is a really controversial opinion.

Because I really do not like the show.

>> Yeah. I feel like I remember you talking about it.

>> Yeah. Have you read the books?

>> Yeah.

>> Okay.

>> I'm the kind of person who's

fascinated by how people adapt something.

>> Okay. Yeah. To me,

it's probably because I read the books semi-recently.

So it's all like everything happens in the wrong order for me.

It's, I don't know.

>> Are the episodes still coming out though?

I thought the season 2 were over.

>> Yeah. It's not done.

>> Oh.

>> Yes. It's still coming out. Yeah.

>> Because it's getting good now.

>> It is definitely getting better.

>> Yeah. We were talking about it though,

because you were just talking about the books again.

>> Yeah.

>> I know Kevin went off on this rant last time.

>> But yeah, it is good.

>> I can get how people wouldn't like the adaptation choices.

To me, it's just interesting. How do you take

a thousand pages or more than that?

>> Ten books.

>> What works on the page doesn't work on the screen,

visuals versus text.

Essentially, how are they remixing it?

I think I'm going to be especially interested

as they hopefully get to continue.

Because I remember some of the middle books being a little slow and

very interesting how they're going to speed through.

>> The famed slog.

>> The slog.

>> I think it's called. Yeah.

>> So yeah, I've been really enjoying that.

>> Yeah. No, I've been enjoying it as well,

even though I don't like the way they've done it.

>> I'm sorry.

>> I'm a super fantasy fan,

so I just have to watch it.

I had to watch The Witcher as well,

even though I didn't like it.

>> I haven't read those books either.

I started to read The Will of Time books,

and I think I got a couple of chapters in.

I just couldn't get into the books. I don't know why.

>> Yeah. So the way he writes,

it's very descriptive.

Things take a very long time to progress sometimes.

>> It's like Lord of the Rings descriptive.

>> Yeah, except there's 14 books.

>> I love The Hobbit, but then I got to Lord of the Rings,

and I'm like, it took me a very long time to finish Lord of the Rings.

I just couldn't.

>> Yeah.

>> It took me a while to read the books.

I'm also like, I can't really binge a series.

So I'd read a book,

and then I take a few months off,

and then read the next one.

But I do wonder how this,

I guess, Brittany, it sounds like you're enjoying it.

Because it feels like there's some world-building stuff where I'm like,

I don't know if you'd entirely,

if there's stuff you're missing if you're not super familiar with the books.

>> Because the world is huge as well.

>> Then they just randomly introduce someone from, I don't know.

I'm just going to take a deep breath.

>> You just got to be along for the ride.

>> Yeah.

>> It's an adaptation.

>> I read those books.

So I think I would probably get into it if I just spent the time to get invested.

>> Then you're three books and you're like,

well, I have to keep reading.

>> Yes.

>> I've already read 3,000 pages.

>> Only seven more to go.

No, but definitely read it.

If you get past, I think,

maybe the first half of the first book.

>> Okay.

>> I've heard people have better luck with the audiobook sometimes too,

because that would just push you through.

>> Yeah, exactly.

>> You'll love it. There's just some boring parts.

>> I think I didn't know enough of the characters.

So you need to get invested in some of the characters in the first part,

and then you have to introduce you to everybody,

and that's the part that's boring to me.

>> Well, it could be now that you've seen the show,

it's like you have some of that investment.

>> Yeah.

>> Yeah. Only they're not the same character.

No.

>> Yeah, it's different.

>> Let's move on.

Or rather, I'll do a pick.

>> My pick is The Wheel of Time books.

>> No, my pick is a series called The Winter King.

It is, I think,

based in the UK somewhere,

and it's like a spin on the Arthur story,

kind of, if that makes sense.

It's pretty good. I've been enjoying it.

Just came out, started airing a couple of weeks ago.

>> What's it on?

>> That is a good question. I do not know.

>> I've never heard of it.

>> Yeah, but it probably differs from Sweden.

>> So it's not like a streaming service. It's not Netflix.

>> I think it is.

>> According to Wikipedia, it's on MGM Plus,

which is a streaming service.

>> There you go.

>> I didn't know that existed.

>> Oh, yeah.

>> I had no idea.

>> They just keep popping up.

>> Yeah.

>> Yeah, and they're going to die out,

I think, at some point.

>> Disney is going to take them all.

>> Unpopular opinion right there.

>> All right. I think that's it for the show.

Jeff, thanks for joining us again.

>> Yeah, it was great to be back.

>> Awesome talking about the Vue Transitions API.

We chatted about this,

I think one or two weeks ago,

and we really had no idea what we were talking about,

I think, or at least I didn't.

I was wildly guessing things that I thought I remembered.

>> Well, good content either way.

>> Yeah, exactly.

Yeah. So thank you again,

and thanks to all the listeners.

Before we go, Jeff, where can people find you? Of course.

>> Yeah. The best place to find me is on my website.

That's jeffrich.net, G-E-O-F-F-R-I-C-H.net.

My link there pointing you to wherever you can find me on social media,

so still on Twitter,

and also Mastodon are the ones I'm mainly posting on.

I have, if you haven't read my work before,

I have a ton of blog posts on Svelte and SvelteKit,

bunch of stuff about Vue Transitions that might be worth a read.

>> Awesome. All right.

Thanks everyone, and we will see,

and we will not see you,

you will see us next week and maybe hear us next week. Bye-bye.

>> Hey, it's Kavir.

If you like the show, please drop a review on your favorite podcast player.

It would help out a lot. Thanks.

[BLANK_AUDIO]