Building and Distributing PWAs: Tools, Techniques, and Insights - JSJ 638 - podcast episode cover

Building and Distributing PWAs: Tools, Techniques, and Insights - JSJ 638

Jul 02, 202438 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

In today's episode, they delve into the fascinating world of mobile web development with our esteemed guest, Maximiliano Firtman, a seasoned web developer from Buenos Aires, Argentina, who has over two decades of experience.
Join them as Maximiliano takes you on a journey through the evolution of web and mobile development, starting from the early days of pure HTML and classic ASP, progressing through the milestones of Perl, PHP, and eventually into the realm of mobile technologies. He provides an insightful look at how mobile development has transitioned from early platforms like WML and BlackBerry to the modern era of Progressive Web Apps (PWAs).
Together with Steve, they unpack the benefits and challenges of bringing the open web into the mobile space, discuss the impact of mobile performance on user experience, and explore various tools and best practices for developing efficient, fast-loading PWAs. From understanding the role of service workers and web manifests to exploring innovative APIs and caching methods, this episode is packed with invaluable knowledge for any developer aiming to enhance their mobile web development skills.
Whether you're interested in optimizing web performance, getting hands-on with PWAs, or curious about the future of mobile app distribution, this episode has something for everyone. Tune in now to uncover actionable insights and expert advice on staying ahead in the ever-evolving landscape of mobile web development.


Socials

Picks


Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Transcript

Hello everybody, and welcome to this episode of JavaScript Jabber. My name is Steve Edwards, coming from a very frigid Portland, Oregon. And with me today I have Max Miliano. I guess you go by Max, right, yeah, fine, Fersmand is coming to us from Winnos, Irish, Argentina. So Max wants to tell us a little bit about yourself and your history and what you do. Yeah, sure, well thank you for the avitation. So yeah, I can go by Max. I'm a mobile web developer.

That's how I define myself today. I've been doing web development for twenty something years. Before then, I started being doing mobile around two thousand and one, so before the iPhone, before the Android. In the middle, I've been doing a lot of Worships trainings, you know, for a couple of books, mostly on mobile and web both. These days, I'm more focused on baw Us progressive webs as well as web performance. Okay, so let's go back a little bit. You said you've been doing this for about

twenty four years. So if you're like me, that mede you started doing web development when the first tools you either handwriting HTML and CSS, or maybe you were using tools like Microsoft Front page, dream weaver what we're using when you started out? So when I started, I was using adit from MS does. Okay, that was my first website with those three one. I think I didn't have Windows ninety five yet, so then yes, I moved into front page. By My first websites were p R HTML. There were

no CSS at the time. And yeah, then I moved into front Page ninety eight I think, and then I was a green we were user for a couple of years before going back to a simple editor. So what was your first scripting language was at ASP? Yeah, it was ASP, the classic ESP before PHP, but yeah, SP. I think I did something on Burl before that, but most of the time was APP. Yeah,

I started I think about ninety eight probably. Yeah, where I started was ninety eight with front Page, and I went down the PHP route on my SQL. And I can remember doing my first website and straight HTML just using a JavaScript goodies or HTML goodies and using the web space provided by my hosting provider, which was AT and T Broadband at the time. My first two websites were I hosted in GeoCities. Oh, there you go. That's old

school for those of us who remember GeoCities. Okay, so you started doing web development and then when you start doing it, say professionally here, I think it was immediately because I started doing HTML. Before that, I was doing some cleeper apps, like some software for MSS. But I started professionally doing web pretty fast. I think it was my third website, but the first one I started to some money from it. So it's probably in nineteen

seven six something like that. Yeah, here, I am still working on the same HTML language exactly. I can remember when the Internet first started coming out, like ninety two, ninety three. I think I remember using my friends dial up connection taking download a photo and he's yelling at me because I'm using up all his hours. And so you started getting into mobile. So I remember the first iPhone coming out around two thousand and eight, somewhere around

there if I remember right. I just remember where seven was the first one. I thought that sixty years before that. So I started with WML, so it was on WML and WML script, so there were four websites for for what patients, then moving to Sham to Java Micro Edition. Then I did BlackBerry is Seen Beyond and many other platsforms before the iPhone and animal, But yeah, I find I started into and seven and then we started seeing

Android in the market as well. Right, okay, so mobile developments, So what's been what have you worked on over the years with the mobile development where you're just basically doing websites that you could see on a phone, and what was the progression from doing that into doing mobile specific apps like we see today? Might like to see that. I always try to offer services or products over mobile, and then the technology that I was using might be different.

So sometimes it was a website or web web based technology, sometimes it was native. So I've been working from probably fifteen s the case for doing native as well. But I always try to bring the web into the mobile space. So I always liked the idea of the web, the open web, and bringing that into the mobile space. So yeah, I did phone app before that, I did some other web solutions available for some platforms like BlackBerry. These days it's mostly about PWAs or pressive web ups. But I'm

also doing worships and deliverery trainings on nating television. Next week I'm traveling to the Bay Area to deliberate training for a company, and it will be a swift OBJECTIVEC. So I'm also a native developer, but I part of my heart is with the web, so I always tried to bring the web into

the mobile space. Okay, yeah, so going back a little bit, I can I can recall I was doing a jupil development for for a number of years if people have heard me mentioned, and when I first started getting to mobile development or when sites that I was working on needed to do that. The way we did it was separate themes, so you had one for desktop and then you'd create a whole separate theme for mobile that was designed differently

and so on. So you're basically maintaining two things for two different presentations for the same content. And then you started getting things like Bootstrap. I believe that was with the first sort of framework that came out that was it was interually a Twitter Bootstrap that was designed to accommodate you whether you're on a desktop

and then a mobile. Is that your recollection in terms of the progression, So yeah, I have I have other other things before that, so I think if you remember the first the first thing was was a mobile version of the website that was completely in the different language that was WML. After that we have the first iPhone. When the first iPhone, we started to support the desktop web on mobile, so it was the first time you can actually

render a desktop website on a mobile device. And then we had a pinch Chest tour soon in then we moved into this idea that yeah, maybe we need to do something special, and we had a moment ventually out so n dot CNN dot com like you separate HTML version and then responsive web design appear, that's what you are paying. So the idea that one code can serve different platforms. The problem was that we didn't realize that responsive web design had

a very high cost web performance for mobile devices. So then that's why after a while we started to see different approaches, not just responsible design. Okay, so the cost was in what the extra JavaScript or the extra code that was needed to handle the responsive changes. Yeah, it's it's JavaScript, but it's also CSS and resourcely so just to keep you an idea, but if you have different CSS fights with even with media query, the browser needs to

download all the CSS fights. Even if the media quarried falls regarding what performance, the browser will not render any pixel on the screen at least at the time if all the CSS was not downloaded on parts. So talking about mobile phones and CELAR networks and probably slow three G networks at the time, that was a problem because then the mobile phone needed to download on parts a lot to CSS that would never use and that lead to some performance issues on mobile

devices and conversion problems. That's why a lot of big companies have to move back to the and dot version of the time because they were having money problems, so they were having less users, less pisits because basically people were not waiting for the page low. I mean, that's still a problem anytime I

heard a discussion about developing for mobile and performance. I mean places like maybe if I'm sitting here, you know, my desktop with my powerful iMac and you know, nice piece, and something's going to be pretty quick for me, or you know on a phone on a new Android or Samsung or iPhone

or whatever. But a lot of other parts of the world, you know, maybe you have older phones and you've got slower downloads, and so it's always an issue of dealing with performance if you want your customers to be able to see your site. So there are a couple of views on this, this problem on the network. Let me let me tell you this. First, let's say that everyone is in four G. Let's say that. Of course it's not true, but let's say that everyone is in four GLD.

The problem with that is that we are thinking about the band with and yeah, four G is better than three G and TG, but in terms of latency, it's better, but it's ten times bigger than the latency that we have at home on a cable or DSL connection. And the latency is the time that it takes to get the bytes from the server per TCP packet. So even those four G lucky users that today is around forty five percent of the users worldwide, even those users, they have a big latency on every

TCP packet. So that's the problem. That's why we t have a performance issue. Let me tell you this. So I'm traveling a lot. I've been to seventy two countries so far, seventy two and different cities, and sometimes I'm in the middle of Silicon Valley. I remember this having my late's iPhone with a four G data plan and I was being downgraded to two G. So this is still something that happens when you get out of the city.

Sometimes you get out of main cities and you are in three G or JUG, but even in four G. Okay, we need to remember the latency. That's the biggest problems that we have. No matter where you are, you can still have a slow connection even if you're in in an area that has four G. Yeah, just a little bit outside of town. Okay. So the solution is PWAs in. Is that sort of seen as the solution from a performance standpoint for some of these issues? Or I guess

let's go this way. What is a PWA? Can you give me a definition? I've heard various I know there are various rules that you have to have, but what is it that makes up a PWA and what is the benefit of a PWA. Okay, let me give you my definition, because there is no definition. So that's the first thing. There is no real

definition of pws. But a PWA shows the designed pattern, like responsive design, it's a design pattern, a set of best practices in this case to create web apps that are install level and they can work offline and fast on several operating systems. So it's not that they can act as a normal website

inside the oustes out the browser window. And also they can be installed, and after they're installed, they have a first class experience of do os meaning in a stand alone Windows on macof Linux or Windows, or meaning being an APK an Android package and Android, or being a stand alone app on iOS. So that's a baby. So it's a website using new APIs and new

solutions from browsers vendors. The will let us install the app and make that up available offline, and after it's installed it looks like any other app on the system. That's roughly the ideas which a design pattern. So then if it's going to be able to run locally with the idea that it doesn't have an Internet connection and offline mode, so that means that it's generally going to have some sort of local data storage. Yeah, exactly. For that,

we have the service worker. So if you have a horrible service worker, it's a childscript file that we set in our web and that service worker will be responsible for cashing and serving those files when the user is software, but also when the user is online because maybe we are online, but yeah, we want to be passed. We want to react like a native app. So that's the service worker will serve those files locally. In fact, I usually one like to say that the service worker is like a web server that

we are installing in the client. Britain, in childscript, a service worker is mandatory for a PWA, so it's the brain. It's the brain of a PWA. Okay, so that's a service worker. It's purely JavaScript then yes, okay, and it's currently compatible with all the browser it's available. That API is available on the latest version of every major browser Safari, Edge, Chrome and Firefox, an Opera, so it's in the browser. But if you're running okay, now I'm confused. So if it's a browser standard,

if you're running natively, it's somewhere they needn't havember browser. The browser is always there even if you don't see the browser. So on aw A on a pw A, when even when an APK is install, APK is the android package on Android, so when you starty a PAW an Android,

you actually get a native package. But inside that NATI package, the only thing that is a store is a URL and Chrome or the browser you're using is the one that is going to render your app without the browser UI, so in full screen mode or a stand alone mode, but this is still the browser Okay, so your your app is being rendered, So is the rendering handled by the native libraries or the native toolkits for you know, rendering a toolbar or a window. That's still all the browser, that's from you.

No, it's it's all the browser. It's not like React Native or native screen. In those cases you use JavaScript, but then that childscript will render on the screen native components from the from the se case, from my us around at p w A will use just HTM and FFS to render the content on the script or SBG or or web web content in general. You can use web assembly if you want, but you cannot access native a PI.

So if you want to access the five system, for example, you need to wait for the browser to have support for that a bi Okay, I see. So it's basically you are using the browser in both places, whether you're using that on the browser, on the phone, the browsers. Okay, that makes a little more sense. So are there any other additional pieces of code or files that you have to have for p w A other than your service worker. Yeah, you need at least one more one more

file. It's known as the web manifest. It's just a Jason file. That you link into your htmal document the jason file. We have the meta data for the US for example, that inkuilds the app name, the icons, and other meta data that is useful for that OS. In particularly, it's on a standard from the W three C so it's not OS specific, but the browser will use information from that manifest to actually integrate with the US when that app is install. So let me tell you this, that's not

the only way that we have to distribute an app the browser today. You can actually distribute officially. Bwas on some app stores, for example Google Blaystore. So there is a way that we have an official way from the Chrome team. You create what I like you to call a bww A launcher, and that's a native APK that will not contain your chanldscrep or egitimeal files,

will not contain the files which has contained the u URL. Then the user will download the app from the store like any other app from the store. But then Chrome a visible Chrome because the user is not actually seeing any Chrome user interface. Chrome will take care of downloading the resources, update in the resourcing when when resources are changing, server file, and rendering the app on the screen. Okay, so you provide RL that has all the reasons for

your particular application that you have to store somewhere, manage somewhere. Yeah, the service worker, the service worker, that little piece of childcrip that we write with with the p w A will be responsible when you open the app for the first time to cash all the resources that are needed later. That cash is not the normal standard cache that if the user clears, the cash

will be deleted, so it has a different life cycle. You can even request with some childcreap apies, you can request a way for the so the browser will not delete those files, so a way to guarantee that those files will be there no matter what. Okay, yeah, it's a separate cash, so it's not going to get cleaned out automatically and you're going to lose

all of your application right exactly. So when you're hosting file these resources that the service workers calling, is that something you store like in a GitHub repost somewhere. It's just that GTP So wherever wherever you want to score, you just need a g GPS. So okay, standard hosting. You can still use FTP service if you want an Amazon A three bucket or drama anywhere. Static assets, like like a normal website. So we are not changing the

foundations of how the web works. It's just a website that is used in a new API and what that API is there, then that app come be installed. Okay, So if I'm loading a PWA on my say, on my computer, on my desktop. You said the service workers you know, working Safari, Chrome, Firefox and so on and so forth, which browser is it using for doing all the rendering? So that's a good question. So the answer is it depends on how are you installing or how are from

where are you installing the app? So to install a PWh should they you have a couple of options. Typically you're installing a p w A from a browser. That browser is going to be the engine. So if you have two browsers and Android, for example, Firefox and Chrome, and you instill the same pew A twice, you cannot do that with Chrome, but let's say you can. You will have two instances of the same paw A using two different browsers. I mean, it's not common an Android that that will

happen anyway. So the answer is that it will use the engine that you used to install the app. What happens with what happens with the store. If you're installing the app from the app store, in this case Google Play Store for Android, let's talk about the Android only for now. So in that case, it will use your default browser. I mean the browser needs to support the new service. For PWA's Chrome is supporting that service and also

something Internet browser and Firefox is about to support that pretty soon. So if you're a Firefox user, then if you install apps PWA is from the store, and by the way, as a user, you don't know if it's a pw A or not. But if you're a Firefox user, then that pw A will use the Firefox engine. Okay, so yeah, it just depends on however you downloaded ten. So going to this scenario where you said maybe you could have two instances of the same p w A on the phone,

does that mean they both would have their own local data stores? And well, it depends on the engine. On iOS, for example, each instance will have its own separate storage. So for example Tinder Tinder dot com. I'm sure if you know that I haven't used Tinder, but anyway, yes, okay, thin that if you go to tinner dot com you can actually install it from your iPhone, Android, or desktop computer and on iOS.

So every time you install Tinder you will have a different instance, and you can have one account to icon because each instance we have its own local storage, cookies, indexv and even its own storage for the files. On Android's if you use Chrome, you won't be able to start more than one because Chrome is actually creating an APK in ash it won't re install another one.

But if you use other browsers, you can actually have more than one instance, and in this case it will use the endshine of each browser. But of course it's not shared with the others. Okay, does it makes any sense? So sandbox is w there is? Yeah, exactly exactly, But let me let me add this because that's important on Android and dexktop when

those Mac Linux and chromeo ads. When you are installed in a pw A with Chrome, the storage of that app is shared with the normal Chrome, which means that if you are already logged in in dinner dot com the website, you are also locked in in tender dot com the app, because it's it's the same Chrome enshine and it's sharing the storage. Okay, yeah, that makes sense if I'm writing a pw A progressive web app. What are

the different tools that I can use to do it? For instance, can I use like a view, Angular React framework with something like React Native or some of the native scripts. Is it only for you know, Swift or Objective c or the tools used for Android. What are the different tools that you can use to write pw A. Okay, you will definitely use tool chains from the web space, not from the native space. So no j GPC, no Swift, no React Native. You can use Angular, React

JS or View. In fact, the CLIs from these tools creates pw as for you if you enable. In the case of Angular, it's an schematic. It's like plugging, So if you enable the p w A plugging, Angular will create the p w A and the service worker for you, and the same you see if you use create React app to create React ups. So it's always on the on the web space. So this is we're talking about W three c APIs. Everything is done with childscript and web technologies and

browser engines, so it's on that side. In the case that you want to publish your PEW in the Google Place store to create that launchair, you might want to use under a Studio. That's the say, the native SDK for native apps, but also there are some freeware and open source tools on the web that will do that for you. Microsoft has launched pw A builder pw A builder dot com and that website. We create that launcher for you, so you don't even need to get into native tools. You just use

Visual Studio, code O, whatever editor you're using. You publish that on any posting or cloud based provider and that's all you need. Okay, So it's pretty transparent to create your launcher. So you got all these different tools, but it's definitely web based. Okay, all right, that makes sense. Anything I'm missing in terms of building PEDGBA is I think we covered the what you need. So it's a web app and then a service worker that

metadata. We've been talking about publishing the BWA, so you install it from the browser. That's I think that's the trickiest part today. So in terms of how users will know about the installations or us know about bwuas today, if you're U seeing Chrome on desktop, maybe you have seen this, maybe not, but sometimes when you're on the website that is actually a PWA,

you will see a little install button of a peers. In the omnibox, the only box is the urlbar, so in the url bar and an install icon with a plus sign will appear when you're in a PWA, So that's how users will know, oh, this website is a PWA. It can actually install. This is something that is still unknown from a user's point of views. Not every user knows about this, and how are you installing a website? So this is something that is getting better with time. The new

browsers. Now you can actually create your own install button in your own user interface, so you can have a button somewhere in your RL say hey, do you want to install the app? Get here and that will trigger the installation dialog. This is a tricky part from a marketing point of view because you sometimes don't know about this. Despite that technologies are premature, so an

effort for basic app. Now you can use a web share. Well, you can use web payments request payment API, so all the web APIs available out there are available on bwas. So not every app can be a bit of value because sometimes you actually need some natives case, but a lot of apps can be bawwa. So if your app it's just consuming web content or web services, which is downloading Jason Fly from the server and rendering that on the Spring. Maybe it's a good candidate for a BWUA because it's just a

website basically. So if you need to go native with some hardware access, well then we need to check if the web technologies and web APIs are mature enough for that particular approject So I want to come back to the local storage real quick. What are the common tools or is there one or the other that are used for your local storage? Is just like a local storage in

a browser type thing. You're talking like, you know databases that you can like my sq A light for instance, as the one that comes to mind, or what are the options for that? So for b w A, we are running under the browser umbrella, right, so that means that we can only use APIs available from the browser. So that means that takes seql Light or my sequel out of the equation. So what do we have right

now? If we have one storage known as cash storage. That storage is for the actual files of the app, so the resources of the app, the HTMAL, the CSS, and an emails. On iOS, we have a limit of fifteen megabytes on all the other platforms, there is no limits, so you can actually tell as many space as you want from the storage. Then we have the data storage, so the actual data that the user is generating or downloading from web services. In that case we can use indextv

that is a no sequel database well known in the web space today. Or local storage is for more simple key value storage that is very limited in space, so we have one storage for the actual app and another storage for the data. Are the limitations the same for the data storage as for the app storage? In terms of physical it's similar, so you have another fifty x

on the index CV for iOS. In terms of let's say Android, Chrome Base, typically you can request more space with user permission, and right now it's a percentage of your available space. So if you have a device with no space, no available space in the memory, or a computer with no space in the hard drive, maybe the space that you have will be just two megs or something like that. If you have enough space, it's pretty unlimited. To be honest, today it sounds scary that every website can store

as much as they want, but that's basically how it works today. Are you able to access like an SD card that's in a mold. Devices are strictly the internal storage that's on the phone itself. So today it's a complete it's an agnostic API, so you just store somewhere. You don't know where. It's up to the browser, so it's a sundbox, so you don't

know exactly the real file system. Chrome is working on a new API that it's called the Native file System API is currently better, so it's started testing that and it will come in the next next one or two versions of Chrome. Only on the Chrome side and with user permission, you can actually access the real file system, so you can actually create a text editor or visually studio code that is basically childscript. It can be directly a website or a

BWA. You don't actually need a native wrapper with that API that's coming. It's not exactly today, So the STORAGEEPS that you have available are storageeets that are diagnostic from the real file system. You shous a store somewhere. You have an API your store you retrieve, but you don't know exactly from where, Which is the point of an API in the first place, right, You just give it what you need and it handles everything behind the scenes.

So exactly. Yeah, okay, that makes sense. I'm just curious, since you've been doing this for a while, can you give us some examples of PWA's that you work on, you know, just in a generic sense in terms of functionalities, maybe that are sort of cool or unique. Well, in terms of functionality, I've been working on bwas for games, for apps that are taking here coats, apps that are for example, so when you order a pizza or something like that, you know, maybe a small

pizza place that you have in town. You don't need a native up and hire Java Epelow or Cotlin developer for Android, or a Swiss developer on a US but you want to have an order app. Well, maybe pew as just web so it's simple to maintain for small businesses. That's one example. But I've been working for a lot of I've been consulting for a lot of big companies doing PWAs. Today, they're big names doing PWA's like Google, Maps, Twitter, Tinder. As I mentioned before, a lot of newspapers

are also having bwua's. I remember one that is in the store. It's one a hundred flowers in the US one hundred flowers. They used to have a native app on the Google Play Store and then replace that with the React based PEWA in the store. So if you go down to the store and download that app, you will actually see a pewgw A. You don't know that as a user, just an app, but it's the same code based because it's not the same codes, it's actually the same URL that the one

that when you go to the website. That's a big advantage. Oh yeah, so right, once you use multiple places I can see. Yeah, definitely use So another way that I know that you can, you know, write web apps and use them on computers or someone is something like Electron, you know, slack, you know, it's the classic example that's written in an Electron. Have you ever compared like performance or any characteristics between the two. Well, most of the time, I mean, as a rule,

bwas will run faster. Why because you're not actually shipping a Crown engine. With Electron, you're actually shipping a Crown engine. And also I know the engine. That means that when you have a pw A, you're actually going to use the engine that you have in sound in your browser. That's being a ball with time. So Chrome every couple of weeks you get a new version, so your p w A will always use the latest version of the

engine. So that's why it's typically faster. But compared with Electron, I think Electron might disappear in the future if we have a lot of new API is coming to the web and Chrome is working on that with something known as Project Fugu. Project Fugu it's the project work that they're trying to bring all the API from the native world to the web. So then we don't need

Electron or phone gap anymore. So we don't need to wrap web into a native container that might have security issues because you are not in control of the engine. Today, electronics are still needed for some reasons because sometimes you need to actually execute NATICO, for example for accessing the five system. So that's why now they are creating new APIs. But yeah, that's Chrome on the iOS world or macware. Things are moving slower, so yeah, you can

start p w as, but they're not adding so many APIs. They are usually on Twitter the web keep guys, they tend to be more how can I say it should be more critical saying like we don't want to push too hard on APIs, We want to be more private when I want to be more let's say slower, they want to be slower in terms of implementation of API. So we have like a kind of a raise here between Chrome and Safari. Chrome is trying to push the limits of the browser a lot and

Apple is trying to play safe. So at that point, it depends on the platform that you want to target. Okay, that makes sense, pretty consistent with what we tend to see from Apple anyway. Okay, anything else do you want to cover that I have failed to bring up? No, I think the best way to try peas is to test one. Just go with a browser to one of the PW's. There is a place up scope.

Just google a scope. A guide of pw A is available, so you just go on install one so you can actually experience that a lot. That's the best way to experience a pw A. Just use your iPhone, add to the home screen and p w A, use your Android and try one so you actually experience how it looks like and what you can do it. Okay, So yeah, here's abscope a p P s c O dot p E. Yeah, okay, the u r L it's actually appscope,

so they're using dot domain exactly. Okay, that's brilliant. Okay. So noticing here that you've got quite a number of books, especially, it looks like you write a lot for O'Reilly. Yeah, high performance mobile web programming for the mobile web, web mobile. So which ones your most current? The last one is free for free on my website. It's hacking web performance,

and the previous one is high performance Mobile Web. So my books, the latest books were more targeting on web performance for mobile, price hacking mobile. Okay. Yeah, so your site is f I R T, DOT and Mobile. That's correct. Yeah, okay, cool, So we'll put that in the show notes for sure. And then it looks like they can see links to all your articles and books and other stuff. Well, great, thanks, I've learned a lot, okay about ways and mobile apps.

I've been pretty desktop focused, so it's good to learn more about the mobile apps. So now let's go into picks or you wear picks or what we do for picks. Just anything that you want to talk about that you think's cool, whether it's technical or non technical, A movie, a book, a tool, something that's been really useful or interesting to you lately. Let me think why you think I'm going to go ahead and do mine real quick. My pick for today is an oldie but a goodie, and it's called

the Club. And the club is basically a thing you can put on your car steering wheel sort of deter fees from it. And it's a particular interest to me because I bought my kids a car a couple of years ago and it's a two thousand Honda Civic. And here in the US, those cars made around then, we're very easy to steal because of the keys and they're

just really poor security. It's easy to break in. So last December my daughter had it stolen from work and we found a couple days later some guy was just of an in it. And then last week my son's been driving it and it got stolen from in front of our house in the middle of the night and we just found it last night and got it back. In both cases, they forgot to put the club on. Every other day we've had the club on there, and people say, oh, it really doesn't

work. Professional fiefs, you can get past it, and that may be true, but for the casual feef it's going to stop them. But in both cases, the one times that they didn't put the club on is when it got stolen when the club's on there, and never have any problems even for a car like that. So there's a few different versions of the club out now. You can get red and yellow versions, and two hooks and

one hook and so on. But my son in this case, he put it on but didn't lock it, which really didn't make it very useful. So I got him a club now that auto locks, so when you put it on the stream, we only spread it part it automatically locks and you don't and then you have to use the key to unlock it. So that's my vote for the club. It's certainly never never had a car stolen when the club has been on it and properly locked. So Max, what's your pick? You got me? I think we'll go back to the p w

A so I will I will not talk about cars. We go watch your paws. So something I've been trying going back to the pw A thing. It's a new tool from Google known as Yama so ll A m A. It's a CLI that they it's on it HAB's open source that we'll create a pw A launcher for you. So you have a p w A or a website, and that CLI will create an Android project that will actually be ready for the play start, so you don't need to know anything about Android development.

It's like a shortcut to your p w A, it's only one month old and something like that. Yeah, I'm looking AT's it's on NPM. Yes, it's MP chaos Lama. Oh maybe it's not that one. Oh no, no, no it's not. Okay, that's for AWS. Let me find another one here. Okay, we'll find it and put it in the show notes. But awesome, so that your only pick, it's yama pack. Yeah, yama pack that I'm based in the URL right now. Okay, awesome, we will put that in the show notes. All right,

Well, thank you very much, Max. Very good to hear from you from down in Buenos Aires. Oh. Where can people get ahold of you if they want a hold of you, whether it's Twitter or GitHub or what's the basic plus get a hold of you? Typically Twitter? I'm f f I r T on Twitter. So four letters, that's a simple use name, the same as my most third one is my my last name is it's the first four letters of my last name, f I r T f I r T on Twitter. All right, all right, well thank you

Max and we will see you around the internets. Yeah sure, thank you Stive. Bye bye,

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android