The panel goes back a few years and reviews some technology predictions that Dan made a few years ago on Quora. These include WASM, Progressive web apps, and others. Most were wrong, but one did end up being sort of accurate. Along the way, they go into some deep rabbit holes but manage to pull themselves out. As always, they end with picks, and Steve's stupendous dad jokes.

Hello everybody and welcome to another exciting episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio and the voice for being a mime, but I'm still your host. And I was voted that way by the other panelists who didn't want to host. Anyway,

 

Hahaha

 

we

 

True.

 

have no guests today because the guests we had scheduled needed to reschedule for various reasons. So it's just the three of us here today and the three of us being myself  and Dan.

 

Hey, I'm doing great, you know, here in warm and sunny Tel Aviv. Interesting, it's like almost October and it's still warm and sunny, so good things.

 

Yeah, it's been the same here in Portland too. It's been really warm and clear and sunny. I think we're up about almost 90 degrees Fahrenheit yesterday and it's supposed to be that way the rest of the week and it's the last week of September. But we tend to get a pretty good, what we call Indian summer around here, very late summer going into September, which is great because we had rain all the way into early July. And before I forget AJ, let's go, AJ O'Neill, how you doing AJ?

 

Yo-yo-yo, coming at you live from the open garage.

 

Yes, it does look sort of sunny in there.

 

So today we just sort of have some random conversations between the three of us talking about Jabber and predictions that did not come true and various other things. So start out, I think to me that sounds the most interesting. Let's talk about predictions made that didn't come true. You wanna fill us in on that, Dan?

 

Yeah, sure, why not? So it turns out that, uh, besides being on, on this podcast and being on Twitter, I also am occasionally on Quora. I don't know why, but I enjoy writing answers there occasionally. Interestingly enough, I've only asked, like, the only one question since I've been there. Uh, but so I occasionally write some answers and to be, to be honest and, you know, kind of surprising to me, my answers are getting a lot of views. I have like millions and millions of views for my But yeah, but anyway, so turns out that four years ago Somebody asked what would web development look like in five or ten years something along these lines And you know, I wrote my prediction. So those predictions are from four years ago and turns out that I was incredibly wrong hilariously wrong even on most of my predictions and it's really funny for me to reread what I wrote and just try to figure out why I thought that these predictions would be accurate and why it didn't turn out that way. So to give an example, my first prediction was that within five years, but not much earlier, the JavaScript monopoly on front-end will end thanks to WebAssembly. Yeah. Raise your hand if you're using WebAssembly for anything. Meaningful on the front end.

 

You

 

Yeah.

 

didn't have to go that far. There were no hands raised.

 

Yeah.

 

You didn't need the limiter.

 

uh

 

I've seen people use it in presentations and I know that there is one website that I use that uses it. Which is I forget the name of it. I haven't used it in awhile. It's the drawing one that you use for doing mockups. Of stuff.

 

Like Figma?

 

Figma, that's the one right? using WebAssembly.

 

a

 

I don't know.

 

figment

 

But,

 

that

 

I

 

but.

 

think

 

just got.

 

I think that's how it works so well on Mac. I hear that on Windows, it kind of sucks. But on Mac, it's just buttery smooth.

 

But that's exactly the thing. I mean, WebAssembly is being used. It's just being used for very specific edge cases. Another great example is Google's amazing Squoosh web app. I don't know if you're familiar with it. It basically takes an image in one format and transforms it into other formats, usually with a significant reduction in size in quality, you know, by using more modern formats and whatnot. And the encoder or encoders,

 

or by using AI.

 

no, not AI. This is not like, you know, trying to figure out like fractals or anything weird like that. It's like totally taking it from, I don't know, being PNG and making it into WebP or AVIF or stuff like that and playing with the quality and, you know, and they show you kind of a split view where you can see format and the new format and adjust the settings. It's really great because I have seen situation well in our own work. We took an image that marketing put in which was something like 400k And turned it into 40k without any noticeable degradation visual degradation, so you know why not and in WebAssembly because basically the image encoders, I think, first of all, they were originally written like C or something, so you want to compile them into something. And also you get much better performance that way when doing encoding in real time, effectively. But again, that's just an example of where WebAssembly is great for very specific use cases. audio encoding, all kinds of encodings. And what I thought is that people would be using it for the mainstream stuff, for building web applications because people kept on complaining about being forced to be using JavaScript on the front end. And the whole thing about WebAssembly is that you could take any language and effectively compile it to WebAssembly. So, you know, if you prefer to do your front end in C sharp, instead of trying to transform JavaScript into C sharp, just use C sharp or Java or Python or whatever and compile them down to WebAssembly. And it turns out that people didn't. If anything is actually replacing JavaScript, it's a TypeScript and that's being compiled to JavaScript, not to WebAssembly. So you know. So it's. It's

 

Side note, there's a thing called Image Optum for Mac that will sounds like it does what Squish does. I'm playing around Squish right now.

 

The great thing about Squoosh is that it's just an online app which launches really quickly because the people who developed it are the people at Google who are kind of focused on web performance. So they're also kind of using it as their playground for trying to make it as fast and performant as possible. So it's also interesting from that perspective.

 

Image Optum is not fast, but what it does is basically there's there's windowing that goes on in the compression. So how many pixels wide by how many pixels tall to our is the target area for the quantization? Is that what it's called of compressing the image? And so it basically, as far as I can tell, just iterates over and over and over and over and over and over again, best and that works really well for PNGs because PNGs oftentimes just by changing the size window by a couple of pixels you can complete it you know change the size of the PNG by 2 4x

 

You know, as long as we're here, you know, one of the things that kind of surprised me, surprises me is that a lot of people, even in web development, aren't familiar with the differences between lossy compression and lossless compression. Do you guys think this is something worth touching on?

 

I do think that's worth touching on just one second.

 

Man, I haven't read about that for a long time. I remember when I was trying to learn Photoshop back in the day, or learning some sort of basic design or image manipulation things, I have totally no natural tendency towards. I remember reading a lot about lossly and lossless and understanding it back then, but I've forgotten all that over the years.

 

Well, the meaning is kind of straightforward. Lossless compression means that no information is lost during the compression process. So if you compress something using lossless compression and then decompress or expand it back, you get something that's identical to the original. It's exactly the same. That's what lossless compression means. And that's certain image compression formats like PNG, which you mentioned, use this GIF, I think, at least in most cases uses it. It also was used in certain audio compressions, like FLAC, I think it's called. Obviously this produces the best quality because again, you get back exactly the same. In some cases, by the way, you have to use lossless compression. For example, when you're using Gzip, let's say, to compress your HTML over the wire, you know, you want to get the exact same HTML that you sent. It wouldn't be a good idea if some letters got switched around. It would kind of make the HTML meaningless. When you compress text you want lossless compression But it turns out that for audio and for images and for video especially a lot of times What you actually want is what you call lossy compression and lossy compression means that you're actually willing to lose some information During the compression process so if you compress something with lossy compression And then you decompress it you get something same you lost some information along the way but if the amount of information that you lost is relatively low then most of the time you won't notice a difference so you know when you're listening to streaming audio for example if you're using i don't know spotify or or apple music or streaming videos, they use lossy compression. And you don't notice the difference as long as the amount of loss is reasonable. Likewise, with images, JPEGs use lossy compression. And you can actually specify the quality, which means the amount of information that you want to retain or to avoid losing. So the greater the quality, the less loss you're willing to accept. And constant, Why would you even use lossy compression? Because when you're willing to lose some information, you can generally achieve much greater compression ratios. So, you know, JPEGs not always but often provides a compression ratio that's like up to ten times faster, not faster, sorry, greater than the equivalent PNGs. The resulting compressed file is just, you know, Again, because you were willing to lose some information during the compression process. And just to finish the topic, some modern formats like WebP support both types of approaches. So in their header, they kind of specify which compression method they're using, and it could be a lossless compression method or a lossy compression method. So usually you would take a PNG and convert it into WebP, then you would use the lossless compression method. If you take a JPEG and convert it into a WebP, you would use the lossy compression method. And that's kind of the difference between lossy and lossless. And what I often see is when people are building websites and they're not aware of this, they use lossless compression image formats like PNGs, need to avoid losing any information because you really don't care because unless you're a brain surgeon or something where every pixel is meaningful when you're looking at a brain image you know that's kind of important but otherwise you know if it's like a picture from your tour somewhere you know your trip somewhere you know what do you care if you lose a little bit of information if the image download is 10 times smaller you know anyway That's the difference between lossy and lossless.

 

Oh, my brows are froze, can you hear me?

 

Yes we can.

 

Okay, good, now done for us. I wanted to add onto that, lossless compression is dictionary-based, always. So whether it's gzip, bzip, 7zip, it is 100% PNG, it's 100% dictionary-based, meaning you take a sample of the data with a sliding window, and you see how often that sample of the data repeats within a larger sliding window of some sort. That's why it is lossless is you're basically looking for patterns or repetition that is easy to predict and define the compression for and seven zip is the one that does kind of like what I was talking about with image Optum where it takes a very large window and tries very different sizes to build the biggest dictionary that it can. To the point that. If you have a one gigabyte file. megabytes that repeats somewhere in the file, it will do every, it'll take a long time. The compression will take several minutes. But it will find any repetition that can be fit into a dictionary and compress it down. So that, you know, even whole files can be compressed with seven zip. window and as moderate efficiency because it is designed so that you can send something that's a somewhat structured format like HTML or later on JSON and be able to in real time encode and decode at relatively small overhead and then broadly is kind of in between it's meant so that you can fly, which is somewhat inefficient, good for API's, but bad for assets, or not bad, but not optimal for assets broadly is something that you can pre compress. And then it can be decompressed in real time where something like seven zip cannot necessarily be decompressed in real time. And that's your, your lossless and on your lossy side, a lot of the times it's literally noise. So for example, you know, I could click the settings in this video right now and my beard and my skin will become smoother and I might look better and the image is more compressed at the same time. So when you're looking at JPEGs and MPEGs and that sort of thing, a lot of times the compression is either equivalent to the noise. Looking at two images, you can tell that they're different, but you can't tell which one is higher quality because literally you're just exchanging real noise for artificial noise in a way that the two are indistinguishable in terms of quality. They're distinguishable in terms They're different, but not that one is better than the other. And then, you know, especially if you're targeting a small phone, you can take into consideration the resolution and then you can you can swap it that way. But the lossless is I mean, the lossy is in the best case, you're just swapping out noise or doing something that people want anyway, like smoothing their skin or smoothing colors so that there's less gradient. But then in movies, you notice this all the time. have a keen eye, you get banding in areas that are very dark. Dark scenes have bands of gray rather than having a smooth gradient. Generally doesn't happen in light, lighter scenes because the algorithms are optimized for lighter scenes.

 

Yeah, all

 

Thanks for watching!

 

I can add is that if you're building a website and you care about your users at all, then you should be making sure that your resources are properly compressed according to their type. So like you said, if these are static assets and they are primarily textual, then probably something like Brotli. If they are dynamic, like APIs or dynamically generated HTML, then probably GZIP. images, then usually you want lossy, but in some specific cases you may want lossless. But

 

Well,

 

then be.

 

it would be is it computer generated or is it real life? It's if it's real life, you want lossy because again, the noise is indistinguishable. You're trading noises. If it's computer generated, you typically want P&G because P&G will actually be able to compress better than the JPEG because if it's computer generated to the art, the you know, let's say has tons of gradients or something. But if it's the simple images with here's a square that's this color almost the whole way through and here's, you know, really, really good compression with PNG because it will understand the computer generated aspect of it because it literally the computer generated it from a dictionary and it's just trying to reassemble it back into a dictionary.

 

Yeah, or another way, a simpler way to think about it is if the colors are rather flat and homogeneous, then

 

Yes.

 

lossless compression can work really well for them.

 

Yes.

 

And that brings up another topic that if we're there, we can mention about the difference between vector image formats and raster image formats, which if it's computer generated, you might as well potentially just go vector, which could provide the greatest compression. And the difference here is that raster images are just that pixel matrix. It's just like you've got the, it's like a printed paper, effectively, to an extent. It's like you've got the matrix of such and such by such and such, and each dot within each is the pixel. or actually multiple values, there are RGB values or whatever, and that just specifies the color of that pixel. And again, this is just data and it can be compressed, you know, according to the ways in which we described. A vector...

 

It's declarative.

 

I don't know why. Why is that declarative versus the vector? I think the vector is potentially declarative as well, no? Or is it...

 

Um, well, I guess, yeah, I guess it's that's one of those sliding scale things too. Yeah. That, but the bitmap, the bitmap is literally the data. The bitmap is the result, the raster, the raster

 

Exactly.

 

is the result.

 

Exactly.

 

Whereas the vector is the instructions on how to produce it.

 

Yeah, so a

 

So

 

vector,

 

the,

 

yeah, exactly.

 

that's why I say the vector would be imperative because the vector is the list of instructions. But I guess the list of instructions are given in a declarative style. So yeah.

 

Yeah, so SVG is the prominent vector format on the web. And it has instructions like draw a line from this coordinate to this coordinate, or draw a circle whose center is at this coordinate with such and such radius and this kind of fill color and border color and whatnot. So basically, you're just giving a whole lot of rendering instructions. In most cases, vector art would be, if you can get it, is the better choice. Because usually, giving the instruction to draw a circle, it's just that one command, versus if you have, you know, you need to, you take it as the result pixels, you know, that's a whole lot more information, unless that circle is really, really small. In most cases, the vector format has a size advantage and also a quality advantage because you can resize it or whatever quality it basically looks perfect, whereas with pixels you get pixelation. Like, if you blow things up too much, you start seeing the blocks. But it turns out that in some cases, the vector approach is problematic as well. had a funny situation at Wix when I was working there, when we added internationalization support and you could pick the language of choice from a drop down and they put the flags in the drop down. And the flags were created using vector art because it seemed that in most cases that would be better. But it turns out that in some cases it was really, really countries have really complicated flags. So the US is an example with all the stars and stripes that you have in your flag. But there are even worse examples, like the Saudi Arabian flag, which actually has writing on it, which is terrible for vector art. And the Brazilian flag, where they have that ball with the sash and writing on the sash within the ball and stuff like that and it turns out that in some cases those tiny graphics ended up being something like 300 kilobytes and we just ended up replacing them with tiny PNGs and You know

 

I think that's actually more common than you think. I would not advise generally trying to use vectors because I think that that situation is kind of the norm rather than, and I could be wrong about this, but I think that's more the norm than the outlier. That the vector is, you know, if you're trying to do something that is, you know, printable wall scale, then yeah, the vector is gonna give you a much better size, that if you're trying to do icons, I think you're nine times out of 10, you're gonna be better off with PNG.

 

So a lot of this discussion is bringing back my memories of learning about these types of formats. And I remember that the description, what I was learning about vector art and its advantages are size, but it also tends to be more mathematically based. Is that even remotely correct what I'm remembering in terms of how it's drawing versus just plopping

 

Yeah.

 

something right there on the screen as compared to Raster? So that made it better for resizing,

 

Exactly, that's what we said before. Like if you're

 

Okay.

 

doing a circle, then you can specify the coordinate of the center and the radius and it would draw, you know, the best circle for whatever screen resolution and zoom factor you have. Whereas if it's pixels, it's just whatever that circle was originally drawn as. And then, you know, you basically increase the size of the pixels, not the size of the circle. You've lost the fact that it's a circle. of pixels that you're resizing.

 

Yep. Pixel width is effectively mute in a vector. Oftentimes they'll be described in pixel widths for our benefit of being able to reason about it in our minds, but it's all it's all ratios. So no matter how far you zoom in, it's always perfectly crisp. You can never zoom into a point that it's not perfectly crisp because every time you zoom in, it just rereads the that resolution. So it's always perfect. Yeah, asterisks because you know, your input has to be perfect. And a lot of times you do things with a vector. I mean, if you've ever watched somebody do vector art, you know, they'll take something and then crop it. And if you zoom in, you'll notice that maybe there's a little bit of an edge that sticks out on this line from where it's supposed to go in. But assuming that the source was perfect, then no matter how far you zoom in,

 

Also, another interesting thing about SVGs is that it's kind of like the DOM, in the sense that it can be manipulated from JavaScript, because it's effectively, the format is essentially XML. So you can actually access the various SVG elements and modify them and, you know, kind of animate whatever, or modify whatever image you have, which, you know, you can kind of do with pixel art, you can render it into a canvas and then start you know, changing the values of the various pixels, but that's like a totally different ballgame.

 

Okay, I think we have had a great

 

Yeah,

 

discussion on formats

 

but

 

of images.

 

Thanks for watching!

 

it's kind of weird how we got here from WebAssembly. If I can put us back to WebAssembly for a minute. So

 

Right.

 

BWAH!

 

we talked about the fact that we got to images because we said that WebAssembly can be really great for manipulating image formats on the web. But turns out that the vast majority of people don't need to manipulate image formats on the web, because it's functionality that's effectively built into the browser, being able to render an image in a variety of image formats. And most people aren't encoding images, again, by themselves. So it's great that if you're doing it, that you have WebAssembly, that you can compile your highly efficient C algorithms into it, and then it will run really, really quickly. But most people don't need that. I thought, as I said, that people would be using simply because they were, you know, bitching and moaning about JavaScript and wanted to use other programming languages. And hey, now you can. So it's interesting to think why this didn't actually happen. And I have a couple of, you know, assumptions or guesses, but, you know, your guesses are as good as mine. You know, I've done no research on that. My guesses are that first and foremost, enough for the majority of cases and you know that's what's being taught in boot camps and and and whatever so people know JavaScript a lot of people are perfectly fine with it and simply have no incentive to switch to something else now you know maybe they're switching to TypeScript but that's because TypeScript is so similar to JavaScript it's so easy to make that transition whereas going to some other programming language which has a totally syntax, semantics, whatever, is much more difficult. So in a lot of ways, TypeScript is to JavaScript what C++ was to C. The transition was much easier because it was so closely related and was intentionally developed as another language that you can fairly easily transition into, kind of piecemeal. Another reason is that for the longest time, you have limitations about what DOM functionality you can directly access from within WebAssembly. For a lot of stuff, I think to this day, you still need kind of a bridge from WebAssembly to the DOM through JavaScript. Now, some frameworks give you that out of the box. blazor framework, whatever that's called, that kind of takes.NET based applications and runs them inside the browser in WebAssembly and they provide the bridge for you out of the box so you don't need to deal with it yourself. And you know, I thought that that might be successful but turns out again that it isn't that, you know, we'll probably get people, listeners, you know, tweeting at Why are you crapping on it and whatever? But the reality is that any JavaScript framework that I can think of probably has many more users than Blazor. or whatever it's called. And maybe another reason is that it's probably also more challenging to debug on the browser side than debugging JavaScript. But again, I haven't tried in a long time, so maybe it's a lot better these days. But be that as it may, I'm just not seeing it. And I don't think that we will be seeing it. were to rewrite my predictions, if I were to write predictions now for five years into the future, if we're going to see WebAssembly anywhere, I think it's actually going to be on the backend or in edge computing rather than in the browser. And that's really interesting because that kind of mirrors what happened with Java, where Java initially was, people don't remember it these days, but when Java came out in the that it was targeted at the front end. And only after it effectively failed in the front end did it become such a big thing in the back end. And then eventually it kind of made its way back to the front end because of Android, but it's still mostly in the back end, I think. And it seems that WebAssembly is going in the same direction.

 

Yeah, I've heard other people who have made other tech podcasts who have made had in the past had made similar predictions regarding web assembly and how they thought it would take over and or not take over be more popular than it is, shall we say, uh, and have noticed that it isn't. So,

 

I

 

so

 

think people

 

yeah.

 

had the wrong idea about it because it was pitched on the slides, you know, because conference slides are so much different from reality, right? And on the conference slides, it was pitched as use your favorite programming language on the web. But the reality of it is rewrite algorithms in your favorite programming language with all of their garbage collection overhead that compounds against the JavaScript garbage collection on the web. So it turns out that the only language suitable for WASM is Rust and Zig. And none of the other languages are suitable. It's not suitable to use Ruby or Python or Go or anything that has garbage collection. Yeah, you can get it in WASM, but then you have the entire, essentially you're recompiling the virtual machine for WASM and then shipping that or whatever, if it's not virtual machine, the runtime. So only languages, basically it's just Rust and Zig. That's it. Those are your wasm languages that you can use, and you can't use them to interact with the DOM. So in the slides, it was, you know, Oh, everything's gonna be wonderful, you're going to be able to use whatever language you want, there's going to be no drawbacks, and it's only going to be butterflies and rainbows. And the reality was, you can only use languages that don't have garbage collection, except for, you know, the pure fun and joy, you cannot use it in a production product unless there's no garbage collection. And you can't do anything with a DOM. You can only manipulate, uh, uh, bite arrays. That's the only thing that you can do.

 

First of all, you're absolutely correct. I totally agree with you. I kind of forgot about the whole GC thing but to be honest, I think it's kind of a chicken-and-the-egg thing because Having garbage collection Support in in wasm was on the roadmap it seems that it didn't happen and Seems like it didn't happen because there wasn't sufficient demand for it to happen and were clamoring to get GC-based languages compiled into WASM, you know, it's open source. I assume that somebody would have done it and kind of didn't happen.

 

Well, that's so look at what Google has done with go. If you're not familiar, it took them. I think it was telling go until go 1.5 that they finally had the garbage collector that they had promised people. So it was at least five years from the time that they told people that they had this magical garbage collector that had no pause time and that had no drawbacks and only had benefits. And it took their engineers, on the, the, all the features of the garbage collector and the threading, uh, thread pool stuff that they had promised on day one in the conference slides. It actually broke a lot of things because a lot of things were written in such a way that they relied on essentially a bug. So, uh, if Google's engineers for their language that they rewrote the internet in and that everyone has since rewrote the internet, and if it took them forever to figure out how to get their garbage collector, right. I just don't think that a couple of open source nerds are going to be able to add it to web assembly.

 

Oh yeah, for sure. Getting a GC right is really, really hard. One of the reasons that Java is so popular on the backend is that so much research and optimizations have gone into Java garbage collection. There are a couple of implementations which have, you know, kind of different areas of focus. But the bottom line is that the garbage collection that's built into the standard JVM is pretty amazing. a really long time to get there. Likewise, by the way, V8 has an amazing garbage collector for what it needs, trying to get good frame rates within the browser and trying to offload stuff as much as possible off of the main thread. So I totally agree that getting GC right is hard, but even some GC rather than nothing at all. have in terms of GC for WebAssembly is crickets. And it seems that that's what we have for WebAssembly in general. Again, certain specific use cases could not have been implemented without Wasm on the front end. But the vast majority of front end developers never touch Wasm and are unlikely to ever touch Wasm, directly or indirectly.

 

Alrighty, so now that we

 

So

 

have

 

that

 

beat

 

was,

 

WASM,

 

yeah.

 

add the images to the F, I was going

 

Yeah.

 

to get back to your predictions. You got one more thing to say?

 

Yeah, a few more predictions. So another prediction, and

 

Okay, there we go.

 

this one I'm really sad about, is that I predicted that progressive web apps rather than just being a particular set of APIs would be as a whole something really significant that we would all be shipping and using, and that they would make significant inroads versus native mobile apps. And it saddens me to say that this has not happened. And it hasn't happened, from my perspective, for two primary reasons. One reason is that the marketing department really prefers native apps. Because I've likened web apps to, like, guests on Airbnb on your device. You know they they come in and then they leave it's like hotel guests or whatever Whereas a native app is a tenant in your device your your it lives there for a much longer time and that's what the marketing people prefer they want to be able to Reach out and touch you and send you push notifications and and whenever you know they want and and at short because it turns out that most people for the exact same reason don't like to install native apps on their devices. So most people have something like the five, six native apps that they have installed and those are the ones that they use and the others that they just don't let in. It's probably TikTok, YouTube, Instagram, email and maybe WhatsApp or whatever messaging application you're using and that's more or less it. and but that doesn't prevent marketing people from thinking hey if we can just can get you know if we'll Show you that annoying message about you know how our experience is so much better in our native app maybe we'll eventually get you to agree to install it and then We will be on your device and we will own you and whatnot and so that's like one reason I think and the other reason is simply Apple that I had not taken into account far Apple would be willing to go to protect their application revenue stream and to try to kill the mobile web. It's kind of sad to say, but they've been really effective at it. And the result is that PWAs on the iPhone remain highly crippled. The fact that you cannot have any browser on the iPhone except for Safari. Now, some people say, what do you mean? I can go into the app store and I can install Chrome and I can install Firefox. And, but you, what you don't know is that it looks like Chrome or it looks like Firefox, And because it's actually because according to the legalese of the Apple App Store you're not allowed to install any browser engine within an application other than and use any browser engine except for theirs Within any application that's installed from the Apple App Store so every so Chrome on is actually forced to use Safari on the inside. And consequently, it has all the capabilities and limitations of Safari. And since one of Safari's limitations is not really supporting all the APIs that are part of progressive web apps, then that's what you get. So if you want push notifications from your PWA on iOS, well, you can't get it. And without push notifications, you what's the value proposition there? Not much.

 

So I was reading in the news recently something along these lines. Don't know if it was in Europe or somewhere else about there'd been some court case that said no, Apple, we want Apple to allow other engines. I know there's been pushes by groups like open web advocacy that have been pushing back against that. And I thought I read something recently, but I can't find it.

 

Yeah, so our good,

 

Well,

 

so.

 

the Digital Markets Act, is that what it is? Europe's Digital Markets Act? Is that ringing any bells?

 

Yeah, so the regulators in Europe are much more, let's call it forceful, than

 

Yes, very much so.

 

for good and bad, than they are in the States. In some cases it's good,

 

Yeah.

 

in some cases not so good.

 

Right.

 

And some friends of this podcast, like Bruce Lawson, who's been on the show, and others have actually petitioned the regulators in Europe and in the UK about Apple's behavior and they have gotten the regulator to basically call Apple out on it. Now, as far as I understand, they haven't really done anything to Apple yet, but they're kind of indicating that they may unless Apple loosens their grip, as it were. And time will tell what Obviously, I'm hoping for the best. I'm a proponent of the open web. But I'm guessing that Apple will likely fight tooth and nail simply because their revenue stream from their store is so significant.

 

Oh yeah, I mean, I've been, so the articles I'm looking at are back dated back in April of this year, April of 2022, about this digital, what's it, the Digital Markets Act. So we'll see if anything actually comes of it. It's amazing, you know, I'm listening, I've listened to other podcasts, a lot of other tech podcasts and hear discussions about all the things Apple will do, fight tooth and nail to safeguard as much revenue as they can, you know, whether

 

Well, to

 

with

 

be fair.

 

restrictions and there's, And there's a certain, you can certainly see reasons that they do at some point, but other, with other issues, it seems to me that it's just, it's all about the revenue. It's

 

Well, you know,

 

shut

 

it's...

 

down the revenues or restrict people just to keep their revenue as high as possible.

 

Well, you know, that's capitalism. I mean, it's perfectly fine for a company to try to maximize its revenue. But we have regulators to keep companies in check when they start behaving in a monopolistic fashion.

 

Mm-hmm.

 

And it seems like that's what Apple is doing in this case. By the way, another person who was on our show who's really fighting the good fight in this context is Alex Russell, who used to be in Google and now he's at Microsoft. And I really hope that this effort is successful, that the threat of regulatory action, because nothing else will move Apple in this case. It's unfortunate, but that's the case. We're not going to see any sort of consumer revolt, really. It's unreasonable to expect that. So it has to be something that's driven by regulators. or would be a good thing. So I hope that the regulators do something. Anyway, so bottom line is this. PWAs as a set of APIs are definitely a good thing. I think that if PWAs were properly supported on all platforms, we would see much more significant use a whole, but the reality is that so far it's not really happening that much. I do think that if you're building a web application, then thinking whether or not being able to function offline is something that you should think about. And if you do want to be able to function offline, then using PWA technologies is something that you need to do. friend of our show, Carl Simpson, is a big proponent of service workers because his claim is that in this modern world with mobile devices and intermittent connectivity, you need to think about those situations where even for short durations, connectivity is gone and you still want your web application to be able to function to a degree at least in those scenarios and for that you need service workers. But yeah, by the way

 

Well, before we move on, I want to point out I did an episode with a developer named Maximiliano Firtzman. He's Argentinian. A couple years ago, January of 2020, JavaScript Jabber, episode 415, 415. And we got into some pretty good detail about what progressive web apps are and how they work and when you'd use them and so on. So I'll put the link to that episode in the show notes.

 

And he's also one of those people who's really pushing Apple on this topic. Whenever Apple comes up with a new version of their Safari browser and they say, hey, now we support this and that, he actually goes through and checks and verifies what actually works and what doesn't. And more often than not, he finds that things don't actually work as they're supposed to. Undoubtedly in this context, Apple has become like Microsoft with Internet Explorer, even worse to some extent, because with Internet Explorer, You had Internet Explorer as the built-in browser, but you always had the choice of installing something else with Safari on iOS You don't even get that choice Anyway

 

Right?

 

moving on to my next prediction My next failed prediction was and we kind of talked about it before the show and you made fun of me But I'm going to describe

 

Ha ha ha

 

it anyway AJ is that I predicted that start being a thing within five to ten years. And even though we are hearing more and more noises from meta about the metaverse, it doesn't seem to be happening yet.

 

Yeah, I I'm gonna repeat what I said before. I don't know how in the world you could have thought that AR and VR was gonna take off. I mean, we had the 3D desktop, we had 3D TVs, Mario Kart Live, awesome. Pokemon

 

Oh, heck yeah.

 

Go, pretty cool. There are a couple of niche little things, but any AR VR game, you play it over the weekend, and that's it. You've experienced everything there is to experience and you're done. And it's like, Oh, that was a cool experience. like going to a theme park. It's good for the weekend.

 

I

 

You know, I can see applications where I can, you know, even back in the early web before AR and VR, those terms were generated. There was some good practical applications. And the one that comes to mind that I can recall was like real estate or like interior design. So the ability to sort of have a 3D look at a house, say the house that you want to buy that's on the market, or you have a room, like a living room or bedroom, whatever, and you want to redecorate it, right? And so you want to be able to sort of see what certain things would look like in that, you know, on the house. What's it going to look like in real life as compared to just looking at a sample and imagining how it's going to look on your walls or in your particular house. I remember that, you know, back in the late nineties, early two thousands, I was obviously a lot harder to do, but that's one of those niche, I guess you call it a niche or an area where I could see something like AR, VR being, very useful and practical. You're muted, dude.

 

I think there are various scenarios in which AR, VR can be really useful and interesting. You know, again, before the show, we joked about the fact that whether or not we go to rock concerts. Well, it seems to me that AR or VR might be really interesting in that context of virtually going or attending a rock concert, or maybe a sporting event, or something like that, For some reason, you're not able to physically attend, and you get the closest possible thing to actually being there. I think that could be really interesting, but that kind of misses the point of why I was bringing it up as a prediction several years ago. And the reason is that I feel like we are late for our next Something like back in the early to mid 90s, we transitioned from having big computers under our desks to using laptops. So that was this big form factor change. And then in the mid 2000s, 2006 actually, 2007, we got the mobile devices with the touch screen. huge form factor change that changed everything. So, you know, four years ago I was thinking, hey, we're due for another big form factor change, you know, we've been using laptops for coming on, what is it, 30 years, we've been using these touch devices for coming on 20 years, where is our new form factor that changes everything? And I figured that, you know, the only thing that I that occurred to something kind of related to AR VR. And either that's not the case and something else will come along, or maybe, I don't know, going to take longer or whatever, I don't know. So it's not necessarily that I think that I want to do my day job of programming in a VR type environment. I was thinking that something new needs to come along.

 

I most technology plateaus, right? Agriculture plateaued books, the printing process, most technology plateaus. We, we have a need due to the scale of civilization, the need of these types of technologies that are, that are lasting technologies that persist decades, centuries, millennia are due to scale of civilization. So for a technology to to plateau it has to it has to solve a scale of civilization problem and we have not reached a different scale of civilization so i would not expect us to need. scale of civilization, but we didn't once we got the thing we needed, we didn't then change agriculture, agriculture has been the same, we're still farming corn and rice and beans and cattle, right? And that we've been doing that for millennia. And with books, we've been doing it for centuries. So it would be a new technology that has a different social impact that would that would cause this new medium to to come into existence. It wouldn't be that we're going to change an existing medium because even with you know, what we could say with the internet revolutionized books, but no, not really. It's still letters. It's still pages. The pages are a different form factor, but we didn't revolutionize reading with the internet YouTube that did that that that was something new. That was a different form factor that

 

Thanks

 

fills

 

for watching!

 

a different niche a different type of intellectual capacity. that reading can't, but I just don't see the VR thing.

 

So two funny stories in this context. So one is that I kind of realized that the things that changed about a decade ago when I went into a living room, saw my son lying on the sofa in front of the TV, but instead of watching the TV, watching something, some video on his phone with that small, you know, even smaller screen that they had back then, and he was totally fine with it and was enjoying it that way. to me at the time, but I've become accustomed to it as well. And looking at him, you know, using that small, sufficiently high quality screen instead of that huge screen hanging on the wall, brought home to me the fact that, you know, things have changed. So that's one example. Another interesting example that occurs to me is an even older one. Back in the day, there was this Byte Magazine and they had a column by Jerry Pornell, I think his name is. He used to be a well-known sci-fi writer. I think he's deceased. But he had a column about technology. Like, he was really into geeky tech stuff and had lots of computers in his house, way more than people used to have back then. And he told the story about like the first time that he watched streaming video. post stamp size on within his on his computer screen highly pixelated and and he excitedly called his wife over to show it to her and basically after he showed it to her she took him by the hand to their living room and showed him the news on their TV and said if you want to see news why don't you look at it that way and and these days I I don't know about you guys but I only watch the I hardly ever watch the news on TV because I get the stuff I want when I want it.

 

I watch it in the shower.

 

You watch the news in the shower, okay.

 

I just put my phone up on the little lip between the shower door and the shower wall. And then the acoustics are good enough with the speaker pointed, you know, because the shower... The way the shower is designed, the acoustics are good enough that I can hear it.

 

Yeah, as long as you're not sharing of your own video, whatever, all is good.

 

No, it's

 

Ha

 

news.

 

ha ha ha ha.

 

It's not only fans, it's news. And I don't know that

 

Ugh.

 

I'd get a great following on OnlyFans.

 

All right, so we're getting pretty close to the end of our time.

 

Oh,

 

Did

 

yeah.

 

you have any

 

So

 

more predictions,

 

yeah,

 

Dan?

 

so there was the one prediction that I think I got right. And I'll be interested in what you think about it. I predicted that the serverless approach will become the norm for most web development so that most organizations would not be required to manage the back end of their own applications. Rather, the entire infrastructure will become a service. And like it or not, because I know that very often, it seems to be, it seems that that's the direction in which everybody is going.

 

I don't know about everybody. I mean, it's certainly

 

critical mass.

 

I mean, Azure's got it, you know, AWS has it, Netlify has got, you know, functions that

 

but

 

you can

 

look

 

run.

 

at it from...

 

I myself haven't come across any cases where I have needed to use or want to use it. Doesn't mean it won't happen. But, you know, you hear it discussed a lot. I just, I have no idea of the scope of implementation, you know, whether it's limited mostly to enterprise type organizations or smaller people use it, or smaller, you know, single devs or smaller shell companies. I have no idea on that. I just, I hear about it, just don't know the scale of implementation.

 

I think it has to do more with the development frameworks that most developers are using. So, you know, these days more and more people are using these, call it, call them Uber frameworks or application frameworks like Next.js or Nox, or Remix or whatever, or SvelteKit. And it seems that these frameworks are kind of steering the developers toward a serverless type of an approach. Now, potentially...

 

You'll own nothing and be happy.

 

Oh, don't go there, please don't go there.

 

Now, yeah, it kind of goes hand in hand with the fact that companies like Versel and like Netlify are offering these type of serverless type solutions, and that these are integrated with the frameworks and platforms that they're offering effectively for free. And the reason that they are offering them for free is because they integrate so well with their services. Yeah, if you're building something with WordPress, then you probably aren't going to go serverless anytime soon. But if you're using Next.js, then you probably will. That's the way I see it. And also, you know, this approach of breaking monolithic services into what's it called... serverless. It's basically microservices, sorry.

 

Oh, right.

 

Yeah, so the microservices approach goes hand in hand with the serverless approach because each microservice runs as its own serverless function or as it were. Now again, you know, I can't tell you the number of times anything you have to modify all the microservices in which case you know you should have just stayed monolithic but but but you know again it seems that that that's kind of the way in which we're going

 

Alrighty, so with that we'll start to wrap up. It's always fascinates me how we come into some of these episodes like this and what are we going to talk about and we head down a road and it takes the whole time.

 

Yeah, we are all talkers.

 

It takes

 

That's

 

doubt.

 

why we're on a podcast.

 

Exactly, exactly. All right. Well, thank Dan for not being afraid to give us your failed predictions. You are certainly not the only

 

Yeah,

 

one who has

 

don't

 

made

 

take...

 

some of those predictions that have not turned out to be true. I've heard other people making some of the same,

 

Don't take any stock

 

having some

 

advice.

 

of the same discussions.

 

Yeah, exactly. Don't take any stock advice from me. That's the short of it.

 

All right on. Okay, so let's move to pics. Pics are things that we like to talk about that may be tech related, maybe not tech related sort of fun things. We'll start out with, let's go with AJ.

 

All right, let me think about this. Hmm. All right. I recently learned what a wire wheel is. And it's just if you have a Dremel tool or a portable drill, or I guess it doesn't have to be portable, but one of those, you know, like rigid to wall, that kind of thing. So have I have I mentioned the four-wheeler I've been mentioned that I've been working on the four-wheeler for Two months now. I bought a beat-up four-wheeler and I've been I've been restoring it

 

No,

 

today. Have

 

no

 

I

 

you

 

have

 

have

 

I talked

 

not.

 

about that

 

No,

 

at

 

you

 

all?

 

have not. And I have to tell

 

that

 

you that I admire people who actually build stuff with their hands versus just, you know, create virtual constructs.

 

Look at all that muscle.

 

Yeah, showing us your guns AJ.

 

Yeah. Whoa, whoa, whoa. Anyway, let me see. Let me see if I can show the four wheeler through the crack here. No, you can't see. Maybe if we just know I can't do it anyway. Yeah, I've been working. I've been working on this four wheeler and trying to get it to a better a better state and rebuilt the rear end and got it. Anyway, the wire wheel turned out to be really useful because I took apart the brake assembly. And essentially what had happened was somebody had replaced the brakes, a screwdriver to pry open the brake panel rather than using a proper lever or pry tool and the screwdriver is not wide enough and so what it did was it just bit the metal in that one area and they just went around the entire brake cover with the screwdriver and you can see there's all these bend points and what that did is it let all this water and mud go into

 

Oh.

 

the brake assembly and

 

Yeah.

 

able to restore the brake drum well enough that it seems to be usable again. And also there they that when they did the service on the brake, you have to take the axle off. Well, they had put some of the parts back on wrong, which allowed water to get into the the rear. It's not a differential but the rear final drive is what it's technically called, but it's the thing that makes the wheels in the back go it connects it to the engine. So some water gotten in there. had to replace that and parts were all rusted up. And anyway, so I just, I was able to, I was able to use these, these wire wheels to remove the rust and get it clean. So I had a good mating surface so I could put the sealants and stuff on there. And, and then I haven't actually tried it out yet but I'm gonna pick Rustoleum because I think Rustoleum is gonna do some magic to, to this. And that's, that's what I've, that's what I've got for today. No, no technical picks. Well, I did mention earlier, him and we talked about Squish so we'll get those links in there but as far as you know pics of

 

Thanks

 

things

 

for watching!

 

I've been figuring out that's wire wheel and and I'm pre picking Rust-Oleum because I can tell it's gonna be amazing

 

So a couple things real quick. First of all, you're talking about a four

 

Thanks

 

wheeler.

 

for watching!

 

You're talking a four wheel ATV, like a Razor, or is this a car, a Jeep, a truck?

 

Oh yeah, so quad bike, ATV.

 

ATV, okay,

 

So

 

gotcha.

 

where I come from in Virginia, these are referred to as four-wheelers. I think more commonly here, oh, what's the word people use? But maybe it's, do they call them quad bikes? I think everybody calls them quad bikes. Even if they call them four-wheelers, they're still called quad bikes because they come from motorcycles. It was motorcycles evolved into three-wheelers. Three-wheelers

 

Right.

 

were so unsafe, they evolved into

 

Right.

 

four-wheelers.

 

Right.

 

Four-wheelers have evolved into side-by-sides because they wanted to be able to have the four-wheel experience but with more people You're not supposed to have two people on a four-wheeler every single four-wheeler says never ride with two people You always ride with two people, you know But so they created side-by-sides for something that is safe to ride with two people And that's kind of

 

Yeah,

 

there's

 

I was,

 

the evolution of motorsports for you

 

yeah, I was down in, in Puerto Vallarta, Mexico last week. And we did a little tour and we rode, uh, one of the things we did was, uh, razors we ran into some razors and we're, which I think is what you're talking about, sort of the side-by-side four wheel,

 

Yeah,

 

you know, with

 

razors,

 

actual seats

 

razors

 

in it.

 

are razors and is that the Polaris razor?

 

I don't remember the make of it,

 

Okay,

 

but

 

but yeah,

 

it

 

yeah,

 

was

 

that's

 

definitely

 

a

 

the razor.

 

side-by-side. That's what they call side-by-sides here. is you can sit side by side and now they have them so you can fit four people or even six

 

Right.

 

people in them.

 

Yeah. The ones that we had were like, I had two front seats and then a seat in the back that you could sit two or three people probably if you really wanted to.

 

Yeah, those things are so crazy. They're more, well, not more, but they're as expensive. They're more expensive than a cheap car. They're more expensive

 

Yes.

 

than a Kia Optima or a Honda Civic. But yeah, those things are crazy.

 

Cool, uh, and I had a question I was going to ask you and I totally forgot it. And I'm sure I'll remember when we're done, but, uh, Dan, you got any pics for

 

Yeah,

 

us?

 

so before I start with PICS, I just wanted to mention, we mentioned Figma a couple of times in this episode

 

Yes,

 

and about

 

that was it.

 

a month ago Adobe announced that they are buying Figma for 20 billion dollars.

 

No!

 

20 billion with a B.

 

No! Do you know what that means?

 

that figma

 

Oh

 

will

 

dude,

 

die.

 

so

 

Oh

 

many people were saying Figma's dead. I know like Scott Tilinski from Syntax had a whole thread and he's even got a video about an open source type of Figma app and I cannot remember what it's called. I'll have to dig it up. But he was doing videos on how to use it and how great it is because everybody's just saying, oh crap, Adobe bought it, it's gone.

 

So the there was two Spotify's before Spotify. One of them was called something media and the other one was Gosh, I can't remember the name of anymore. Then there was a third one songs. And two of them were bought by Google. One of them was bought by Apple. All three of them were shut down and there's probably more other than those but they they Apple bought. that it bought because they outsold they were outselling iTunes and they didn't even adopt the technology I think they adopted their their audio matching technology for iTunes match I think that's I think that's what they ended up using from the company but the the part of the company that made the money was their checkout and billing system and Apple just scrapped it

 

Well,

 

because they had a

 

well look If you buy it if a company buys another company to kill it just just for the Express purpose of killing it even if they don't announce it, but that's what what they intend to do It's unfortunate, but I can understand it. You know, it's a shame that it happens in ideal world It wouldn't but you know, that's one way of getting rid of a competitor But a lot in a lot of cases we see companies buying other companies to do something with them and you know it's still most of the times doesn't work out. Back in the 90s we used to call IBM the place where companies go to die because they

 

Hehehehe

 

would literally buy companies make really grandiose announcements about them and two three years later they'd be gone and they would be totally out of that market or whatever. Anyway so I just wanted to mention that.

 

Oh, here it is. I found what I was looking for. The open source alternative that people have been mentioning is called Penpot. So basically a Figma type of app that is just open source. So I'll throw that out there.

 

OK, anyway, so actually, you know what, Steve? You kind of you posted a dad joke on Twitter, which I'm sure

 

I'm

 

you'll

 

sorry. I'm sorry.

 

also tell us about a bar. And it reminded me

 

Yes.

 

of one of my favorite dev jokes about this developer who decides to open a bar. And then he invites his favorite QA engineer to test this bar. into the bar, orders a beer, orders zero beers, orders a billion beers, orders a lizard, orders minus one beers, and everything works out. And then the first actual customer walks in, asks where the bathroom is, the bar explodes, and everybody dies. So yeah.

 

I've seen that one. That does sound very familiar. So thank you for bringing that.

 

Yeah, anyway, so with that out of the way, my first pick is a technical one. And it's the fact that just, I think, yesterday as of the time of this recording, the HTTP, the Web Almanac, sorry, the Web Almanac for 2022 was released by HTTP Archive. We'll put the link in the show notes. They basically use lots of data collected by the Chrome User by HTTP Archive, both topics that we've spoken about with Rick Viscome from Google on this show. I don't remember the episode number. Again, we can put in the link in the show notes. Really interesting conversation. But it turns out that a lot of information, unless you opt out, a lot of information is collected about the websites you visit if you're using a Chrome browser. This information is collected anonymously into this cloud-based database, and you can actually run queries on it. perform various tests on these websites using tools like web page test and get all sorts of interesting information about them. And then once a year, they release this kind of open source document where they kind of tell you what the state of the web is. You know, from serious things like what are the more popular or less popular technologies to amusing stuff like what's the favorite CSS color to the least favorite CSS color web. And I can tell you that color is name in a bit. But some interesting facts out of there. So one really sad bit of information is that over the past 10 years, the total weight of web pages on mobile for them on the mobile web has grown by 600%. So if you're wondering

 

Only that much.

 

only that much. So yeah, we're

 

even with videos on the homepage.

 

Videos are streaming. And I don't

 

Oh,

 

know.

 

so they don't count.

 

I'm not even sure they count. Yeah. It's mostly.

 

Because you know that's the thing now is every home page has a video in the background that plays for five minutes with some girl walking up and smiling and laughing

 

Maybe

 

and

 

it

 

some

 

does

 

guy

 

count.

 

on

 

Yeah,

 

his motorcycle.

 

I don't know. Yeah, but don't you just love it when you're on this data plan? While traveling abroad and you're trying to get into the airline's website Uh to check when your flight is at or stuff like that and they insist on downloading this huge video or image of you know Airplanes taking off like I don't I know what an airplane taking off looks like Why are you eating all my data plan just to show me? uh, but anyway, um Some other interesting bits of information from there in case you were wondering can you guess what the largest? Style sheet on the web is like the page that has the largest Style sheet how big is that style sheet compressed? We were talking about compression about G zip G zipped. How big is that?

 

20 megabytes.

 

Haha, it's 78 megabytes

 

Oh,

 

Dang. That's a lot of style.

 

but wait, but is it one of those websites that's a joke website

 

I

 

or

 

have no idea. And another

 

it's

 

in,

 

not Wix?

 

no, it's not. Yeah, you know,

 

Ha ha ha.

 

Wix is heavier than it should be, but not that heavy. Another interesting fact is that the webpage with the most number of individual style sheets, the number has actually gone down from last year. Last year, the biggest offender had 2,300 style sheets.

 

That was New York Times, right?

 

Probably this year.

 

Boy, that gives new meaning to the term microservices,

 

Yeah,

 

huh?

 

this year it's down to 1300 or 1400 style sheets, which I guess is a lot better But there are a lot of really interesting and useful information in there about performance accessibility You know image the leading image formats and so on and so forth and by the way as a serious note Wix compared to other website builders and CMS's as has some of the lowest amount of image downloads because they use modern formats like WebP automatically. So yeah. So that would be my second pick, the Web Almanac. Really interesting. I highly recommend looking through it. And my final pick for today, I think it's my final pick. I forget what it is. So whatever it is, we'll skip it You know what? I just remembered what that other pick is We are watching fargo on TV. I know it's like It's like, you know, it's not it's not new. It's like this series I think came out in 2006 2008 or something like that, but we're finally watching it and we're loving it So if you haven't watched fargo on TV, the movies is amazing Of course, if you haven't watched a movie you owe it to yourself to watch the movie but the TV series is excellent as well. At least, you know, we watched the first season so far and we enjoyed it a whole lot, so I'm highly recommending that. And my final pick is that pick that I always pick, and that's the ongoing war in Ukraine. Nothing more to say except that the situation just keeps getting worse. Now Russia has announced that they are, you know, recruiting their reserves. over a million and consequently lots and lots of Russian men are now trying to escape Russia just so that they won't be sent to the front lines and you know it's just getting more and more sad and I don't know unfortunate and and whatnot so that would be my final pick for today.

 

Okay, so to counter that sadness, I will finish off with the dad jokes of the week. I'm hoping I haven't told this when I was off on vacation last week and wasn't posting my dad jokes as I normally do. I know it left a hole in great many people's lives. But see, I'll go back here. So a stork is carrying an old man and the old man turns to the bird and says, can you at least admit that we're lost? Right, stork didn't deliver the baby. Anyway, okay,

 

I got

 

yeah,

 

it. I got it.

 

yeah. So what do you call a dinosaur with poor eyesight? I

 

I know this

 

do you

 

one.

 

think he saw us.

 

I watched Jurassic Park.

 

Yeah, somebody mentioned that when I posted that in my company Slack. Um, somebody said, Hey, it's a throwback to Jurassic park. And believe it or not, I'm probably one of the few people in the world that had never watched that movie all the way through. Uh, but, uh,

 

The first

 

at

 

one

 

this

 

is

 

point

 

good.

 

I should. Yeah. Yeah. The very first one. Yeah. I certainly need to sit down and watch that one for sure. Especially if it's got a good joke like that.

 

It's Unix, I know that.

 

And

 

Oh

 

then

 

whoops,

 

finally,

 

wrong one. Hold on.

 

say what?

 

Oh, did y'all not, did you hear the soundboard

 

Yeah,

 

or

 

hardly.

 

no?

 

It's a unique system.

 

Barely

 

I know

 

was

 

that.

 

in the background

 

I

 

there.

 

know this, yeah.

 

So.

 

And obviously it looks nothing like a unique system when she, when you know, anyway.

 

I actually downloaded that program. It is for an IREX computer. I have it saved somewhere for historical purposes. I think it's also available on archive.org. It was, you know, it's one of those experimental things like Microsoft Bob or whatever.

 

Hmph.

 

Nobody actually used it, but dang, it was cool for the movie.

 

And then Dan or AJ, do you know what the first rule of passive aggressive club is?

 

Uh, no.

 

You know what, nevermind, forget it.

 

Okay.

 

And then finally, I'll tell the joke that Dan referenced earlier today. So three golf clubs walk into a bar. The putter orders a beer and the wedge orders some whiskey. The bartender asks the third one if he wants anything. He replies, no thanks, I'm the driver. or are you golf fans out there? Alrighty, anything else before we sign off gents?

 

No, no, I think it's interesting where we went with this episode, you know, not where I thought we would go but anyway

 

Yes, I think I'll title the episode, Dan's failed predictions

 

Ha!

 

or something like that. And with that, we will wrap up this episode of JavaScript Jabber. Thank you for joining us and we will talk at you next time.

 

Bye.