Speaker 1: Hello, everybody, Welcome to another exciting episode of JavaScript Jabber.
Speaker 1: I am Steve Edwards, the host with the face for
Speaker 1: radio and the voice for being of mine. But I'm
Speaker 1: still your host at least I lost the coin flip
Speaker 1: today with me on our panel as mister Dan Shapiir
Speaker 1: coming live from Tel Aviv.
Speaker 2: How you doing, Dan?
Speaker 3: Hello from Tel Aviv where we're not at what with
Speaker 3: a run anymore?
Speaker 1: Yes, the last time we had Dan on, I believe
Speaker 1: he had run when bomb sirens started going off.
Speaker 2: So hopefully that won't happen to you.
Speaker 4: Yeah, missiles not bombs, but.
Speaker 1: Sorry, yeah, but slightly different, same end result exactly. And
Speaker 1: our special guest today I'm going to try to get
Speaker 1: this right is mister Benicius de Laqua.
Speaker 2: How you doing?
Speaker 4: Did great? Yes? Doing great. I'm here from Sweden where
Speaker 4: we can't decide if it's hot or not this summer.
Speaker 4: It's like days not. What is with this shot? It
Speaker 4: can actually get like up to like thirty five degrees? Wow,
Speaker 4: that is actually pretty hot.
Speaker 1: That's pretty warm. That's what around one hundred farenheit something
Speaker 1: like that.
Speaker 3: Yeah, I can hear that it's quite close to here
Speaker 3: that Europe is undergoing like this kind of severe heat
Speaker 3: wave we are.
Speaker 4: Yeah. Yeah, Like south of Europe is quite brutal, right now,
Speaker 4: like up to like forty six degrees or something.
Speaker 3: Wow.
Speaker 4: Places, Wow, that's quite bad.
Speaker 2: Is warm?
Speaker 3: Yeah, and not everybody has our conditioning. I guess no,
Speaker 3: Europe is not built for heats.
Speaker 4: I'll tell this.
Speaker 1: Yeah all right, So what we're here to talk about
Speaker 1: is the confluence of performance and AI. So actually, before
Speaker 1: we get started, we know where you live. Why don't
Speaker 1: you tell us what else you do and why people
Speaker 1: should give you money if they should, and that kind
Speaker 1: of thing.
Speaker 4: Yes, So I am a soft engineer. I've been around
Speaker 4: for quite some years. As you can see from the
Speaker 4: white hairs around there.
Speaker 2: It's like a lot of the gray going to So yeah,
Speaker 2: I like to.
Speaker 3: Say white Harry is better than no here.
Speaker 4: Yeah yeah, yeah, yeah.
Speaker 2: I feel.
Speaker 4: I've been working for a while, I mean being around
Speaker 4: since like I had to ship for even like a
Speaker 4: four four oh wow. Yeah yeah, yeah, so I had.
Speaker 2: To remember those days, I.
Speaker 4: Tell you, focus on performance for the biggest of my career,
Speaker 4: Like although never had really like the title of like
Speaker 4: performance engineer, performance was always like the focus of my
Speaker 4: interest and career coming from Brazil, Central Brazil, nonetheless, where
Speaker 4: you know, internet speeds were never up to standards, let's
Speaker 4: say like that, Let's put it like that. So you know,
Speaker 4: ux performance front end kind of became a thing for
Speaker 4: me as well, more and more over time. But performance always,
Speaker 4: because always was a subject that I care deeply about.
Speaker 3: Before we continue, just I'm just curious centers, Like what
Speaker 3: my mouse.
Speaker 4: That's not actually so central Brazil zo is like token
Speaker 4: Chin's Brasilia, So that's that's within the center. I was
Speaker 4: born in the north the States, but then like my
Speaker 4: entire life are lived in token Chinese, which is central Brazil.
Speaker 2: Okay, Yeah, that's an interesting point you bring up.
Speaker 1: You know a lot of developers when they're developing apps,
Speaker 1: they get so used to their you know and formax
Speaker 1: on their high speed you know, fiber internet and don't
Speaker 1: always think about the person might be using their app
Speaker 1: that's in you know, three g out in the middle
Speaker 1: of nowhere, you know, something like that. And so yeah,
Speaker 1: performers like that in terms of bundle sizes for JavaScript
Speaker 1: and whether you need that much JavaScript, you know, that's
Speaker 1: books and all topics.
Speaker 4: Of Yeah, I'll tell you this, like for where I
Speaker 4: come from, the average speeds for Internet is still like,
Speaker 4: you know, around like fifteen megabytes, like one hundred megabytes.
Speaker 4: If you're like very very well off, like it's very hard.
Speaker 4: It's very hard to get like like a bite over.
Speaker 4: It's like most people live on like four G connection.
Speaker 4: I was actually checking out a map I would a
Speaker 4: world map for like five G connectivity around the world,
Speaker 4: and Brazil is still, like Central Brazil especially, still very
Speaker 4: much mostly on four G.
Speaker 3: So back when I was working at WIGS, WIGS has
Speaker 3: a pretty strong presence in South America and especially in
Speaker 3: Brazil and Argentina, and that was definitely a concern about
Speaker 3: making sure that we provided proper a good experience in
Speaker 3: those regions. But I want to emphasize that it's not
Speaker 3: just people in certain countries, it's everybody in certain situations.
Speaker 3: I've been in airports in various places where I'm on
Speaker 3: this funky data plan and I'm trying to check my
Speaker 3: flight on an airline website, and it's super slow because
Speaker 3: they're downloading this huge image of an airplane taking off
Speaker 3: that I have absolutely no need for, or so you
Speaker 3: know it, or you might be on on in a
Speaker 3: subway with bad reception or in an elevator or I
Speaker 3: don't know where, but it's this problem of connectivity. Of
Speaker 3: bad connectivity is something that can happen to everybody in
Speaker 3: certain scenarios, and very often in the scenario where you
Speaker 3: especially need to get at that data.
Speaker 4: Absolutely, yeah, absolutely, And I mean it was always at
Speaker 4: the forefront of like my biggest interest in concern when
Speaker 4: I moved to Europe, you know, now I actually like
Speaker 4: I became kind of like skewed towards the better end
Speaker 4: of connectivities. And it's ver easy to build up your biases,
Speaker 4: but you can be humbled very quickly when you come
Speaker 4: to test stuff on connectivities there are its body or
Speaker 4: or you know, unreliable. So one of the things that
Speaker 4: I always care about and drove like used to drive
Speaker 4: where whatever work is performance. So from that ied up
Speaker 4: getting more into depth tools kind of became a thing
Speaker 4: for me. Driving performance initiatives, driving performance as a subject
Speaker 4: also all kind of always walked hand in hand with
Speaker 4: the tools in a way, at least for me. So
Speaker 4: it also walked hand in hand with product, which you know,
Speaker 4: in the end brings me very close to being like
Speaker 4: a product engineer. So it kind of helps self dog
Speaker 4: food within the profession, but it brought me very close
Speaker 4: to death tools over time, so I ended up building
Speaker 4: integrations with highthouses and very early in the days where
Speaker 4: we didn't even have like proper integrations with like house
Speaker 4: and work with these kind of things to facilitate and
Speaker 4: developers usage of death tooling and performance tooling, and over
Speaker 4: time it became kind of the project that I'm currently
Speaker 4: building now, which is a fork of depth tools in
Speaker 4: a way to bring kind of a different vision of
Speaker 4: how I think, not how I think, but like what
Speaker 4: could there when it comes to death tools that I
Speaker 4: was built for the app let's say, quote unquote the
Speaker 4: average developer because one of the biggest problems that I
Speaker 4: always faced, and they ended up being the reason why
Speaker 4: I ended up working death tools and ended up building
Speaker 4: this tool which the two that I say and to
Speaker 4: put like, the tool that I'm talking about is called
Speaker 4: per Flab and the perfect agent, which is Paul per Flab,
Speaker 4: And the reason why I ended up building is just
Speaker 4: one of the things that ended up happening. Even like
Speaker 4: I worked at Spotify for for almost four years, I
Speaker 4: worked to Klina for like almost three years, and a
Speaker 4: very common thing was that developers either did not have
Speaker 4: as much interest to open the tools and explore the
Speaker 4: flame graph and explore you know, those problems the data
Speaker 4: behind it, or they were kind of intimidated by it,
Speaker 4: even at places such as Spotify and Klina, because it
Speaker 4: is a lot of information all at once, and it
Speaker 4: is it can become a very noisy, you know tool
Speaker 4: if you don't if you're not an expert. So for me,
Speaker 4: and then ended up being a way to experiment and
Speaker 4: explore how to build something that is approachable by anyone.
Speaker 1: So you talking about performance the front end? Sorry, Dan,
Speaker 1: it sounds like all yours is on the front end.
Speaker 1: You ever do any back end performance stuff or it
Speaker 1: was all your performance work pretty much been on the
Speaker 1: front end in the browser.
Speaker 4: It's being mostly in the browser.
Speaker 1: Yeah, because I mean, and so I can remember doing
Speaker 1: PHP profiling with like xd bug Kino profiling, So there's
Speaker 1: certainly performance on the back end. I think a lot
Speaker 1: of people take performance on the back end probably for granted,
Speaker 1: you know, because the general rule is if you can
Speaker 1: you know, when I'm dealing with a false stack app,
Speaker 1: you know, I prefer PHP view with a nurse JS
Speaker 1: for instant. That's one of my favorite stacks, and you
Speaker 1: can always say if anytime you can offload stuff from
Speaker 1: the front end to the back end and get your
Speaker 1: data so that when you get to the front end,
Speaker 1: you're not doing a bunch of calculations to do that,
Speaker 1: because the assumption there is that you're going to have
Speaker 1: beef your resources on the back end in terms of
Speaker 1: yours and stuff, and so there's probably not as much
Speaker 1: performance profiling, although I have known people who have been
Speaker 1: really big on performance profiling on the back end, but
Speaker 1: I think it's more it's just sort of assumed, Okay,
Speaker 1: you're back and can handle us better because you've got
Speaker 1: to be for your resources back there, and so the
Speaker 1: front ends we're really where we need to focus on
Speaker 1: performance stuff.
Speaker 3: First of all, I'd like to obviously mention that we've
Speaker 3: had quite a number of people on the show in
Speaker 3: recent months talking about this topic, So if people are
Speaker 3: really interested, there's definitely a lot of shows here to
Speaker 3: check out. We've had people from the Google from Google
Speaker 3: talking specifically about building the tools we had. I think
Speaker 3: I'm not mixing his name up talking about react profiling
Speaker 3: the tools that he built for that, So we've had
Speaker 3: Harry Roberts, so we've had a lot of people talking
Speaker 3: about these subjects. So there's definitely a lot if people
Speaker 3: are interested, there's definitely a lot of content here on
Speaker 3: the podcast about it. But going specifically to your point, Steve,
Speaker 3: it's you know, it's it's tricky because very often it
Speaker 3: is about the back end because it might be just
Speaker 3: simply an SQL query that's not properly optimized or doesn't
Speaker 3: have the properity indexes defined and runs way too slowly
Speaker 3: and something like that. But on the other hand, it
Speaker 3: could your back end could be really, really well optimized,
Speaker 3: but it's worthless because, as I give an example before,
Speaker 3: you're downloading a huge image and that's just eating up
Speaker 3: all your bandwidth, regardless of anything else that you're doing.
Speaker 3: So you really kind of need to take a holistic
Speaker 3: view of performance and try to pinpoint the you know,
Speaker 3: the root causes and identify bottlenecks. And that's usually what
Speaker 3: dev tooling is for, is for identifying those and understanding
Speaker 3: what to focus on and doing the proper attribution of
Speaker 3: locating the areas that are most problematic exactly.
Speaker 4: And it's really like that's one of the main reasons
Speaker 4: why performance is such a difficult subject. Right, I like
Speaker 4: to become let's say, an expert, even like someone that
Speaker 4: is confident to solve performance problems. Is a very steep
Speaker 4: vertical The tooling can be somewhat intimidating if you never
Speaker 4: you know, delve tape into it or dedicated the hours
Speaker 4: for it and force for experienced developers or specialists, what
Speaker 4: is information can be noise for let's say the average
Speaker 4: developer that doesn't go around on debt tools as much.
Speaker 4: So with that premise, I was interested on experimenting around
Speaker 4: and seeing, you know, what I could come up with,
Speaker 4: So I ended up working Chrome dept Tools. The advantage
Speaker 4: of Crome dept Tools. First of all, the source code
Speaker 4: is beautifully documented, so self phone boarding on it very easily,
Speaker 4: was very easy on It is Web components with typescripts,
Speaker 4: so it's actually web technology, so it's really approachable for
Speaker 4: the average developer out there.
Speaker 3: Yeah, who would have thought that Web thev tooling is
Speaker 3: built on web technologies like Inception.
Speaker 4: Yeah, I mean because a lot of people think it's
Speaker 4: simpless plus right, Like because the browser, the Chrome, the
Speaker 4: main chrome is simplus plus the main interface, so a
Speaker 4: lot of people actually end up thinking it is simplus plus,
Speaker 4: which is not the case. It is built on top
Speaker 4: of web technologies, but it communicates through the browser view
Speaker 4: the debugging protocol, and it communicates also via the different
Speaker 4: protocols and within the native layer. I ended up working it,
Speaker 4: and the first try around was building per flab as
Speaker 4: in the main let's say the main app, and per
Speaker 4: flab was a fork of the Performance Panel, so extracting
Speaker 4: it as a sound alone web component. It is already
Speaker 4: built on web components, so extracting it was was not
Speaker 4: as hard. And what ended up happening that I noticed
Speaker 4: is that because I still used the performance a panel
Speaker 4: as the main interface to drive interactions around stead of
Speaker 4: being something very close to like dashboard. And one of
Speaker 4: the things that I that I constantly had a gripe
Speaker 4: with is that dashboards can be also very daunting and
Speaker 4: its sub utilized. Like a lot of dashboard systems and
Speaker 4: SaaS companies have really good product, but it's heavily understand
Speaker 4: underutilized because people don't understand the data, they didn't understand
Speaker 4: what they want to extract out of the data, end
Speaker 4: up sub utilizing the systems and so ended up being
Speaker 4: not as you know, initiate like friendly for earlier stage
Speaker 4: developers or developers that don't have performance as their main
Speaker 4: for tail, let's say, their main subjects.
Speaker 3: It's interesting that this is something that Google themselves have realized,
Speaker 3: like that the performance tab is really daunting. It's a
Speaker 3: very very busy interface with a ton of information, and
Speaker 3: they actually created an alternative tab I think it was
Speaker 3: called Performance Insights or something like that, which was, as
Speaker 3: we've been told on the show, never intended to be
Speaker 3: like a long term solution. Rather, it was this kind
Speaker 3: of a playground where they were testing out various alternative
Speaker 3: ideas that they thought that they would eventually bring back
Speaker 3: into the main performance steps. So kind of playground to
Speaker 3: try out various optimizations and way of making the interface
Speaker 3: clearer and easier to understand, especially to junior developers.
Speaker 4: And the Chrome team has been on an absolute role
Speaker 4: when it comes to improving the experience around that tools
Speaker 4: in general. So my next adventure with building something with
Speaker 4: that tools was I think about like three years ago, no, sorry,
Speaker 4: about a year and a half ago. So when AI
Speaker 4: in general became more broadly disc like part of the
Speaker 4: common discourse, we started having better developer frameworks for building
Speaker 4: with AI and stuff like that. So I was like,
Speaker 4: and everyone was building their own chatbots in a way,
Speaker 4: so I was like, you know, I'm gonna I'm gonna
Speaker 4: see if I can build something that is approachable for anyone.
Speaker 4: And so like I remember being I think it was
Speaker 4: last year's perth Now talking with the different people from
Speaker 4: the death Tools.
Speaker 3: And I also don't know, by the way, Perfonal Performance
Speaker 3: Now is, yes, probably the leading performance related conference takes
Speaker 3: place in Amsterdam, so that's actually fairly close to you.
Speaker 4: Yeah. Yeah, and I'm gonna be there this year as well.
Speaker 4: I'm going to be actually talking this year. Oh cool. Yes,
Speaker 4: it's been on a very similar subject. So this is
Speaker 4: kind of like a teaser, I say, long long form
Speaker 4: teaser of the talk. But so within you know, last
Speaker 4: year's a perf Now I brought up with different members
Speaker 4: of the death Tools teams like uh, kind of like
Speaker 4: let's say a thought exercise of what could it be
Speaker 4: that the smallest possible subset of a depth too looks
Speaker 4: like and you know, helps people engage with it without
Speaker 4: being daunting. So this this was kind of like the
Speaker 4: thig exercise. I was trying to to to have within
Speaker 4: those conversations and a lot of things, and I was
Speaker 4: demoing perth Lab in within the within Perth now as
Speaker 4: well get like gathering some some talks and discussions around
Speaker 4: the tools building. So early this year I started, I
Speaker 4: decided to build Perth Agent. So with perf Agent, startled
Speaker 4: with the same kind of spirit of birth Lab, working
Speaker 4: part of Chrome def tools. So within going too much
Speaker 4: into details, so we have some some partitive depth tools.
Speaker 4: There are the drivers of how dev tools reads and
Speaker 4: trace information. So that trace Engine is something that I
Speaker 4: then extracted. So instead of going for the main performance panel,
Speaker 4: I started to take trace Engine to help me extract
Speaker 4: information out of traces and with that create my own
Speaker 4: agent that's that can understand traces and try to help
Speaker 4: people to solve performance problems. So in a way I
Speaker 4: ended up building a chat what in a way. But
Speaker 4: the some of the things I was trying to play
Speaker 4: with is of course with the advent of generative UI,
Speaker 4: build that thought process of what is the smallest possible
Speaker 4: self self of a debt tool that I can build
Speaker 4: that is progressive and which means it doesn't present all
Speaker 4: the information at once, so it tries to be more
Speaker 4: friendly also like a knowledge assistant and helps with solving
Speaker 4: performance problems, building on top of AI agents that can understand,
Speaker 4: you know, trace files and can understand calls, tax and
Speaker 4: all this kind of stuff and help you solve problems.
Speaker 3: So just to understand, you're building this what as an
Speaker 3: open source project, as a service, as a product that
Speaker 3: you intend to sell as all of the above, what
Speaker 3: is it?
Speaker 4: It's a very good question. I am. I'm building it.
Speaker 4: It's going to be open source, like within the next
Speaker 4: couple of weeks, just cleaning up parts of the code
Speaker 4: and making sure that it is in a good state
Speaker 4: to be open sourced and collaborated with more people because
Speaker 4: it's been just me so far, long givings and whatnot.
Speaker 4: But it's also up of a flab so people can
Speaker 4: not that they can join the wait list, and I'm
Speaker 4: slowly getting people on boarded into the service, mostly because
Speaker 4: it's just me. So inference costs is a thing as well,
Speaker 4: one of the biggest being with the eyes inference costs.
Speaker 4: So I'm going to come up with probably some form
Speaker 4: of pricing model or hopefully sponsorship to keep it free
Speaker 4: or whatever. But I don't have any. I didn't have
Speaker 4: any necessarily like any big plans for it because it's
Speaker 4: built on top of the open source and like most
Speaker 4: of the tools I use nowadays, it's kind of let's
Speaker 4: say common ground. It used to be more the secret
Speaker 4: sauce as people say, where the system prompts, how you
Speaker 4: organize the workflow, and how you organized the tools used
Speaker 4: to be a big power of differentiates one a itol
Speaker 4: from another. But as everyone pretty much started doing this,
Speaker 4: it became less important so much to a lot a
Speaker 4: lot of different companies open source their system prompts and
Speaker 4: how they they're building workflows and things like that. Even
Speaker 4: Yes code now with Copalative open sources the system props.
Speaker 4: That is so so I'll ask my question in a
Speaker 4: slightly different way. Is this your day job? No, it's not. No,
Speaker 4: it's not my day job. It's a good question. It's
Speaker 4: been a passion project. It's being evenings and weekends building
Speaker 4: this stuff. Because now we live in a very interesting
Speaker 4: point in time where there is this inflection point kind
Speaker 4: of coming and I feel like the like as a developer,
Speaker 4: as an engineer, I'm naturally curious, and I feel like
Speaker 4: it's one of the things that a good engineer is
Speaker 4: is that natural curiosity to try stuff and see where
Speaker 4: they fit within your workflow. But I did not want
Speaker 4: to just be a consumer. I also wanted to build
Speaker 4: something with it, and so I ended up studying some
Speaker 4: you know, even deeper ends of models and model platform
Speaker 4: architectures and how to train models, the whole stuff. So
Speaker 4: much so that actually as a side thing, I ended
Speaker 4: up building the workflow to kind of simulate the mystery
Speaker 4: of experts architecture, where you have like a router that
Speaker 4: delegates to different workflows and different especialists. Because the whole
Speaker 4: if you think about performance, as we just opened up
Speaker 4: the show, it has different subjects, right, and that's one
Speaker 4: of the biggest challenges of building a system, an AI
Speaker 4: system with a complex subject such as performance, because it's
Speaker 4: very deep and also has different branches that goes all
Speaker 4: of them go through Deep and Google kind of like
Speaker 4: if you go digging around the Depth Tools source code,
Speaker 4: you will see that they're using kind of the same
Speaker 4: approach where they have AI agents that represent different parts
Speaker 4: of the Depth tools. You have one for the network
Speaker 4: one or call frames, one for CSS, one for elements.
Speaker 4: So it's a very similar way but then within the
Speaker 4: whole thing that I built is has like a router
Speaker 4: that that we understand the request and you know, navigate
Speaker 4: workflows and different specialists to to call within you know,
Speaker 4: the two chain. But it's like it's a very interesting
Speaker 4: inflection point that we're going to have in a few
Speaker 4: in the next few years, and experimenting with it, it's
Speaker 4: felt like almost like an obligation to me to understand
Speaker 4: where do all of us fit in within the next
Speaker 4: few years as developer, where does the web even fitting
Speaker 4: Because one of the things that I started thinking a
Speaker 4: lot about is and that's ended up being the reason
Speaker 4: why and they're building PERF agent is what is a
Speaker 4: dev tool in this new era when we can have
Speaker 4: agents kind of talking to each other solving problems. So
Speaker 4: last week we had last week we had I you
Speaker 4: connect and for you connects. One of the things that
Speaker 4: I wanted to do for your connect is to see
Speaker 4: if I So I built a quick hack over the
Speaker 4: weekend just before I connects where I created an mcpiece
Speaker 4: of a built inside of DEB tools. So the purpose
Speaker 4: of that is because I already built the agent tool
Speaker 4: that understand traces and can solve problems, but you have
Speaker 4: to haunt it traces. So now MCP is all the
Speaker 4: hype and all this kind of stuff, So I wanted
Speaker 4: to see how can I, okay, how can deb tools?
Speaker 4: How can a browser adopt those new things? Right? So
Speaker 4: I started with depth tools and depth tools, So I
Speaker 4: built an MCP serve within debt tools, so it connects
Speaker 4: to clot code, to cursor, whatever is your AI editor
Speaker 4: of choice, and it connects through MCP. So what happens
Speaker 4: is that within the agent, what you can do is
Speaker 4: you just have it ask it to like go fire
Speaker 4: trace and then get insights and it creates this self
Speaker 4: healing loop because as people nowadays have these kind of
Speaker 4: tools to build stuff, and it's more approachable than ever
Speaker 4: for people to prompt their way into building an app. Now,
Speaker 4: as we all know, it doesn't build the most correct way.
Speaker 4: It works, but at what cost we don't know yet.
Speaker 4: So that's kind of the next step, right, instead of
Speaker 4: let's see how would it work within that kind of workflow.
Speaker 3: So it's kind of like within cursor, I could theoretically
Speaker 3: tell it like here's my code, make it faster, and
Speaker 3: it would try to optimize it and then run it
Speaker 3: through dev tools get back some data, make modifications, run
Speaker 3: it again and see whether it's improving or regressing stuff
Speaker 3: like that.
Speaker 4: Yeah, and even like it can even fix actual points
Speaker 4: within it code because I hooked the same internals. So
Speaker 4: within the tools, I hooked the same internals that I
Speaker 4: used to build my agent within the trace engine. So
Speaker 4: when the mcps have is called from cursor and say okay,
Speaker 4: record the trace, and record of course the trace, and
Speaker 4: then then it has another two that will say okay,
Speaker 4: now give me the insights. So we will connected with
Speaker 4: the server, will return actual insights with like a prompt
Speaker 4: to guide like this is what I see on the
Speaker 4: CAULD trace, and we'll return a full on prompt to
Speaker 4: guide cursor on what to patch, what to fix, and
Speaker 4: cursor like can self execute and improve the code based
Speaker 4: on that. So connecting straight into debt tools.
Speaker 3: So what have you seen this kind of system be
Speaker 3: able to achieve? What kind of improvements have you seen
Speaker 3: it make?
Speaker 4: I have just before I built this, and as a
Speaker 4: thought exercise, I introduced a very big problem with inputs,
Speaker 4: So I purposely made the I INP metric worse. So
Speaker 4: without telling curs exactly what I built or what I've done.
Speaker 4: I just said, okay, go fire deb tools with the
Speaker 4: MCP server and fix whatever problem you face. You say
Speaker 4: you see in there, And it did precisely that if
Speaker 4: from the call stack and the prompt that dev tools
Speaker 4: returned back to it, it was able to find within
Speaker 4: the code what was the problem and fix it. So
Speaker 4: it can really create this like self healing look within
Speaker 4: an MCP connection straight into the tools. So this is
Speaker 4: the kind of of experimentation that I'm very interested on
Speaker 4: now on like what is dev tools in this new
Speaker 4: era of agents, and how is a browser to behave
Speaker 4: as an agent with agents? And how can we how
Speaker 4: can both browsers and dev tools embrace this and move
Speaker 4: forward with this new generation of developers, because it's one
Speaker 4: of the things that I was I'm constantly talking with
Speaker 4: different people from from def tools team outside of the
Speaker 4: deft tools team, is like, how can we ensure that
Speaker 4: the web as a platform can adapt and thrive within
Speaker 4: this new self paradigms. On agentic you see perplexities building
Speaker 4: their own browser. You see open ai is not open
Speaker 4: only developing, but they are developing their own browser.
Speaker 3: And oh yeah, I wasn't aware they've.
Speaker 4: Been poaching you know, so they are certainly building their
Speaker 4: own browser. And you have DIA from the browser company
Speaker 4: up there, and here in Stockholm we have a browser
Speaker 4: company called stuff. It's called Strawberry, which I ended up
Speaker 4: looking up with them and talking with them because they're
Speaker 4: very local, so I wanted to talk with with them.
Speaker 4: But they also have an agentic browser. So agentic browsers
Speaker 4: is something that we keep hearing about.
Speaker 3: And what and by agentic browser, do you mean something
Speaker 3: that instead of the actual website, it reads the website
Speaker 3: and then presents me with its own version as it
Speaker 3: were the website that's more appropriate for my particular needs
Speaker 3: and wants. Is that what it does? What does it
Speaker 3: do exactly?
Speaker 4: That is a good point, Like I don't think there's
Speaker 4: a definition yet, So when it comes to agentic browser nowadays,
Speaker 4: they should take a for example, DIA, it should take
Speaker 4: comment which is coming up soon as well for open access.
Speaker 4: For what I have seen is a browser with a
Speaker 4: with an agent panel like with a chatbot on the side,
Speaker 4: so you can either extract information out of a web
Speaker 4: page or you can automate some things. But it's not
Speaker 4: yet entirely what you said, although that seems kind of
Speaker 4: anticlimactic for you for now, it is, but it's definitely
Speaker 4: I feel like every developer out there is seeking that
Speaker 4: next situation of what you said. I myself have written
Speaker 4: a sort of like an essay that's pinned into my
Speaker 4: into my X page, which is about what you just
Speaker 4: said on what is a browser to be when in
Speaker 4: the age of agents? Right, what are we to be?
Speaker 4: Because if you consider if you consider the follow the
Speaker 4: following premise on and when we're going to go back
Speaker 4: to performance in a minute, because it kind of build
Speaker 4: builds up to that. So if you're considering the current
Speaker 4: premise of nowadays, a lot of people are automating more
Speaker 4: and more in regards to what they do on the
Speaker 4: web with with open eyes, Chator or Claude or anything
Speaker 4: as such, and what they get to return is a
Speaker 4: mark down. So there is a natural evolution of that,
Speaker 4: and you see Considerts driving mcpuy or rather the capabilities
Speaker 4: of MCP rendering UI, which ends up being like us
Speaker 4: embedding micro interfaces as a response to agents. There's a
Speaker 4: lot of discussion within the web on what is going
Speaker 4: to be or what is the possibility not necessarily like
Speaker 4: what is going to be what is the possibility of
Speaker 4: us interacting with the web in this kind of agentic workflow.
Speaker 3: So, for example, these days, when you ask Google a question,
Speaker 3: you know the response their reaction to what open Ai
Speaker 3: did when you ask Google a question. In many cases,
Speaker 3: instead of just returning a list of links of possible pages,
Speaker 3: they use a German to generate an answer for you.
Speaker 3: It's not a huge leap. And by the way, in
Speaker 3: many cases, if that answer is actually good enough, then
Speaker 3: that's it. You don't actually go to any page, You
Speaker 3: just use that answer that Google provided. Well, it's theoretically
Speaker 3: not a huge leap to think of a scenario where
Speaker 3: they literally generate a website on the fly that provides
Speaker 3: the exact information you ask for, not just as text,
Speaker 3: but has a holistic website with images, with menus, with
Speaker 3: an interface that's specific to you and your use case
Speaker 3: in your query at that point in time. It's not
Speaker 3: such a huge leap.
Speaker 4: No, it's not so much so that I feel like
Speaker 4: it's kind of converging a lot of people converging too
Speaker 4: something similar. I feel like from within the COME team,
Speaker 4: I know pol Killen is writing a lot about his
Speaker 4: thoughts on what is the to the platform around agents
Speaker 4: and things like that. He has this website called AI
Speaker 4: Focus where he writes a lot of his insights, and
Speaker 4: he's being around for for a long time as well.
Speaker 4: He's the most respected names out there when it comes
Speaker 4: to the platform and depth tools. So he's been writing
Speaker 4: a lot of insights that converted to similar theories and
Speaker 4: similar places where you are arriving where I have a
Speaker 4: arrived at Cancie dogs I see the remix guys are
Speaker 4: arriving on the same kind of points as well, So
Speaker 4: there is a lot of convergence and it's up to
Speaker 4: the platform, of course, to ensure that that there are
Speaker 4: good primitives out there that provides this kind of experience.
Speaker 4: And actually, like I was joking with Malte from Cito
Speaker 4: over Seal, like in passing like that they should have
Speaker 4: an MCP for zero because it kind of enables experiences
Speaker 4: like that, right, if you have a browser that can
Speaker 4: connect to different cps and you can use different services
Speaker 4: to generate. Because it ended up being a taste thing, right,
Speaker 4: some people prefer this model over that model. Some people
Speaker 4: would prefer this AI generator over that AI generator, And
Speaker 4: it's about providing the right primitives in the end to
Speaker 4: access these kind of things. But one of the things
Speaker 4: that I was discussing getting back to the performance part
Speaker 4: of the subject is after I shared that all that
Speaker 4: uh that I did the map for connected five G
Speaker 4: connectivity of the world, one of the things that one
Speaker 4: of the insights that I get nowadays is since a
Speaker 4: lot of the web traffic is being diverted away from websites,
Speaker 4: and because it's so much it's being done via different
Speaker 4: workflows within different agency the open eye or entropic or
Speaker 4: what have you, what ends up happening is that a
Speaker 4: lot of that traffic is not within their mobile anymore
Speaker 4: because what they gain returns the mark now with some
Speaker 4: images in a way if you think about it, not
Speaker 4: I don't think that's the end result for us. The
Speaker 4: web should be rich and full of experience. But as
Speaker 4: an interim, as a operacess or at least like a
Speaker 4: thought provocation, is that that's actually better if you have
Speaker 4: low low work connectivity.
Speaker 3: Right.
Speaker 4: It's kind of what Google Google try to provide with
Speaker 4: what is was it Google Sites or no? What was
Speaker 4: it called? I know what you what you're talking about?
Speaker 4: I don't remember the name as it escapes now yeah,
Speaker 4: exactly the same, but those those like read only or
Speaker 4: read mode for for websites, but you have because mark
Speaker 4: down is so so much faster to render. It kind
Speaker 4: of ends up being a good experience for people that
Speaker 4: lives in for connectivity because they get information they want,
Speaker 4: they can get things done without having to pay heavy.
Speaker 3: But on the other hand, on the other are two
Speaker 3: problems with it. First of all, when you still have
Speaker 3: that model generating the response on the fly, which is
Speaker 3: obviously much slower than a pre prepared response and also
Speaker 3: also much more expensive to generate, certainly consumed a lot
Speaker 3: more energy. So a world where every query for everybody
Speaker 3: is answered with the page that's generated specifically for that person,
Speaker 3: we might get there eventually, but we but it's certainly
Speaker 3: not it's not going to improve the performance of the
Speaker 3: initial load, let's put it this way.
Speaker 4: No, So without getting too much into the economics of it,
Speaker 4: there is of course those scaling problems. But my thought
Speaker 4: on this is is purely on like the platform level,
Speaker 4: on how what kind of experiences are we you going
Speaker 4: to end up having. One of the things that I'm
Speaker 4: very much interested on thinking about nowadays is is kind
Speaker 4: of now that we are capable of generating interfaces on
Speaker 4: the fly. There is a nuance to that, of course,
Speaker 4: but we are capable of eliminating quite eliminating quite a
Speaker 4: lot of noise from the from the UY from the interfaces.
Speaker 4: We don't have to generate static menus and side but
Speaker 4: a sidebar with lots of options and deep nested menus
Speaker 4: things like that. So we now can generate a much
Speaker 4: simpler and much more concise interface and progressively introduce the
Speaker 4: users or nuage the users towards different levels of information.
Speaker 4: So both for depth tools, I feel like that's a
Speaker 4: great thing because you can lower the threshold, lower the
Speaker 4: bearer for entry for developers building something that is more
Speaker 4: approachable at first, and you can of course dig deeper
Speaker 4: with different workflows. And also for websites.
Speaker 3: What would that mean in the end, So putting aside
Speaker 3: the bigger issue of what's the future of the web
Speaker 3: going to be and moving back to the quote unquote
Speaker 3: simpler issue of dev tooling and performance tooling. So you said,
Speaker 3: you build an MCP server that's integrated into depv tools,
Speaker 3: and then you can get information out of dev tools
Speaker 3: into something like cursor or something like that as actionable data.
Speaker 3: What else are you thinking about in the context of
Speaker 3: the future of performance tooling.
Speaker 4: I feel like tooling Google if you observe what Google's
Speaker 4: doing within the Depth tools, I'm kind of helping on
Speaker 4: using a lot of that work to power the other
Speaker 4: experiences I'm building around it. It is a lot on
Speaker 4: providing hints and providing knowledge assistance, providing debugging assistance. So
Speaker 4: there is different, of course, experiences and levels you can dig.
Speaker 4: So you can have something that is more approachable or
Speaker 4: not approachable rather but like something that is more active,
Speaker 4: so it's actively trying to help you, or something that's
Speaker 4: more that's going to be requested. Like currently on Depth Tools,
Speaker 4: you you hover or you click right click to activate
Speaker 4: the eye insights. Some of the insights are being delivered actively,
Speaker 4: but you know there are different experiences you try and
Speaker 4: can try to gauge. I'm trying to lean on on
Speaker 4: the experiences that are more actively helping people or trying
Speaker 4: to deliver something that is more actively trying to help people,
Speaker 4: trying to be more knowledge system at the same time
Speaker 4: as a tool that can help to solve actual problems
Speaker 4: performance problems.
Speaker 3: So one of the things I recall hearing about though,
Speaker 3: to be perfectly honest, I've not actually had a chance
Speaker 3: to try it out and see how good it is.
Speaker 3: Is I recalled, they've been talking about using local Gemini
Speaker 3: to analyze the stack traces in the flame chart, Yes,
Speaker 3: and provide better understanding. Like for those of you like
Speaker 3: what I said, sounds like gobly goop when you are
Speaker 3: record performance session. When you record the performance of a
Speaker 3: session in the Chrome Dev Tool's performance tab, one of
Speaker 3: the things that it does is that it analyzes JavaScript
Speaker 3: execution over time and basically checks at every point in
Speaker 3: time what the stack trace looks like, and basically maps
Speaker 3: the progress of executions through the actual application code. And
Speaker 3: then what you get is called often a flame chart
Speaker 3: because it looks it uses different colors, so it looks
Speaker 3: kind of like a fire. And if the stack is deep,
Speaker 3: then you see a lot of boxes, but if it's shallow,
Speaker 3: then you see fewer, and you can kind of follow
Speaker 3: along and see where executions spent its time, which method
Speaker 3: got called very often, which methods or functions took a
Speaker 3: long time to process, et cetera, When where you blocked
Speaker 3: maybe on a network operation, et cetera, et cetera, And
Speaker 3: those flame charts are sometimes difficult to analyze because again
Speaker 3: they represent a ton of information in a very condensed
Speaker 3: sort of way. So if you can get better hinting
Speaker 3: and suggestions about what it means, like okay, but what
Speaker 3: does this function actually do? That could be very helpful.
Speaker 3: But I've not actually checked the quality of information that
Speaker 3: it provides. I guess that you've been playing with it
Speaker 3: quite a bit. What do you think about it?
Speaker 4: So I'm actually using a lot of the internals that
Speaker 4: they are using to provide that aside, of course the
Speaker 4: on board Gemini model that they have on Chrome. I
Speaker 4: am using Gemini, but the hosted version for that both
Speaker 4: flash and a pro and two point five flash and
Speaker 4: to per five pro for different kind of things. But
Speaker 4: to answer the crux of the massa, it's getting really
Speaker 4: good right now. It's too struggles with some form of directions,
Speaker 4: but that's mostly on prompting. So one of the things
Speaker 4: that I did I use most of the same prompting
Speaker 4: that the Chrome de tools uses for Gemini to analyze
Speaker 4: a flame graph. But the things I differentiate is that
Speaker 4: I'm trying to drive it to be a bit more
Speaker 4: direct when it comes to offering suggestions that are what's
Speaker 4: next to do. So, for instance, I used to kind
Speaker 4: of the same it's pretty much the same prompt but
Speaker 4: what difference is it's the prompt I'm using is in
Speaker 4: some different parts of prompt engineering of how I want
Speaker 4: the model to be more decisive and I also want
Speaker 4: to teach the model. For instance, when it's analyzing a
Speaker 4: bundle from next years, you will know. When s analyzing
Speaker 4: a bundle that comes from different kind of frameworks, you
Speaker 4: will know and will try to give you a bit
Speaker 4: more decisive actions like okay, I see that these kind
Speaker 4: of call frames are coming from this ACT, which is
Speaker 4: a framework asset, so you kind of have a framework
Speaker 4: logic there where you can try to fix. So it's
Speaker 4: trying to be a bit more directed towards giving you
Speaker 4: an answer and then use I use the same model.
Speaker 4: I use the same kind of prompts for the MCP too,
Speaker 4: which kind of helps courser be also be more decisive
Speaker 4: of fixing stuff.
Speaker 3: So again, can you give a concrete example of some
Speaker 3: practical results or outcomes that you've seen from this type
Speaker 3: of operation right now?
Speaker 4: Will be It's kind of in between. It's a bit
Speaker 4: of a hit and miss. It can be a bit
Speaker 4: of a hit to miss, but those two the tools
Speaker 4: are actually it can be a little bit of a hittimism,
Speaker 4: but the tools are evolving quite quite a lot, and
Speaker 4: with more prompt engineering, with more data collection understanding evow
Speaker 4: or like you're having better evows, so it will only
Speaker 4: get better. So it is, it is, There is definitive value,
Speaker 4: especially for people that are trying to understand the flame
Speaker 4: graph the AI asked within Depth tools, the agent I'm
Speaker 4: building can be tools that will help you understand things
Speaker 4: better and hopefully give you insights. So the manage may vary,
Speaker 4: of course, but over time it will only get better.
Speaker 3: So aside from the MCP connectivity, again, what else are
Speaker 3: you building?
Speaker 4: So right now I'm focusing again. I did this MCP
Speaker 4: as a thought process because I mean, I can't ship
Speaker 4: the MCP that are built unfortunately, because I built straight
Speaker 4: into Depth Tools, so I can't ship my own version
Speaker 4: of Depth Tools within Chrome. But I actually am going
Speaker 4: to continue exploring because like I was talking with the
Speaker 4: Depth Tools team, the next thing is could be like
Speaker 4: to help a tool to have a tool that can
Speaker 4: use the bugging protocol to drive different kinds of scenarios.
Speaker 4: Let's say now the agents can also execute. Let's say
Speaker 4: you whilst the agent, can you please measure the interaction
Speaker 4: when you click this button and try to fix any
Speaker 4: performance problems. So instead of you manually go into the
Speaker 4: browser and recording that trace, the agent can do that
Speaker 4: for you and return with the insights and the prompts
Speaker 4: that will help it fix the next stage. Right, So
Speaker 4: that's kind of like it became a thought process that
Speaker 4: I've the thought that I want to try to execute
Speaker 4: on to see how can you make the browser respond
Speaker 4: to as a dev to to an agentic flow. So
Speaker 4: that's something that I'm looking to experiment with next. But
Speaker 4: when it comes to shipping within within the within perflab,
Speaker 4: the next thing for me is helping the agent to
Speaker 4: understand more of the performance as a subject. So because
Speaker 4: right now what I've built is web vitals Insights, so
Speaker 4: it understands different parts of the web virus and it
Speaker 4: can generate quite good insightful reports on how to fix
Speaker 4: different problems from the webviders that it's sees within the trace.
Speaker 4: But then next for me is that the network getting
Speaker 4: better insights for the network, so it does LCP so
Speaker 4: kind of has a network agent there, but I want
Speaker 4: to build better network agents to understand server timings, understand
Speaker 4: the kind of other subjects within the workflow, and help
Speaker 4: with different subjects within performance because there is a lot
Speaker 4: more things to fix. And then alongside of that, bake
Speaker 4: in a memory layer so you can the agent can
Speaker 4: remember how to fix the problems and it gets a
Speaker 4: bit more proactive on fixing problems, understanding that what problems
Speaker 4: is seeing before and what kind of fixes is seen
Speaker 4: before with the memory layer. So I'm interested on seeing
Speaker 4: how the agent starts to self evolve in a way
Speaker 4: when you start introducing your memory layer to solve performance problems.
Speaker 3: So a couple of thoughts of suggestions even about that. So,
Speaker 3: first of all, it seems to me, based on the
Speaker 3: workflow that you're describing that integration with something like Playwright
Speaker 3: might be a more natural evolution. And trying to couse
Speaker 3: Chrome to record kind of headless sessions or sessions that
Speaker 3: don't involve actual user interaction because you're literally automating the
Speaker 3: web in order to perform a genetic operations.
Speaker 4: Yes, and I would go one step further because I
Speaker 4: know I know play right, I've used it for a
Speaker 4: long time but I've been experimenting with and I actually
Speaker 4: like be in contact briefually with the people from Browser
Speaker 4: based and stagehand, so they have this kind of really
Speaker 4: good automation for the browser. One thing that I'm going
Speaker 4: to actually check with them is that I plan to
Speaker 4: check with them, is how much of the dev tools
Speaker 4: that they have access to, because as far as I know,
Speaker 4: within the debugging protocol, it does not really have access
Speaker 4: to yet at least does not have access to some
Speaker 4: of the insights. So the way I'm driving the MCPS
Speaker 4: of experiment that I'm running locally is all based on
Speaker 4: the AI insights, and those are internal depth tools, so
Speaker 4: I'm you leveraging those AI insights the same that Google
Speaker 4: is surfacing for the ask AI within depth tools to
Speaker 4: create a loop with cursor to this self healing mode
Speaker 4: for developers that are using that, either Vibe coding or
Speaker 4: even developers that don't necessarily know how to fix performance problems.
Speaker 4: So within the debugging protocol, you don't necessarily have access
Speaker 4: to that kind of stuff. You can drive a browser,
Speaker 4: a headless browser, or a browser session autonomously, but what
Speaker 4: I'm interested is less on the driving the session autonous,
Speaker 4: but more on getting access to those internals to get
Speaker 4: the information out of the telemetry I get to give
Speaker 4: back within an mcpiece of to cursors or any AI
Speaker 4: editor to solve problems autonomously. So it's less about driving
Speaker 4: the web autonomum autonomously, but more about fixing things autonomously
Speaker 4: based on a telemetry I can get from depth tools.
Speaker 3: So that's kind of what you're doing, these kind of
Speaker 3: loops where I guess where you're you're trying a certain
Speaker 3: well you're not you the age and the model is
Speaker 3: trying a certain optimalization and then checks to see whether
Speaker 3: it actually improves or the grades the actual performance yestt
Speaker 3: making any difference at all.
Speaker 4: Yes, So for that kind of stuff, you can use
Speaker 4: different services. For soundboxing, there's many like Daytona or actually
Speaker 4: Versella has released one recently, so you can use a
Speaker 4: soundboxing service where you can hook up to like an
Speaker 4: automated session to test actual fixes. But then for me,
Speaker 4: there is that pop that, of course I will experiment
Speaker 4: with within perflab, but I'm also interested on the reason
Speaker 4: why I'm playing with internals, dept tools and MCP integration
Speaker 4: within depth tools and different kind of experimentation within a
Speaker 4: browser space is kind of to play with this next
Speaker 4: version of browsers, debv tools, and the web in general
Speaker 4: on how they look would look like or can look
Speaker 4: like rather because as I feel, I feel like I
Speaker 4: think it was, I think it was. I don't remember
Speaker 4: what I said it, but we are very where we
Speaker 4: are one good, really good ux away from a complete
Speaker 4: shift on how we think about interfaces or the web
Speaker 4: in general. So there's a lot of experientation that can
Speaker 4: be had and should be had. So this is kind
Speaker 4: of where I'm navigating nowadays.
Speaker 1: Yeah, I heard that quote recently too. I want to
Speaker 1: say it was West Boss, but yeah, I've heard.
Speaker 4: It was it. Yeah, I mean I'm not sure if
Speaker 4: it was, if it was Wes or or someone else,
Speaker 4: but I have a feeling it was, Yeah, someone from
Speaker 4: those circles earlier this week. So yeah, I know you
Speaker 4: worry about.
Speaker 3: The web becoming something generated by agents for agents.
Speaker 4: There is a layer, so there is layers to that,
Speaker 4: and I share so I will repeat AI focused from
Speaker 4: from Paul Killen, like if you haven't read yet, it's
Speaker 4: really really good. But there are those fears of like
Speaker 4: when it comes to publishers monetization experiences out like the
Speaker 4: excessive may may be accessive automation isn't an actual concern,
Speaker 4: it's very valid one. But one thing that I'm kind
Speaker 4: of looking forward to is for personalization, for enabling what
Speaker 4: people are calling the personal web. So in a way,
Speaker 4: we're kind of going back to your cities where people
Speaker 4: just put silly websites that they just wanted to build
Speaker 4: and build it like that. That's why I love I
Speaker 4: see tools like Lovable, like Vizero as kind of us
Speaker 4: returning to that ingenuity and accessibility of people creating what
Speaker 4: they want and putting things out there. So, of course
Speaker 4: there are different challenges both on a social aspect, on
Speaker 4: an economical aspect, on an environmental aspect that we should
Speaker 4: not be blinded to, but there is also a lot
Speaker 4: of good that can be had.
Speaker 3: One more thing that I wanted to suggest to you,
Speaker 3: especially if you're looking at memory. By the way, I
Speaker 3: was supposed to give a talk at the conference here
Speaker 3: in Tel Avisi in Israel on using hip dumps to
Speaker 3: analyze performance issues in node rather than the browser. I think,
Speaker 3: and that's the point. I think that node is a
Speaker 3: great candidate for these types of analysis. Operations as well.
Speaker 3: If in fact, optimizing node operations in many ways is
Speaker 3: even more difficult than optimizing browser operations. That is true,
Speaker 3: and it's in its effectively a lot of the same
Speaker 3: processes and the same APIs and the same protocols. Yes,
Speaker 3: the solutions that can be applied to the browser can
Speaker 3: be well, obviously they would need to be somewhat modified,
Speaker 3: but can generally be applied to node as well.
Speaker 4: Yes. So for back end is something that is very
Speaker 4: much in my head. We have serviy timings, which I
Speaker 4: wrote about. One of the things that I love about
Speaker 4: modern day tooling is that we have things like INP
Speaker 4: and low of animation frames. I believe is one of
Speaker 4: the best APIs released in a more odern times for
Speaker 4: JavaScript or the web performance in general. I've talked about
Speaker 4: it this year, destination last year and something that I
Speaker 4: really like.
Speaker 3: But when it comes back and at least so bepole
Speaker 3: you proceed, can you elaborate on that a little bit?
Speaker 3: What do you mean by that? Those APIs?
Speaker 4: So I n P Interaction to next Paint is a
Speaker 4: relatively new API made into Chrome Virals as an official
Speaker 4: metric as of March this year, and it's driven by
Speaker 4: an internal metrical animation frame, and the animation frame is
Speaker 4: where you aggregate different sections of work that the browser
Speaker 4: needs to produce in order to ship the next frame.
Speaker 4: So that's why you have long animation frames or low
Speaker 4: app as an API to fetch animation frame. Animation frames
Speaker 4: there are with a timing larger than fifty milliseconds, which
Speaker 4: is the well known or at least is the standardized
Speaker 4: metric for long tasks.
Speaker 3: Yeah, it just to a little bit of context or information.
Speaker 3: It actually comes from the other way around. Basically, in
Speaker 3: order to provide a good visual experience jank fee experience
Speaker 3: on displays, you usually want to achieve something like sixty
Speaker 3: FPS or sixty frames per second. And when you divide
Speaker 3: sixty and when you check how long you have to
Speaker 3: actually work on each frame in order to achieve sixty FPS,
Speaker 3: you see that it's sixteen points something milliseconds per frame.
Speaker 3: So that's where it comes from. Now, given that crowd
Speaker 3: there itself needs to do a little bit of work itself,
Speaker 3: it leaves you with fourteen or fifteen milliseconds to do
Speaker 3: whatever it is that you want to do, and whenever
Speaker 3: you exceed that, you get junk because you cause the
Speaker 3: browser to drop below that sixty FPS. And by the way,
Speaker 3: it's worth noting that on high end displays and on
Speaker 3: three D displays, you actually, like if you're using something
Speaker 3: like GLA smart glasses, you actually want to hit one
Speaker 3: hundred and twenty FPN exactly.
Speaker 4: It's which it's hard, which believe is you even less
Speaker 4: work window. I actually have a talkie my like Dan
Speaker 4: about the background from where where do? Where did we
Speaker 4: come from to where we are now? In regards to
Speaker 4: interactivity metrics, I've long ann mention frames. The name now
Speaker 4: escapes me, but I did last year at REAP Advanced,
Speaker 4: and I also did in person for the Mozilla meet
Speaker 4: up at Personnel the same day. So I think you're
Speaker 4: going to joy I'm going to share the link with
Speaker 4: you for.
Speaker 3: Sure, probably also if you don't, if it's public, we
Speaker 3: can share in this public in the show notes for this.
Speaker 3: By the way, what I would suggest to you if
Speaker 3: you're interested in these things is also participate in the
Speaker 3: Receiver Performance Working Group where we generally talk about all
Speaker 3: these metrics and how we can improve them and involve them.
Speaker 3: But again coming back to what we were talking about,
Speaker 3: So you're talking about this API that can measure and
Speaker 3: see when you're exceeding the allotted time for frames, resulting
Speaker 3: in a jan ky user interface or in a no
Speaker 3: exect somewhat non responsive user interface.
Speaker 4: Yes, so animation frames. The reason why I love it
Speaker 4: so much is within both per flab and pervagent, I
Speaker 4: created histograms use the animation frames to show you activity
Speaker 4: like processing activity based on the different virus thresholds. But
Speaker 4: the reason why I like it so much is that
Speaker 4: it aggregates within one common name space or metric all
Speaker 4: the different problems that can happen for you two that
Speaker 4: might lead to JENK. So you have processing time, input delay,
Speaker 4: and presentation delay, all of which have different subset of
Speaker 4: problems that may impact the different subsections. So my talk
Speaker 4: this year at Gestination is about that. But the reason
Speaker 4: why I love it so much is that it makes
Speaker 4: the conversation a bit more productive because it gathers within
Speaker 4: one common metric. It gathers all different aspects of shipping
Speaker 4: a frame instead of just focusing on processing or just
Speaker 4: focusing on style on layout. So it's really really good
Speaker 4: and makes it the conversation a bit more productive. The
Speaker 4: reason why I use it so much and moving back
Speaker 4: into the back end is because thinking about this kind
Speaker 4: of metric and work, what I'm going to end up
Speaker 4: doing for perflab and pervagent to teach agents how to
Speaker 4: deal with back end is then zoom out into hotel
Speaker 4: and spans in general. Right, So it's about rebuilding attribution
Speaker 4: based on spans and building attribution based on server timings
Speaker 4: hotel spans. So it is one of those things that
Speaker 4: I'm curious to try on. It's like open telemetry span, yeah, exactly,
Speaker 4: So trying to build this kind of attribution, like we
Speaker 4: use the same medal because I feel like for the
Speaker 4: front end, we have so much work done to standardize
Speaker 4: set of timings and build this kind of aggregation of
Speaker 4: data to better understand performance problems, and we could leverage
Speaker 4: some of this knowledge of some of this at least
Speaker 4: way of thinking to build automation for for processing times
Speaker 4: on hotel spans or just serving stuff via servery time
Speaker 4: can be also a great deal help.
Speaker 3: You should be speaking with mattel Colin and the other
Speaker 3: I didn't speak with him at the GEST Nation this year,
Speaker 3: so I'm going to I'm curious to doing more conversations
Speaker 3: about this stuff with him, because I know he's very interested.
Speaker 4: Days I'm actually sharing I've shared per flab with him,
Speaker 4: So let's see what can be done with that.
Speaker 3: And before we finish, what are your future thoughts, Like,
Speaker 3: where are you thinking about taking this tool? What are
Speaker 3: you thinking about in terms of new technologies and new approaches.
Speaker 4: So for me right now, I'm going to be open
Speaker 4: sourcing it in the next couple of weeks and it's
Speaker 4: going to be available for as a party to and
Speaker 4: anyone that want to collaborate. Of course, it's more than
Speaker 4: welcome to and I would, and it's I'm curious to
Speaker 4: see what kind of collaborations comes out of the open
Speaker 4: sourcing of it. The two for me is a way
Speaker 4: of expressing my thoughts and my feeling towards how I
Speaker 4: feel like dev tools can evolved or not evolved, but like,
Speaker 4: how could they be embracing AI first or taking the
Speaker 4: subject of a side is how to build something that
Speaker 4: is approachable for people that are not as technical and
Speaker 4: trying to remove all of those natural barriers that people
Speaker 4: keep bringing up when it comes to the tools, which
Speaker 4: I feel like that tools is such a great, great tool,
Speaker 4: but for me, I'm used to deptols have been used
Speaker 4: for more than a decade right now, and something that
Speaker 4: is kind of second nature. But I'm very acutely aware
Speaker 4: of working with different teams of different knowledge levels. That
Speaker 4: not the case for every developer out there, and we
Speaker 4: can be trying to, you know, force a squarepag into
Speaker 4: a into a circle and just tell them like you
Speaker 4: should learn the tools which which they should if I'm
Speaker 4: being honest, But then you know, the approach may not
Speaker 4: have may have varying success to different people, especially on
Speaker 4: what their interests are. So building something that can be
Speaker 4: the smallest sub self of a debt to building more
Speaker 4: progressive and approachable for people of all knowledge levels is
Speaker 4: something I'm curious and also evolving from the de tools
Speaker 4: on to the browsers space as well, which is where
Speaker 4: I'm growing deeply more interested on experimenting with. You know,
Speaker 4: how can a browser be a better agent and how
Speaker 4: can agents interact better with browsers is something that I'm
Speaker 4: experimenting with nowadays.
Speaker 3: Something that might be really interesting to look at and
Speaker 3: in a certain way both simultaneously easier and more difficult,
Speaker 3: is thinking about how to optimize not necessarily the JavaScript,
Speaker 3: but the CSS. Yes, people underestimate the impact that CSS,
Speaker 3: especially modern sophisticated CSS, can have on rendering performance, and
Speaker 3: in general, I find that developers are a lot less
Speaker 3: familiar with the intricacies of CSS, and CSS is seems
Speaker 3: like something that should be handled by AI. Anything in
Speaker 3: that context would be really helped for So being able
Speaker 3: to play around with the CSS and see how that
Speaker 3: impacts performance sounds something that that could be really really interesting.
Speaker 4: Yes, absolutely, And there is a lot of value on
Speaker 4: getting you know, knowledge assistance and also automation based on
Speaker 4: on on on things that developers consider either bootstrappy or
Speaker 4: hard to approach, so that there is a good mix
Speaker 4: where we can experiment with and build good experiences around.
Speaker 4: And this is kind of where I'm very curious to
Speaker 4: experiment with.
Speaker 3: So if you're going to be releasing this as an
Speaker 3: open source, where will people be able to find it?
Speaker 4: So within from my ex handle, you have the links,
Speaker 4: it's the live versions is agent dot perf lab dot
Speaker 4: io and that's where you have the agent and then
Speaker 4: perflab dot io is where you have let's say the
Speaker 4: legacy one where it's not legacies live and will be
Speaker 4: but that's the let's say the rest version. The Agents
Speaker 4: is where I'm focusing most of my time nowadays to
Speaker 4: experiment with and the Agent. Both Agent and per Flab
Speaker 4: will be fully open source in the coming weeks, but
Speaker 4: the services are going to still stay up and I
Speaker 4: mean I'm constantly going to be writing about it on
Speaker 4: X and Blue Sky as also. You can always catch
Speaker 4: up there, all right.
Speaker 1: So with that, we are a little over time, so
Speaker 1: we're going to start wrapping things up. So if people
Speaker 1: want to follow you and give you money and give
Speaker 1: you accolades and all those kinds of things, were the
Speaker 1: best places to find you.
Speaker 4: So on X, I am web Twitter. So Twitter is
Speaker 4: t W I t R. So literally that the.
Speaker 2: Web two point oh spelling of Twitter, I think.
Speaker 4: Kind of build right around that.
Speaker 3: You should have changed it to WebEx or something.
Speaker 4: I tried. I try to use WebEx because by the
Speaker 4: time I built, like I got my Twitter account, I
Speaker 4: used WebEx everywhere. But WebEx was taken already. So that's why.
Speaker 3: Water there's a company called WebEx.
Speaker 2: I think exactly think there is that sounded familiar as
Speaker 2: soon as you said that.
Speaker 4: So yeah, so so yeah, web web Twitter, t W
Speaker 4: I t R on X and on Blue Sky, I
Speaker 4: am web x at top blue Sky. In consistencies, maybe
Speaker 4: maybe I should try to find some new personal branding
Speaker 4: to to try and like consolidate to this name.
Speaker 3: Look at Italian Roberts who stuck with CSS Wizardry Harry.
Speaker 4: Harry is very fortunate to have one one consistent naming
Speaker 4: everyone every socials. What a legend. But yeah, so you
Speaker 4: can find me, I mean if I believe, if you
Speaker 4: look it up for Venetius de Laqua on Twitter or
Speaker 4: Blue Sky, there will be very little. It's fingers crossed.
Speaker 4: It's not so such a common name. I think that's right.
Speaker 1: Well, you have an interesting combination. I think beforehand you
Speaker 1: were telling us the name of Italian. So you're Brazilian
Speaker 1: with an Italian name, swe.
Speaker 4: Name exactly married to a British woman.
Speaker 1: Oh wow, that's four levels of four level journalism, right, yeah, exactly.
Speaker 2: Already.
Speaker 1: So with that will move to picks picture, the part
Speaker 1: of the show where we can talk about anything we
Speaker 1: want within reason that doesn't get us fined, and tech
Speaker 1: are non tech related, Chuck sunt here. So we probably
Speaker 1: will not get our board game fixed this weekend, but uh,
Speaker 1: never fear. He will be back next week. He's celebrating
Speaker 1: his twentieth wedding anniversary.
Speaker 4: With his wife. This.
Speaker 2: Wow, so that's why he's not here.
Speaker 1: I'll start My picks are generally the at least I
Speaker 1: consider him the high point of any episode with dad jokes.
Speaker 1: But before I get to the dad jokes of the week,
Speaker 1: I'll pick a couple interesting posts that I saw today
Speaker 1: on Hacker News, and in light of the conversation we
Speaker 1: just had about AI cloud Flare, which we know is
Speaker 1: a tool that a lot a lot of people use
Speaker 1: for deploying apps, or for shielding or you know, for
Speaker 1: any number of services they are inducing.
Speaker 2: This is an article in the New York Times.
Speaker 1: They're introducing a default blocking of AI data scrapers. One
Speaker 1: of the uses, Yeah, one of the uses of AI,
Speaker 1: obviously is setting a tool to go out and beat
Speaker 1: the crap out of websites and get all their data off.
Speaker 1: And websites don't like that so much, so they're providing
Speaker 1: that option. Also is Figma, you know, which is a
Speaker 1: very very popular tool for design and any number of things.
Speaker 1: They had a I don't remember the reason for why
Speaker 1: it failed, Dan, Maybe you can refresh my memory where
Speaker 1: they were going to get bought by Adobe and then
Speaker 1: it fell apart.
Speaker 4: Yeah, because of the DOJ.
Speaker 2: There's anti trust, right.
Speaker 4: And they trust some monopoly or something along these lines.
Speaker 2: Right, So they are filing for an IPO.
Speaker 1: They are going to go public and trying to make
Speaker 1: up for the nine million dollars they didn't get from
Speaker 1: Adobe and get money this way. Interesting to see how
Speaker 1: that goes. And now to the dad jokes of the week.
Speaker 1: So let me see where was they at. Oh yeah,
Speaker 1: the other day, this is what not to do if
Speaker 1: you're married. My wife said, for our anniversary, she wanted
Speaker 1: wanted me to take her to one of those restaurants
Speaker 1: where they make all the food in front of you.
Speaker 1: You know, it's really good, and you got the chef
Speaker 1: right there and everything. I said, sure, so I took
Speaker 1: her to Subway.
Speaker 4: Right.
Speaker 1: Subway is a sub sandwich shop where they make it
Speaker 1: right in front of you. If you're not aware of that,
Speaker 1: here's a conversation, the devil saying, this is the lake
Speaker 1: of Lava. You will be spending eternity in me. Actually,
Speaker 1: since we're underground, that would be Magma. Devil says, you
Speaker 1: do understand this is why you're here, right right?
Speaker 4: Yeah?
Speaker 1: And then for you Leslie Nielsen fans. He was amazing median.
Speaker 1: I went to the doctor and the doctor told me
Speaker 1: you have cancer, but we can treat it. I said,
Speaker 1: what's the cure? He says, The cure is a British
Speaker 1: rock band fronted by Robert Smith. But let's try to
Speaker 1: stay focused.
Speaker 3: Yeah, anybody who's ever seen the movie Airplane, Airplane, it's
Speaker 3: full of these types of joke.
Speaker 2: Hospital.
Speaker 1: That's a large building with lots of patients, But that's
Speaker 1: not important exactly, Dan, What do you got?
Speaker 4: Four us picks?
Speaker 3: Not so much in the way of picks I mentioned before.
Speaker 3: Happy to say that at least the war with Iran
Speaker 3: seems to be over, at least for now. Hopefully the
Speaker 3: other wars that we're currently experiencing will be ending soon
Speaker 3: and not soon enough, we will see.
Speaker 4: But those are not my picks.
Speaker 3: So I obviously have opinions on politics, geopolitics and stuff
Speaker 3: like that. I don't share them on the podcast. Obviously
Speaker 3: I don't share them on X so much either, because X,
Speaker 3: from my perspective, is intended for more of the technical
Speaker 3: aspects of what I'm involved in. But if anybody is
Speaker 3: interested in my views on like I said, politics, geopolitics, diplomacy, war, whatever,
Speaker 3: all the soft stuff, also some tech stuff, but also
Speaker 3: a lot of the soft stuff. You can find that
Speaker 3: on Quora, where I post as I don't put up questions.
Speaker 3: Don't think I've ever actually put up a question, but
Speaker 3: I do post a lot of answers, and I've actually
Speaker 3: gotten a lot of views. So I've got over the years,
Speaker 3: I've gotten over six million views. I've been a top
Speaker 3: writer on several occasions and on several topics and in general.
Speaker 3: So if anybody is interested in that part of my life,
Speaker 3: just going to Quora and search for Dan Shapier and
Speaker 3: and see what I think, and see if it matches
Speaker 3: your opinions on stuff. All good, whether you agree or disagree.
Speaker 2: That's interesting.
Speaker 1: I can remember Quora being a thing way back. I
Speaker 1: didn't know it was still a thing to be understand.
Speaker 3: I don't don't stalk, you know, but I do get
Speaker 3: tens of thousands of views there on a weekly basis,
Speaker 3: so apparently people are still using it. I actually also
Speaker 3: think that AI agents use it a lot because it's
Speaker 3: it's information that's easily accessible and usable and rankable by
Speaker 3: by the various AI tools. So so like Wikipedia, it's
Speaker 3: a source of information for a lot of these agents.
Speaker 4: Mmm. Interesting, but anyway, be that is it made. That's
Speaker 4: my pick for today.
Speaker 1: Alrighty, and finally will save the best for last, Benicias,
Speaker 1: you got any picks for us?
Speaker 4: Yes, so set up a couple of times their focus
Speaker 4: from from Polking and really good reader for trying to
Speaker 4: wrap her head around you know this higher level concepts,
Speaker 4: how the platform can play or has played this this
Speaker 4: long game. It's really good information in general, but on
Speaker 4: a non technical one. For tomorrow, we're actually going to
Speaker 4: have the second season of Sandman on Netflix. As avid
Speaker 4: reader of the graphic novel and someone who really enjoys
Speaker 4: season one, I'm looking forward to that big time.
Speaker 2: Sandman.
Speaker 4: Yeah, Sandman.
Speaker 3: Sand Despite new game means fall from grace, It's still
Speaker 3: considered a very good read. It's a brilliant breed separating
Speaker 3: the artists from the art as it were.
Speaker 4: Yeah, yeah, well, Sunman is a brilliant read. The show
Speaker 4: is really really good as well, the season one and
Speaker 4: season two. It's coming up soon, so I'm looking forward
Speaker 4: to that.
Speaker 3: Yeah, season one was good. I enjoyed season one.
Speaker 1: Yeah alrighty, So with that we will wrap up this
Speaker 1: episode of JavaScript Jabber. Thank you to Vinicius for joining
Speaker 1: us from Stockholm. My pleasure and hopefully we feat your
Speaker 1: interest in AI and dev tools, which I have to
Speaker 1: admit was a combination I had not a lot of
Speaker 1: before today. Thanks Dan for joining us and we will
Speaker 1: talk at you next time on JavaScript Jabber.
Speaker 4: Bye Nebe