Performance on the web with Houssein Djirdeh
Houssein Djirdeh joins us to talk about performance on the web. We touch on a lot of different topics like bundle size, framework size and much more.
Houssein Djirdeh joins us to talk about performance on the web. We touch on a lot of different topics like bundle size, framework size and much more.
Sponsors:
[00:00:00] KA: Hello, everyone. Welcome to another episode of Svelte Radio. As always, weāll start with introductions. Iām Kevin, and I ran a site called Svelte School where I teach people about Svelte as well as other fun stuff around the web. Yeah.
[00:00:16] SW: Hey, everyone. Iām Shawn. I work on, I guess, on a bunch of things, but currently Iām a senior developer advocate at AWS.
[00:00:24] AJ: Hey, everyone. Iām Anthony. Yeah, I also work in a bunch of things, but I can only run my own startup called Beyonk, which Iām the CTO. And Iām also a Svelte maintainer.
[00:00:34] KA: Awesome. So, today we have an awesome guest on the show. Can you introduce yourself?
[00:00:40] HD: Yeah, absolutely. My name is Houssein. I am a web developer advocate on Google, on the Google team. So I work with Chrome, but I also work in the focused web as a whole.
[00:00:50] SW: Thatās awesome. Itās kind of my idea to bring in Houssein on the podcast, because I thought heād be a good guest. Houssein has basically dabbled in every framework ever. I didnāt know you started out in Angular actually, but I dug through your blog and I was like, āThis guy did Angular?ā I first met you at Boston, React Boston, where you gave a really good talk that turned into this kind of semi-viral blog post on React performance. And now youāre dabbling in Svelte, and then between you and your twin. You cover all the frameworks. I think thatās a strategy somewhere. So, yeah. I mean, I figured youād be a really good guest, because you have a cross-framework perspective that most people donāt.
[00:01:30] HD: Yeah. No. Thanks for having me. And Iām glad you mentioned that, because I like Iāve never actually properly used Vue, but my twin brother hasnāt. Heās been really involved in that space [inaudible 00:01:39].
[00:01:41] KA: So you started out with Angular. So, can you like talk us through the history of like the frameworks youāve used?
[00:01:48] HD: Yeah. Yeah, for sure. Absolutely. I only gone into web development about 4, 5-ish years ago. And that happened right after I graduated from university. I was in my first job and I was just trying to get my footing and like my first sort of role. And then I sort of joined the web development, and we were building a pretty large insurance platform. And we were using AngularJS. And this was pre-component AngularJS. So weāre talking model view controllers. Weāre talking root scope, and bindings, and dependency injection, and services. So that was kind of my first hurrah into the frameworks world, which is interesting, because I think we see a lot of discussion on Twitter and the like about how a lot of people think itās better to just first understand JavaScript, the basics of JavaScript before you jump in to a framework. Thereāre a lot of other people who think it doesnāt really matter. Learning is learning.
I think that for me was a forcing function for me to just learn JavaScript, because I had no idea what was going on in the beginning. So I felt really lost for at least a few months. Funny story, it was me and my twin brother at the same job sitting side-by-side working on the project for a year.
[00:03:02] KA: I can really relate to getting forced to learn JavaScript by doing frameworks.
[00:03:08] HD: Right? Exaxctly.
[00:03:08] KA: Same thing for me. Yeah.
[00:03:09] HD: Right? Exactly. But I think after a few months, I started actually also spending some time learning JavaScript on my own, but also trying to understand how AngularJS worked. Like things started clicking and I was like, āOkay. Wow! Now, I can see why it makes sense to use a framework.ā And then from then on, it just kept growing where I tried dabbling in Angular 2 when it was brand-new and I started learning how to use Angular 2+. And then about a year after that, I started using React. I actually started using React Native before React, because I was like it might be cool to just build a mobile app, and I had an idea for a mobile app. So whatever time that I had in the side, like I was still doing my day job, but I would go home and I was like, āLet me try to build a mobile app.ā It took a long time. I did it and itās super cool. And then I only used React for the web after I used React Native, which is I think an interesting direction. But I think it was also cool took, because it actually showed me how the framework worked.
[00:03:59] KA: Yeah. Most people usually do it the other way around, right? They start with React, and then React Native.
[00:04:04] HA: Exactly. Exactly.
[00:04:05] SW: Yeah. Well, you wrote the book on React Native too. Thatās fun.
[00:04:09] HA: Yeah. So I worked with Devin, who at the time was at Airbnb, but now he does freelancing and a lot of contracting work. And then I worked for Fullstack.io. Theyāre a publishing company. But I wrote an Angular book with them first. So like a modern AngularJS book. Yeah. And it was an interesting idea at the time, because Angular 2+ is already out. And, Nate, one of the main organizers in the publishing company was like, āMaybe we should actually talk about actually building AngularJS apps using all the new tooling in AngularJS ecosystem.ā How do you build component AngularJS subs? How do you migrate to Angular 2+? Itās a very interesting idea, and I actually saw the merit behind it, because Iāve seen large AngularJS apps in a lot of companies Iāve worked with, and theyāre just trying to figure out what to do with it, right?
So I did that first. And then when I actually started dabbling with React Native for a bit, we talked a bit more and weāre like, āHey, maybe it might be good to have a React Native book.ā And then I also introduced to Devin, and then there was Sophia and Anthony, a few other cool authors, which is nice because I wasnāt only the person writing that book. Itās always good to have some extra hands. But yeah, that was a great experience too.
[00:05:14] SW: Obviously, Iāll be using Angular 1 as well. Is writing Angular 1 to 2 pretty much just rewrite everything? Or is there a better way?
[00:05:23] HA: Yeah. I think thatās a great question, and I think it honestly depends what state the AngularJS app is in. If weāre talking about Angular 1.3 where itās all model, new controls, then yeah, itās going to be a very hard shift. But if youāre using one of the later Angular 1 versions, which are already using components, I think that transition is going to be a lot easier. Itās still going to take a lot of work, but I think itās just having that. I think the book that I wrote kind of also try to describe that. It really depends what state and what version of Angular 1 youāre using.
[00:05:53] SW: And it depends I guess on having good architecture in the first place, making the right decisions, I suppose.
[00:05:58] HA: Exactly.
[00:05:59] KA: So, after React, where did you move? Or are you still stuck in React land?
[00:06:05] HA: Yes. I was working on React, and at that time I was working at a company called Rangle, which is based out of Toronto. And theyāre sort of a dev agency, dev consultancy. So I worked on many different projects that used React, a few projects that used Angular. It was nice to actually shift around and just play around with different frameworks depending on my project. Iāve always wanted to just try to Vue. I guess never got the chance to.
So I kept doing that. Then I joined Google about a year after in that company, and the role at Google that I had that I mentioned was Iām a developer advocate, which is not your typical software engineer. And for anyone listening who doesnāt really know what a developer advocate is, every company I think has slightly different definition of a developer advocate. But theyāre essentially engineers, but they act as a bridge between the core engineering team that are building a project, building a tool, and the community. So if there are new APIs coming out, new features coming out, how do you make sure those are being assessed properly? How do you make sure that developers that use those features know how to use them? What if they have feedback? How do you bring them back and so forth?
I also think itās very different say youāre a developer advocate for something like the web, right? Because weāre not pushing a product. I donāt go around trying to push Chrome. No one in my team does, which is good. So I think thatās also different. So my focus on has been primarily just speed and performance. How do you make sure the web as a whole improves in terms of speed and performance? And the nice thing that I think I have is I joined the team from the Angular frameworks. So itās more so like how do we make sure we have perform in React apps? How do you make we have perform at Angular apps, and Vue apps?
And something that Iāve been doing for the past while now is Iāve been trying to measure and just see the usage of all sites that use frameworks? How expansive is framework usage in the wild? And if we can prove that letās say billions of page loads every week around sites that use frameworks. I think itās a very clear cut evidence that we improve these frameworks. We end up improving the web as a whole, right?
[00:08:03] SW: Yeah. To me, this is kind of like a very notable shift. Honestly, that time I met you in React Boston was the first that I even knew that thereās this sort of new direction. I donāt know if itās actually a new direction. But as far as I understood, basically, Chrome hired Nicole Sullivan to lead and embrace the frameworks, because previously Chrome was very much like use the platform and all of you framework people are just wrong. And it seems like Chrome is a lot friendlier. I donāt know if itās Chrome or I donāt know if itās Google. Google as a whole is a lot friendlier to frameworks than maybe there years ago, which has been awesome to watch and it enables people like Hussein to actually work on cross-framework initiatives that improve the overall performance of things.
[00:08:45] KA: Weāre going to talk about one of those projects that youāve been working on, the PerfTrack. I donāt know. Would you call that a website or a project?
[00:08:54] HA: Both. Web app, I guess. Yeah. Website.
[00:08:57] KA: All right. Weāre just going to take a small break for a sponsor spot, and then weāll be back with more on that.
[BREAK]
[00:09:04] KA: Are you looking to get better at building websites in Svelte? Well, youāre in luck. Level Up Tutorials has tutorials on how to get started. Scott is an excellent teacher and has courses on a broad range of web development topics. So, if you want to support the show and learn Svelte at the same time, check out the Svelte for beginners and Sapper for beginners courses at svelteradio.com/levelup.
[INTERVIEW CONTINUED]
[00:09:29] KA: So, performance track, what is it?
[00:09:31] HA: Maybe a little bit of background before I talk about that exact app. Actually, at the time of React Boston, that was when I kind of wanted to just get some data on how many sights that use React and how well were they performing. And I thought itād just be a good slide, itāll be a good data point. Shawn, I donāt know if you remember. I had one slide in my presentation that just talked about, I think, the number of React sites that have a certain JavaScript byte percentage or percentile. I donāt remember the exact numbers. But I just thought itād be a good thing to just sort of talk about how, āOh! X% of React sites are doing this in terms of performance. Thereās room for us to improve and grow.ā
So I was just looking for ways to actually do that. I was looking for where I can get this kind of information from. And then thereās this project called HTTP Archive that initially was built by, I think, I few Googlers working on it. And I think Steve Souders was one of the original authors. And now itās a pretty large initiative. Many Googlers and even external community members are working on it. And the idea behind HTTP Archive is itās an open source attempt to track how the web is built. And what it does is it actually has a massive pipeline where tests and crawls, millions of URLs every month. Now, I think weāre looking at 5 to 6 million URLs. And then itāll store data on them, all kinds of data. And it does that by running different tools on them. So, webpage test is one of them. It runs Lighthouse on these pages as well. And the nice thing is it just has this massive dataset where anybody, itās completely public. Itās free to use, and anybody can download and just look into these datasets themselves.
There are different ways to do that. One way that Iāve been trying to do that is by using BigQuery. It allows you to run pretty simple queries to just run complex operations. And I was doing that, and thatās when I started getting some data in React. How many React sites exist in this 5, 6 million dataset? How well are they performing? How many data of bytes are they shipping? And I just wrote this super simple Google Doc that has this information for React and a few other frameworks. And I just shared it with a few Googlers internally. And then a massive sort of thread started where people were super interested in seeing this information and they were like, āWow! This is really interesting. We had no idea about the scope of size of these frameworks.ā We donāt even know like how well theyāre performing. And then I realized, āOkay. This is a big bigger than just a one-page Google Doc.ā Because then I was just thinking of ways of now how can I visualize the data? [inaudible 00:11:55] data in my mind. I was using that in talks like React Boston. And I just didnāt know exactly what was the easiest way for people for anybody to sort of see this information, right?
So Iāve had this idea of maybe I can build this dashboard type of site. I spent a while coming up with the name. Ended up with PerfTrack. Obviously, itās not the best name. But at this point itās too late. And I just an idea of like what if I can just visualize this data in some way? Also make it possible for people to just pick different months, because HTTP Archive crawls happen every month. And then what if they can just start seeing friends in this information, right? What if, for example, Angular, Vue, Svelte, so forth, the authors and developers of these frameworks, what if they can actually start seeing how sites that use these frameworks are performing? And what if they can also see patterns?
Letās say they noticed X% of their sites are performing poorly in one aspect? Maybe thatās for a specific reason. Maybe thereās something that they can do about that. That was the idea of PerfTrack. I built the initial version about a year ago also with Svelte. Didnāt look like anything it did right now. It was like a weekend project, and I just wanted to get something up and running. So it had a significant amount of issues, but I just have something up and running. And then I kind of shelved it for a bit. And then I came back and I was like, āOkay. I think now is a good time to just clean it up and make it public.ā And I did that. And I think the one thing that I was really hesitant about was even though all the data is coming from public data sources, which is HTTP Archive and Chrome user experience report, I think I was just super hesitant to have it out in the world because I knew once I did that, people are going to immediately start looking into it and start seeing things like, āOh, framework X is performing a lot better than framework Y on this aspect. I think framework X is a better framework. This is the framework to use.ā And I think thatās just a very unfair judgment to make, right? Looking at a certain number doesnāt mean that a framework is at fault, right?
People use a framework or using a million other things. And so I wrote an about page. I try to emphasize that significantly enough. I still get that sentiment time-to-time. But I think itās natural. As humans, when you see numbers and you just start comparing, youāre bound to do so. But itās something Iāve been stressing quite often.
Yeah, itās up and running. Thereā been a few contributors already actually adding and helping out. Right now what it does is thereās I think about 6 or 7 frameworks at the moment, and it shows some core information from HTTP Archive, like what are the JavaScript byte percentiles? For example, at the 50th percentile, how many bytes or React sides shipping? And it does it for total bytes and image bytes. And then Iām also using Chrome user experience report, which is another data source. And this comes from Chromeās internal metrics pipeline. That actually tells you real user information. Like user metrics, like how are users experiencing first [inaudible 00:14:37] paying your site? How long does it take them to see the largest element in your site? Are they seeing any layout shifts? And thatās all real information. Weāre like weāre not just looking at lab data. Weāre looking at how real users experience it.
So, thereās a section of the site that does that too. Thereās like 6 or 7 metrics where I show that information. But yeah, thereās an initiative called web vitals core vitals, which actually only happen about ā I think we announced it about 6-ish months ago. And the idea is we have all these metrics weāve been telling developers to look at and authors to look at for a while now, right? A lot of people in Chrome are very heavy on these important metrics. Not just Chrome, other browsers as well. But we sort of had this initiative to group these key metrics into one thing.
For example, when we say core vitals, we mean three metrics; largest [inaudible 00:15:21] paint, first infra delay and [inaudible 00:15:24]. The reason why we have that is we think that thatās a very good characteristic of performance. Youāre not only looking at just paint times. Youāre looking at other things, like layout shift and how it takes for the user to interact with your page. And even though that that might change in the future, the metrics might change in the future, the initiative is here to stay. So, thereās a section on PerfTrack that actually show these vital metrics. And I think thatās also for people to see.
[00:15:47] AJ: I donāt know if this is a thing that you know or not, but thereās a notion that the service worker now doesnāt really contribute to the Lighthouse score anymore. There someone telling this morning that itās become less important.
[00:16:02] HA: Yeah. Actually, Iām not super curious. I donāt know if thereās a specific audit that looks for a service worker. So maybe I think he or she was alluding to that, where maybe previously they were talking about a certain audit that suggested using a service worker. And now that specific audit is not doing that anymore, and I think that might be the case. Iām not 100% certain. So Iād double check.
Yeah. In terms of performance, like looking at the performance scores, I think using a service worker or not, thereās no specific flag that will show up. It might improve your performance numbers. And if it does, the number would just be better.
[00:16:32] SW: Cool. It makes sense. So Iām on this site right now. You can toggle between the frameworks. But in the category section, you have the overall framework, and then thereāre the meta-frameworks on top of the frameworks. And I you toggle between most of them, youāll see that, basically, adding like a static or server-rendering layer improves all the metrics across the board. It just like shifts all the web vitals to the right.
[00:16:54] HA: yeah, exactly. And I think that was one nice thing to sort of see, right? We always have these discussions, a lot of people do, about does server-rendering help? Does having meta-frameworks with all these additional tooling by default, like automatic code splitting, static rendering, does all that help by default? I think itās just nice to see some data.
Again, thereāre I think a lot of caveats to mention, like the sample size is different, right? When do you kind of filter like React and NextJS? I think thereāre always a lot of those things that might mind. But, still, looking at the overall data, itās still interesting to see how that number actually shifts when you pick a meta-framework over just using all of a certain framework like React.
[00:17:30] SW: I have a question about, I guess, the metrics. So, to you it might feel like youāve been advocating for this for a while, but I feel like the messaging especially on the new metrics, like I guess first [inaudible 00:17:41] delay, and cumulatively, all shifts are like the new ones. That really only picks up like in the past year or so.
But I think Nicole, in some of her talks, and I think she did like a tour of conferences last year. So, one of the issues that we have in the framework land is that we definitely take a hit in terms of load time to load more data so we can do client-side browsing, side? Nicole is basically saying we donāt have a metric to do the tradeoff between like, āOkay, weāll load more stuff in on the first load to make the subsequent loads much faster.ā Or is the idea that everything should be async anyways. So we will just like chop it off. Whatās the thinking behind that?
[00:18:20] HA: Yeah. No. Iām glad you brought that up. Even like in PerfTrack, right? Itās great to see things like paint times. But just like you said, Shawn, when youāre talking about something like using a client-side framework that has client-side routing, we miss a really important aspect, right? The fact that when you have your JavaScript bundles hydrated at the beginning, just navigating between pages, doesnāt need a new document, right? It doesnāt need a new server interaction. I think thatās just really important if weāre talking about buffering works in general. Thatās a tradeoff you get from having a large JavaScript bundle to begin with. Thatās a really missing blind spot right now in web vitals, in core vitals and metrics in general.
Nicole is super invested into that, which is awesome. Sheās been doing a great job. Itās so nice to have someone like her and other people in the team that are just thinking of that from the lens of frameworks, as well as just sites that client-side routing in general. So thatās a really missing blind spot right now.
But the good news is Nicole and a lot of other people as well on the Chrome speed metrics team are looking into it like actively. I think itās one of the higher priorities right now. And it might take some time, but itāll be hopefully in the near term, not in the very long term. We might start seeing things we can use to actually measure, right? And then itāll be nice to actually look at that and just compare and be like, āOh! Youāre using a framework. Yes, your first paint times might be slow. But youāre getting a lot better in terms of client-side navigations.ā
One thing that weāve also been doing in the Chrome team, like we have a small sub-team that have been working on improving frameworks itself, and weāve been working a lot with the NextJS team, trying to see if we can have that framework improved significantly. So one thing that I did was I actually added some performance marks and measures into NextJSās routing framework. I just had like sort of a custom identifier so people can actually now measure. And if any NextJS developer could extract that information themselves for every route change they make, but itās just NextJS specific, right? How do we scale that now? Do we do that for every framework? Every other router? Do I jump into Reactās router? Add marks and measures? We could. But weāre also thinking of ways to just have it in a high-level instead of trying to do it for every single routing library and framework that exists, right?
[00:20:28] KA: Makes sense.
[00:20:29] SW: Yeah, thatād be awesome. Yeah, I think image, especially for a cumulative layout shift, the image place holder, whatever you call it. Every framework is going to have to have an image component. Gatsby has had this for a while. [inaudible 00:20:41] some PR to NextJS. It seems like itās a really good thing to have. Yeah, I think we need some primitives at some higher level. I donāt know what that looks like.
[00:20:52] HA: For sure. No. Thatās a good point. Yeah. It was Alex, Alex Castle who I think opened up the RFC on NextJS [inaudible 00:20:58]. But yeah, itās super nice to see some core frameworks doing this. But I agree. This might also just mean, right? Like if every framework is using a clone like that, maybe we can have something at the web level that could do this, right?
[00:21:12] SW: With image lazy loading, right? I havenāt actually used it, but doesnāt it do that? Doesnāt do that already? Like why do we need a separate component?
[00:21:20] HA: Yeah. So, we do have ā Yes, we do have an API now to natively lay and load images. So instead of using third-party libraries or running APIs like intersection server, you can just have a loading attribute in any image. Loading lazy, and thatās it. So thatās super. When we announced in a launch, it was great. I think the feedback is super useful. A lot of people had some interesting feedback about what are the thresholds? Can we control how like as the developer, right? I think that now fine-grained control is not available yet, but at least the functionality is there.
So I think the image component, it does lake lazy loading, but it also looks into a lot of other things. It looks into image sizing and responsive images. It looks into having an appropriate place holder. The thing is a lot of things that an image component and a framework like NextJS could do. And the idea I think behind Alexās proposal is, as a developer, I wouldnāt need to worry about any of these. I just want to have my image, define my image, and then let the framework take care of all of it. So, lazy loading is one thing, but thereās just a lot of other aspects on top too.
[00:22:21] SW: Yeah, lots of features. It makes me compare it to React Suspense as well. They intentionally released it without any [inaudible 00:22:30]. Like it was just like a Suspense component, only for loading components. But a lot of people actually want more features. Itās just that we donāt want to release that yet, because we donāt know what it looks like. So I kind of compare it that similar API design. I donāt know. I like API design.
[00:22:44] HA: Yeah. No. Itās a good way to think of it too, for sure.
[00:22:47] KA: So, going back to the data on the site, what kind of conclusions can you draw about frameworks, and specifically ā
[00:22:57] SW: Why is Svelte the best?
[00:22:59] KA: Yes. And React, to be honest, right?
[00:23:05] SW: Svelte is doing very well.
[00:23:06] AJ: I have to make an observation here. Because we started, Svelte has ā The split is really weird on Svelte. So, most the application, like two-fifths are really small, and then one-fifth is really big. And everything else is in between. And itās weird and it makes me think that maybe thereās a bunch of people using Svelte because itās just like super compact and small. A bunch of people are using it just because itās really nice to use and it got a good DX. But when I was thinking about this through, I think that one of the things I thought was maybe itās just because there isnāt as many huge sites, like massive like the Airbnbs using Svelte yet that may be that results from a little bit weight in terms of thereās a lot of hobby projects out there, which are quite minimalistic. And maybe itās not quite the split that I think it is.
[00:23:51] SW: I also wonder about double counts. Like what if a site is using two frameworks? Like in mid-transition?
[00:23:56] HA: 100%, yeah. Anthony, also, thatās a great point, right? I think if you just think of it as from the perspective of a typical developer working in a large scale or a medium-sized company or whatever, and they have to build, I donāt know, an application thatās going to last two or three years. Iām sure having those discussions, theyāre probably like, āShould we use something like Svelte?ā And then when they look at the examples, theyāre probably, āI donāt know, but itās worthwhile. Maybe letās use React.ā I 100% agree. I feel like we definitely need to keep thinking about that too, right? That queue matters. Weāre comparing small hobby projects from tech savvy developers who want to try something new versus these large scale method apps, right? So that definitely matters.
Also, if you look at Svelte and PerfTrack, the sample size is tiny for I think a number of reasons. One of them being I donāt think thereās a very easy way to detect Svelte, right? So, all these tools here, they rely on some detection methods, right? And unless I know for sure that detection method is super bulletproof, like Iām hesitant to add.
[00:24:54] AJ: How is it detecting Svelte, by the way?
[00:24:57] HA: Right now, itās actually looking for, I think, spell dash class identifiers.
[00:25:01] SW: Thatās pretty good. Thatās pretty good.
[00:25:03] HA: Iām sure itās good. Iām sure itās probably maybe ā I donāt know if thereās going to be a false-negative. Iām sure there has to be at least. But I think thatās probably the best way now, right? That we have now.
[00:25:12] AJ: Yeah, right now. Yeah. Yeah, I mean, there was a feature request to change that to be able to change that prefix. We havenāt implemented it yet, but ā
[00:25:18] HA: Really? I didnāt know that. Okay.
[00:25:21] AJ: It might [inaudible 00:25:22] results.
[00:25:23] HA: That might definitely change things.
[00:25:26] KA: Iām looking at like the datasets that are available. So you currently have two datasets per framework, right? If that makes sense, April and May. So are there any plans for adding future months or past months at this point, I guess?
[00:25:41] HA: Yeah, yeah. Absolutely. Yeah HTTP Archive and Chrome user experience where they generate new datasets every month. Iāve just meaning to get the tenth and the time to do so. But I will be adding all the newer datasets. And the idea, what Iām hoping is after your ā However long, anybody can use the site and just sort of see if things have changed, right? Month, to month, to month. I think that is just super useful thing to see, right? As a framework author or a developer, just to see the actual changes in the ecosystem.
Yeah. No. I definitely plan on adding new ones. I think the one thing I do want to mention too is like these crawls happen in the first of the month, but the data becomes available I think around the third week of the month. So itās going to be staggered a bit. But eventually Iām hoping to always just have every month there and we can always just look back and use it as some sort of canonical resource of how well framework sites are doing, or they need improving.
[00:26:36] SW: Is there a room for folding these projects into HTTP Archive? Because, I mean, itās kind of ā Like HTTP Archive also has some other metrics and then it also tracks them overtime. Googlers kind of own it. Is there a path there? Or are they just completely separate?
[00:26:53] HA: Yeah. So when I built PerfTrack, I was kind of just built it from the standpoint of, āOh, this is HTTP Archive.ā But kind of like my visualization take on it. Like I just wanted to have some certainty of points. And youāre right, because if you look at HTTP Archiveās website, thereās a bunch of different reports. Thereās like a state of JavaScript or a state of images report, and they just show some nice high-level graphs on some data points. Itās kind of doing what PerfTrack is trying to do on a lot of other things, which is super cool [inaudible 00:27:21].
So I did have the idea of maybe eventually maybe it could be cool ā I donāt know, state of the frameworks report, right? And PerfTrack doesnāt have to be its own thing, and it could be something that just lives in the HTTP archive website. And Iāve been talking a lot with Rick [inaudible 00:27:35]. He actually helped a lot help me build PerfTrack, because heās built a lot of similar tooling. I donāt know if heās made public yet, but looking at CMF platforms. How a lot of site is using WordPress is doing? How well are sites using Shopify doing? And so forth.
[00:27:48] SW: Oh! Thatās important.
[00:27:49] HA: And thatās super important.
[00:27:51] SW: Wix.
[00:27:51] HA: Wix. Yeah, Squarespace, and the list goes on, Magento, GRPL. But I think weāre both now talking about itās cool that we have two separate things, but maybe we should combine them, right? Like combine efforts. I think people would love to see all that information.
[00:28:04] SW: For sure. Probably reduce the individual lift for you as well, especially like manually syncing. Another similar sort of initiative that I kind of compare this to is tooling.report, which was also cross ā I guess, cross-tooling, like a little bit potentially political. But they put a single number under every logo. And it kind of makes it a little bit of a contest. And I know you wanted to be very sort of like, āYes, there are many dimensions on which like a framework can be evaluated.ā But would you attempt it to reduce everything down a single number?
[00:28:41] HA: I really would. I can lie and say Iām not tempted to do that. I personally would love to see like a high-level number, right? At least it gives you some sort of indication on how well theyāre performing with all the caveats, right? But Iām just so scared to do that, because I know if I do, weāre going to start seeing threat in Hacker News with like, āOh! Take a look. We have Angular, or React, or Vue performing at this number. Can you believe it?ā Iām like, āI donāt know if Iām ready for that.ā
[00:29:09] SW: And I think it was Jason and a bunch of other people. But, yeah, what they did was they just got the maintainers involved. So everyone had buy-in and then everyoneās like, āOkay, well these are some things that we think are valuable and weāll try to be better on those. I think itās more of a buy-in about not ever doing it.
[00:29:25] HA: Great point. Youāre right. And maybe itās just more so like how we can serve that information. And Iām glad I just said too, because Iāve talking to the Angular team for a while, and theyāve been giving me some great feedback. Theyāre like, āOur tool sample size looks interesting.ā Theyāre like, āWeāre pretty certain weāre larger than that. Is there something going on in the detection method?ā
So like theyād been helping me try to figure out if thereās something wrong. And I donāt blame them for thinking that, right?
[00:29:46] SW: Yeah, that is 0.4, and it could be like maybe just itās Angular 1.
[00:29:49] HA: Yeah, exactly. Like the way Iāve done it now is specifically just Angular 2+, which is not including Angular 1. But even then, maybe thereās something missing. Maybe thereās something Iām not doing thatās missing a lot of Angular site. So, youāre right. I think getting buy-in is so important, especially also if we end up trying to show like numbers or high-level indicators that just try to sum everything up. Yeah, I like that. Thatās a good way to put it instead of just saying no.
[00:30:11] AJ: Just another question actually around the data that HTTP Archive uses, what does it gets its list of URLs from? How does it pick them?
[00:30:20] HA: Yeah. Thereāre some certain criteria. I generally donāt know if that specifics can be made public. But it literally just fines. It creates a top list in some sense of popularity. And I think when it started, it was much less URLs. I think thereās only about a million. And only about a year or two ago, they kind of moved it up to a 5 or 6 million. It gets the URLs from Chrome user experience report.
So even though ā And itās kind of confusing at first, but Chrome user experience [inaudible 00:30:48] separate data source, but itās sort of also the source of all the URLs, and itās kind of like just a public mini version of all of Chromeās internal metrics pipeline. We have our own internal metric pipeline. This is just a small public lens to it. And thereāre some specific criteria.
One of them that I know definitely is true is I think usage static reporting has to be enabled in the browser. Thereāre definitely some certain things like that. And then that is all given to HTTP Archive. HTTP Archive gets that list of top URLs, and it does what it needs to do. Thatās also something to keep in mind, because yes, itās a lot of URLs, but weāre also not taking into account the millions of other URLs that are not included into the dataset.
[00:31:28] AJ: Sure. I guess weāll take about tech stack. Thatās the big one.
[00:31:31] KA: Yeah. Thatās the last question. What did you use to build this?
[00:31:35] HA: I use Svelte to build it. Yeah, I did spend a little time trying to figure out what I wanted to use. The nice thing about just building projects every now and then, I think I can dabble and pick something else. But Iāve never used Svelte before, and Iāve always wanted to. And I thought this would be the perfect way to just get familiar with it. Itās not a small app, but itās not very massive either. Thatās your basic components. I got to worry about how components work together. I got to figure out routing and all that. So I thought this would be a good exercise just start thinking about and how Svelte works. Yeah, I picked Svelte.
I was also really considering using Sapper. Did it, and now I kind of regret it. Iāve been meaning trying to figure out how can I add server-rendering somehow with Zapper, which I hope wouldnāt be too bad. But yeah, and itās been a great experience. Yeah, I definitely enjoyed Svelte a lot. And I feel like the one thing that I really sort of enjoyed was Iām trying to think of it as like if I wanted to learn a framework as a brand-new developer, I feel like I was just so intuitive to just create Svelte files at a script tag at a [inaudible 00:32:36] tag and do markup, and thatās it. I didnāt have to worry about JSX. I didnāt have to worry about dependency injection. I was just like, āIf I was to learn a framework from the very beginning four years ago, and if I just saw about the way it was, Iām like, āThis would have been perfect for me.ā Yeah, that was my first thought using Svelte.
[00:32:54] AJ: Thatās good to hear that. Thatās kind of the goal, I guess. Thatās really good.
[00:32:58] SW: I think the phase that appealed to me from Rich was like HTML is the fundamental sort of language of the web that everyone learns to speak first before basically everything else. And every Svelte file is basically a tiny superset of HTML. So, it seems like a very natural progression. I almost want to ā Yeah, I donāt know if itās appropriate, but like beginners, if they want to start with Svelte first, then I think thatās a really good idea actually.
[00:33:27] HA: Yeah, 100%. Yeah. Like I feel like now, if somebody asked me and said, āHey, I wanted to use a framework and I just want to learn how component scoping works, what do I use? I think immediately Iād be like just try Svelte instead of suggesting, āHey, use this other tool. But you got to worry about this and that too, and go learn that,ā right? I think Svelte to be a very nice thing to just try out at first, right? No. I agree. I agree, for sure.
[00:33:49] KA: So I personally went from React to Svelte, and I was so amazed by the developer experience. Itās really nice.
[00:33:59] AJ: I went from Angular 1 to Svelte.
[00:34:00] HA: Oh, wow!
[00:34:03] AJ: Yeah. This is back in the day. Well, I mean, I was previously a backend and I sort of had to do frontend, because I was running a startup based by myself. So I sort of learned frontend, and I learned Angular, because I kind of new a bit anyway. And I have to say itās like night and day going from all the injector pass and stuff and services. And with actually component-sized, the Angular app, the Angular 1. ā I have no idea what it even was, 1.6 maybe. I donāt remember. But it was componentized, but it was just lot of wiring. And we were trying to do the same things and what I looked at Svelte, like what itās already there. Itās already done. So it was an easy sell.
[00:34:41] AH: For sure. When was this? Was this like a number of years ago?
[00:34:44] AJ: This was when Svelte 1 was the thing. So double braces, lots of handle body type stuff. And lots of nice bugs to play with. Yeah, but it was great. It worked. And I started using it for like widgets to put it on the sites, because it was perfect. No runtime, that kind of thing. And then when I had to go work on the main app, it was like, āOh! How do I move this? How do I move this stuff out?ā
[00:35:05] HA: Yeah. Thatās when it gets kind of ā When you start dreading it. But once you start, I feel like itās not as bad as its anticipation.
[00:35:11] AJ: Yeah. Yeah, absolutely.
[00:35:15] SW: Anthony, I got bad news for you. Hussein uses a router, but itās not Routify. Itās this thing, Svelte routing.
[00:35:22] HA: It is.
[00:35:22] AJ: Svelte routing. Wow!
[00:35:23] SW: Iāve never heard of it.
[00:35:24] AJ: I mean, to be honest. There are so many routers with Svelte. Itās unreal. None of them are official, but there are so, so many. I think Routify is brilliant. Routify, Routify I think is fantastic. But I only use it in one project as well. I use Page.js a lot. I had gone with sort of traditional ā
[00:35:39] KA: Page.js? Yeah, thatās like a general one, right?
[00:35:42] AJ: Yeah. Itās just of another router, yeah. This kind of works.
[00:35:46] SW: Thatās pretty nice that it works out of the box sort of.
[00:35:49] AJ: But the fun thing I guess about Svelte, is again ā Because itās quite simple writing. A router is not that difficult. So, a lot of things Iāve done, and I love to think my friends have done actually. Weāve just used the Svelte component with this, and he just changed the angle past them, and itās done, like your routing is finished. And itās that easy and itās like, āWell, do I need a router? Maybe not.ā
[00:36:09] HA: Yeah. To be honest, I just wanted to find something, and I found Svelte routing and I was like, āOkay, I think this might work.ā
[00:36:17] AJ: It worked.
[00:36:17] HA: It worked. Actually, itās done what I needed to do. No. I think that was the one thing I kind of had to get used to. Thereās no first in-class router. I donāt know if Rich or anyone, Anthony or anyone involved, right? Yeah. I can imagine.
[00:36:31] AJ: Yeah. Thereās a plan. We havenāt really picked one it will be yet, or whether itās a grand of rewrite, but itās definitely ā It was definitely an opinion of the maintainers that we would going to have a router. They will bring their own. Letās not be opinionated about it. And itās just the amount of pushback from the [inaudible 00:36:46] and demand has been right. We probably need a router.
[00:36:49] SW: A lot of people come from Vue and expect a router. Itās usually what I ā
[00:36:54] AJ: Yeah, absolutely. Or anything else actually, because everything else has a router, right? Everything else.
[00:36:58] HA: Yeah. Yeah.
[00:36:58] SW: Yup. So, I was going to ask you like some more general questions about where you think the web is heading in the future. Do you think weāre getting heavier or lighter sites in terms of JavaScript payload?
[00:37:14] HA: Yeah. I think weāre definitely getting heavier, and the trends are showing that itās getting heavier. With that being said, browsers are improving, the JavaScript engines, right? Like parsing, compiling. Even executing are improving. So an example, if you look at, letās say, Chrome 41 versus the current version of Chrome and try to load the same bundle of JavaScript. Youāll notice how significant the change has been.
I think thatās also progressing and improving, which is great. With that being said, I do think sites are getting heavier and heavier, and I donāt generally know if theyāre happening proportionally. I think thatās something we ā Yeah. And thatās pretty much my job with a lot of the people that I work with. How could we course correct that? Itās not going to be easy, but itās going to take some time. Yeah.
[00:37:58] KA: What are people putting on their websites thatās so heavy?
[00:38:01] HA: Iām glad you said that, because coming in from a frameworkās angle, theyāre very ā I wouldnāt say anti-framework, but thatās essentially the first thought. Theyād be like, āOh, youāre using a heavy framework.ā Itās immediately costing X JavaScript bytes in your site. Consider to use something else. And thatās not wrong. If youāre using anything that has an initial cost, itās going to really affect your initial performance. But I think when you start looking at also like data as a whole you realize that thatās usually a very small percentage of the total. And you look at, for example, third-party dependencies and third-party bloat. Iāve seen so many statistics. Some of them being 70% of 80% of most sites are coming from third-party scripts. And then you start seeing things like that and youāre like, āWow! Okay. I spent so much time telling people what to do with their first party code.ā But thatās going [inaudible 00:38:50] comparison if theyāre fetching a thousand scripts, right? Theyāre doing a million different things.
I think thatās a very costly thing. That hasnāt improved in so long. Itās only getting worst. Like I know a lot of things are happening now in Chrome as well as other browsers. But thatās something that definitely needs to improve. How could we improve the dependency bloat that we have today?
[00:39:10] AJ: I think essentially, because when I started Beyonk, again, I wasnāt particularly a strong frontender, and I sort of was learning. I was sticking dependencies [inaudible 00:39:20] or anything like that. And the moment you put Lodash in there, even though with the tree shaking, itās not that small. And I saw that in there, and I thought I donāt need this. Iām using like [inaudible 00:39:31] out of it. And I pulled it out and I [inaudible 00:39:33] about two megs and I thought, āWell, hang on a minute. How can I ā I can do better than this.ā
So I started looking at all the dependencies. I started looking at moment, for example. Moment is huge. Page.js is basically a drop and replacement, and itās two kilobytes. So I start on this path and I found [inaudible 00:39:50], a collection of libraries called Just, where it has a bunch of stuff, which is one thing. That replaces Lodash. Thereās moment. Thereās a whole load of like alternatives, but theyāre not very visible. I find people ā People always come at Axios, for example. Axios fetches in the browser. Thatās zero kilobytes, right? All the stuff is kind of built-in. Why isnāt there a bigger kind of visibility? I think now bigger [inaudible 00:40:12].
[00:40:13] SW: Is this just 11 or is there a bigger story? Like why are people still using this stuff?
[00:40:19] AJ: Well, I think itās just browsers. Isnāt it really? Browsers and string [inaudible 00:40:24], things like that. They donāt, and they probably shouldnāt have every single utility in the world on top of them. Itās getting less and less important.
[00:40:32] HA: When we talk about IE 11 or other browsers, right? Like polyfilling is also a huge issue. I think a lot of people, when they build the websites and they need to support legacy browsers, they end up including so many modules, that the vast majority of the users who are using a lot of new browsers donāt need, and thatās a huge one, right? So, thereāre been a lot of things that weāve been advocating for a lot of patterns, like module, no module. I donāt know if you guys heard of that. But itās the idea of adding a module attribute to a script. That doesnāt have any particles. Thatās using neuro syntax. That having a no module script. So browsers can now selectively pick the right one, which makes perfect sense.
But a few folks, me, Jason, Gary and other field people are actually looking at ways we can make that even better, because although thatās super useful, a lot of third-party dependencies in general are being published using legacy code. If somebody who pushes something to NPM, theyāre not trying. Most, I think. Most package are that arenāt trying. Theyāre thinking of ways of using the most newest syntax, right? Theyāre just trying to make it as widely as usable for everybody, for every browser, right? And they just want to make sure that anybody can use a package. And that is also an angle we need to be looking into a lot better.
Yeah. I think that browser support is huge. I also think part of it too is just knowledge, right? Anthony, you might be super savvy enough to actually spend some time looking into your bundles, be like why axios to your ā But if you think of the millions of sites out there and the millions of developers using millions of like legacy applications, they probably donāt even know whatās actually happening beneath the scenes, right? I think just developer knowledge is a huge factor. Yeah.
[00:42:08] AJ: I think actually one of the hardest parts about that process was, and I think itās using Webpack at the time, was actually installing the plugin that gives you the report of whatās in your bundle. That was probably the hardest bit of the whole process. And I think thatās almost ā It feels like it should be built-in almost now, like a flag. Because itās really important. Itās really important.
[00:42:28] HA: 100%. Youāre probably using Webpack, bundle analyzer, or something similar like that.
[00:42:33] AJ: Something like that. Yeah, rings a bell.
[00:42:33] HA: Exactly. And I agree.
[00:42:36] KA: This talk about like dependencies really makes me want to build like a small website that just shows you like alternatives to all these heavy widely used packages. That would be really nice to have.
[00:42:50] SW: You may not need, and then just fill in your dependency.
[00:42:53] AJ: Yeah, thatās a great idea. Actually, there is a guy whoās done this. But itās very unknown small project right now, but the groundwork is there.
[00:43:02] SW: Well, can you name? Like itās going to stay unknown if you donāt.
[00:43:06] AJ: I wish I could. I have to search my GitHub [inaudible 00:43:08]. Maybe itās my pix.
[00:43:12] KA: Yeah. Sounds like something we could promote at some point.
[00:43:16] SW: I have a couple thoughts on this. Thereāre a few things. So, one is I think thereās a culture that I really like in Svelte where Svelte is most peopleās second or third framework. Most people donāt come to Svelte straight away. So theyāre a little bit more thoughtful about dependencies when they come here. When they come to Svelte, partially because they come to Svelte for the bundle size reason. And then I just see like all the tools in Svelte ecosystem tend to be a little bit more conscious about the weight that they add. And I think itās something that comes from Rich Harris himself, like he wrote a blog post which I really like. I think he said ā I think itās called something like small modules, maybe not. Where he kind of questions like this whole culture that we have of like, āOkay. Weāll import this one thing, then imports this other thing.ā And itās like, āYeah, itās a Unix philosophy, but thereās a whole bunch of defensive coding in there, and we donāt really audit what we bring in.ā
But it does tend to have this like weird upside ā Like Stranger Things, like thereās the normal world that everyone else lives in, and thereās an upside world where like itās just like the duplicate versions of every library that people use. Most of them are done by Lou Jackson for some reason. To me, thatās not a world I want to live in as well, because I want everyone to kind of use like a best in class tool. But maybe itās just too difficult at this stage.
The other thing that comes to mind, Iāve sort of mentioned it on this podcast before, but I think since heās your coworker, Llya Grigorik, who wrote High Performance Browser Networking. But he also talks a little bit about how weāre never going to reach the ā Whatever, like 50% of developers who just continuous to build big sites of the way they always have been. They just always ā It just always has worked that way. So they just keep doing that. And if you really want it work, you have to kind of build it into the platform. And I donāt know what the conclusion is, but maybe this is a problem that reaches beyond frameworks and goes into right into browsers.
[00:45:10] HA: For sure. Yeah. My frameworks I think plays a part, but thereās definitely a lot more to it. 100%.
[00:45:18] SW: So it seems like Anthony found the [inaudible 00:45:21].
[00:45:21] AJ: I did. I did. I will look to that from my stars. Yes. Itās really hard to read out their beliefs. Weāll tweet as well from the account, right? But itās pioneerpart with a zero after the PI, smaller-npm-packages. Yeah, have a look. Itās a very short list right now, but if people will contribute, itāll be amazing.
[00:45:40] SW: I kind of call this bending the curve, because itās very 2020 to bend curves. But like I thought weāre having some impacts. I thought things were leveling-off in terms of ā I think one of the other discussion that is coming up is this separation between who build sites and people who build apps. Because people who build apps, youāre trying to compete with native apps, which are hundreds of megabytes, and they donāt care, because they just do the initial download. And itās kind of unfair to hold all these sites on the same benchmark and give them the same tools to express what they need. I think thereās this discussion about like what if we had a new document type that was like document type app or something? I donāt know if youāve seen that, but itās something that Rich Harris is also gotten into.
[00:46:25] HA: Yeah. I did see some discussion around there. Yeah, I think a few other folks also kind of wrote some articles exploring that mindset. Yeah. I remember seeing that, which is super interesting. Yeah, Iām super interested in that kind of information. Like it makes sense to think about things and those lens, but those like how do we make sure things like that could be sustainable in the future. But, yeah. If weāre thinking about predictions, I feel like thatās one thing that I feel like. I donāt know. You might start seeing in ā I donāt know. 5 yearsā time, if thatās not too conservative.
[00:46:54] KA: Yeah. All right. I think thatās it. Do you guys have any picks? I have one. We didnāt warn you. We never warn our guests about things. We should start doing that.
[00:47:03] AJ: Yeah, we should.
[00:47:04] HA: Iām like quickly thinking of something.
[00:47:08] KA: Iāll go first them.
[00:47:09] SW: It doesnāt have to be tech related. It can just be anything that is [inaudible 00:47:12].
[00:47:13] HA: Okay. Nice.
[00:47:14] KA: So Iāve picked a computer mouse today. Itās called a MX Vertical. It looks kind of funny. So think of it like a regular mouse, but you turn it 90 degrees. So you kind of hold it in like a natural way. Itās really nice. Nice for your underarms ā
[00:47:32] SW: Nice for your underarms. What does that mean? Where are you putting your mouse, man?
[00:47:38] KA: Itās like the angle. You have your arm in. Gets better if you turn your hand up 90 degrees. Sort of hard to explain, but it seems to be working for me at least. Iām enjoying it.
[00:47:51] HA: Nice. Yeah. No. I think I definitely need to invest in something like that, for sure.
[00:47:56] AJ: So, for my pick, itās going to be ā Itās actually weird. This is a weird one. I always like ā Itās a tradition now that I have a weird pick that doesnāt make any sense. But itās a laptop I donāt yet own. I have used them before, and Iāve seen a couple of friends whoāve got them. And itās a system 76 [inaudible 00:48:11] new laptop. The name has slipped me by right now. I completely lost the name, but itās there. Kind of alternative to the DELL XBS and HPMV. Itās a very thin ultrabook. The nice thing about it is actually the components inside arenāt soldered to the motherboard. So you can configure the amount of RAM you want. But Iām going to get on with 4o gigs of RAM, because Iāve been stuck with this Dell XBS, which has got 8 gigs of solid RAM for so long. And it really struggles. Itās struggling with this. It struggles with a lot of things. Itās time to upgrade, and I think that soldered RAM should now be a thing of the past. So, Iām looking forward being able to slot some of these sticks in there and stuff. And itās got this really nice spec. Itās very lightweight. Itās lighter than the XBS. In fact, I think itās no point. Itās a hundred grams lighter. So itās just over a kilogram, which is not bad for a sort of very modern i7 laptop with 40 gigs of RAM. And you configure up to a 4 terabyte SSD, which [inaudible 00:49:05]. Letās face it.
[00:49:08] SW: Iām afraid to ask this. But do you guys know how many hours a day you spend on YouTube?
[00:49:12] AJ: Too many.
[00:49:14] HA: Way too many.
[00:49:14] SW: You can actually draw it up on your own stats. You just got a YouTube app, and then you just hit the time watched, and it shows you the hours a day. I spend roughly three hours a day, which kind of makes it my second most used app after my podcast player. So Iām just going to pick YouTube Premium, just because it lets you skip ads. It lets you download stuff. And I actually got the family plan.
So, my dad works in aviation, which side note, is not doing well. So, heās been spending all day watching YouTube. And I was like ā I saw him and I was like heās just sitting through a lot of ads. I just got the family plan. And itās super cheat. It gets a lot of entertainment. And thereās a lot of quality stuff in YouTube, and I like it a lot. So figured Iād pick a Google product here.
[00:50:02] HA: Nice. Yeah. I think I have one. Itās going to be really random, but I donāt know if you all use certain weather apps in your phone to just track the weather. This is like the default weather app that your phone comes with. But somebody recently just told me about this app called Dark Sky.
[00:50:17] SW: They got bought, right?
[00:50:18] HA: I think so. Yeah. They did. Yeah. I didnāt think I would need that kind of information. But I was like, āYou know what? Let me just it.ā A couple of dollars. I think it was the first mobile app Iāve ever bought, like ever. That goes to show like how I never try to buy anything on my phone. Yeah. But I was like, āOh! Itās pretty cool.ā Because it kind of shows some super hyper local information. I think it goes down to the minute of like whether itās going to rain. Whether itās going to snow. So, Iāve been having fun just playing around the app. But yeah, Dark Sky. A random play.
[00:50:46] KA: Does it work like the predictions? Yeah.
[00:50:48] HA: It does work. Yeah. [inaudible 00:50:51]. Prediction is new actually for like ā Ever since Iāve gotten it the past few weeks, like when it says itās going to rain at 7PM, it rains at 7PM. So definitely not 100% accurate, but itās definitely like surprised me. Thatās for use.
[00:51:08] AJ: I have used Dark Sky in the past actually, and I found it to be very, very accurate. It was almost on the minute, which is quite amazing. Itās a great app. Yeah.
[00:51:13] KA: Itās sort of scary at the same time.
[00:51:16] AJ: I felt it was gone, because when Apple bought it, they seem to sort of make it disappear. So itās good itās still around, I guess.
[00:51:24] HA: Yeah.
[00:51:24] KA: Could be only Android maybe?
[00:51:27] HA: No. I have an iPhone. I have an iPhone. I have it. So, Apple did something good.
[00:51:31] AJ: Well, I have to get it then.
[00:51:32] HA: Yeah.
[00:51:32] AJ: They actually have a bunch of really cool [inaudible 00:51:33] libraries as well, such as the time zone converter, which is really useful. Itās worth checking out at GitHub too.
[00:51:40] HA: [inaudible 00:51:40]. I didnāt know that. Wow!
[00:51:41] KA: Okay. So, I think thatās it. Thank you, Zach, for coming on ā
[00:51:47] SW: Studio audience. The studio audience is very excited. Very excited.
[00:51:53] KA: Thank you for coming on and talking to us about PerfTrack, the web and any and all topics we spoke about today.
[00:51:59] HA: For sure. No. Thank you guys. This is great. This was a good chat. For sure.
[00:52:03] AJ: Thank you.
[00:52:03] KA: Awesome. All right, see you next time, listeners. Bye.
[00:52:08] AJ: Bye.
[00:52:08] SW: Bye.
Sponsors:
- Level Up Tutorials brings you cutting-edge, focused & high quality video tutorials for web developers and designers. Support the show and check out the Svelte For Beginners as well as Sapper for Beginners courses.
- You? Svelte Radio is currently looking for another sponsor! Send me a message at sponsor@svelte.school.
- Perf Track
- Google Lighthouse
- Lighthouse
- Tooling Report
- HTTP Archive
- smaller-npm-packages
- Nicole Sullivan: Design Systems, Frameworks and Browsers
- Kevin: MX Vertical - I was talking about forearms, not underarms š
- Shawn: YouTube Premium
- Houssein: Dark Sky
- Antony: System76 Laptop
[00:00:00] KA: Hello, everyone. Welcome to another episode of Svelte Radio. As always, weāll start with introductions. Iām Kevin, and I ran a site called Svelte School where I teach people about Svelte as well as other fun stuff around the web. Yeah.
[00:00:16] SW: Hey, everyone. Iām Shawn. I work on, I guess, on a bunch of things, but currently Iām a senior developer advocate at AWS.
[00:00:24] AJ: Hey, everyone. Iām Anthony. Yeah, I also work in a bunch of things, but I can only run my own startup called Beyonk, which Iām the CTO. And Iām also a Svelte maintainer.
[00:00:34] KA: Awesome. So, today we have an awesome guest on the show. Can you introduce yourself?
[00:00:40] HD: Yeah, absolutely. My name is Houssein. I am a web developer advocate on Google, on the Google team. So I work with Chrome, but I also work in the focused web as a whole.
[00:00:50] SW: Thatās awesome. Itās kind of my idea to bring in Houssein on the podcast, because I thought heād be a good guest. Houssein has basically dabbled in every framework ever. I didnāt know you started out in Angular actually, but I dug through your blog and I was like, āThis guy did Angular?ā I first met you at Boston, React Boston, where you gave a really good talk that turned into this kind of semi-viral blog post on React performance. And now youāre dabbling in Svelte, and then between you and your twin. You cover all the frameworks. I think thatās a strategy somewhere. So, yeah. I mean, I figured youād be a really good guest, because you have a cross-framework perspective that most people donāt.
[00:01:30] HD: Yeah. No. Thanks for having me. And Iām glad you mentioned that, because I like Iāve never actually properly used Vue, but my twin brother hasnāt. Heās been really involved in that space [inaudible 00:01:39].
[00:01:41] KA: So you started out with Angular. So, can you like talk us through the history of like the frameworks youāve used?
[00:01:48] HD: Yeah. Yeah, for sure. Absolutely. I only gone into web development about 4, 5-ish years ago. And that happened right after I graduated from university. I was in my first job and I was just trying to get my footing and like my first sort of role. And then I sort of joined the web development, and we were building a pretty large insurance platform. And we were using AngularJS. And this was pre-component AngularJS. So weāre talking model view controllers. Weāre talking root scope, and bindings, and dependency injection, and services. So that was kind of my first hurrah into the frameworks world, which is interesting, because I think we see a lot of discussion on Twitter and the like about how a lot of people think itās better to just first understand JavaScript, the basics of JavaScript before you jump in to a framework. Thereāre a lot of other people who think it doesnāt really matter. Learning is learning.
I think that for me was a forcing function for me to just learn JavaScript, because I had no idea what was going on in the beginning. So I felt really lost for at least a few months. Funny story, it was me and my twin brother at the same job sitting side-by-side working on the project for a year.
[00:03:02] KA: I can really relate to getting forced to learn JavaScript by doing frameworks.
[00:03:08] HD: Right? Exaxctly.
[00:03:08] KA: Same thing for me. Yeah.
[00:03:09] HD: Right? Exactly. But I think after a few months, I started actually also spending some time learning JavaScript on my own, but also trying to understand how AngularJS worked. Like things started clicking and I was like, āOkay. Wow! Now, I can see why it makes sense to use a framework.ā And then from then on, it just kept growing where I tried dabbling in Angular 2 when it was brand-new and I started learning how to use Angular 2+. And then about a year after that, I started using React. I actually started using React Native before React, because I was like it might be cool to just build a mobile app, and I had an idea for a mobile app. So whatever time that I had in the side, like I was still doing my day job, but I would go home and I was like, āLet me try to build a mobile app.ā It took a long time. I did it and itās super cool. And then I only used React for the web after I used React Native, which is I think an interesting direction. But I think it was also cool took, because it actually showed me how the framework worked.
[00:03:59] KA: Yeah. Most people usually do it the other way around, right? They start with React, and then React Native.
[00:04:04] HA: Exactly. Exactly.
[00:04:05] SW: Yeah. Well, you wrote the book on React Native too. Thatās fun.
[00:04:09] HA: Yeah. So I worked with Devin, who at the time was at Airbnb, but now he does freelancing and a lot of contracting work. And then I worked for Fullstack.io. Theyāre a publishing company. But I wrote an Angular book with them first. So like a modern AngularJS book. Yeah. And it was an interesting idea at the time, because Angular 2+ is already out. And, Nate, one of the main organizers in the publishing company was like, āMaybe we should actually talk about actually building AngularJS apps using all the new tooling in AngularJS ecosystem.ā How do you build component AngularJS subs? How do you migrate to Angular 2+? Itās a very interesting idea, and I actually saw the merit behind it, because Iāve seen large AngularJS apps in a lot of companies Iāve worked with, and theyāre just trying to figure out what to do with it, right?
So I did that first. And then when I actually started dabbling with React Native for a bit, we talked a bit more and weāre like, āHey, maybe it might be good to have a React Native book.ā And then I also introduced to Devin, and then there was Sophia and Anthony, a few other cool authors, which is nice because I wasnāt only the person writing that book. Itās always good to have some extra hands. But yeah, that was a great experience too.
[00:05:14] SW: Obviously, Iāll be using Angular 1 as well. Is writing Angular 1 to 2 pretty much just rewrite everything? Or is there a better way?
[00:05:23] HA: Yeah. I think thatās a great question, and I think it honestly depends what state the AngularJS app is in. If weāre talking about Angular 1.3 where itās all model, new controls, then yeah, itās going to be a very hard shift. But if youāre using one of the later Angular 1 versions, which are already using components, I think that transition is going to be a lot easier. Itās still going to take a lot of work, but I think itās just having that. I think the book that I wrote kind of also try to describe that. It really depends what state and what version of Angular 1 youāre using.
[00:05:53] SW: And it depends I guess on having good architecture in the first place, making the right decisions, I suppose.
[00:05:58] HA: Exactly.
[00:05:59] KA: So, after React, where did you move? Or are you still stuck in React land?
[00:06:05] HA: Yes. I was working on React, and at that time I was working at a company called Rangle, which is based out of Toronto. And theyāre sort of a dev agency, dev consultancy. So I worked on many different projects that used React, a few projects that used Angular. It was nice to actually shift around and just play around with different frameworks depending on my project. Iāve always wanted to just try to Vue. I guess never got the chance to.
So I kept doing that. Then I joined Google about a year after in that company, and the role at Google that I had that I mentioned was Iām a developer advocate, which is not your typical software engineer. And for anyone listening who doesnāt really know what a developer advocate is, every company I think has slightly different definition of a developer advocate. But theyāre essentially engineers, but they act as a bridge between the core engineering team that are building a project, building a tool, and the community. So if there are new APIs coming out, new features coming out, how do you make sure those are being assessed properly? How do you make sure that developers that use those features know how to use them? What if they have feedback? How do you bring them back and so forth?
I also think itās very different say youāre a developer advocate for something like the web, right? Because weāre not pushing a product. I donāt go around trying to push Chrome. No one in my team does, which is good. So I think thatās also different. So my focus on has been primarily just speed and performance. How do you make sure the web as a whole improves in terms of speed and performance? And the nice thing that I think I have is I joined the team from the Angular frameworks. So itās more so like how do we make sure we have perform in React apps? How do you make we have perform at Angular apps, and Vue apps?
And something that Iāve been doing for the past while now is Iāve been trying to measure and just see the usage of all sites that use frameworks? How expansive is framework usage in the wild? And if we can prove that letās say billions of page loads every week around sites that use frameworks. I think itās a very clear cut evidence that we improve these frameworks. We end up improving the web as a whole, right?
[00:08:03] SW: Yeah. To me, this is kind of like a very notable shift. Honestly, that time I met you in React Boston was the first that I even knew that thereās this sort of new direction. I donāt know if itās actually a new direction. But as far as I understood, basically, Chrome hired Nicole Sullivan to lead and embrace the frameworks, because previously Chrome was very much like use the platform and all of you framework people are just wrong. And it seems like Chrome is a lot friendlier. I donāt know if itās Chrome or I donāt know if itās Google. Google as a whole is a lot friendlier to frameworks than maybe there years ago, which has been awesome to watch and it enables people like Hussein to actually work on cross-framework initiatives that improve the overall performance of things.
[00:08:45] KA: Weāre going to talk about one of those projects that youāve been working on, the PerfTrack. I donāt know. Would you call that a website or a project?
[00:08:54] HA: Both. Web app, I guess. Yeah. Website.
[00:08:57] KA: All right. Weāre just going to take a small break for a sponsor spot, and then weāll be back with more on that.
[BREAK]
[00:09:04] KA: Are you looking to get better at building websites in Svelte? Well, youāre in luck. Level Up Tutorials has tutorials on how to get started. Scott is an excellent teacher and has courses on a broad range of web development topics. So, if you want to support the show and learn Svelte at the same time, check out the Svelte for beginners and Sapper for beginners courses at svelteradio.com/levelup.
[INTERVIEW CONTINUED]
[00:09:29] KA: So, performance track, what is it?
[00:09:31] HA: Maybe a little bit of background before I talk about that exact app. Actually, at the time of React Boston, that was when I kind of wanted to just get some data on how many sights that use React and how well were they performing. And I thought itād just be a good slide, itāll be a good data point. Shawn, I donāt know if you remember. I had one slide in my presentation that just talked about, I think, the number of React sites that have a certain JavaScript byte percentage or percentile. I donāt remember the exact numbers. But I just thought itād be a good thing to just sort of talk about how, āOh! X% of React sites are doing this in terms of performance. Thereās room for us to improve and grow.ā
So I was just looking for ways to actually do that. I was looking for where I can get this kind of information from. And then thereās this project called HTTP Archive that initially was built by, I think, I few Googlers working on it. And I think Steve Souders was one of the original authors. And now itās a pretty large initiative. Many Googlers and even external community members are working on it. And the idea behind HTTP Archive is itās an open source attempt to track how the web is built. And what it does is it actually has a massive pipeline where tests and crawls, millions of URLs every month. Now, I think weāre looking at 5 to 6 million URLs. And then itāll store data on them, all kinds of data. And it does that by running different tools on them. So, webpage test is one of them. It runs Lighthouse on these pages as well. And the nice thing is it just has this massive dataset where anybody, itās completely public. Itās free to use, and anybody can download and just look into these datasets themselves.
There are different ways to do that. One way that Iāve been trying to do that is by using BigQuery. It allows you to run pretty simple queries to just run complex operations. And I was doing that, and thatās when I started getting some data in React. How many React sites exist in this 5, 6 million dataset? How well are they performing? How many data of bytes are they shipping? And I just wrote this super simple Google Doc that has this information for React and a few other frameworks. And I just shared it with a few Googlers internally. And then a massive sort of thread started where people were super interested in seeing this information and they were like, āWow! This is really interesting. We had no idea about the scope of size of these frameworks.ā We donāt even know like how well theyāre performing. And then I realized, āOkay. This is a big bigger than just a one-page Google Doc.ā Because then I was just thinking of ways of now how can I visualize the data? [inaudible 00:11:55] data in my mind. I was using that in talks like React Boston. And I just didnāt know exactly what was the easiest way for people for anybody to sort of see this information, right?
So Iāve had this idea of maybe I can build this dashboard type of site. I spent a while coming up with the name. Ended up with PerfTrack. Obviously, itās not the best name. But at this point itās too late. And I just an idea of like what if I can just visualize this data in some way? Also make it possible for people to just pick different months, because HTTP Archive crawls happen every month. And then what if they can just start seeing friends in this information, right? What if, for example, Angular, Vue, Svelte, so forth, the authors and developers of these frameworks, what if they can actually start seeing how sites that use these frameworks are performing? And what if they can also see patterns?
Letās say they noticed X% of their sites are performing poorly in one aspect? Maybe thatās for a specific reason. Maybe thereās something that they can do about that. That was the idea of PerfTrack. I built the initial version about a year ago also with Svelte. Didnāt look like anything it did right now. It was like a weekend project, and I just wanted to get something up and running. So it had a significant amount of issues, but I just have something up and running. And then I kind of shelved it for a bit. And then I came back and I was like, āOkay. I think now is a good time to just clean it up and make it public.ā And I did that. And I think the one thing that I was really hesitant about was even though all the data is coming from public data sources, which is HTTP Archive and Chrome user experience report, I think I was just super hesitant to have it out in the world because I knew once I did that, people are going to immediately start looking into it and start seeing things like, āOh, framework X is performing a lot better than framework Y on this aspect. I think framework X is a better framework. This is the framework to use.ā And I think thatās just a very unfair judgment to make, right? Looking at a certain number doesnāt mean that a framework is at fault, right?
People use a framework or using a million other things. And so I wrote an about page. I try to emphasize that significantly enough. I still get that sentiment time-to-time. But I think itās natural. As humans, when you see numbers and you just start comparing, youāre bound to do so. But itās something Iāve been stressing quite often.
Yeah, itās up and running. Thereā been a few contributors already actually adding and helping out. Right now what it does is thereās I think about 6 or 7 frameworks at the moment, and it shows some core information from HTTP Archive, like what are the JavaScript byte percentiles? For example, at the 50th percentile, how many bytes or React sides shipping? And it does it for total bytes and image bytes. And then Iām also using Chrome user experience report, which is another data source. And this comes from Chromeās internal metrics pipeline. That actually tells you real user information. Like user metrics, like how are users experiencing first [inaudible 00:14:37] paying your site? How long does it take them to see the largest element in your site? Are they seeing any layout shifts? And thatās all real information. Weāre like weāre not just looking at lab data. Weāre looking at how real users experience it.
So, thereās a section of the site that does that too. Thereās like 6 or 7 metrics where I show that information. But yeah, thereās an initiative called web vitals core vitals, which actually only happen about ā I think we announced it about 6-ish months ago. And the idea is we have all these metrics weāve been telling developers to look at and authors to look at for a while now, right? A lot of people in Chrome are very heavy on these important metrics. Not just Chrome, other browsers as well. But we sort of had this initiative to group these key metrics into one thing.
For example, when we say core vitals, we mean three metrics; largest [inaudible 00:15:21] paint, first infra delay and [inaudible 00:15:24]. The reason why we have that is we think that thatās a very good characteristic of performance. Youāre not only looking at just paint times. Youāre looking at other things, like layout shift and how it takes for the user to interact with your page. And even though that that might change in the future, the metrics might change in the future, the initiative is here to stay. So, thereās a section on PerfTrack that actually show these vital metrics. And I think thatās also for people to see.
[00:15:47] AJ: I donāt know if this is a thing that you know or not, but thereās a notion that the service worker now doesnāt really contribute to the Lighthouse score anymore. There someone telling this morning that itās become less important.
[00:16:02] HA: Yeah. Actually, Iām not super curious. I donāt know if thereās a specific audit that looks for a service worker. So maybe I think he or she was alluding to that, where maybe previously they were talking about a certain audit that suggested using a service worker. And now that specific audit is not doing that anymore, and I think that might be the case. Iām not 100% certain. So Iād double check.
Yeah. In terms of performance, like looking at the performance scores, I think using a service worker or not, thereās no specific flag that will show up. It might improve your performance numbers. And if it does, the number would just be better.
[00:16:32] SW: Cool. It makes sense. So Iām on this site right now. You can toggle between the frameworks. But in the category section, you have the overall framework, and then thereāre the meta-frameworks on top of the frameworks. And I you toggle between most of them, youāll see that, basically, adding like a static or server-rendering layer improves all the metrics across the board. It just like shifts all the web vitals to the right.
[00:16:54] HA: yeah, exactly. And I think that was one nice thing to sort of see, right? We always have these discussions, a lot of people do, about does server-rendering help? Does having meta-frameworks with all these additional tooling by default, like automatic code splitting, static rendering, does all that help by default? I think itās just nice to see some data.
Again, thereāre I think a lot of caveats to mention, like the sample size is different, right? When do you kind of filter like React and NextJS? I think thereāre always a lot of those things that might mind. But, still, looking at the overall data, itās still interesting to see how that number actually shifts when you pick a meta-framework over just using all of a certain framework like React.
[00:17:30] SW: I have a question about, I guess, the metrics. So, to you it might feel like youāve been advocating for this for a while, but I feel like the messaging especially on the new metrics, like I guess first [inaudible 00:17:41] delay, and cumulatively, all shifts are like the new ones. That really only picks up like in the past year or so.
But I think Nicole, in some of her talks, and I think she did like a tour of conferences last year. So, one of the issues that we have in the framework land is that we definitely take a hit in terms of load time to load more data so we can do client-side browsing, side? Nicole is basically saying we donāt have a metric to do the tradeoff between like, āOkay, weāll load more stuff in on the first load to make the subsequent loads much faster.ā Or is the idea that everything should be async anyways. So we will just like chop it off. Whatās the thinking behind that?
[00:18:20] HA: Yeah. No. Iām glad you brought that up. Even like in PerfTrack, right? Itās great to see things like paint times. But just like you said, Shawn, when youāre talking about something like using a client-side framework that has client-side routing, we miss a really important aspect, right? The fact that when you have your JavaScript bundles hydrated at the beginning, just navigating between pages, doesnāt need a new document, right? It doesnāt need a new server interaction. I think thatās just really important if weāre talking about buffering works in general. Thatās a tradeoff you get from having a large JavaScript bundle to begin with. Thatās a really missing blind spot right now in web vitals, in core vitals and metrics in general.
Nicole is super invested into that, which is awesome. Sheās been doing a great job. Itās so nice to have someone like her and other people in the team that are just thinking of that from the lens of frameworks, as well as just sites that client-side routing in general. So thatās a really missing blind spot right now.
But the good news is Nicole and a lot of other people as well on the Chrome speed metrics team are looking into it like actively. I think itās one of the higher priorities right now. And it might take some time, but itāll be hopefully in the near term, not in the very long term. We might start seeing things we can use to actually measure, right? And then itāll be nice to actually look at that and just compare and be like, āOh! Youāre using a framework. Yes, your first paint times might be slow. But youāre getting a lot better in terms of client-side navigations.ā
One thing that weāve also been doing in the Chrome team, like we have a small sub-team that have been working on improving frameworks itself, and weāve been working a lot with the NextJS team, trying to see if we can have that framework improved significantly. So one thing that I did was I actually added some performance marks and measures into NextJSās routing framework. I just had like sort of a custom identifier so people can actually now measure. And if any NextJS developer could extract that information themselves for every route change they make, but itās just NextJS specific, right? How do we scale that now? Do we do that for every framework? Every other router? Do I jump into Reactās router? Add marks and measures? We could. But weāre also thinking of ways to just have it in a high-level instead of trying to do it for every single routing library and framework that exists, right?
[00:20:28] KA: Makes sense.
[00:20:29] SW: Yeah, thatād be awesome. Yeah, I think image, especially for a cumulative layout shift, the image place holder, whatever you call it. Every framework is going to have to have an image component. Gatsby has had this for a while. [inaudible 00:20:41] some PR to NextJS. It seems like itās a really good thing to have. Yeah, I think we need some primitives at some higher level. I donāt know what that looks like.
[00:20:52] HA: For sure. No. Thatās a good point. Yeah. It was Alex, Alex Castle who I think opened up the RFC on NextJS [inaudible 00:20:58]. But yeah, itās super nice to see some core frameworks doing this. But I agree. This might also just mean, right? Like if every framework is using a clone like that, maybe we can have something at the web level that could do this, right?
[00:21:12] SW: With image lazy loading, right? I havenāt actually used it, but doesnāt it do that? Doesnāt do that already? Like why do we need a separate component?
[00:21:20] HA: Yeah. So, we do have ā Yes, we do have an API now to natively lay and load images. So instead of using third-party libraries or running APIs like intersection server, you can just have a loading attribute in any image. Loading lazy, and thatās it. So thatās super. When we announced in a launch, it was great. I think the feedback is super useful. A lot of people had some interesting feedback about what are the thresholds? Can we control how like as the developer, right? I think that now fine-grained control is not available yet, but at least the functionality is there.
So I think the image component, it does lake lazy loading, but it also looks into a lot of other things. It looks into image sizing and responsive images. It looks into having an appropriate place holder. The thing is a lot of things that an image component and a framework like NextJS could do. And the idea I think behind Alexās proposal is, as a developer, I wouldnāt need to worry about any of these. I just want to have my image, define my image, and then let the framework take care of all of it. So, lazy loading is one thing, but thereās just a lot of other aspects on top too.
[00:22:21] SW: Yeah, lots of features. It makes me compare it to React Suspense as well. They intentionally released it without any [inaudible 00:22:30]. Like it was just like a Suspense component, only for loading components. But a lot of people actually want more features. Itās just that we donāt want to release that yet, because we donāt know what it looks like. So I kind of compare it that similar API design. I donāt know. I like API design.
[00:22:44] HA: Yeah. No. Itās a good way to think of it too, for sure.
[00:22:47] KA: So, going back to the data on the site, what kind of conclusions can you draw about frameworks, and specifically ā
[00:22:57] SW: Why is Svelte the best?
[00:22:59] KA: Yes. And React, to be honest, right?
[00:23:05] SW: Svelte is doing very well.
[00:23:06] AJ: I have to make an observation here. Because we started, Svelte has ā The split is really weird on Svelte. So, most the application, like two-fifths are really small, and then one-fifth is really big. And everything else is in between. And itās weird and it makes me think that maybe thereās a bunch of people using Svelte because itās just like super compact and small. A bunch of people are using it just because itās really nice to use and it got a good DX. But when I was thinking about this through, I think that one of the things I thought was maybe itās just because there isnāt as many huge sites, like massive like the Airbnbs using Svelte yet that may be that results from a little bit weight in terms of thereās a lot of hobby projects out there, which are quite minimalistic. And maybe itās not quite the split that I think it is.
[00:23:51] SW: I also wonder about double counts. Like what if a site is using two frameworks? Like in mid-transition?
[00:23:56] HA: 100%, yeah. Anthony, also, thatās a great point, right? I think if you just think of it as from the perspective of a typical developer working in a large scale or a medium-sized company or whatever, and they have to build, I donāt know, an application thatās going to last two or three years. Iām sure having those discussions, theyāre probably like, āShould we use something like Svelte?ā And then when they look at the examples, theyāre probably, āI donāt know, but itās worthwhile. Maybe letās use React.ā I 100% agree. I feel like we definitely need to keep thinking about that too, right? That queue matters. Weāre comparing small hobby projects from tech savvy developers who want to try something new versus these large scale method apps, right? So that definitely matters.
Also, if you look at Svelte and PerfTrack, the sample size is tiny for I think a number of reasons. One of them being I donāt think thereās a very easy way to detect Svelte, right? So, all these tools here, they rely on some detection methods, right? And unless I know for sure that detection method is super bulletproof, like Iām hesitant to add.
[00:24:54] AJ: How is it detecting Svelte, by the way?
[00:24:57] HA: Right now, itās actually looking for, I think, spell dash class identifiers.
[00:25:01] SW: Thatās pretty good. Thatās pretty good.
[00:25:03] HA: Iām sure itās good. Iām sure itās probably maybe ā I donāt know if thereās going to be a false-negative. Iām sure there has to be at least. But I think thatās probably the best way now, right? That we have now.
[00:25:12] AJ: Yeah, right now. Yeah. Yeah, I mean, there was a feature request to change that to be able to change that prefix. We havenāt implemented it yet, but ā
[00:25:18] HA: Really? I didnāt know that. Okay.
[00:25:21] AJ: It might [inaudible 00:25:22] results.
[00:25:23] HA: That might definitely change things.
[00:25:26] KA: Iām looking at like the datasets that are available. So you currently have two datasets per framework, right? If that makes sense, April and May. So are there any plans for adding future months or past months at this point, I guess?
[00:25:41] HA: Yeah, yeah. Absolutely. Yeah HTTP Archive and Chrome user experience where they generate new datasets every month. Iāve just meaning to get the tenth and the time to do so. But I will be adding all the newer datasets. And the idea, what Iām hoping is after your ā However long, anybody can use the site and just sort of see if things have changed, right? Month, to month, to month. I think that is just super useful thing to see, right? As a framework author or a developer, just to see the actual changes in the ecosystem.
Yeah. No. I definitely plan on adding new ones. I think the one thing I do want to mention too is like these crawls happen in the first of the month, but the data becomes available I think around the third week of the month. So itās going to be staggered a bit. But eventually Iām hoping to always just have every month there and we can always just look back and use it as some sort of canonical resource of how well framework sites are doing, or they need improving.
[00:26:36] SW: Is there a room for folding these projects into HTTP Archive? Because, I mean, itās kind of ā Like HTTP Archive also has some other metrics and then it also tracks them overtime. Googlers kind of own it. Is there a path there? Or are they just completely separate?
[00:26:53] HA: Yeah. So when I built PerfTrack, I was kind of just built it from the standpoint of, āOh, this is HTTP Archive.ā But kind of like my visualization take on it. Like I just wanted to have some certainty of points. And youāre right, because if you look at HTTP Archiveās website, thereās a bunch of different reports. Thereās like a state of JavaScript or a state of images report, and they just show some nice high-level graphs on some data points. Itās kind of doing what PerfTrack is trying to do on a lot of other things, which is super cool [inaudible 00:27:21].
So I did have the idea of maybe eventually maybe it could be cool ā I donāt know, state of the frameworks report, right? And PerfTrack doesnāt have to be its own thing, and it could be something that just lives in the HTTP archive website. And Iāve been talking a lot with Rick [inaudible 00:27:35]. He actually helped a lot help me build PerfTrack, because heās built a lot of similar tooling. I donāt know if heās made public yet, but looking at CMF platforms. How a lot of site is using WordPress is doing? How well are sites using Shopify doing? And so forth.
[00:27:48] SW: Oh! Thatās important.
[00:27:49] HA: And thatās super important.
[00:27:51] SW: Wix.
[00:27:51] HA: Wix. Yeah, Squarespace, and the list goes on, Magento, GRPL. But I think weāre both now talking about itās cool that we have two separate things, but maybe we should combine them, right? Like combine efforts. I think people would love to see all that information.
[00:28:04] SW: For sure. Probably reduce the individual lift for you as well, especially like manually syncing. Another similar sort of initiative that I kind of compare this to is tooling.report, which was also cross ā I guess, cross-tooling, like a little bit potentially political. But they put a single number under every logo. And it kind of makes it a little bit of a contest. And I know you wanted to be very sort of like, āYes, there are many dimensions on which like a framework can be evaluated.ā But would you attempt it to reduce everything down a single number?
[00:28:41] HA: I really would. I can lie and say Iām not tempted to do that. I personally would love to see like a high-level number, right? At least it gives you some sort of indication on how well theyāre performing with all the caveats, right? But Iām just so scared to do that, because I know if I do, weāre going to start seeing threat in Hacker News with like, āOh! Take a look. We have Angular, or React, or Vue performing at this number. Can you believe it?ā Iām like, āI donāt know if Iām ready for that.ā
[00:29:09] SW: And I think it was Jason and a bunch of other people. But, yeah, what they did was they just got the maintainers involved. So everyone had buy-in and then everyoneās like, āOkay, well these are some things that we think are valuable and weāll try to be better on those. I think itās more of a buy-in about not ever doing it.
[00:29:25] HA: Great point. Youāre right. And maybe itās just more so like how we can serve that information. And Iām glad I just said too, because Iāve talking to the Angular team for a while, and theyāve been giving me some great feedback. Theyāre like, āOur tool sample size looks interesting.ā Theyāre like, āWeāre pretty certain weāre larger than that. Is there something going on in the detection method?ā
So like theyād been helping me try to figure out if thereās something wrong. And I donāt blame them for thinking that, right?
[00:29:46] SW: Yeah, that is 0.4, and it could be like maybe just itās Angular 1.
[00:29:49] HA: Yeah, exactly. Like the way Iāve done it now is specifically just Angular 2+, which is not including Angular 1. But even then, maybe thereās something missing. Maybe thereās something Iām not doing thatās missing a lot of Angular site. So, youāre right. I think getting buy-in is so important, especially also if we end up trying to show like numbers or high-level indicators that just try to sum everything up. Yeah, I like that. Thatās a good way to put it instead of just saying no.
[00:30:11] AJ: Just another question actually around the data that HTTP Archive uses, what does it gets its list of URLs from? How does it pick them?
[00:30:20] HA: Yeah. Thereāre some certain criteria. I generally donāt know if that specifics can be made public. But it literally just fines. It creates a top list in some sense of popularity. And I think when it started, it was much less URLs. I think thereās only about a million. And only about a year or two ago, they kind of moved it up to a 5 or 6 million. It gets the URLs from Chrome user experience report.
So even though ā And itās kind of confusing at first, but Chrome user experience [inaudible 00:30:48] separate data source, but itās sort of also the source of all the URLs, and itās kind of like just a public mini version of all of Chromeās internal metrics pipeline. We have our own internal metric pipeline. This is just a small public lens to it. And thereāre some specific criteria.
One of them that I know definitely is true is I think usage static reporting has to be enabled in the browser. Thereāre definitely some certain things like that. And then that is all given to HTTP Archive. HTTP Archive gets that list of top URLs, and it does what it needs to do. Thatās also something to keep in mind, because yes, itās a lot of URLs, but weāre also not taking into account the millions of other URLs that are not included into the dataset.
[00:31:28] AJ: Sure. I guess weāll take about tech stack. Thatās the big one.
[00:31:31] KA: Yeah. Thatās the last question. What did you use to build this?
[00:31:35] HA: I use Svelte to build it. Yeah, I did spend a little time trying to figure out what I wanted to use. The nice thing about just building projects every now and then, I think I can dabble and pick something else. But Iāve never used Svelte before, and Iāve always wanted to. And I thought this would be the perfect way to just get familiar with it. Itās not a small app, but itās not very massive either. Thatās your basic components. I got to worry about how components work together. I got to figure out routing and all that. So I thought this would be a good exercise just start thinking about and how Svelte works. Yeah, I picked Svelte.
I was also really considering using Sapper. Did it, and now I kind of regret it. Iāve been meaning trying to figure out how can I add server-rendering somehow with Zapper, which I hope wouldnāt be too bad. But yeah, and itās been a great experience. Yeah, I definitely enjoyed Svelte a lot. And I feel like the one thing that I really sort of enjoyed was Iām trying to think of it as like if I wanted to learn a framework as a brand-new developer, I feel like I was just so intuitive to just create Svelte files at a script tag at a [inaudible 00:32:36] tag and do markup, and thatās it. I didnāt have to worry about JSX. I didnāt have to worry about dependency injection. I was just like, āIf I was to learn a framework from the very beginning four years ago, and if I just saw about the way it was, Iām like, āThis would have been perfect for me.ā Yeah, that was my first thought using Svelte.
[00:32:54] AJ: Thatās good to hear that. Thatās kind of the goal, I guess. Thatās really good.
[00:32:58] SW: I think the phase that appealed to me from Rich was like HTML is the fundamental sort of language of the web that everyone learns to speak first before basically everything else. And every Svelte file is basically a tiny superset of HTML. So, it seems like a very natural progression. I almost want to ā Yeah, I donāt know if itās appropriate, but like beginners, if they want to start with Svelte first, then I think thatās a really good idea actually.
[00:33:27] HA: Yeah, 100%. Yeah. Like I feel like now, if somebody asked me and said, āHey, I wanted to use a framework and I just want to learn how component scoping works, what do I use? I think immediately Iād be like just try Svelte instead of suggesting, āHey, use this other tool. But you got to worry about this and that too, and go learn that,ā right? I think Svelte to be a very nice thing to just try out at first, right? No. I agree. I agree, for sure.
[00:33:49] KA: So I personally went from React to Svelte, and I was so amazed by the developer experience. Itās really nice.
[00:33:59] AJ: I went from Angular 1 to Svelte.
[00:34:00] HA: Oh, wow!
[00:34:03] AJ: Yeah. This is back in the day. Well, I mean, I was previously a backend and I sort of had to do frontend, because I was running a startup based by myself. So I sort of learned frontend, and I learned Angular, because I kind of new a bit anyway. And I have to say itās like night and day going from all the injector pass and stuff and services. And with actually component-sized, the Angular app, the Angular 1. ā I have no idea what it even was, 1.6 maybe. I donāt remember. But it was componentized, but it was just lot of wiring. And we were trying to do the same things and what I looked at Svelte, like what itās already there. Itās already done. So it was an easy sell.
[00:34:41] AH: For sure. When was this? Was this like a number of years ago?
[00:34:44] AJ: This was when Svelte 1 was the thing. So double braces, lots of handle body type stuff. And lots of nice bugs to play with. Yeah, but it was great. It worked. And I started using it for like widgets to put it on the sites, because it was perfect. No runtime, that kind of thing. And then when I had to go work on the main app, it was like, āOh! How do I move this? How do I move this stuff out?ā
[00:35:05] HA: Yeah. Thatās when it gets kind of ā When you start dreading it. But once you start, I feel like itās not as bad as its anticipation.
[00:35:11] AJ: Yeah. Yeah, absolutely.
[00:35:15] SW: Anthony, I got bad news for you. Hussein uses a router, but itās not Routify. Itās this thing, Svelte routing.
[00:35:22] HA: It is.
[00:35:22] AJ: Svelte routing. Wow!
[00:35:23] SW: Iāve never heard of it.
[00:35:24] AJ: I mean, to be honest. There are so many routers with Svelte. Itās unreal. None of them are official, but there are so, so many. I think Routify is brilliant. Routify, Routify I think is fantastic. But I only use it in one project as well. I use Page.js a lot. I had gone with sort of traditional ā
[00:35:39] KA: Page.js? Yeah, thatās like a general one, right?
[00:35:42] AJ: Yeah. Itās just of another router, yeah. This kind of works.
[00:35:46] SW: Thatās pretty nice that it works out of the box sort of.
[00:35:49] AJ: But the fun thing I guess about Svelte, is again ā Because itās quite simple writing. A router is not that difficult. So, a lot of things Iāve done, and I love to think my friends have done actually. Weāve just used the Svelte component with this, and he just changed the angle past them, and itās done, like your routing is finished. And itās that easy and itās like, āWell, do I need a router? Maybe not.ā
[00:36:09] HA: Yeah. To be honest, I just wanted to find something, and I found Svelte routing and I was like, āOkay, I think this might work.ā
[00:36:17] AJ: It worked.
[00:36:17] HA: It worked. Actually, itās done what I needed to do. No. I think that was the one thing I kind of had to get used to. Thereās no first in-class router. I donāt know if Rich or anyone, Anthony or anyone involved, right? Yeah. I can imagine.
[00:36:31] AJ: Yeah. Thereās a plan. We havenāt really picked one it will be yet, or whether itās a grand of rewrite, but itās definitely ā It was definitely an opinion of the maintainers that we would going to have a router. They will bring their own. Letās not be opinionated about it. And itās just the amount of pushback from the [inaudible 00:36:46] and demand has been right. We probably need a router.
[00:36:49] SW: A lot of people come from Vue and expect a router. Itās usually what I ā
[00:36:54] AJ: Yeah, absolutely. Or anything else actually, because everything else has a router, right? Everything else.
[00:36:58] HA: Yeah. Yeah.
[00:36:58] SW: Yup. So, I was going to ask you like some more general questions about where you think the web is heading in the future. Do you think weāre getting heavier or lighter sites in terms of JavaScript payload?
[00:37:14] HA: Yeah. I think weāre definitely getting heavier, and the trends are showing that itās getting heavier. With that being said, browsers are improving, the JavaScript engines, right? Like parsing, compiling. Even executing are improving. So an example, if you look at, letās say, Chrome 41 versus the current version of Chrome and try to load the same bundle of JavaScript. Youāll notice how significant the change has been.
I think thatās also progressing and improving, which is great. With that being said, I do think sites are getting heavier and heavier, and I donāt generally know if theyāre happening proportionally. I think thatās something we ā Yeah. And thatās pretty much my job with a lot of the people that I work with. How could we course correct that? Itās not going to be easy, but itās going to take some time. Yeah.
[00:37:58] KA: What are people putting on their websites thatās so heavy?
[00:38:01] HA: Iām glad you said that, because coming in from a frameworkās angle, theyāre very ā I wouldnāt say anti-framework, but thatās essentially the first thought. Theyād be like, āOh, youāre using a heavy framework.ā Itās immediately costing X JavaScript bytes in your site. Consider to use something else. And thatās not wrong. If youāre using anything that has an initial cost, itās going to really affect your initial performance. But I think when you start looking at also like data as a whole you realize that thatās usually a very small percentage of the total. And you look at, for example, third-party dependencies and third-party bloat. Iāve seen so many statistics. Some of them being 70% of 80% of most sites are coming from third-party scripts. And then you start seeing things like that and youāre like, āWow! Okay. I spent so much time telling people what to do with their first party code.ā But thatās going [inaudible 00:38:50] comparison if theyāre fetching a thousand scripts, right? Theyāre doing a million different things.
I think thatās a very costly thing. That hasnāt improved in so long. Itās only getting worst. Like I know a lot of things are happening now in Chrome as well as other browsers. But thatās something that definitely needs to improve. How could we improve the dependency bloat that we have today?
[00:39:10] AJ: I think essentially, because when I started Beyonk, again, I wasnāt particularly a strong frontender, and I sort of was learning. I was sticking dependencies [inaudible 00:39:20] or anything like that. And the moment you put Lodash in there, even though with the tree shaking, itās not that small. And I saw that in there, and I thought I donāt need this. Iām using like [inaudible 00:39:31] out of it. And I pulled it out and I [inaudible 00:39:33] about two megs and I thought, āWell, hang on a minute. How can I ā I can do better than this.ā
So I started looking at all the dependencies. I started looking at moment, for example. Moment is huge. Page.js is basically a drop and replacement, and itās two kilobytes. So I start on this path and I found [inaudible 00:39:50], a collection of libraries called Just, where it has a bunch of stuff, which is one thing. That replaces Lodash. Thereās moment. Thereās a whole load of like alternatives, but theyāre not very visible. I find people ā People always come at Axios, for example. Axios fetches in the browser. Thatās zero kilobytes, right? All the stuff is kind of built-in. Why isnāt there a bigger kind of visibility? I think now bigger [inaudible 00:40:12].
[00:40:13] SW: Is this just 11 or is there a bigger story? Like why are people still using this stuff?
[00:40:19] AJ: Well, I think itās just browsers. Isnāt it really? Browsers and string [inaudible 00:40:24], things like that. They donāt, and they probably shouldnāt have every single utility in the world on top of them. Itās getting less and less important.
[00:40:32] HA: When we talk about IE 11 or other browsers, right? Like polyfilling is also a huge issue. I think a lot of people, when they build the websites and they need to support legacy browsers, they end up including so many modules, that the vast majority of the users who are using a lot of new browsers donāt need, and thatās a huge one, right? So, thereāre been a lot of things that weāve been advocating for a lot of patterns, like module, no module. I donāt know if you guys heard of that. But itās the idea of adding a module attribute to a script. That doesnāt have any particles. Thatās using neuro syntax. That having a no module script. So browsers can now selectively pick the right one, which makes perfect sense.
But a few folks, me, Jason, Gary and other field people are actually looking at ways we can make that even better, because although thatās super useful, a lot of third-party dependencies in general are being published using legacy code. If somebody who pushes something to NPM, theyāre not trying. Most, I think. Most package are that arenāt trying. Theyāre thinking of ways of using the most newest syntax, right? Theyāre just trying to make it as widely as usable for everybody, for every browser, right? And they just want to make sure that anybody can use a package. And that is also an angle we need to be looking into a lot better.
Yeah. I think that browser support is huge. I also think part of it too is just knowledge, right? Anthony, you might be super savvy enough to actually spend some time looking into your bundles, be like why axios to your ā But if you think of the millions of sites out there and the millions of developers using millions of like legacy applications, they probably donāt even know whatās actually happening beneath the scenes, right? I think just developer knowledge is a huge factor. Yeah.
[00:42:08] AJ: I think actually one of the hardest parts about that process was, and I think itās using Webpack at the time, was actually installing the plugin that gives you the report of whatās in your bundle. That was probably the hardest bit of the whole process. And I think thatās almost ā It feels like it should be built-in almost now, like a flag. Because itās really important. Itās really important.
[00:42:28] HA: 100%. Youāre probably using Webpack, bundle analyzer, or something similar like that.
[00:42:33] AJ: Something like that. Yeah, rings a bell.
[00:42:33] HA: Exactly. And I agree.
[00:42:36] KA: This talk about like dependencies really makes me want to build like a small website that just shows you like alternatives to all these heavy widely used packages. That would be really nice to have.
[00:42:50] SW: You may not need, and then just fill in your dependency.
[00:42:53] AJ: Yeah, thatās a great idea. Actually, there is a guy whoās done this. But itās very unknown small project right now, but the groundwork is there.
[00:43:02] SW: Well, can you name? Like itās going to stay unknown if you donāt.
[00:43:06] AJ: I wish I could. I have to search my GitHub [inaudible 00:43:08]. Maybe itās my pix.
[00:43:12] KA: Yeah. Sounds like something we could promote at some point.
[00:43:16] SW: I have a couple thoughts on this. Thereāre a few things. So, one is I think thereās a culture that I really like in Svelte where Svelte is most peopleās second or third framework. Most people donāt come to Svelte straight away. So theyāre a little bit more thoughtful about dependencies when they come here. When they come to Svelte, partially because they come to Svelte for the bundle size reason. And then I just see like all the tools in Svelte ecosystem tend to be a little bit more conscious about the weight that they add. And I think itās something that comes from Rich Harris himself, like he wrote a blog post which I really like. I think he said ā I think itās called something like small modules, maybe not. Where he kind of questions like this whole culture that we have of like, āOkay. Weāll import this one thing, then imports this other thing.ā And itās like, āYeah, itās a Unix philosophy, but thereās a whole bunch of defensive coding in there, and we donāt really audit what we bring in.ā
But it does tend to have this like weird upside ā Like Stranger Things, like thereās the normal world that everyone else lives in, and thereās an upside world where like itās just like the duplicate versions of every library that people use. Most of them are done by Lou Jackson for some reason. To me, thatās not a world I want to live in as well, because I want everyone to kind of use like a best in class tool. But maybe itās just too difficult at this stage.
The other thing that comes to mind, Iāve sort of mentioned it on this podcast before, but I think since heās your coworker, Llya Grigorik, who wrote High Performance Browser Networking. But he also talks a little bit about how weāre never going to reach the ā Whatever, like 50% of developers who just continuous to build big sites of the way they always have been. They just always ā It just always has worked that way. So they just keep doing that. And if you really want it work, you have to kind of build it into the platform. And I donāt know what the conclusion is, but maybe this is a problem that reaches beyond frameworks and goes into right into browsers.
[00:45:10] HA: For sure. Yeah. My frameworks I think plays a part, but thereās definitely a lot more to it. 100%.
[00:45:18] SW: So it seems like Anthony found the [inaudible 00:45:21].
[00:45:21] AJ: I did. I did. I will look to that from my stars. Yes. Itās really hard to read out their beliefs. Weāll tweet as well from the account, right? But itās pioneerpart with a zero after the PI, smaller-npm-packages. Yeah, have a look. Itās a very short list right now, but if people will contribute, itāll be amazing.
[00:45:40] SW: I kind of call this bending the curve, because itās very 2020 to bend curves. But like I thought weāre having some impacts. I thought things were leveling-off in terms of ā I think one of the other discussion that is coming up is this separation between who build sites and people who build apps. Because people who build apps, youāre trying to compete with native apps, which are hundreds of megabytes, and they donāt care, because they just do the initial download. And itās kind of unfair to hold all these sites on the same benchmark and give them the same tools to express what they need. I think thereās this discussion about like what if we had a new document type that was like document type app or something? I donāt know if youāve seen that, but itās something that Rich Harris is also gotten into.
[00:46:25] HA: Yeah. I did see some discussion around there. Yeah, I think a few other folks also kind of wrote some articles exploring that mindset. Yeah. I remember seeing that, which is super interesting. Yeah, Iām super interested in that kind of information. Like it makes sense to think about things and those lens, but those like how do we make sure things like that could be sustainable in the future. But, yeah. If weāre thinking about predictions, I feel like thatās one thing that I feel like. I donāt know. You might start seeing in ā I donāt know. 5 yearsā time, if thatās not too conservative.
[00:46:54] KA: Yeah. All right. I think thatās it. Do you guys have any picks? I have one. We didnāt warn you. We never warn our guests about things. We should start doing that.
[00:47:03] AJ: Yeah, we should.
[00:47:04] HA: Iām like quickly thinking of something.
[00:47:08] KA: Iāll go first them.
[00:47:09] SW: It doesnāt have to be tech related. It can just be anything that is [inaudible 00:47:12].
[00:47:13] HA: Okay. Nice.
[00:47:14] KA: So Iāve picked a computer mouse today. Itās called a MX Vertical. It looks kind of funny. So think of it like a regular mouse, but you turn it 90 degrees. So you kind of hold it in like a natural way. Itās really nice. Nice for your underarms ā
[00:47:32] SW: Nice for your underarms. What does that mean? Where are you putting your mouse, man?
[00:47:38] KA: Itās like the angle. You have your arm in. Gets better if you turn your hand up 90 degrees. Sort of hard to explain, but it seems to be working for me at least. Iām enjoying it.
[00:47:51] HA: Nice. Yeah. No. I think I definitely need to invest in something like that, for sure.
[00:47:56] AJ: So, for my pick, itās going to be ā Itās actually weird. This is a weird one. I always like ā Itās a tradition now that I have a weird pick that doesnāt make any sense. But itās a laptop I donāt yet own. I have used them before, and Iāve seen a couple of friends whoāve got them. And itās a system 76 [inaudible 00:48:11] new laptop. The name has slipped me by right now. I completely lost the name, but itās there. Kind of alternative to the DELL XBS and HPMV. Itās a very thin ultrabook. The nice thing about it is actually the components inside arenāt soldered to the motherboard. So you can configure the amount of RAM you want. But Iām going to get on with 4o gigs of RAM, because Iāve been stuck with this Dell XBS, which has got 8 gigs of solid RAM for so long. And it really struggles. Itās struggling with this. It struggles with a lot of things. Itās time to upgrade, and I think that soldered RAM should now be a thing of the past. So, Iām looking forward being able to slot some of these sticks in there and stuff. And itās got this really nice spec. Itās very lightweight. Itās lighter than the XBS. In fact, I think itās no point. Itās a hundred grams lighter. So itās just over a kilogram, which is not bad for a sort of very modern i7 laptop with 40 gigs of RAM. And you configure up to a 4 terabyte SSD, which [inaudible 00:49:05]. Letās face it.
[00:49:08] SW: Iām afraid to ask this. But do you guys know how many hours a day you spend on YouTube?
[00:49:12] AJ: Too many.
[00:49:14] HA: Way too many.
[00:49:14] SW: You can actually draw it up on your own stats. You just got a YouTube app, and then you just hit the time watched, and it shows you the hours a day. I spend roughly three hours a day, which kind of makes it my second most used app after my podcast player. So Iām just going to pick YouTube Premium, just because it lets you skip ads. It lets you download stuff. And I actually got the family plan.
So, my dad works in aviation, which side note, is not doing well. So, heās been spending all day watching YouTube. And I was like ā I saw him and I was like heās just sitting through a lot of ads. I just got the family plan. And itās super cheat. It gets a lot of entertainment. And thereās a lot of quality stuff in YouTube, and I like it a lot. So figured Iād pick a Google product here.
[00:50:02] HA: Nice. Yeah. I think I have one. Itās going to be really random, but I donāt know if you all use certain weather apps in your phone to just track the weather. This is like the default weather app that your phone comes with. But somebody recently just told me about this app called Dark Sky.
[00:50:17] SW: They got bought, right?
[00:50:18] HA: I think so. Yeah. They did. Yeah. I didnāt think I would need that kind of information. But I was like, āYou know what? Let me just it.ā A couple of dollars. I think it was the first mobile app Iāve ever bought, like ever. That goes to show like how I never try to buy anything on my phone. Yeah. But I was like, āOh! Itās pretty cool.ā Because it kind of shows some super hyper local information. I think it goes down to the minute of like whether itās going to rain. Whether itās going to snow. So, Iāve been having fun just playing around the app. But yeah, Dark Sky. A random play.
[00:50:46] KA: Does it work like the predictions? Yeah.
[00:50:48] HA: It does work. Yeah. [inaudible 00:50:51]. Prediction is new actually for like ā Ever since Iāve gotten it the past few weeks, like when it says itās going to rain at 7PM, it rains at 7PM. So definitely not 100% accurate, but itās definitely like surprised me. Thatās for use.
[00:51:08] AJ: I have used Dark Sky in the past actually, and I found it to be very, very accurate. It was almost on the minute, which is quite amazing. Itās a great app. Yeah.
[00:51:13] KA: Itās sort of scary at the same time.
[00:51:16] AJ: I felt it was gone, because when Apple bought it, they seem to sort of make it disappear. So itās good itās still around, I guess.
[00:51:24] HA: Yeah.
[00:51:24] KA: Could be only Android maybe?
[00:51:27] HA: No. I have an iPhone. I have an iPhone. I have it. So, Apple did something good.
[00:51:31] AJ: Well, I have to get it then.
[00:51:32] HA: Yeah.
[00:51:32] AJ: They actually have a bunch of really cool [inaudible 00:51:33] libraries as well, such as the time zone converter, which is really useful. Itās worth checking out at GitHub too.
[00:51:40] HA: [inaudible 00:51:40]. I didnāt know that. Wow!
[00:51:41] KA: Okay. So, I think thatās it. Thank you, Zach, for coming on ā
[00:51:47] SW: Studio audience. The studio audience is very excited. Very excited.
[00:51:53] KA: Thank you for coming on and talking to us about PerfTrack, the web and any and all topics we spoke about today.
[00:51:59] HA: For sure. No. Thank you guys. This is great. This was a good chat. For sure.
[00:52:03] AJ: Thank you.
[00:52:03] KA: Awesome. All right, see you next time, listeners. Bye.
[00:52:08] AJ: Bye.
[00:52:08] SW: Bye.