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.

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.

Links:

• Perf Track
• Google Lighthouse
• Lighthouse
• Tooling Report
• HTTP Archive
• smaller-npm-packages
• Nicole Sullivan: Design Systems, Frameworks and Browsers

Picks:

• Kevin: MX Vertical - I was talking about forearms, not underarms 😭
• Shawn: YouTube Premium
• Houssein: Dark Sky
• Antony: System76 Laptop

Transcription:
[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.

Episode source