Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show on WEB News Station. I'm Dave Anchor Man Rupert and with me is Chris the Weatherman Coyier.

[Laughter]

Chris Coyier: There you go.

Dave: How are you, Chris?

Chris: Yeah, thanks for joining us on WWEB. Live from Austin, Texas, the bathtub of the south.

[News channel promo music]

Dave: Well, crazy….

Chris: There should be a WWEB. I don't know. That could be our four-letter news callout station.

I guess the point of all that was, we're going to do news this week. Sometimes we sprinkle news in, but I was thinking, "Gosh, there is so much to talk about." It must be Web news season because every major tech company is dropping stuff right and left. I don't know.

Dave: Yeah, there are a lot of headlines, so big ticket items would be, there was Microsoft Build, right?

Chris: Is it always? Is IO and Build, Google I/O and Microsoft Build always neck-and-neck next to each other?

Dave: This year, they overlapped, which is pretty cheap. I don't know. You know?

Chris: Hmm. Yeah, because it's like you're picking sides, super for sure.

Dave: I feel like developers do both, right? Yeah, and then, right after this, there's going to be a WWDC too, but then there was Microsoft Build. There's Google I/O. There was, like, GitHub had a really big event and then WWDC will be in June, I think, so kind of big news for the Web here. I don't know.

WWDC is always the interesting one because it's like we get the Safari announcements of what they're actually supporting. [Laughter] Then you're like, "Oh, okay. Here's kind of what we can use on the mobile Web now."

Anyway, Chris, of all these big events, what sort of stood out for you? I kind of have my thing, but--

Chris: Oh, really?

Dave: Yeah.

Chris: I have a dozen things on this list. Let's try to rapid fire a little bit just because I think it would be fun to talk about lots of news, but I like the idea of starting with our number one thing. What's your number one? Can I guess? The bash on Windows, we've talked about before, but it's kind of like a faker? Is it the real terminal, the real Linux terminal in Windows got you going, or is that not it? What's your number one?

Dave: Well, you know, that should be it because--

[Laughter]

Dave: If you followed us through the ShopTalk Show journey, getting up and going on Windows was a little rough, getting Ruby and things like that going. I think, as a direct result of the ShopTalk Show, they invented WSL, Windows System for Linux. I'm just going to take credit for that.

[Laughter]

Dave: Then they put Linux on Windows because of us here on this show. It's good, but there is a longstanding issue where it's like it's kind of slow. By kind of, I mean real slow, like you're just kind of, "Oh, man, this takes longer."

The initial thrill of running Linux on your Windows machine, natively, without a VM or something like that, Sequin, or something, is so thrilling that you don't care. But after a year or two, you start noticing this is actually very slow. It all comes down to how Linux works and how Windows, the file system, works.

It's at the file system level. When you save a file in Windows, there are file operations that happen, like before filter, after filter sort of things, you know.

Chris: Right.

Dave: Like, oh, let's do a virus scan after we save it to make sure there's no virus in there. You know.

Chris: If you're writing a file from Linux, does it kind of have to fake it or Windows all of a sudden sees it and runs a bunch of stuff?

Dave: I think Windows even will save a copy to safely save it and then overwrite or replace, but Linux is like, "Yeah, I'm just going to overwrite." But then, a lot of operations like Git or NPM, they do a lot of metadata querying like, "Hey, tell me a little bit about this file. What's the e-tag?" You know?

Chris: Yeah.

Dave: "Give me metadata," and that's an expensive operation in Windows for whatever reason. The geniuses in Microsoft -- [Laughter] I like when you say geniuses at somewhere. It's always condescending.

[Laughter]

Dave: But I really mean this. They're moving the subsystem for Linux, which was kind of like a subsystem. They're moving it kind of like to a first -- they're moving the Linux kernel part of that to the native Windows, basically, and they said some operations are 20x faster. NPM will be 5x faster or something like that. That's going to impact my life greatly. I mean I don't know.

I NPM install and I give up on the project before I even start. It's different, but it should be kind of rolling out this summer, so I'll definitely see it on my laptop, which is a little low powered. It's just the Surface.

Chris: It's mostly a speed thing. I thought it was more than that. Not that that's not enough. That's like a super big deal, but it doesn't open any new doors. It just makes things way faster.

Dave: Yeah, I think they have all the doors mostly fixed. Most everything works. I think there are people having SQLite problems or something like that, but SQLite is also kind of a weird thing.

Chris: This was not your number one. What is your number one if that wasn't?

Dave: You know, well, so that's huge, but I'm thinking a lot about that Google I/O stuff, the state of the Web. Deon and Ben do the State of the Web. I don't know if you watch that YouTube or that talk.

Chris: I watch some stuff, but not the State of the Web one.

Dave: But they kind of go over the high level features, right? First is like portals, right? This is kind of a big thing, like new portals, a portal element which acts like an iFrame. I don't know. You could probably describe it better.

Chris: Oh, well, I don't know because it was right when it came out; I overheard some joking in various Slack channels that were like, "So, it's an iFrame." I think their documentation clarifies that right away and says, "Well, it's iFrame-like, yes. You can load another document within the parent document, but it comes with a bunch of fancy, additional APIs."

One of them is promoting the URL of that little iFrame. Let's stop calling it an iFrame; a portal, I guess. You promote it to being the URL of the parent page, which to me, I'm like, that's a nice convenience API, but we had push date and stuff, so it's not like we didn't have the ability to change the URL before. You can still load an iFrame and then -- I don't know. There's still a path to changing URLs here, but it is kind of interesting.

I guess, to go a little bit more high level in case you're not following along with this at all, the demo was kind of like, you're looking at a webpage, right? Then imagine a little picture in picture. I don't think this is the only way you can use portals, but it's one of the ways. Imagine the lower left corner. There's another entire website, which would definitely be an iFrame, you know.

Actually, imagine this in the context of CodePen, too. Pretty interesting there, right? We have this whole grid of little tiny webpages on the homepage. You click on one of them and then it just kind of, through animation--and I think animation is a big part of this--it expands up to take the place of the entire webpage and the URL changes while it's doing that.

Dave: Mm-hmm.

Chris: A lot of the demos were shopping cart based. Imagine you have a server side rendered Web app that has a shopping cart. You put things in it. Now you're done looking at the cart and want to move to the next stage, which is the first stage of checkout.

Maybe the cart whisks away to the left and the checkout page whisks in from the right, but they're literally different URLs and you're not writing in React or Vue or anything. This is some WooCommerce server-side checkout or something. You can still do that single page app-like stuff by animating out one page, animating in the next page, but having it kind of already have prerendered, so it feels really fast and smooth.

Oh, my God. I feel like I just did a terrible job explaining this, but it brings SPA-like stuff to server-side rendered apps, if you want it to be.

Dave: Yeah, I mean if you think about when you checkout and you use Stripe, PayPal, or something, and it's like, "Oh, now going to the PayPal site." What if that all happened in the same tab and no weird bounce out, the bounce back?

Chris: White flash.

Dave: It just happened. Yeah, white flash. It just happened kind of seamlessly. It could be very, very cool.

I think, for me, the demo they showed was this recipe site that you kind of bounce around and it connects to your social network where you share recipes. It was four different websites kind of interacting. Right?

Then I went and enabled it in Canary. I got the demo prototype or whatever. Then it was like a major letdown, for me, because it was not the same as that demo they showed, like the delta between the demo and what I have on Canary.

Chris: Oh, it didn't. Right after it happened, you're like, "Why does it break the back button?" which does seem significantly not great.

Dave: Yeah, it broke the back button. They were like, "Oh, there's a bug for that," so they're on top of that, but it was like, "Uh, this is not as advertised," would be how I'd describe it.

But it is cool. You get this little picture in picture. Then you click it. Then it's the URL and you can animate that and stuff like that.

Chris: Yeah.

Dave: I hadn't even thought about CodePen but, yeah, if I could work on CodePen, minimized, and then maximize it, then close it, and minimize it again. I guess you could maybe do that with iFrames now.

Chris: I think we can do that stuff anyway because we're moving more and more towards React. Quite literally, it won't be too long until we're just a client-side rendered app. Not that we're not going to have any server-side rendering stuff. We're going there, too. But by the time CodePen is fully booted up and hydrated and everything, we don't need portals because we have React, but my WordPress--

Here's a million dollar idea, ShopTalk Show audience. Make a WordPress theme that's all portalled up, right? That's all server side.

Just do the basics. Just do, when I click a link, I want it to use portals to have some kind of animate, inanimate out behavior.

Dave: Wipe down the article.

Chris: Yeah.

Dave: Weep, like screen lapse.

Chris: I mean I wrote an article a million years ago about how to do this in WordPress with jQuery that was like, okay, I'm going to intercept all clicks on links. When you click on a link, if I can tell that it's an internal link to this website, use jquery$.ajax to go fetch a URL, like all the content of the server side rendered, whatever URL that is, and then replace the front-end part of it. You could scope it to be like, well, don't replace the header and the footer because those are the same throughout the site. Just replace the middle stuff of the page, or whatever.

Something like jQuery made that a little bit easy, but it was like, eh, you're kind of faking it in a way. Then there's all kinds of stuff you have to do for yourself. You have to then use window.pushstate to change the URL. As soon as you ever use that API, then you have to be always watching the state of the URL as well to make sure that the back button, for example, works because it won't if you don't otherwise.

Dave: Mm-hmm.

Chris: It wasn't particularly efficient. You've got to load in a whole additional library to do it. You'd have to bring your own kind of animation finished. If you wanted to animate out, you'd have to load the page, make sure the page is loaded, then do the animation. Wait for the animation to finish. Replace the content in some off page thing that animated in. It's just a lot of work that you had to do yourself for this just to replicate something.

Dave: Yeah.

Chris: It's not like this is going to be work too, though. At least it's native.

Dave: Yeah, I mean I think the two things would be like the drill-down slide effect, like where you click a list of items and the next one slides over. Then you hit a back button and that dismisses.

Chris: Mm-hmm.

Dave: It shows the previous one and the other one slides over. I would like to see those effects kind of achieved, but maybe the Web doesn't need to mimic the iPhone. Maybe we come up with our own nomenclature.

Chris: Portals are URL based, though.

Dave: Yeah. Yeah.

Chris: You can't say, "Just give me the JSON data for one tiny little list item." A portal is like, "Give me the entire URL of all of this." You'd have to really architect your app around that concept, in a way.

Dave: Yeah. Yeah, and I don't even know how client-side frameworks would even have it. You know what I mean? I guess it could render. I guess if you made a request, it would render that page, but then do you lose all your state? It's interesting tech.

Chris: A lot of unanswered questions. It's not that it's not cool. As confused as we are about some of the things, I still think it's a big deal. It's a big deal in that there are some sentiment that the reason the Web has gone as client-side rendered as it has is because the feel of client-side rendering can be so nice in page transitions and loading of data.

Dave: I agree with that.

Chris: To have a native thing that's built to address that head-on so that you don't necessarily need to go down the road of client-side rendering just to achieve this. You can bring this to your server-side rendered apps is a big deal.

Dave: Yeah. To that statement, I do; I think about, oh, maybe I need to convert the Paravel site or something over to a single page app so we get those cool animations and can wow clients and things like that, but I think we're on the, like, "Let's wow them with the speed instead." [Laughter]

But you know there are agencies that that's their whole thing. Active theory does such amazing stuff, but their whole portfolio is just a canvas. It's just canvas.

I don't know. I think these are going to be cool. It's cool tech, and it seems like it has more of a standardization process than the page transition API or something like that.

Chris: Yeah. It is funny, though, if you have a smokin' fast site. You know what's funny? I just read an article on Google recently that says, "We're making all this headway to remove white flash, too. If it's the same domain link, then we're going to do all we can to not show you a white flash."

You have a smokin' fast site anyway. CSS-Tricks isn't smokin', smokin' fast, but it's pretty okay. If you click from page to page, I don't feel like I'm -- for want -- I don't think I'm like, "Oh, I wish that page slid out and the next page slid in." Those effects are kind of fun, but I don't know that it's entirely necessary for a site like mine.

Then to have Google say, "Oh, we're even making those on page links even feel faster and better," it's like, eh. It's nice that it's being tackled from both sides.

Dave: Yeah.

Chris: I'm sticking by it. I would like to see somebody make a default WordPress theme that felt SPA-like through this technology.

Dave: Yeah.

Chris: It'd be cool.

Dave: No, that'd be cool. You know one thing, too, in that Google I/O thing, I was going at 2x when I was working, too, so I need to go back and watch it. At one point, Paul Lewis, @aerotwist, hops on the stage. Paul is back, and he demos, I want to say, like a QR thing, but it was more like it had machine learning and it could tell you what an object is, kind of thing. I believe that's what it was.

He's kind of showing an API, how this is built into the browser, but then he was like, "And if you don't have it, we're using WebAssembly as a fallback." This was the first time I've seen a camera or something built in WebAssembly as a fallback, like a whole--I don't know--AI or something on the website. I think it was called Perception Kit. Anyway, it was just very interesting. It was just kind of like I hadn't really seen somebody be like, "Oh, yeah, and they made a WebAssembly fallback to this kind of nascent browser API." I thought that was kind of cool.

Chris: It feels the opposite in my mind. I would you think you'd have to make a fallback for browsers that don't support WebAssembly, not a WebAssembly fallback for browsers that don't support something even more futuristic.

Dave: Yeah. I mean that was kind of -- I mean, I don't know. I think WebAssembly is maybe here, if that makes sense. [Laughter] Maybe it's more ubiquitous than we even imagined.

Chris: Yeah. I mean I sort of loosely get it, especially the fact that other languages can compile to it and then it turns into this, and that even maybe our regular old website packages might maybe be able to take advantage of it. Of course, my dream is to just change one line in my Webpack config that outputs WebAssembly instead and then my website gets delivered as this amazing little package that is already precompiled and it loads even faster in users' browsers and I did no work whatsoever. That would be cool. [Laughter] That's what I want out of WebAssembly.

Dave: Mm-hmm.

Chris: But I understand it's much more than that.

[Banjo music]

Chris Enns: This episode is brought to you by Mux. Mux.com is an API first platform powered by data and designed by video experts to make beautiful video possible for every development team. Mux makers building amazing video experiences easy. What Stripe does for payments, Mux does for video. Teams of all sizes can get started in minutes. Post a video; get back a video URL that plays well on any device in just seconds.

Mux Video has a unique, just-in-time transcoding engine, an optimized streaming origin, and CDNs expertly configured for the most efficient video streaming. You can get started in minutes, not months. Integrate streaming video in a few lines of code in the programming language of your choice. Mux supports your video workflows, no matter how complex. It's powered by data and coding and delivery are self-optimizing to work perfectly on every device every time.

By using Mux, you can future proof your video stack. New devices, new formats, no problem; Mux handles it all. Leverage their ten-plus years of experience building video infrastructure and stay ahead of the curve. You can get started today at Mux.com with a free account. Our thanks to Mux for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Other news out of Google I/O; I heard some tweets that were like, "Of all the amazing tech announced, this one kind of flew under the radar and then, all of a sudden, not so much." There are lots of people talking about it. It was that the Googlebot, which is the thing that crawls the entire Internet is the thing that informs Google search results and whatnot of your new pages now runs evergreen Chrome. It's just one more thing that's evergreen in the world in a way that, you know, your Firefox auto updates and, to some degree, your Safari auto updates and your Edge auto updates and stuff. You just wake up some morning and your browser is updated to the newest version. That is incredible in its significance to the Web.

Now the Googlebot does that too, and I'll tell you; it confused me in a way partially due to my ignorance. I didn't even think of Googlebot as being a rendering engine let alone one that was pegged to a very specific version, and so the news around it was like, "Since everybody automatically knows that the Googlebot ran Chrome 44 and that development teams would, on purpose, package older JavaScript to deploy their apps because those development teams know that the JavaScript engine of Chrome 44 didn't support intersection observer or whatever, and so, for SEO reasons, companies produced legacy, shipped legacy JavaScript."

I'm like, I don't know. I've never ever heard anybody make a choice about what JavaScript they shipped based on Googlebot, but that's, to some degree, my own ignorance. I don't know every company out there.

Dave: Yeah, I saw Alex Russel being like, "Now you don't need Polyfills," or whatever. I was like, "Uh, Alex."

Chris: Oh, shit. We needed Polyfills?

Dave: Well, yeah, or you need whatever - some weird Polyfill for Chrome 38 or whatever the Googlebot was. I'm just like, uh, I use Polyfills for IE11. I'm stuck there. I don't know. I can't. I'm not released from a prison just because Googlebot updated. [Laughter] You know? I don't know.

Chris: Yeah, I feel like I just never made choices, technological choices, based on what Googlebot was doing. I didn't even think of it as a rendering engine. I thought it would be its own special -- because there's so much shrouded around how Google crawls webpages and ranks results and stuff anyway that I didn't think that was super public knowledge, how it crawled and looked at your site.

Dave: Mm-hmm.

Chris: Anyway, because I heard plenty of people be like, "Oh, thank God. I can just ship my website however now. As long as it looks good in evergreen Chrome, then that's that. I don't have to think about this anymore," which is not what they're saying.

If your website still is client-side rendered only, like it has to boot up a bunch of JavaScript and then pulls content from some API and then renders it, the Googlebot can tell that, which that is shrouded in mystery to some degree, still. They're not exactly telling you what criteria places you in this special queue, but that's what happens is that it can say, "Oh, I see what's happening here. This is a client-side rendered app. It requires JavaScript in order to render it and look at the content that's on that page. I'm going to put you in a special slow queue," and that slow queue is, I've heard, a week at the soonest is how quickly they are able to get to it, and that includes the first time that it's looked at, as well as updates to that URL when it changes.

Does it have an impact on your SEO? You're damn right it does - a huge impact. If it doesn't affect ranking, which I'm not sure if it does or doesn't, it at least affects how quickly it's able to get into search results at all and then how quickly it's able to be re-indexed when that content changes. That's great or whatever that Google has this evergreen Googlebot. It's good for you and me and good for everybody, good for the Web, but it doesn't mean that you get to be like, "Oh, phew. I was going to look at SSR, but I guess I don't have to now because Google took care of that." No, that's not what they're saying.

Dave: Yeah, it's confusing, right? You think, "Googlebot updated. Great. Now it's on a modern browser," but that doesn't mean, "Oh, you don't have to do any--" or it doesn't solve all your problems, I guess.

I did find that thing that Paul Lewis demoed. It's called perceptiontoolkit.dev. I was a little bit wrong. It's an AR thing, but it's basically built into the browser, Window.Perception Tool Kit, but it's just this idea that you can scan an object, a barcode, or a logo and it knows what you're looking at, if that makes sense. It's almost like a cognitive service API, sort of like a visual screen reader or something.

Chris: Hmm.

Dave: Tell me what I'm looking at. There's a demo where he scans this little toy, like a Funko Pop, and it goes, like, "Okay, that's this Funko Pop." Then he scans the Squoosh logo for that image compression app and it links to the Squoosh app.

Chris: Ah!

Dave: It could be kind of cool. You see a CodePen logo, you scan it, and then you're like, "Oh, that goes to the CodePen app." I don't know. It's kind of--

Chris: It's cool and scary, right? I heard a sentiment from somebody just the other day. They were wanting to integrate some kind of image uploading service onto their website. They picked one, you know. Then part of the marketing for that service was like, "Oh, in addition to being this media hosting service for this website, we have a couple of other interesting features. One of them is facial detection technology." It was a little vague about what it did, how, and why, and whatnot.

Then somebody else reacted to that and be like, "That's a little scary," you know? I'm going to upload my website's assets to your servers and lord knows what machines it's training or are you automatically looking at my photos and deciding what's in them for some questionable reason, even if it's maybe some future reason for myself? I don't know. Why? Can I turn that off? What are you doing with my images?

Dave: Yeah.

Chris: This makes me think of that.

Dave: One slip up and you can Google Dave Rupert's butt.

Chris: Get a highly accurate rendition? [Laughter]

Dave: Yeah. Yeah. You know?

Chris: Yeah.

Dave: Or something like that. Is that a possibility or whatever? I don't know. Or like with this one.

Chris: But on the one hand it's really cool. I don't want to tell my camera. If it just sees a QR code, it might be nice if it was just like, "That looks like a QR code. Can I help you with that?" Rather than having to download some special app that's on purpose looking for QR codes all the time. Do I have that right; it just knows what it's looking at?

Dave: It figures out what you're looking at and it'll tell you something about it. You know, where does this start and stop? Could I Skype people in a conference or whatever and then it'd take me to their live journals or whatever? [Laughter] I don't know. Where do we start? How far does this rabbit hole go?

Chris: Yeah.

Dave: That's the question.

Chris: Right.

Dave: It could be a cool feature. I don't want to be poo-poo, but I also just see that, "Yikes, dude. Everything."

Chris: More and more, technologies like this are presented to us as, like, "Look at this cool, new technology," not like, "This is cool new technology, and I want to be really upfront about how seriously we're taking privacy concerns with it." That always seems to be like, "Oops, let's talk about that later," or, "If we get called out on this, we'll release a public statement," but it's never like on the forefront, which is a little scary.

It gets me thinking about this. It's not just, okay, there's the Googlebot news, the portals news. There is Google has shipped lazy loading for images to great applause. Like, holy crap. Native lazy loading, that's amazing.

They shipped font display as part of Google Fonts. Oh, that's exciting, right? It's just a parameter and the URL that you link to. All of a sudden, you get font display. Now they're the first font host ever to allow that in such an easy way. A huge, huge win.

I read some article, other article the other day about how they kind of have this alternative to local storage that's way faster called KV Storage that I was fascinated by that's kind of asynchronous-based, so it doesn't block the thread and stuff, kind of classic Google stuff that they're concerned about lately. It's fascinating how you use it. You're able to import it like an ES6 module, but you don't import it from some URL or some other file. You import it from the browser itself. It just has this built in.

But if you want to use it, you have to ask for it. You have to import it. It's not just a built-in API. You know? Isn't that funky and weird? Anyway.

Dave: Hmm.

Chris: All this stuff, but it's rapid-fire, particularly from Google lately. "We did this. We did this. We did this," and the vast majority of it is amazing. You're like, "Yes!" I wish I was at I/O in the audience clapping with some of this stuff. It's cool. They're doing good work.

Just to paint a picture of the wider industries, I've heard from people that, for example, work at Mozilla that they're just like -- because we've talked about browser diversity on this show already, like releases from Firefox are a little further and fewer between and they're a little bit more like, "We improved this little part of our developer tools," and it could be this great release, but it's not as, like, change the industry huge. It's because Google has 100 times more developers or something.

This diversity thing, it's already over. Firefox is totally steamrolled by Google. That steamrolling isn't just happening. It's happened.

Dave: Yeah. No, I mean that's kind of a scary thought, right? I think it was Mike Taylor who did a talk on the browser gap, and I think we had talked about it on the show before. It's widening. What can Mozilla catch up on?

I've even heard people at Amp tout that, like, "Oh, we've contributed back to WebKit." It's like, "Yeah. Okay. Do Firefox too." You know? You're contributing to WebKit because it's easy and I understand that, but you also want it on the other mobile browser. You know? I think that's Firefox's issue, too, is they don't have a top three mobile browser.

Chris: Maybe that's good, so they can slow down. I'm sure they very carefully have to pick what they're going to work on to maintain the most compatibility as they can because there is no way they can grab all of it. Is there going to be Firefox portals coming in the next couple of months? No way.

Dave: Yeah. Yeah, and I didn't really see a path to progressively enhance portals. I was kind of like, "How would this work?" I guess you could do an iFrame that just goes big or something, but I think it's cool tech. I don't want to knock portals, but I didn't see the pathway to, like, "Okay, I could do this and then what a normal, non-portal user will get is this." I didn't really feel that or get an idea of how that would work.

Chris: Maybe that team has an answer, too. Maybe somebody listening to this show is just like, "You idiots totally have it wrong. We released a Polyfill or said we're going to. It's coming soon. This is standard track stuff. We're doing all the right things."

Fine, but it's not just portals. There are 50 other features that are kind of in the same bandwagon that are just like Chrome things for Chrome. Even if they're all doing the right things, let's say they are, that's awesome, that Firefox can't do all 50 of those. Then next year, there are 50 more. The next year, there are 50 more. It's already over. The writing is on the wall.

Dave: Yeah. It's a denial of service attack.

[Laughter]

Chris: Yeah.

Dave: On Firefox.

Chris: It's DDOS features. Yes, exactly.

Dave: Yeah, basically. You hate to be like, "Oh, Google is intentionally DDOS-ing Firefox," but I don't know.

There was that article that kind of made the rounds. It was about how YouTube killed IE6.

Chris: Yeah, that was fascinating.

Dave: Did you read that one?

Chris: Yeah, totally.

Dave: The story goes, as it goes, is from YouTube, a former YouTube developer. They had a bunch of bugs. IE6 is weird. Let's be totally real, especially if you're trying to run a video platform where video didn't exist. It doesn't have HTML5 video. It's just a weird platform. They kind of said, "On this day, we're going to start showing a banner to download a new browser."

Chris: Right.

Dave: They randomized the order in which you could show Chrome, Firefox, or--

Chris: IE8 or whatever, yeah.

Dave: IE8, yeah. They randomized that order to avoid legal trouble. That was very smart because I think lawyers showed up because they saw Chrome first, and they were like, "What did you do?" But they randomized that.

It's very interesting because, on the day they switched that thing and said, "We are not going to support your browser anymore," IE6 traffic plummeted, like unnaturally plummeted. I think that's -- I don't know. I think that it's cool that they brought the Web forward and they just made a bunch of people upgrade their browser. I think that's really cool, but it's also very scary to me that a browser, one website, can basically change the browser landscape. You know what I mean?

Chris: Yeah, a website, not even a big company but one particular website can have that power.

Dave: One website owned by one big browser company, but what's interesting, kind of taking it today, there are things like YouTube Creator Studio does not work in Firefox. You know what I mean?

Chris: Yeah, I mean I think the sentiment goes that every time something like that happens, although that's been a longstanding one, so I can't speak to that necessarily, but there's been a lot of like, "Oops, that wasn't our intention. Let me fix that. Oops, here's the bug. Oops, here's the bug. Oops, here's the bug," kind of thing that it starts to feel like not like, "Oops, that's a bug," that that's the way we do things around here is we're just going to push it real quick first for us, wait for somebody to complain about it, and then fix it, kind of thing.

Again, that's probably not what it feels like overall. It probably feels like that really was a mistake. That's really not our intention. We really do plan to fix that. We're really sorry about that. But for the 60th time, it's like there is a pattern here. You know?

Dave: Yeah, well, and for me, it's a failure in management. I think there are managers who are like, "Just make it work in Chrome," like that's what they say. You know.

Chris: Yeah, and there's another aspect to that that's like the way that you succeed around here is to do something big and new. It is not, "Slow down. Make sure the spec is really good. Fix it up. Be this interoperator and make things run really smoothly and happily."

It's like, no; new and big. And I don't know; I don't work--

Dave: Shiny wins. Shiny wins.

Chris: I feel like every time I say this, I'm like crapping on all the good stuff because I don't want to be because it's pretty dang rad, all the stuff that they do. They have an incredible team of people that they've put together. I feel like the standards are really high over there, but we've just got to watch it. Then sometimes I feel like it just doesn't even matter what I think or do or say anyway because it's just so big.

Dave: Yeah. Yeah, it's such a big operation, you know.

[Banjo music]

Chris Enns: We've talked a lot about Netlify Build before, the Git workflow for Web development where you can build, deploy, and manage modern Web projects super easily with Netlify. They just launched something new they're calling Netlify Dev where you can run their entire platform right on your laptop or your desktop, I suppose, too. You can preview it all: site generation functions and edge logic. Imagine the productivity boost of being able to locally test your site generator, API integrations, serverless functions, and edge rules all in a single development server. That's Netlify Dev, a powerful way to build and test modern Web apps on your local machine.

With one simple command, you can install Netlify Dev to user on any project. That'll spawn a fully local environment of Netlify Dev that automatically detects and runs your site generator, makes environment variables available, performs edge logic and routing rules, and compiles and runs cloud functions. The extra bonus is that you can even stream that live, so Netlify Dev takes hot reloading to a whole new level, allowing you to actually stream your dev server to a live URL, which is great for collaborative development. You can now share your work as you work and get instant feedback. I could be working on my site. I could have it open in a browser, open on my phone, see the changes live as they're happening, but you could also have it wherever you are in the world open on your browser or on your phone. Whenever I update something, the site will update, and you'd be able to see it.

Netlify Dev automatically detects common tools like Gatsby, Hugo, Jekyll, React Static, 11ty, and more, providing a zero config setup for your local dev server.

Netlify has faithfully replicated their powerful edge logic engine in WebAssembly so you can locally test all the same rules before deploying them to their global infrastructure. You can write cloud functions in modern JavaScript adding needed dependencies. Netlify will compile your functions as AWS Lambdas and deploy them as full API endpoints.

Local testing works too. It all comes with Netlify Live, a hosted service that continually runs your dev command just like you do locally, watching for changes. The result is an instant preview you can share with your entire team with live updates as code and content changes.

Like I said at the beginning, Netlify Dev installs with a Netlify CLI. Create new sites, set up continuous deployment, and push new deploys right from the command line. Netlify Dev is just the beginning. Take your local developments to Netlify Build, power collaboration through Netlify's Git-based workflow with deploy previews, branch testing, and more.

Check out Netlify Dev at Netlify.com. Our thanks to Netlify for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Lots of news. That was just their news, but is there more? Is there more interesting Microsoft news? I feel like they drop cool stuff all the time, too, especially VS Code just gets better and better all the time, doesn't it?

Dave: Yeah, VS Code is getting better. I think their big thing that they're kind of pushing is the real-time collaboration.

Chris: Yeah, Live Share. Have you tried it?

Dave: Live Share. I haven't yet, but I would love to because -- I don't know. How many times have you gone on a screen share, like a Slack screen share, Zoom, or whatever?

Chris: Yeah.

Dave: You're like, "No, that line." Then they scroll and you're like, "Oh, go back. Okay. Stop. Don't do it."

Chris: [Laughter] Zoom, you can take control, but that's a little awkward, too. It's not that this isn't awkward either because you're on the Zoom call anyway, so you have to choose.

Now I'm seeing their screen through Zoom, but I'm also seeing their screen through Live Share. It's like, which one do I focus on?

Dave: Mm-hmm.

Chris: It kind of confuses me. What things synch and what things don't? Okay, so we're live sharing. Basically, I've granted them access to my dev environment here. They don't need the repo either. It can be just local to my machine only if we wanted. That's nice that it's not like we have to have both have Git pulled recently and it's own operating system. It just shares what I'm looking at which I think is pretty cool.

But then let's say you have five tabs open. Do they have those same five tabs open? If I close one, does it close on their machine too? Let's say they hop over to the third tab, but I'm on the first tab. How do I know where they are? Should my interface change to follow them or not? Do they have to tell me they're now in the third tab so that I can go look in the third tab? I find it a little confusing.

Dave: Well, and I think they're doing interesting stuff, too. Okay, your node modules; am I using your node modules or my node modules? How do those synch up? I think they're even putting third party servers in between, if that makes sense, or you can work on the same Ubuntu or something like that. I think it's interesting. I don't know. Maybe we should get somebody from Code on here to talk about all this stuff.

Chris: Right, because then the terminal, is it like if they save a file and I have a file watcher going, that should just trigger a save on my end. My file watcher will see it, do some stuff in the terminal, and then is their terminal a real terminal or is it just like a video of my terminal so that they can see what's going on? That's where that node module stuff kind of comes in, right? Is it just piping whatever happens in my terminal to their terminal so they can see what happens, or is it local to their machine in some way?

Dave: Right. Right. I think it may be, like, you're all working on the host computer. Whoever is the host, we all are editing on that.

Chris: Yeah.

Dave: Again, I don't know. I don't know and I don't know why….

Chris: I've only used it like three times, but it was effective all three times. I thought that it was cool in that way.

My favorite way to work together was always that -- what was that? There was some -- it might have been Mac only, so sorry, but it was the one that Slack ended up buying and putting it in Slack, but then they didn't do anything cool with it.

The idea was that you both got cursors. In Zoom, if I share my session with you and give you control, then just you control, right? I can't move the mouse because it'll screw up you. You move the mouse. We'd be fighting.

This app, we both had separate mouses somehow, and we could both do different things at the same time, which is pretty rad.

Dave: Yeah.

Chris: Then it was no question about, what are each other looking at? We're looking at the same screen. There's no ambiguity there at all.

If you change a tab, well, visually the tab has changed, so we're looking at the same thing at all times. It's definitely local to my machine. That was kind of my favorite way to co-work because you weren't stepping on each other's toes and you were looking at the same stuff all the time.

Dave: Kind of Google Docs-y, in a way.

Chris: Yeah.

Dave: You know there are other Microsoft news. I mean the big one is probably Edge, you know.

Chris: Yeah, there is a release for that, and they're still calling it Edge, although I've heard people again talking. Jen Simmons is like, "There's going to be a new name. I can't wait. What's it going to be?" I'm like, is there? I don't know. So far, it's just Edge, right?

Dave: Sure, let's call it something different. We'll call it Rupertonium.

[Laughter]

Chris: Ooh!

Dave: I'm just going to throw that out there.

Chris: Is it because it's not production yet? Normal old users just using Edge, they're not using Chromium. You have to opt into this in a special way.

Dave: Yeah. You have to go to the website and download the beta. There's a dev channel. There's a stable, a dev, and a canary channel, just like Chrome. The dev channel gets updated every week. The canary is every night, so new features are arriving all the time, but it's neat. For me, it's the best looking Chrome. I think I said that before, the version of Chrome.

What they announced at I/O this year was kind of some different features. There's going to be privacy configuration. You can basically set it to default, like don't track me. Then you can even go to, like, I want to be like dark Web style. I don't want to be full Tor, but I want to be very hidden or whatever.

Then they're like, "I don't care. Just track the hell out of me," setting. I doubt that'll get used, but anyway.

They also announced this new feature called Collections. I don't know if you saw that, but it's basically like Pinterest in the browser. A little sidebar shows up and you can just drag links, images, or whatever you want to it.

Chris: Nice.

Dave: I only bring it up, I mean, like I actually could use it for Weeknotes. I don't know if you're on that Weeknotes trend, Chris. It's a hot new blogging trend that's sweeping the world.

Chris: Like W-E-A-K?

Dave: No, W-E-E-K.

Chris: Oh, oh, oh, oh. Yeah.

Dave: You just blog about your week and share some links that you saw during the week. It's kind of a fun, little trend, like a reading list kind of trend.

Chris: Yeah, I've read yours and a few other people's that do it. I do like it because of the personal nature of it. It lends itself to the pros of, "I was walking down the street," type of stuff, which I like. Even if it's tech news heavy, it can still have a very personal feel to it that I like.

Dave: Yeah. I personally try to keep it -- I'm not operating like a Peter Cooper newsletter or anything like that. [Laughter] Like, "Best of the Web links!" or whatever. There are a lot of Web links in mine but, also, this is a chance for me to reflect on the last couple of weeks.

I collect links in a Notion. It'd be hard to break up with Notion, to be honest.

Chris: You use their Web Clipper?

Dave: If I could just stash -- yeah, if I could Web clip and just stash things into this collections thing, that might actually be useful or, for people who don't have Notion--I'm sorry--that might be a useful feature.

But I guess the big meta discussion I want to bring up is, is this kind of the future? Is this how browsers compete on these kind of weird or extensions, basically, like native extensions? Is this kind of what's--?

Chris: That's my favorite competition of browsers is when they release features that are really cool and useful for users but aren't a fundamental transformation of how websites are delivered and rendered. I want there to be innovation there too, as much as possible, really. But if a browser is going to do something like innovative and interesting for a user, it's so cool when it can happen at the UI level.

Like this Web clipper kind of thing has nothing to do with Web standards. They can do whatever the hell they want in there. Go crazy. Make it amazing. You can compete on that feature and make people choose your browser because that feature is so cool without having to be like, "Well, we invented three native APIs to do it and only shipped them in this browser," which, of course, I feel like the alarm bells are starting to not go off as much when that type of thing happens these days, which is the gateway to browser wars.

Dave: Yeah. Yeah, we're just like, "Yeah, thank you. Awesome. Oh, I can't believe Firefox doesn't support the brand new Web perception toolkit API." You know it's like it just happened.

Chris: That's you fighting against yourself. When you say stuff like that, that's you saying I want the Web to be a worse place. If you're yelling at one browser for not supporting something that that other browser just, like, went rogue and shipped, it's all over.

Dave: Mm-hmm. But sometimes there are surprises. You're just like, "I can't. This is like 12-year-old tech. I can't believe it doesn't -- why is this not supported?" You know?

Chris: That's true. There are safer ways to do that, like if you're mad.

Dave: For me, link rel preload in Firefox has been under a flag for like two years. Let's get it out there. Anyway, that's just me; just one example.

I think I actually went to the issue and that's the nice thing about Firefox is that issue tracker is so transparent you can almost find out every discussion about, like, "Why don't they support this?" You just go and read them talking about why they don't support it.

It's interesting, but I think we're starting to get a sense of the new browser wars, I guess you might say. Can we coin that and patent that and only we talk about the new browser wars?

[Laughter]

Dave: Just because I think it is, as Chrome sets the pace and Chrome is sort of the standard bearer, for better or for worse, we're starting to see how this is going to play out. It's interesting.

Chris: It is. It is. It is. Safari still exists, too, which is WebKit and not Blink, and Apple is such a huge company, they are a bastion of a diverse-ish -- you know, even though it has the same lineage as Blink, it's been long enough apart that it almost feels like a different browser, in a way, and Firefox is still there. There's the Samsung Internet.

Dave: Yeah, I would say there's rendering parity, but not feature parity, if that makes sense.

Chris: Yeah. Yeah, that's about right. When they release stuff, a lot of times it's just like, okay, we've caught up on what we feel the important things are. We've slipped in a few bonus things. Surprise; here are some new, weird metatags or whatever.

Most of the recent news from them is, one of them was some dark mode stuff. They've been kind of evolving that, which matters more to some people than others, I guess. It's interesting lately in that there is--

Dave: That is so hot right now.

Chris: It's actually just like a CSS property now. You just get to declare whether your site supports these dark mode things or not. Then I think it's going to actually have some functionality. Let's say that was the only piece of CSS that you wrote on a page was that dark mode was supported. I think it will actually change some stuff, like the user agent style sheet will have a dark background automatically and the text will be light colored automatically.

Dave: I have questions. Can I ask questions?

Chris: Yeah. Don't quote me on that either. I'm not sure.

Dave: No. I like dark themed UIs or whatever, but can I see the light themed website? I don't always want the dark themed website. I think a lot of dark themed websites start off as a good idea and end up being phoned in.

Am I able to bail out or am I just stuck? Do I have to change my whole operating system's theme to make this website readable? Do you know what I mean?

Chris: Yeah, that is interesting, isn't it? Because you changed dark mode anyway at the system preferences level, does that mean that if I flipped that switch that it's totally out of my hands while browsing your website? Certainly, I could, as the author of that website, offer you some control over that, but it seems like it's not really encouraging that.

Dave: Yeah. Yeah, I don't know. Uh!

Chris: Maybe it is. Maybe the fact that it's just one setting in your CSS that you change, it makes that switch really easy to write. You just change one thing in your CSS.

Dave: Well, yeah, if you use CSS variables and it's like a class that you're tricking or whatever, switching.

Chris: Yeah.

Dave: Yeah, we could probably add toggles on our sites, but all these new APIs are kind of like automatic dark mode if you're in dark mode or if Safari is in dark mode. That's always interesting. I don't know. I don't think it's 100%, I want dark mode all the time. That's where I'm coming from.

Chris: Yeah. They've also been -- I think they just shipped the Web Share API, which I think has somewhat long existed for iOS Safari, which I really like. I think it's a really nice API. I think it's cool that you can trigger it based on some sharing action on a website. Share this, whatever, and it comes up with the native phone level share thing.

Dave: Share LS.

Chris: Which is like, send it to Twitter; send it to Vizwik; send it to anything that I, as a user, have configured. I might configure my Notion in there or my Bear app or some of these other apps that I like. It just gives me that as a user rather than me having to code up my own share thing or use third-party JavaScript widgets to do the sharing. The native sharing is so much nicer, I think. It's both better UX and more fully featured and lighter weight. That's just all awesome all the time, and they've shipped it for desktop Safari now, too, which I think is quite cool. I'd love to see that every browser pick up that Web Share API stuff. I think that's cool stuff.

Dave: Yeah. Now we can just use that weird fork icon or whatever, the share icon and just trigger that Web Share.

Chris: Yeah. Oh, yeah, one of them looks a little bit like a Git logo.

Dave: Yeah.

Chris: One of them is like the box with an arrow pointing straight up out of it.

Dave: Oh, yeah, Up Box.

Chris: Up Box. [Laughter]

Dave: Up Box and--

[Laughter]

Chris: Too bad this is an audio show because that would be fun to have flashcards of little SVG icons and we both have to name them just on the fly.

[Laughter]

Dave: Yeah. Yeah. Instead of, like, it's teen's React, it's like senior citizen's React to, like, icons.

[Laughter]

Dave: Just be like, "What about this one?"

Chris: Uh-huh.

Dave: Or, like -- yeah, we could do that.

Chris: Back to Edge for a minute, did they all of a sudden just drop it on a Mac? Did people know that was coming? Chromium Edge runs on a Mac, too, all of a sudden.

Dave: I think it's on a Mac and then somebody, a sneaker-sneak hacker, found the download URL and you can download it directly now. I think it's the same sort of -- I mean because it's all Chromium-based now, right? I think there is still some code that maybe is trying to connect to some Windows thing, you know, like, "Are you logged in through the Active Directory?" or something like that. That's why it was kind of unreleased at this point, but I think it works.

Chris: Yeah.

Dave: Yeah, so you can see what I see.

Chris: That's why they have to compete on some kind of UI level. Why would I use that browser if it's exactly the same as Chrome? Well, I'll tell you why. Because it has some features that I want for some reason. Like Dave says, it looks nice. Well, that's a great feature, actually, if it's nice that way.

Maybe I use Edge on multiple machines and log in through Microsoft's thing. I like that it keeps all my Edge browsers in synch or whatever. That's a pretty compelling feature too.

Maybe it integrates somehow, some way nicer with online Office stuff. Well, that's a pretty compelling reason too. I like those types of reasons to use browsers.

Dave: Yeah, I mean it sounds silly, but if you spend all your days in Office or whatever, which a lot of businesses do. Yeah. You know how you log into your GitHub account in your browser and you automatically logged into Gmail or whatever? It would be that but for Office 365….

Chris: There's a connection here with that old IE or the conspiracy to kill IE6. Let's say you visited Office online with Edge on your Mac or whatever and it just was fine, but then you visited it on a Chrome and they put a banner up that said, "You should try Edge instead," is that somehow anticompetitive? Do lawyers care about that?

Dave: Oh, yeah. I don't know. Good question. It probably is. I don't know.

Chris: I would think you'd have all the right in the world to do that. Why would they care?

Dave: Yeah. I don't know. I would guess that regulators are kind of watching this like a hawk. [Laughter] Just kind of like, "What's going on there?" monopolistic stuff and all that.

Chris: Yeah. Okay, so speaking of some of this browser news stuff, this is like totally the browser news episode, which is fun, I think, is that there is iOS Safari. They dropped in an update to it, if you dug in through the settings on your iPhone or whatever, or iPad. There was a toggle that was just switched on that said, "Accessibility Events," and it wasn't particularly clear what it was for. There was some fairly little documentation on Apple's site that was just like, "Oh, this is basically a way to detect accessibility events as they happen in the DOM. Then you can use those DOM events to do stuff," like maybe you can use them. They mentioned a slider somewhere in the doc, so maybe you could implement a slider that somehow is more accessible because you had access to these accessibility events in which to do that, which sounds nice on the surface.

Then there were lots of accessibility people that chimed in and said the second that you're able to detect whether someone is using an accessibility feature or not is bad news. It opens up a door that hasn't been opened before and, when this type of thing historically happens is that it causes more problems than it's worth. It opens up this kind of if-else logic possibilities in your code that's just like, "If user equals accessibility user, then do this experience; else, do this experience," which is, at its extreme, ship them off to some other website or something. Ship them off to the ADOT, the accessible dot version of your website or something, which gets updated every three years or something.

Dave: Yeah.

Chris: There is some danger there. Matt Marquis wrote about it for CSS-Tricks from kind of a client work perspective that clients often ask about this when it comes up. Isn't there some way to know when a user needs accessibility information and do something different for them? He's always been happy to report that there is not a reliable way to do that. "We can't. Sorry. Bye." End of conversation.

Now, all of a sudden, there is, at least in iOS Safari and nobody liked it. I didn't read a single thing about this from an accessibility person that was like, "This is a good idea." That's what his article is about.

I heard from Apple. They were not particularly pleased about Matt's article. I told Apple, "Show me the code, then. Show me a way in which how this works with code, not with a paragraph. Then we'll see, have you built a better way or have you opened up a door to serve an accessibility ghetto, as it's been called?" They didn't do that and wouldn't do that and wouldn't say anything on the record, so I let the article stand.

Then--what--the very next release they said, "We're pulling this." [Snicker] Okay.

Dave: Yeah. Yeah, I think it was on the Access Lab site. They called it Digital Apartheid, which is kind of shocking. But if you think about it, it's like giving -- oh, finally, a way to give somebody a second class experience. [Laughter] That's just not fair.

But I understand, from an engineering standpoint, you do. You're like, "Oh, man. Maybe we can make a better experience if we just only knew there was a screen reader involved," or something.

Chris: I can't even explain it all the way because I never saw any code demos.

Dave: Right.

Chris: I feel like I am kind of relegated to the position of ignorance here. Do the people that worked on accessibility events, were they evil villains of the Web? Maybe accidentally we could cast them that way. But I'm sure when they were working on this, they were like, "This is going to be awesome. People are going to sign the praises of this. We're going to be able to deliver more accessible experiences to the Web, which is important to us."

Surely what they thought was that this was going to be awesome for the Web. Maybe there is some stuff, salvageable stuff in there that is going to result in that way. I certainly hope so.

Both Matt and I said, "I hope we're wrong about this. I hope that there is a net win to be had here that everybody is happy with," but apparently that wasn't it.

Dave: Yeah, well, and the issue, too, right, is it was on by default. If you were a voiceover user, you were basically outed. It's disabled, and that's--I don't know--a bummer too, right? You don't out people. [Laughter] That's their personal life. That's their personal information. They're not like, "Yeah, I'd like to tell everybody I have to use a screen reader."

Chris: In Dave's tinfoil hat world, isn't there a world in which an accessibility event is detected, which proves -- not proves, but it just indicates strongly that you're a human being on planet Earth that needs assistive technology in some way? I'm sure you could detect what type of accessibility depending on which API they used and how. Then that data is reported back to some website and just stored forever along with your IP address that says that this user needs these type of assistive technologies, meaning like, hmm, maybe we should revisit that insurance policy premium or who knows what all.

Dave: Oh, yeah. You want to go full dark? Yeah. You know there is the white hat idea, like, "Hey, we can do better for people." Then there's just this black hat, like, "Yeah, how can I -- whatever -- make money off of this personal information?"

Chris: Yeah, I mean we already just think it's weird that we're in our kitchen talking about how we really need our knives sharpened and you wake up to seeing some ad that's like, "Knife sharpening by mail," and you're like, what happened there exactly? Is this just a coincidence or am I starting to feel a little tinfoil hatty?

Dave: It is entirely listened to, Shop-o-maniacs, don't @ me with that Reply All episode because they don't know nothing.

[Laughter]

Dave: The thing is frickin' listening to you.

What this. Pizza, pizza, pizza, pizza, pizza. See, you're going to get an ad for pizza pretty soon. It's happening right now.

Chris: It's happening. Oh, I love that.

Dave: Oh, so we are getting late here, but there's one huge, huge, huge kind of piece of information is the GitHub package registry. Whoa! Did you see--? I didn't see this coming at all.

Chris: Um, well, I mean, yes. No, neither did I. Not really.

Dave: No insider - no insider news.

Chris: I guess if you sat around and thought about it, you're like, "Well, the pipelines thing was interesting. We'll see what happens with that," but it's kind of like one way to read that is like GitHub versus Travis CI or whatever, like, "Well, we'll bring that in-house too. Lots of our users use that. Why don't we offer it as well?"

We can even paint a picture that says, "We're not trying to compete. We want to support all these services, but we see lots of our customers doing this, so we'll bring that thing in-house," which I think GitHub actions is like, "Eh, it's a way to run your tests and deploy to different services and just do continuous integration type of stuff."

I don't think there are any limits to what it can do. It's a way to spin up some machines and tell them what to do. It's pretty cool.

I haven't seen a ton of usage of it yet. I think it's still pretty early beta for that thing. If your read on that thing is, "We're GitHub. We're big. We have lots of engineering power. Let's try to expand our services to take over some other tech cottage industries like CI industry," cool.

Then, okay. If that's their mantra now, what other little cottage industry type of stuff can we tackle? Well, why don't we stomp all over NPM and then paint it in a picture that says, "We're not actually competing with NPM." Of course, NPM will still work, but of course they are to some degree.

Dave: Yeah.

Chris: I thought it funny that the Tech Crunch article was like, "This isn't competing with NPM." You're like, "It sure as hell is. Come on."

Dave: Yeah. I mean you don't create a package registry to not compete. Their thing is like, "Oh, it's like a hub," or your Docker or your Ruby Gems.

Chris: Yeah, it's not just NPM. In fact, we've had NPM guests on before which say, "We intentionally aren't trying to be your Ruby package manager, on purpose. That community hasn't asked for our help in that way. It's not necessary for us to get into that market." Whereas GitHub is saying, "No, we'll get into that market. We're your registry for any language."

Dave: Yeah, we do that. Yeah, we do that.

Chris: Yeah.

Dave: It's not cheap or whatever to run that package registry, so it's kind of a big investment for them. I'm curious to see where it goes. I think it happens at a bad time for NPM because they were having--

Chris: Yeah, bad press.

Dave: --a CEO change and some staffing stuff. Then I don't feel the NPM hurt because a lot of people in my sphere, I guess, we're like, "Oh, great. GitHub launched it. Good-bye, NPM. Later." Like, finally, you know.

Chris: No. The trust is not there yet. We don't know. We don't know nearly enough for that to happen.

Dave: Well, yeah. But I mean, I think, for me, it was just like, "Whoa! Whoa! I'm totally content with NPM," and I've had people be like, "Oh, we've got to switch this over to Yarn because of some weird bug with the NPM," which is totally fine too. But I just was like, I just don't have the NPM problems that everyone else has, but the staffing stuff does concern me, you know, as it makes a play, I guess, a corporate play.

Chris: Mm-hmm.

Dave: Yeah, I wasn't like, "Good riddance," and I saw a lot of tweets that were kind of like, "Yeah, good riddance!" but maybe that's just people love GitHub.

Chris: No. First, you need all the major packages to get on this and register to have it be useful anyway.

Dave: Right.

Chris: Has React tagged themselves? Are they ready to go on GitHub?

Dave: Yeah, it's wild, right? I mean you have a lot of people already on GitHub, a lot of open source packages, and they already have a lot of -- there's already a lot of--

Chris: In a sense, you don't even need to opt into it, right? You could always kind of NPM install.

Dave: Yeah, I'm not sure if it uses the NPM version or not.

Chris: Yeah.

Dave: But, yeah, it's kind of this -- I don't know. I just was like -- they have the code. There are bit buckets and Git labs that have NPM packages on it, so like those two need to exist in this ecosystem. They have it, and I think some people were saying, like, they could do really cool things with sign packaged because they have a verified owner of this package.

Chris: Yeah. Didn't they also say that they have to be scoped, like they have to be org scoped to work on this registry?

Dave: I think it is. I think it's like you don't get NPM cool guy, you know, NPM install cool guy. It has to be like an at thing for @davatron5000, not cool guy.

Chris: Yeah.

Dave: Which I think that's actually great. I think org scoping is probably awesome.

Chris: That's cool.

Dave: What happens when you transfer a rebuild? I don't know.

Chris: Oh, that's a good point too. Yeah. I'm sure they've thought through more of this than we have but, yeah, it seems kind of like a big deal.

Dave: Yeah, maybe we should have somebody come on and talk about it. Anyway, that's going to change, I think. It'll be a big change in Web development in 2019 that I wasn't really expecting, so anyway.

All right. Well, Chris, we should wrap it up, huh? We're way over time.

Chris: Yeah. Yeah, I know, and I still have a whole list of crap I want to talk about, but that's why you should listen next week and every continuous week.

Dave: Because who knows. We may just do another news show. This has been Dave Rupert with WWEB News Channel 9.

[Laughter]

Dave: Thank you, dear listener, for tuning in, in the evening hour here, the prime, just before primetime. Next up is Wheel of Fortune. You're going to love it.

Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

[News channel promo music]

Chris Enns: Before we end the show, we've got a job opportunity for you, ShopTalk Show listeners, over at Close. They're a company that's building the sales communication platform of the future. For anybody looking for a remote job, they're a 100% globally distributed team of 33 high performing, happy people that are dedicated to building a product their customers love.

They're app's front-end is a single page JavaScript Web app mostly written in React, originally built with Backbone. They bundle Webpack and target only modern browsers. Their UI updates in near real time and is written in less CSS With Flexbox and Grid layout, so lots of fun, modern stuff to play in.

They care a lot about performance, maintainability, and testability of their front-end code. They love to sweat the UI and UX details and work collaboratively with the product team throughout the design process. This means diving into low-fi, freehand wireframes and communicating continuously when those ideas are brought to life using Sketch and Abstract in code.

Their front-end app is built on top of their REST API and GraphQL endpoints, and the back-end tech stack consists of Python Flask, Mongo DB, Postgres, Elasticsearch, and Redis. They're looking for a full-time front-end software engineer to join their engineering team. Someone who has got a solid understanding of Web technologies and wants to help design, implement, and launch major user-facing features. Follow the links in the show notes to check out the job posting with Close.

Dave: Chris, do you have anything else you'd like to say?

Chris: [Whispers] ShopTalkShow.com.