Jono Alderson - AUDIO EDIT
===

Paul: [00:00:00] Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket provides AI first session, replay, and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling and try for free@logrocket.com today. My name is Paul and joined with me today is Jono Alderson. He's an SEO consultant expert, and we're gonna talk about why Symantec HTML still matters. You know, the things with tags when you actually cared about was in the tags. So welcome to the podcast, Jono. Excited to dig in and get your take on things.

Jono: Thank you. Thanks for having me. This should be fun, hopefully.

Paul: Hopefully. Do you think now is the most prudent time of them all to be having this conversation?

~Um, if I,~ of a different nature of the pods we've been doing.

Jono: I think so. I think,~ um,~ we're at a wonderful inflection point where the very nature of the whole internet may well change overnight. ~Right. ~So probably a good time to start asking big questions like. What is a page and what are the things that interact with pages or units smaller than pages? And [00:01:00] how do internet and what is a website and what's it for and how do we build it?

~Um, ~and there's a real chance that tomorrow all of this changes again, right? Should we be even worrying about putting HTML on URLs or should we be thinking much more broadly about pipelines and integrations and just pure js n who knows? ~Um, ~but I think we should probably hedge our bets and make sure that at the very least we are set up for succeeding in that intermediate,~ um,~ period before whatever comes next lands.

Paul: What is a page like? That's a, it's almost like an existential question of the internet. ~Um, ~that's a big

Jono: Yes,

Paul: It's a question you would ask if ~you, ~you've been around pages for a bit, I presume. ~Um, ~so ~where, ~where are you coming from, Jonah? Are you in the OG web dev from

~back in the ~back in the bubble era from the Rails era.

~Um, ~how'd you get into SEO.

Jono: Yeah, so I'm a PHP nerd from oh, sheesh, well over 20 years now. ~Um, ~and ~I, ~I know people will cringe when I say I'm an SEO, but I'm a back as, my background is as a web developer, building little websites for small local businesses, and I fell luckily into the world of agency and tool vendors, et cetera, and ended up consulting.

But my [00:02:00] background is really. ~Trying,~ working with companies saying, how can we leverage your technical choices to grow your business? ~Um, ~and that's where my obsession really started. Because you're a small business with limited budget and options, the order of your HTML tags and whether or not this thing has or not are all attribute and how these bits of JavaScript interact with these bits of CSS.

It can have a meaningful impact on do, did I get a hundred visits or 200 visits, and how many sales did I make? So I really got down into chasing perfection in markup, and that stuck with me ever since. And a large part of the flavor of SEOI do is focused on. What are we shipping to the browser, not just markup, but also headers and compression algorithms and server setups and CDNs and all these other bits and pieces, but ultimately still with this focus on every single bite and every single tag and everything that's in the dom matters and how they're treated matters, and they're really.

Is a huge amount of opportunity still for many businesses and sites in really [00:03:00] caring more about that. And I think one of the struggles that I'm sure we'll talk about surely, is that most development and engineering pipelines have abstracted way away from that. Like nobody is touching actual HTML in 2025.

~Um, ~and I think that's a problem. I think that has come with all sorts of nasty side effects, where we've drifted away from quality as a concept. Because nobody actually understands how their stack works. Yeah. Fun stuff.

Paul: Because not understanding how it works is ~kind of ~the crux of the problem. Because if I have a simple project I'm just messing around with, I'll get ~a, ~a large section of tags in there using clot. That wouldn't be there normally.

Jono: Yeah. And these systems are trained on the bad practices that we've developed over the last 15 years, right? So the more we move into vibe coding and generative stuff, the more soup we produce that then feeds tomorrow's soup and it gets worse. So yeah, as you say, now is probably the right time to be having this conversation around what do we want tomorrow's architecture to look like?

Paul: ~So. ~Coming back to that first statement I ~kind of ~asked at the beginning, is now a prudent [00:04:00] time to be talking about this? ~Um, ~I think a lot of times HTML can be seen as like a byproduct or it's just part of the system, and now might be more of an important time than ever to say. That's absolutely not the case.

It's opposite of that. ~Um. ~One of the main things that we just discussed is the importance of it, and then ~we, ~we don't wanna produce more soup because that's what we're getting out of it. What are, what's, like another reason why HTML is certainly not a byproduct and it shouldn't be treated as one,~ um,~ or one reason why we're moving in that direction that you think ~like ~can help bring us back out at that thousand foot view of what HTML means.

Jono: Sure. So there's a timely, and I know not very trendy angle here, so let's get this out the way, which is just accessibility. ~Um, ~which is you look at, I know the us ~uh, ~best estimate,~ um,~ circa 10 to 15% of people have some kind of disability or impairment, which means that conventional web browsing is tricky.

Then you consider, okay, now throw a 20 megabyte [00:05:00] JavaScript application at them that's gonna do client side hydration. That's gonna lazily load stuff based on scrolling and tapping interaction. There is not the slightest chance that they're gonna have a good experience there. These people have needs and shopping behaviors and disposable income actually fascinatingly more disposable income on average than your average other person, because shopping online is so hard, so they're less liable to spend money.

A kind of weird circular effect there. So I think at the very least, Symantec, HTML, which plays nicely with assistive tools and other systems and other ecosystems. Straight out the door unlocks another 15% market share. And I can't imagine there are many significant organizations where handed the option of, do you wanna go your market by 15%?

That is probably quite significant, right? Versus everything else on your roadmap. So just tweaks to whatever your horrendous JavaScript nightmare stack is spitting out might be an easier way to go market share and revenue than all of your big strategy stuff. So I think [00:06:00] that's a big argument. ~Um, ~the other, I think two other arguments.

One is,~ um,~ the further away you get from Symantec HTML, the less likely you are to have a performance efficient site, and they're not directly connected, but the kinds of compromises and decisions and architectures which produce Diviv Soup and Tailwind nightmares typically. ~Uh, ~there are some exceptions.

Our grants typically aren't fast, typically aren't well understood, typically aren't well optimized. When you look at things like, okay, how does the browser paint these pixels? What does the critical rendering path look like? These kinds of stacks aren't often well configured. To optimize for those. And I know that's not a problem with the stack.

That's a problem of the people using the stacks, but they become somewhat synonymous, right? So the further away you are from understanding and really having a grasp on what is the actual H TM L structure, and how does that interact with the CSS, and where does JavaScript layer into this, and what order does that all happen in, and how does the browser literally paint pixels on the screen as a result?

The further away you are from [00:07:00] that, the harder it is to understand that or to even care about it and remember it. So often these sites are slower and worse than they would be if people had paid a bit more attention. And the third is this kind of broader ecosystem, which we've touched on of LLMs and connected toasters and TVs and fridges.

And one of the things we've got away with for a decade or so is browsers being ~very, ~very good at. Overcoming poor or broken or confusing markup like Google in particular, putting my SEO hat on for a moment has got phenomenally good at understanding that even though your markup is a diviv ~within a diviv, ~within a diviv, within a span, within a diviv with 500 megabytes of tail in classes, it can still just about understand, okay, this was meant to be the main heading if only had been an H one.

This is the hero image, this is the content of the page. And ~they, ~they comprehend that reasonably well. But chat, GPT doesn't. They just extract or H TM L and it's just and discard most of it. And what they're left with is fragmented noise and your smart toaster or whatever comes tomorrow. And the systems that are gonna interact [00:08:00] with those systems and the agents that are gonna query them and that whole ecosystem is gonna be much less forgiving.

And even if they can pass and process and understand and mangle all of that, those are CPU cycles. That's bites on the wire. That is GPUs cooking laptop fans, like all of these things really do have a cost and in aggregate it does add up. ~Um, ~so I think getting away from that abstraction by default and the norm, and actually getting back to caring about.

What is, what are, what is the meaningful language that we are putting in ~our, ~our documents to communicate with the things that consume those documents? I think that's an important mindset to revisit. Like we are publishing documents on the web. Some of us are building apps and some of these things are apps and lots of people spend lots of time in apps.

But for the majority of the stuff, we are interested in our documents on websites, on pages, and if we're building them as apps rather than as websites and documents. We're ~kind of ~We're kind of doing it wrong and there are costs to that.

Paul: I, these three arguments you gave are more broad, right? They're talking about caring. [00:09:00] About the structure, the guts of the website,

about what happens to the JavaScript, what happens to the CSS, and we're ~kind of ~using,~ um,~ structured HTML as a proxy to,~ to,~ to talk about ~sort of ~like this family,~ I, I guess, ~of,~ uh,~ of topics ~that, ~that are becoming more overlooked. ~Um, and, ~and notably it's not. I think the conversation five years ago was more centered around, do you have semantic, HTNL? ~Like, ~do you have it? Because if you do, you put it there. It probably means something. And now the conversation is more like put good semantic h tm L in there. ~Like, like ~think about it a little bit and don't just ~like ~put it there that, that's the more conversation with the delta.

So in, in light of that, people are gonna be putting semantic HTML and maybe they're gonna try to think about like render cycles. Through a tool through an LLM and that again, will ~you, ~you pointed out Jonah, that'll land you ~in the, in the, ~in the slot category. ~Um, ~potentially.

So how do you recommend people go about not sacrificing all their time?

'cause like we're,~ we,~ we have an average listener here. They're working on an app, maybe three apps. ~Um, ~they wanna lean more into the [00:10:00] semantic HTML lean more into understanding ~their, ~their render cycle. What's a happy medium between not just throwing LOP on there? ~Um, ~but being able to start to tackle this mindset ~and, ~and revisit it again effectively.

Jono: It's a great question. I think this is the crux of the problem, which ~the, ~the broader problem, which is that over the last, I don't know, 15 years or so, we have optimized ~very, ~very heavily for developer experience. At the expense of the longer term user experience where users are not just people consuming the app, the website, but also marketing teams and businesses, et cetera.

So we have got ~very, ~very good at using abstractions and tooling and layers to build stuff quickly. That's good enough. But then the long term cost of that over the coming days and months and years, et cetera, is the marketing team struggle to publish stuff. Google struggles to understand it, users with accessibility needs, can't access it, et cetera, et cetera.

And those costs are high. So I think the sensible middle ground is slower and that's unfortunate and that's something we might have to accept that really thinking about stuff does take more time and energies and [00:11:00] calories, but those are a good trade off and that taking that extra time to say, rather than just.

Spitting out HTML as an exhaust of whatever the stack produces actually thinking. Should this be a section tag? And if it is, then should the H two that's inside it actually be wrapped in a heading tag? Is that something, is that better or worse, the yada. And those, there aren't any perfect answers to those quite often, especially with the mess that the HTML five spec was, a lot of the time you will be making compromises and trying to come up with a reasonable opinion on what does better look like.

But I think at the moment we spend zero time on that. So a middle ground would be anything more than zero? ~Um, ~yeah, I think slowing down a little bit to build something that is more useful and robust for tomorrow ~is a, ~is a good trade off.

Paul: And ~it's, ~it's notably like slowing down so that you can speed up so that you can think about ~the, the, ~the semantic HTML structure and think about how your website's loading. ~Um, ~you mentioned, you know, kind of in the shadow, shadow realm here. We have frameworks, stacks, all this sort of stuff. ~Um, ~if we peel back a [00:12:00] little bit just from this meta conversation about,~ uh,~ Symantec, HTML, do you see a successful direction for developers to refocus what tools they might be leaning into, whether that be, ~um. ~Trying like raw HTML, I don't know if that's like where your brain's

going. ~Um, ~or maybe working with something a little bit more elementary, like HTMX where you get your hands dirtier a little bit. ~Um, ~are there any practices that you would recommend for people on their next project?

Jono: HTMX is interesting, but it has its own pitfalls. No, I'm really struggling with this. This is one of the problems is I don't see a good route out of the world we've created, and I think one of the challenges there is that we've built ourselves into a very component centric world, and that's been very useful for building things that were quite components.

But I think there is an alternate mindset, which is more template centric. And I think the more time I spend in the world of web performance, for example, ~the more challenges I'm seeing where ~the more challenges I'm seeing around websites and applications where each individual component is doing its own thing [00:13:00] and there are fundamentally unsolvable problems at template level where.

Pages and systems are ~kind of ~architecturally and a step back from those components need to understand how are those components behaving and what resources are they loading and which should be preloaded before we even send an HT TP response and those kinds of things. So I think stepping away from that kind of component and style components world and starting to think about how do we orchestrate and architect pages that run on templates that contain components.

I know this is very abstract. ~Um, ~but I think that's a better mindset than how do I,~ um,~ compose pages from components and thinking about how do I build systems that have that logic downwards? And then it becomes much easier to think about semantic HTML as well because you've got clear hierarchies and structures.

You're building templates, not down, not components up. So you can think about things, okay, this is a section that contains other sections that contains a n and the side, et cetera. But it's so hard to break outta the component centric world to do that upwards.

Paul: Oh, that, that's so true. ~I mean, ~I'm certainly younger developer. The new, I've [00:14:00] probably been working on web tech for eight years ~or, ~or so, and in that time it's been components, like that's how I entered the industry. That's how I'm currently sitting in the, in industry. ~Um, ~when you have to think about things in a layout and page context, it's ~like, ~oh, that's a special thing.

that we do. We do the, that we like checked that box and now we can, ah, now I can finally work on components. I'm so excited. ~Um, ~so I think you hit the nail on the head with that one. ~Um. ~I felt called out,

Jono: Sorry.

Paul: No, it's great. ~Um, and, and, and, ~and up a similar vein, we have,~ um,~ things like Tailwind, which in the past four to six years have grown wildly in popularity, which also bring us a layer even more into the component space.

'cause

we're thinking about ~like, ~theme components ~and, ~and animation,~ uh,~ key frames that were ab abstracting away. ~So, um, ~yeah, it, it de it definitely felt ~very, ~very fitting. ~Uh, I had, um, my, my next question about pages queued up here. Um, it wasn't on the outline, and then it, and then it, sorry, Elizabeth,~

Jono: ~Oh, ~

Paul: ~I'm gonna ask her to cut this little one out while I scroll around.~

Jono: ~Yeah. Yeah.~

Paul: ~Oh, here we are. Um, ~so thinking and thinking about pages, Jonah, we're, so we're going from components. Frame of thinking into pages, and you mentioned at the beginning of the pod, what is a page like that might

change? ~Um, ~and I, we've heard this a few times with people coming on,~ uh,~ pod Rocket here, ~you know, ~oh, MCP servers, it, [00:15:00] that's gonna be the page, ~you know, ~or cl you use it through Claude.

Maybe it's gonna be something like, ~uh. ~More. More of an offline web where we are, we're leveraging local storage and the new web assembly perimeters coming out. ~Like ~is

that a, that's a totally different page and data loading scenario. What are you thinking about for the next year to five on what a page is?

Jono: That's huge. ~I, ~I wrote about this recently. I think the short term future remains pretty much as is. I think for better or worse, Google still drives a huge amount of the way that the ecosystem works, and it's really their paradigm that has made us page centric, I think. The early web evolved, not the ~early, ~early web, but certainly the early Google Web and ~the, ~the most of the money that went into driving content and websites for SEO and for discovery was based around the fact that Google, and to a lesser extent, Bing and others, consumed content on the web on a one-to-one topic to page relationship, more or less.

So everybody's websites are built in that style and structure. That's why Flash died because other [00:16:00] paradigms, which weren't based on the idea of A URL, is one page with one topic just didn't fit Google's kind of neat artificial structure at the web, and now that's the norm. Now that's permanent, but that isn't necessarily the future, and it.

~Really, ~really hard to imagine what other versions of the web might look like because we've baked that in so heavily. But we're starting to see exactly things like MCP and for other protocols and processes, and for a long time now, even Google and others have consumed and evaluated the web. In smaller units than pages.

Like we know for years that Google is assessing individual paragraphs and chunks of content on pages and mashing those together with other stuff to form understandings so we could free ourself from this kind of relationship with the URL. I think the challenge though is that much of the web and the commerce on it is still driven by systems crawling and discovering and consuming other systems.

And those things need signposts and they need to live somewhere. So we still need something like URLs and places where things can poll and discover and then you go, okay, ~well ~[00:17:00] what if there are better formats of that? ~If, ~if URLs just represent webpages, which are essentially marketing pamphlets for emotionally susceptible humans, why do I need chat TPT to have any of that governance?

~Like ~does it really need the images and the CSS and the JavaScript? Could it just have some Jason and some data? Maybe Then you get into an interesting challenge where. As soon as you have two different versions of your site or your page, or a bot friendly version, why would the bot trust that you look at the amount of resources that Google has spent over the last 20 years going, we don't trust you to tell us what your website's about because you will lie and you'll say it's about Viagra, so we will evaluate that.

Yeah. Yeah. So even if you have an alternate optimized version, none of these platforms will be incentivized to trust it. Even if they still wanna use it, they will have to reconcile that back against the original, which is now twice the crawling overhead and a reconciliation process. So you are, oh no, five xing their costs to consume the web.

So that won't happen. So we're stuck with websites being marketing pamphlets, which also have to market to and communicate with machines. ~Um, ~and at the moment that's a kind [00:18:00] of awkward thing where. Attractive. They're just stripping out all the html and boilerplate stuff as best as they can and tokenizing what's left, which is pretty crude.

~Um, ~it's not hard to imagine. They might wanna do a better version of that. They might actually want to understand the difference between primary content or is this the author's bio or is this an advert in the sidebar? That's the kind of bit where structured data starts to become more interesting, I think for these systems and also schema.org and ~kind of ~broadly metadata of that type.

I think there is a world where our websites become things which recognize that half of your audience is probably not human, and it needs to be not just a marketing pamphlet, but a database. We start saying maybe there are different bits for different consumers that get surfaced in different ways. Maybe my website should be exposing structured pricing information rather than just strings on the page.

That's super interesting. And I think actually that's one of the scenarios where build pipelines and processes and stacks and things might actually be far more advantageous than handcrafting HTML,~ um,~ because these things become brittle and they need managing and pairing and [00:19:00] synchronizing. ~Um, ~so yeah, maybe there's, maybe that's an interesting direction.

~Who knows, ~who knows where we end up? ~I'm, ~I'm dubious about. Truly alternate formats and synchronized siblings and Jason only views. 'cause the trust thing is such a massive issue.

Paul: Yeah, and it's interesting too that you point out the perspective Google might have about, do we trust you? No, they didn't in the past. So why are they gonna do

it again? 

Jono: Yeah.

Paul: ~Um, ~okay,

Jono: And in fact, sorry, just on that, we see one of the one challenges around ~is, ~is chatt BT and similar systems quite often return low quality results because they don't have the layer of sophistication that Google has developed in explicitly not trusting us. And one of the ways that these platforms are getting around that is they are scraping and or buying data from Google or from third parties who are scraping and evaluating Google.

So the trust issue is really big and it sits at the heart of a bunch of this because Google is essentially a proxy at the moment for all of these platforms determining what they ~should and ~should and show, I dunno how sustainable that is. And when that breaks for either technical or legal reasons, then what?

Yeah, it's gonna be a mess.

Paul: I know Google has been in the,~ uh,~ antitrust bubble a [00:20:00] lot recently, so I. Would, wouldn't be surprised ~if they, ~if they have more,~ uh,~ findings there.

Jono: Oh yeah. Yeah. That's ~gonna get ~gonna get messy.

Paul: ~Uh, ~Jonah, we have a quick round and this one is interesting 'cause I'm gonna like fire a question at you and we just want the raw unbridled, my Jonah. 

Jono: Sure. 

Paul: what

thoughts are beaming through. So if you're ready, I'm ready ~and we'll,~

Jono: Yeah, let's do it.

Paul: Okay. ~Uh, ~so the first one is one HTML Element Jonah, that you wish developers used more often. And it, it doesn't need to be like a semantic HTML tag or something.

It could also be a an HTML purist kind of.

Jono: Sure. No, there's an easy answer here. It's the picture tag, which,~ um,~ nobody ever uses and I wish they would. ~Um. ~I did a 45 minute conference talk a couple of years ago on how deceptively hard it is to put an image on a webpage,~ um,~ that if you want it to be actually performant and you want to account for different device layouts and types and formats and sizes and orientations.

Actually managing that and preloading the right version and blah, blah, blah, blah, blah, blah. Getting all of that right is really hard. ~Um, ~I don't see enough people wrapping their image tags in picture elements and using source elements [00:21:00] to describe the various options, whether that's by format or orientation or art direction or whatever.

There's so much power there. It's got really good over the last couple of years. Things like,~ um,~ individual heightened width and sizes, attributes on source tag. You can go ~really, ~really granular in how do I serve exactly the right image for exactly the right scenario,~ um,~ without shipping too many or too few bites and without having the browser resize everything on the fly done well, it's just glorious.

It's the best HTM l there is.

Paul: I love the surefire answer. ~Like ~that was awesome. ~Um, ~all right, next one. The single most damaging HML anti-pattern ~you see?~

Jono: ~Uh, ~two,~ um,~ theus the diviv within a diviv, within a div, ~within a diviv, ~within a diviv. ~Um, ~that just means when you actually try and understand what's going on, it's a nightmare. Also, the performance overheads of that, that browsers constructing the dom and the CSS arm have to traverse all of that. And then if you animate or move or show or hide something that's 28 levels deep, you're gonna have to reconstruct that whole thing, and it's all gonna be non compositing, and the GPU's gonna overload and you're gonna crash the browser.

All of that is nasty. ~Um, ~and I had another one. What was the second one?~ I had a second one for a reason. Um, nope, it has gone vanished. Oh, I know, I know. Um, ~it's the component centric thing again. It's, ~um. ~When we get into a [00:22:00] world where you really do need to think at a template level because things like preloading and http, early hints sort a thing, and all of these standards,~ um,~ having all of your HTML logic live in the component and then go, let's output metatags in the component that's in the body.

Or I've seen sites recently doing link rail, preload, even components in the body. Not really sure that's gonna make much of an impact because the browser's already found everything. So, yeah. ~Um, non non html,~ non body h TM L ~in ~in the body is not nice.

Paul: All right, next one. Revisiting our,~ uh,~ conversation about frameworks and,~ uh,~ stacks and such like this. ~Uh, ~if you could fix something about how some of the most popular tools generate markup, what would it be? And ~th~ this could also be like data loading specific,~ or,~ or rendering. It doesn't have to be strictly markup, but within the realm of what we've been discussing.

Jono: Sure. So I can join the dots here quite nicely. I think,~ um,~ you choosing and configuring it to use sections and footer and main and header and those kind of structural semantic HTML elements and properties because then you can take advantage [00:23:00] much more easily of lots of the shiny new CSS around,~ uh,~ content visibility.

Which can be hugely impactful for performance. Like you can essentially lazy load ~sort of ~at least the painting and the rendering of elements which are offscreen or not in the initial viewport, which yes, you can do with divs ~within divs, ~within divs, but it's gonna be far harder because you don't already have that structural clue as to where is this thing and what is this.

Like the ability to, in one line of CSS, go, you know what? Lazy load the entire footer you shave. 200 milliseconds off your pages paint time. Just so, so nice. But yeah, much harder to do if you don't have,~ um,~ a platform that understands what the things on the page are.

Paul: Alright, awesome. And then the last one, do you think LLMs will ultimately reward good HTML structure or will they abstract away from it? And this could also bleed into ~like, ~do they trust us? That is something

that we as devs are putting on the page very carefully and pedantically we're doing it correctly. ~Um, ~will LLMs learn to not trust that and ~sort of ~just ~like ~take a step back 'cause there's gonna get more powerful. What's your take there?

Jono: Yeah, I think it might be [00:24:00] too late. I think they've already trained on a bad web, and as you say, the incentives and the trust relationships aren't great. And at the moment, at least, almost all of these systems just throw away everything that looks like markup before they then tokenize and pass the content.

However. I think there are a whole bunch of really interesting second order effects. Let's take the accessibility thing as a, for example. ~Um, ~you build an accessible site with semantic HTML. You've got 15%,~ um,~ more visitors who are very vocally very happy with the fact that you are not awful and your competitors are, and those people are more likely to post on social platforms, to engage in Reddit, to review your business, to,~ um,~ thumbs up on a YouTube video talking about blah, blah, blah.

All of these things. Create signals and behaviors which LMS can understand and evaluate and use to determine whether or not they're more likely to recommend you. So I think directly chatty BT probably doesn't care about your markup, but users do directly or indirectly, and the changes in their behaviors are measurable and impactful.

Paul: Nuanced to answer there. Yeah. About, [00:25:00] about how it bubbles up ~and, ~and affects ultimately the end user, which is who we care about.

And Google. 'cause they're certainly a, an end user in this world,

~um, of, ~of how they broadcast us. Well, Jono,~ uh,~ thank you for your time,~ uh,~ getting through this,~ uh,~ pod with me,~ um, and, ~and helping spread the word about things we should. Revisit as developers. ~Um, ~you had some great advice, honestly, that has felt like a new flavor of ice cream in, in the,~ uh,~ conversations about AI ~and, and, ~and developing fast, and shipping fast in, in the new framework of the month and such.

So I'm sure people listening are gonna want more. ~Um, ~you mentioned, you know, you do some consulting.

Do you post anywhere? Do you have additional,~ uh,~ talks where people can learn more about what's going on in your brain

Jono: Uh, yeah, definitely. Thank you. Yeah. ~Uh, ~over@johnoalderson.com I've got a page that says where I'm speaking, I'm at a bunch of events over the next six months. I post a bunch of stuff there and or on LinkedIn on a mix of either very, very technical browser stuff. So I just did a. 9,000 word post, I think, on how ~HTTP header, ~HTP caching headers work and a similar one on how to load fonts, which is deceptively [00:26:00] hard.

~Um, ~and then ~kind of ~big think strategy stuff. I've got, I did one recently about what even is A URL in this upcoming world. So yeah, bit of both ends of the spectrum. Oh

Paul: Ah, awesome. Good. Like reading pieces to go

noodle on. Okay. On the LinkedIn side. ~Um, well ~thank you again. It's been a pleasure and hopefully we'll have you back soon to, to see where the web has been taking us,~ um,~ through

Jono: If we all survive. Right. Thanks a lot. Nice. I.