Choosing Wisely: SPA vs. HTMX for Your Next Web Project with Chris May

Speaker 1: Thank you again for the wonderful applause. I'm excited to be here. Um Last year? Well, it doesn't seem like it. Oh, there it goes. I was here last year and I introduced it working or not. It is working. Thank you very much. I appreciate it. I introduced many to the idea that you could have a spa-like experience with Django using tools other than Spa , tools that you normally use for a spa framework, like HTMX. And I'm honestly excited I get to be back here to answer some of the questions that came up. The most common one was, well, when would I want to use HTMX versus a SPA? And so yeah, I'm I'm excited to talk. But I just learned from our keynote speaker that I should start with a question to prime

Speaker 1: the audience to make sure you're good for learning. So thank you, Sheena. So I wanted to ask. First off, are you using a spa? And if so, what would make you change? When do you think you should use a spa? What tools are your favorite tools and are you using them well? I asked this because You know, the SPA pattern, HTMX, these are, we use tools to make these different patterns. And they're literally they are just tools. They are things that we leverage to help ourselves and our teammates accomplish our goals. But sometimes certain teams may look inside their toolbox and they may see just hammers

Speaker 1: Or maybe they have a variety of tools, but they've been taught how they're used how to use their tools in a suboptimal way. And so I wonder this is something I think about a lot as I'm interacting with a number of teams. And I've come to the conclusion that Many times we are we take on tools, but we may not really think about how to use them well. And one way many of us use our tools is to make a single-page application. It is the common way of making applications today, by far the most common, but many people in the industry are concerned about the overuse of this pattern. For example, the large consultancy company ThoughtWorks, they regularly experiment with new tools, patterns, architectural patterns.

Speaker 1: Philosophies, a number of different ways. They constantly experiment on their projects and they share their insights on a quarterly basis. And they have said that the single-page application pattern incurs complexity that teams blindly accept by default, even when business needs don't justify it. Furthermore, they say that some people aren't even aware of an alternative approach because they've spent their entire career in a framework like React, one tool. Adding to this discussion is one of their most respected voices in web development, Alex Russell. He built one of the first JavaScript frameworks that many people used to get things done on the web. And he was hired by Google to work on the Chrome team.

Speaker 1: He's now shifted to Microsoft and is working on Edge, but he's passionate on helping us to make great web apps. with exceptional user experiences. And as somebody who works on the browsers that we use, he's in a great position to help us know how to do this. And he has said that the single single-page application pattern promised better user experiences, but has utterly failed to deliver on this. These stacks have proven to be expensive duds. And why is that? One weakness of the pattern is that when a user goes to a page that is powered by a single page application, They download what little HTML there is, they download CSS, and then the browser has to download a custom JavaScript application.

Speaker 1: And once it downloads, it needs to uncompress it, parse it, initialize it, and then it can run in memory. But that's just the application shell. Once that's loaded, it needs to reach out to get the data that you're that you're going to be working on. And so it reaches out through JSON uh APIs. And gets the data. And once it's there, then the app is up and running and you can interact with it And this is the com when I use the web, this is very much the experience I see. A lot of spinners, a lot of time waiting for things to happen. And it's very suboptimal. Now I want to make it clear, this is not a talk that's against JavaScript.

Speaker 1: JavaScript is an important part of the web. It empowers us to do everything, really. But the spirit with which I want you to hear this talk is that this is a talk about patterns. What works well, what doesn't, and when. Because every pattern works well in certain situations. And as I've done my research and as I've interacted with many teams, I found. A couple patterns that are working really well and are emerging to help teams get more done quicker. But before I get there, allow me to introduce myself. My name is Chris May. I am a Python technical coach. My website is everydaysuperpowers. com. dev, excuse me. It just rolls off the tongue. And I have the privilege of being able to join teams, come alongside them, and teach them and help them to

Speaker 1: help their users and their fellow developers fall into success and help them have fun along the way. I have made many single-page applications. I started building websites back in 1995. My first single-page app was built in Backbone. js back in roughly 2009-2008. And I've used many of the tools that a lot of us use throughout the web. And so I know you know I've done a lot of research. This is something I've been really interested in in because I love exceptional user experiences and I want to give you tools that could do that and patterns to do that. So, this is what I plan to talk about for the rest of the talk. And we're going to start off with the three options you have when you're making a web app.

Speaker 1: The first option is a static HTML web app. In this case, if you want, if the user wants new data, they're going to have to either load a new page or re or refresh the page they're currently on. Next, we have a progressively enhanced web app where you can leverage Ajax and JavaScript to update parts of the app. And then you have a single page app, which can enable you to do things like optimistic commits. There are two main criteria that are going to limit or to kind of help you figure out what is the best option for your app. The first is where is the data located that you want to that you're going to need to work on? If it's on the server side, you're going to need to say more to the left side of this chart.

Speaker 1: But if it's on the client side, in the browser, on the user's machine, you can move more to the other side. Secondly, is how long is the user going to use your app? Again, if it's a short session, you're going to need to stay more towards the left side. But if a user is going to be on your website for a long time, you can get over that initial penalty that the single-page application uses or is inherent in its pattern. And you can be more towards the right side. Based on these two metrics alone, the vast majority of web apps should be progressively enhanced web applications. Now if you're not familiar with the term progressively enhancement, and I should even pause, as I've come to many teams, I've noticed

Speaker 1: that terms morph And so uh I've been surprised like one of the teams I've joined recently, uh not a big story, but like essentially I I understand uh a term a specific way, and the team understands it a very different way. So let me be clear that Progressive enhancement essentially boiled down means your page, the website works when JavaScript isn't present. And this is either because the user is downloading the JavaScript file, or they may have disabled JavaScript. But as JavaScript scripts are downloaded and initialized, then it enhances the experience. A good example of this would be like type ahead search.

Speaker 1: If no JavaScript is present, you should be able, the user should still be able to type in a search term, hit submit, and Do a search, perform a search. But if JavaScript is there, it can give you suggestions as for terms to search for. So those are your three options when you come to create a web app. Because of the popularity of spaz. And just in case you feel like you are more on the right side in the scale that I presented, I want to kind of focus in on SPAS and really speak to some of the reasons why I want I suggest you limit the uses of SPAS. For Alex Russell, as we talked about earlier, said that any system that puts JavaScript in the critical path

Speaker 1: starts off at a disadvantage. This is because JavaScript costs three times more in processing power, byte for byte, than HTML and CSS. And it removes the browser's ability to optimize page loading. When you use JavaScript, you pay a performance tax of no less than four times. Because first you need to download the JavaScript. itself. You usually need to de-unpress it. You need to compile it and parse it, then compile it, and executing it. And as a part of executing it, you have to pay a memory cost for it to live in the browser's memory. A browser also is limited because its main thread is responsible for handling user input, calculation, style calculation, layout, and painting.

Speaker 1: And if we're clogging it up with a bunch of JavaScript, The main thread has no chance to do these things in a timely manner. This leads to l uh input lag and jank, as we'll see in a minute. But all that to say is there are plenty of times when spas could be worth their wait. And Alex Russell, I think, has some three great questions you can ask to kind of distill down: like, is this a great uh chance for it? The first is, does your app interact with the same subset of data roughly 20 times? The thought behind this is kind of the combination of the two things I said above uh in the chart. Is there a long session where the initial performance hit pays off? And

Speaker 1: two, is the data is there one group of data that you're able to interact with constantly? Two Does the UI require features that naturally create long-lived sessions, like say chats or video conferencing? And is that the primary purpose of your app? And third, is there a reason why you can't progressively enhance the experience? Are you writing a game? Are you doing video editing, audio editing, uh, any kind of like massive document editing? These kind of things occasionally may be progressively enhanced, but could be a significant challenge, in which case, yes, the spa is a great fit. So

Speaker 1: now that I've focus on spas, I really want to reach touch on something that ThoughtWork said and actually Alex says a lot too is complexity. Because no matter your choice, complexity kills projects. Alex said that a massive investment in controlling complexity is the only way to scale a JavaScript front end. And this is especially true for a single page application because as we're developing the single-page application, we tend to grow the bundle size without check. And you can easily tip over into across a threshold into a point where it's a bad user experience on slow devices. Especially because I mean how many of us have slow devices that we check as we're developing?

Speaker 1: One, two, okay, a handful. Nice. That's it. Excellent. I mean you guys get star points because You know, we have fast laptops, we have fast phones usually, you know, tablets, but there's a whole class of people who are on old phones. Who have to use our web apps. And if we don't get their experience, we're missing out. Especially, you know, many of us think about a you know the average experience of somebody, but If you think about people who are having like a 90th percentile, like slow connection, slow-powered machine, like this is the people that we want to delight. Because if we can take care of them, then the fast people are just going to have an even better time. The other issue about uh

Speaker 1: one about this is that once we reach that cross that threshold where we're giving a less a bad user experience. Any new feature we need to add to our web app is now in tension with every other feature that's there because we just keep building more and more and more. This um the initial performance hit, the use initial user experience hit of the single-page application is actually not a surprise to front-end developers. or I should say the people who are creating the tools that enable the single-page application pattern. And over the last five or so years, they've Had a new strategy to try to help cope with that.

Speaker 1: And they've actually decided we're going to reach out to the server side and use server-rendered components. And they've come up with multiple strategies to incorporate that. And honestly, when I when this talk was uh accepted, I was so excited because I had been learning about these things, but I really wanted to deep dive deep and understand like when are these going to be worth their wait? How are these views best? And as I watched the videos and looked at the tutorials about these, all I saw was more complexity. Because you know when you're rendering a component, you have to think, okay, what where am I? Am I on the server or am I on for on the front end? And you know, there's just more code splitting or more paths you have to go to. And it, I'm just like I quickly realized this is not a great solution, especially for us who do not control JavaScript on the front end and back

Speaker 1: end This wasn't just me who came to this conclusion. There was a developer named Katie Seiler-Miller who saw this a similar issue, and she proposed a new pattern that a lot of people love, and I think it's a really good idea. It's called the component island pattern. And the way this works is when a user visits a website, the server renders a static HTML page and sends it down to the browser. This static HTML page has slots for dynamic widgets, and each widget will render a static version of itself and kind of be included in the HTML HTML that gets sent down. It also sends down the JavaScript for each component. And each component is independent, so

Speaker 1: when the JavaScript initializes, then it you know empowers that component and they can do different things. Unlike spas, and I think this is the key thing that she realized, is like if you the spas have one root HTML, oh I'm sorry, JavaScript component that has to control everything. And so everything needs to be initialized before the whole app can be initialized. And so without that one root JavaScript component, it drastically reduces complexity. In a way, it almost seems countercultural because you think splitting up a single-page application into individual components can actually reduce complexity. And this is because the browser can handle so much. Especially 10 years ago

Speaker 1: when spas happened, like the browsers have made incredible changes. I mean, even not even needing going to the browser first. Let's just talk about routing. If you have the browser and the server control routing, that's a whole lot of JavaScript you can remove. If you have uh JavaScript that tries to remember your your scroll position, the your user's scroll position, so if you hit the back button and know that they can tell it where it to the user is. It's more JavaScript you don't need because the browser can do that. There are great cool things like CSS view transitions, which make incredible um transitions when you're loading a new page. that just in CSS you can have incredible transitions and it's available today in every major browser except Firefox. It's incredible.

Speaker 1: Yes, I got on a on a roll. I'm trying to remember what else I needed to say here. So that is one way of reducing complexity is this pattern of, you know, I appreciate this pattern that Katie came up with. Another way to reduce complexity is deciding what you want to return from your server for JavaScript uh Ajax requests. Because if it it turns out if you return JSON from the server, you're inviting complexity. Or at least you're eliminating the friction to adding more complexity. Because when you download that JSON, you need JavaScript, of course, receive that and then convert it into HTML. And chances are you're not just going to stick the data straight into HTML. You're going to need some kind of component that has the business logic as to what to display and

Speaker 1: how to display it. And then, well, now that you have the data on the page, you might as well have a state manager so you can use it in other components. And it you just become more and more and more complex. But if you return HTML from the server, you actually require much less JavaScript on the front end to insert it into the page. This insight has inspired several tools. And I want to explain one of them. Django Unicorn. I think it is a really cool package that, at least in my experience and looking around at the people I've talked to and the teams I've been a part with, it's been a very underused tool. And so let me show you how it works as a way of reducing complexity. When a user comes to a website that is powered by Django Unicorn, Django renders the app as normal

Speaker 1: and downloads the JavaScript that is Django Unicorn. And once it initializes, it essentially takes control or enhances the components that opt into it. So when there is a change or interaction on the component, it reaches out to the server. And the server re-renders the component and sends the HTML down. Django Unicorn then looks at the page, the current state of the page, and the response and sees what's different about it. And then just renders those that difference to the page. So this is a really incredible pattern that does a lot of things that you don't have to do, including coming up with routing. And that's one one thing I love about Django Unicorn is that you can really focus in on your components and you don't have to come up with a new wrap for every new piece of data you need to pull in.

Speaker 1: With that, I think that about covers reducing complexity. But I want to talk about another pattern. Because the single page application is overused, as we've covered. Progressive enhancement is not a pattern, but a strategy. And I think that the component islands pattern is a really good start. But I think that there are a couple of things we can add to that to really enhance it. So today I want to propose the streamed HTML components pattern, which essentially kind of starts off with the component islands pattern, but adds a couple of things. When a user visits a page that is following this component uh this pattern, the first thing that does is that instead of the server rendering the whole HTML in memory and then sending it down to the user in one chunk.

Speaker 1: As soon as it can, it starts sending uh streaming the HTML r in bits. And if it needs to wait for data, it'll wait for data, but it just It's like the user essentially is just has this incredible experience of having a very short time to interactive. Like the page appears in in in front of them. quickly and as it's progressively enhanced, every component is in or is uh uh you can work with every component as it appears. Since this is a focus on components and individual components, you can choose different tools based on the complexity of each component, and each component can vary widely. You can have some components that are just HTML and CSS. Others could use Django Unicorn. And then finally, maybe some you need something like Svelte or React

Speaker 1: to really give it everything it needs. As each component is independent, they can also independently speak to the server. And then by default, the server will respond with HTML responses. And even though they're independent components, they can speak to each other through JavaScript events. One thing I really like about this pattern is that this enables you to experiment. If you if there's a tool that you would like to use, but you don't want to kind of devote an entire new project to it, you could experiment with one component. As long as the complexity stays low and the user experience says, like, yes, this is a good experience. And yeah, and speaking of tools that you can use, I want to kind of share a couple of tools.

Speaker 1: We've already talked about Django Unicorn and how I think it's a really great option and I think it would be a great starting point. But sometimes you need a little something more, a little more Uh control perhaps. Maybe you want to make an infinite scrolling section or uh update multiple pages at once from a payload. In that case, I recommend a tool like HTMX. HTMX , the its its purpose is to speak to your server, get responses back, and put those responses into the browser. It does not do things like great interactive things like modals. I mean you can kind of do some of that, but you'll probably want to add on multiple other tools that kind of help with HTMX depending on your use case. And for that, I recommend a few.

Speaker 1: Alpine. js is a great small JavaScript package that can really empower front-end components and experiences. Django template partials is a great tool to kind of help pull out parts of your your templates in Django. And then sometimes you want something a little bit more robust, like you have a component that has a lot of JavaScript, a lot of interactivity, a lot of needs. And I think something like Django components would be a great thing to pick up. Now these are just three. I'm sure there are many, many more out there, but I just wanted to give an example of some tools that you might want to pick up. Additionally, another tool that I think is very interesting is DataStar. It was created by someone in the HTMX community who loves HTMX and Alpine

Speaker 1: and had some really interesting opinions on like, wouldn't it be great if these two kind of came together in this specific way? And he talked to the people at HTMX and Carson Gross, the creator of HTMX, was like, those are some great ideas, but we're not going to change our framework to meet those. You should make your own. And so he did. And there's some really, really interesting things there. Uh finally, I also think Unpoly is an exceptional Tool. I haven't used it yet, but the more I research about it, the more I learn about it, the more impressed I am. It is a progressively enhanced first toolkit that has many other tools to kind of help you as you need more from it. So we've talked a lot so far about

Speaker 1: uh this the spas and this new pattern. I want to now transition to sharing some success stories. Now, obviously I just proposed the streaming HTML components pattern, so there are these people have not used this yet, but I want to share stories of people who've leveraged the tools and the ideas behind it to great success. The first one is Umuzi. Who you may have heard of of from our um keynote speaker. Thanks, Sheena. She didn't talk talk about much about Amusi here, so let me give a little background. It's an incredible organization who is it investing in the young people of South Africa. As China

Speaker 1: said, they they they pay people to learn because they have um uh clients who say need 20 web developers. And so they will find they they have a list of people who are have the aptitude to learn HDM. uh technical uh trades like web development and data science and things like this. But these people are in an underprivileged environment. And so getting them the access to these jobs We'll give them access to salaries that they've never seen, that their families have never seen, that their communities have never seen And I think it's awesome that they also teach him how to be financially sound so that they can support their families and their communities without kind of running dry themselves.

Speaker 1: And to teach these people, they bring them into a central location near Johannesburg and they they train them up. At least that's how it worked before the pandemic. Once the pandemic hit, they kind of had to pivot and figure out how can we send these people home in a way that we can still support them. And as a part of that, they created a single-page application to support the learners. Once the dust settled, it feels weird to talk about you in the in the third person, but um I appreciate you like going through this with me ahead of time. Uh once the dust settled, uh Sheena looked around and she realized she had a problem. That the this the for somebody to accomplish a new task, they had to know a lot about every little part of the single-page framework. And it people just were not that productive.

Speaker 1: So she needed something to change and she tried out HTMX and Alpine and was shocked at how fast she was able to reproduce some of the functionality. So she handed that piece that she did off to some junior developers and had her have them experiment to see if they could create something new and they knocked it out of the park. As a result, junior developers were able to contribute meaningfully without significant oversight. And then all the other developers got a huge productivity boost. And the remote learners benefited from this as well with an accessibility boost. They need didn't need as fast of an internet connection, and they could use uh older browsers on lower powered machines.

Speaker 1: And you could she's excited about it. She can tell it was a great success story. Next, I want to talk about context. This comes by the way of David Guillot, who gave an incredible talk at DjangoCon Europe 2023. And I'm going to kind of skim through this a little bit more, but if you haven't seen his talk, absolutely look it up and see how great the experience is of his app. He transitioned from a single-page application to a solution that has Django components and HTMX. And technically, one of the things I find fascinating is that they were able to reduce their time to interactive from six seconds down to two. Which by itself is pretty good. But what I find fascinating is that when they had a single page application, they were limited to only showing 50 items at a time.

Speaker 1: So if you scrolled, they had to like remove things from the top and add things to the bottom in a quick way of controlling the memory. But they were able to remove that governor and they could still show up to 3,000 items. And still have a two-second timed interactive. That's incredible. Additionally, they reduce the lines of code by over 90%. I mean, can you imagine that? That's so much less you have to wrap your mind around. Next, Open United. They had similar reduction in code by just by 61% this time. But what I find very interesting is that The number of story points each developer could accomplish was multiplied by five. Like this is a stat I just can't wrap my head around.

Speaker 1: How how could you how would it feel at work if you multiply the number of story points by five that you could accomplish in one task? Like, I just don't understand how this is possible. And they're also so comfortable in editing HTML that they're actually directly editing HTML to do experiments in user experience instead of using something like Figma. And finally, I love that it's an open source project. So you can compare how they did it before and how they do it now and see for yourself. My last story is one from a developer named Taylor Hunt. He wrote a five-piece blog post series, and the first blog post is entitled Making the World's Fastest Websites and Other Mistakes.

Speaker 1: And it chronicled his time at a grocery store chain. He knew their groceries, that grocery store needed to change, it had a problem with its production web app and needed to change. But no matter how much data he shared, no matter the metrics, no matter the conversations, nothing moved the needle. And so he decided, I need to find a way to viscerally help people understand what's going on. So this chain of supermarkets sells mobile phones, and he bought the most several copies of the most popular phone that they sell. And then he recorded people accomplishing what should be a simple task: loading the website. Uh searching for eggs, adding the first result to the cart, and starting the checkout process. And as I play this, you may say, Chris, you didn't play anything.

Speaker 1: Because on this device, this is how long it takes on the public internet to download the JavaScript. And as you'll see, once it starts to load, Preparing the application gets in the way of the user typing. They're gonna type E, G G, and only E is gonna show up. And once the application is fully initialized, it's actually gonna wipe what the user typed in. Which we'll see in just a second. There it goes. Imagine how crazy, like the you know, people talk there's a uncali valley, uncanny valley of when it seems like the application is useful, but it's not. And this is one of the most dangerous, bad patterns of a user experience in user experience. It's going to take the person using this phone almost four

Speaker 1: four whole minutes to accomplish what should be a simple task. I mean, and I've been in environments like in that simulate this where I'm on my phone looking at a in a supermarket trying to find where is this item? And the internet is slow and it's taking me forever. And I'm seeing spinners all over the place. And it's just a horrible, horrible experience. Well, Taylor knew there was a better way. And so he wanted to create a demo app to show what's possible. And yeah, uh I gotta say this demo app, what you're about to see is single-handedly the biggest thing that inspired the streamed HTML components pattern. So watch as the page streams into existence as I hit play.

Speaker 1: Boom, it's already there. This search Page the search thing is already uh available. And before the page even loaded, they were already searching for eggs. It's important to important to note that this Web app is a multi-page HTML-driven web app that is faster, obviously, than the web, the production web app, but even faster than the native Android app on this phone. The person who did this was able to accomplish their task in 20 seconds. And I mean this is so much more fun to use, isn't it? Your web app could be just as fun, and I want to encourage you to give it a try. It's important to note that this web app uses the same APIs as the other one. It's on the same internet, hitting a server co-located with the production

Speaker 1: app. It's essentially the same. It even creates the same data in the back end and pulls the same data, as I said, from the API. So it is a functional equivalent, but obviously a drastically better experience. And I want to empower you to do this in your web app. So with that, I've talked about. the options you have when it comes to creating your web app. I've warned you to use single page applications when they're best used. I highly suggest you reduce complexity and try to keep it under control as much as you can. I've introduced streamed HTML components and shared with you a few stories of people who have absolutely loved Transforming their code from a single-page application and to this new pattern.

Speaker 1: And before I take questions, I just want to stop and say thank you so much to the sponsors who made this event possible, to everybody who is Video recording this and and transcribing this. Thank you all for being here. This is an incredible event, and I appreciate being able to share my ideas. Are there any questions? Are there any questions?

Speaker 2: Uh yes. Great question, great talk there. Um just one quick question. I saw those uh Kroger demos were featuring uh Mount Karma and Oakley stores. Was it were you did you choose Cincinnati stores because you're in Cincinnati or cause that's the Kroger headquarters?

Speaker 1: Oh, uh I chose it because of the the website, uh uh the the blog post. The the Taylor worked for Kroger. Um nothing against Kroger. Like I don't I I tried to not say the name just in case, but like, you know, they're just developers just like the rest of us, and I'm sure many companies have a similar issue. Any other question?

Speaker 3: Hey, great talk. Do you have a more detailed uh like example workflow or something of the streamed HTML ML components? Because from the items it seems hard to picture how it actually works in in practice.

Speaker 1: Great question. And honestly I should. This quarter has been really crazy, so I'm gonna Definitely prepare a blog post and put it up on my website, Everyday Superpowers. You know, the the slides are also available, so you can at least have the bulleted list until I have that up. But yeah.

Speaker 3: Awesome. Thanks.

Speaker 1: Sure.

Speaker 4: Uh one of the um big selling points for uh folks that uh what like the the spa pattern is that you can split large teams into a front-end and a back-end development team. So they can both work independently and gain additional velocity. Have you seen similar um approaches used within just Django splitting teams between like the Django front end and the back end? using an approach, you know, like with HTMX to get similar results?

Speaker 1: I have. Absolutely. And it and I think each team is going to have to decide for themselves how to implement that pattern. But I have definitely seen kind of a scene where You the front-end teams handle the HTML and the JavaScript and essentially communicate, you know, maybe through the view what they need, you know, communicate with the team with how they get the data they need. Um so it's I I do find it interesting, you know, that uh I think actually, no, with David Guillot, whom no, I'm sorry, I'm trying to remember if you One of the people I was inspired by mentioned how there was a division between front-end developers and back-end developers. And by switching to this pattern, everybody grew and kind of appreciated that they could learn. e both sides. Now that's obviously not going to happen in every team, but I do appreciate the fact that like, you know, I I find it interesting that people really feel

Speaker 1: When I've seen people online talk about like, why would I ever want to incorporate these two groups of people together? Like there seems to be like a chasm that has been building between the front-end developers and back-end developers. And I don't know, one for kind of allowing them to come as close as they want to. Obviously, each team is different. So I can understand maybe sometimes you might want to keep them separate, but uh yeah. Any other questions? Oh, hold on.

Speaker 2: Yeah, this question is from uh Matt McLanahan on online attendee. Uh does Firefox still lack support for the SSR techniques you mentioned? And if so, have you heard anything about if they're still working on it?

Speaker 1: Does Firefox still lack support for what?

Speaker 2: The SSR techniques.

Speaker 1: Service side render techniques?

Speaker 2: Yes.

Speaker 1: I am unaware of this.

Speaker 2: Okay.

Speaker 1: Uh I don't know, but

Speaker 2: quick reply came in. Let's see. Oh, he thought that oh that that uh was supposedly about just about the CSS transitions.

Speaker 1: CSS transitions, yes. I I don't know this I can't remember what the status is with view transitions. Is that I'm sorry, was view transitions? Yeah, okay. Because I looked it up on Can I Use uh before I came here and I just can't remember. Like on Can I Use they don't have any specifics about it, but I know other people have uh are following. Firefox. I don't know as to any kind of uh timeline with which it would be supported, but you know, uh I feel like one thing that's nice about CSS is like you can add it in, a kind of progressive enhancement, right? You can make sure it works and you can add the CSS to that supports view transitions, and it gives an incredible experience for the people who can see it. And those who can't will still have a good experience, especially if you're able to stream your pages and have

Speaker 1: great great performance. I mean, shoot, the the the app that we showed from Taylor, he had no view transitions And it was so fast, right? This is this is stuff that's incredible once you're able to to harness it. Yeah.

Speaker 5: Sure. So a question I had uh stems from a server returning HTML by default.

Speaker 1: Yeah.

Speaker 5: So there seems to be a lot of uh I just I see developers, you know, returning static HTML. And so Alright, I I guess hard-coded HTML. And and so I I suppose how do you do it in such a way that's dynamic so that you know you're not hard-coding something like that? If that makes sense.

Speaker 1: How to Okay, let me see if I understand your question. How how can you I'm trying to parse it in a way that and and echo it back. So my understanding is that you're wondering No, can you ask it again? I'm sorry.

Speaker 5: So I I was just it you know, it especially for um you know things which is Ajax. Um You know, uh especially say just developing projects, there seems to be a lot of limitations behind you know programmatically being able to return HTML so that it's not hard-coded. And I was just wondering, you know, if there was any additional input that you could maybe provide on how to do that more dynamically.

Speaker 1: I I I'm curious because uh uh uh uh you're when you say hardcoded not having hard coded HTML, uh I that that is part that I'm kind of hang getting hung up on as many times you know we're rendering dynamic HTML from a server. Um is that Like well let me let me address what I think I can say is that like I knew many uh Teams who just re-render the entire page on a on a request, like say, like uh, you know, let's say you uh fill in a contact and you now you have you want to add a new contact to a list. I know of some teams that re-render the whole page and use a tool like HTMX, which you can say, I just want to grab this part of the page and just re-render it.

Speaker 1: And so if that It aligns what you're saying. There are many of the tools are smart enough where you can tell it like from whatever HTML gets generated, this is the part I want. And then there are other tools actually like Django Unicorn, which they respond with HTML, but in a JSON blob that have other data associated with it. And so, you know, I kind of I think that downloading or returning JSON, I'm sorry, returning HTML by default is good, but you can sometimes enhance it by uh converting it into JSON. And so Jingo Unicorn has additional things that can help it to uh work faster with that. Does that?

Speaker 5: It does, yes.

Speaker 1: Okay, cool. Thank you very much. Take care.