Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hard stop edition, Chris.

Chris Coyier: [Laughter] Always, isn't it? That's just our lives now. Everything is busy.

Dave: Oh, busy. Meetings, meetings, meetings, business.

Chris: We've got some questions picked out. We'll get to them. Is there any news? There's the Edge goes Chrome. [Laughter]

Dave: Edge is now on Chrome. Edgium, I believe, is the slang term there. Edgium has happened. It's good. I use it. You should download it. Yeah, I don't know. I think it's very much like Chrome except maybe a prettier UI, in my humble opinion.

Chris: Sure. Bottom line, you can use details now, but only for things like just expanding a piece of text.

Dave: Yeah. Yeah.

Chris: That's all you need to know.

Dave: You can use details if you just have text that doesn't require a heading. That's what I've learned.

Chris: [Laughter] Ship it. Of course, there's lots more to say about that, but I don't know that I really feel like having an all Edge show again.

Dave: Yeah. Well, and I was going to say -- well, what's weird -- sort of a bit of hot drama, Edge drama--

Chris: Yeah? Yeah? Yeah?!

Dave: The same day Edge came out, there was a bunch of layoffs at Mozilla. Sorry if you were in that, but it raises the alarm level, right?

Chris: That's it. It's like the alarm. That's a good way of putting it, like the health of the webometer. It feels like it went down a little bit. If you happen to be on the side, which there are very much two sides to this--I hate to admit--there are people that think, "Well, this is just only a good move," and, "Wow, I don't have to cross-browser test that anymore? Slick!"

Dave: Mm-hmm.

Chris: And there are people that are like, "This is really bad for the diversity and overall health of the Web." Two camps, in a way. Plenty of nuance in between. Very interesting stuff. But if you happen to be on the side that, like, this is kind of bad for the diversity and health of the Web from an ecosystem perspective, a checks and balances perspective, you might be really bummed off when those two things happen together.

It's not like Mozilla is saying, "We're giving up as a browser too," but super healthy, thriving companies don't announce major layoffs.

Dave: Right. Well, and if you're on the ultra-progress -- so, actually, this is interesting. I've read a book about this, Chris. I have book knowledge about this.

I just read a book called The Wizard and the Prophet. It's about these two, I guess, farmers, essentially. They basically learned how to help. They were deployed to Mexico in the '30s or something like that and were told to grow wheat in Mexico and stuff like that.

One of them became kind of a prophet and his thing became an ecological conservationist before that was even a word or a term. He was all about like, "Hey, we need to scale back what we're doing. Scale it back." He was very much a prophet in that regard just warning, foreboding, "Hey, please, everyone, stop consuming everything because there's not enough to go around. Resources are scarce."

The wizard was this other guy. He basically came in and was like, "Well, I'm just going to bread 400 varieties of wheat and see if we can grow wheat in this really hard area." He just did it. He experimented and used science and came up with a strand of wheat that was able to grow. He's the wizard who used science to build something.

Now, it follows this whole thing through hundreds of years with global warming and even where things like Monsanto--

Chris: Mm-hmm.

Dave: Where grains are patented and GMOs, et cetera. I don't want to get into that. You can read the whole book. [Laughter]

When you think about it in the context of the Web, it's very much like you have these wizards who are like, "Well, Chrome is great so let's just use the best browser and we'll all wizard it forward." Then the prophets are like, "No, we need diversity on the Web. We need this whole ecosystem preserved."

I feel like if you were a wizard and you're like, "All these blog posts about losing Edge means the Web is dying that you're overreacting," but then I don't know how you feel the same way when the same day Edgium comes out, Mozilla has a big layoff. I don't know how you're like, "Yeah, everything is cool still," you know?

I think the prophets are very much in this camp of like, "Oh, my gosh! That is the worst news that could happen on this day." Yeah, I don't know.

Chris: There are some takes on this because you can't roll back time here. This has happened, so too late - to some degree. But the "too late" part is like, well, Firefox hasn't folded yet, though. This is so important to me. It's kind of like your duty to use Firefox.

Dave: Yeah. No, I mean I think I've heard people say that. It's like, how can you support Firefox? The answer is quite literally, "Use it!"

Chris: Right.

Dave: Or give money. Buy one of these VPN products they have coming out or something like that.

Then I've even read another post. Did you post it, maybe? It was about -- no, it was on -- oh… I'm going to -- Seimei Vetus (phonetic)--I hope I'm pronouncing his name right. I've only read it--has that wonderful Web platform weekly email list and had a post in there just about the -- what is the DRM thing, Google's wave vine or something like that?

Chris: Oh, I don't even know what you're talking about. I have no idea.

Dave: Oh, my gosh.

Chris: Was it a standard piece of tech or is it a proprietary thing that they bake in?

Dave: Well, it's proprietary, right? Microsoft, Google, and Apple all have it. They all have a version of it. It's basically DRM on videos.

Okay. Google, Apple, Microsoft, three providers of CDMs, content delivery mechanisms, I guess, are required for playback in encrypted media browsers. But only Google CDM--

Chris: So, for Netflix in the browser.

Dave: Yeah, Netflix in the browser. That's what we're talking about. Only Google's CDM, Widevine, is freely available. It's also used by Firefox. Okay? This allows Google to act as a gatekeeper for new browsers. There's a post over on--

Chris: Oh…

Dave: Again, sort of a prophet blog, but Samuel Maddock's blog. It's The End of Indie Web Browsers, just this idea, like, okay, let's say I make my own browser called whatever, Davefari. I wrote it from scratch with all my own--

Chris: You need this because if Netflix doesn't work on it, you're done. You have to have it.

Dave: Yeah. Well, and I'm sure, increasingly, it's like YouTube won't work on it or the nice YouTube channels don't work on it. You know what I mean? Yeah.

Chris: And Chrome has to say, "Okay, you can use this," so it's not open source but it's free if you get their blessing. Is it that gnarly?

Dave: Yeah, I don't know. You have to fill out a contact page and hopefully, they write back. You know?

[Laughter]

Chris: Okay. Okay. Part of it, this is just to throw another interesting wrench into this. If I was a betting man, I would have said, "For sure there's never going to be another major browser." It's so expensive. Are you crazy to just start from scratch and just be like, "I think I'm going to write a browser"? It's just too many manhours for too much risk and too little payoff.

Then all of a sudden I read over on PPK's blog, oh, here's an interview with this one guy who is just writing a browser from scratch and they already have a bunch of commercial clients for it. It's not open source. You can't even download it, but it's shipping. They started writing an SVG engine and had a good time doing that and are literally having fun doing it, so just decided to do HTML instead. It's this fascinating interview about how one of the most challenging things is laying out text because text needs to wrap and wrapping is really complicated, yadda-yadda. It's a fascinating interview, but they have a working, shipping browser.

Dave: Yeah.

Chris: They ship it. Because they wrote it from scratch, it has no memory usage. Not none, but they can design it to be perfect for TVs and stuff.

Dave: Yeah. No, I think it's very low footprint. Is it called Flow? Is that what it is?

Chris: Yes, Flow. Right.

Dave: It's made by Ekioh. You know a trusted brand there. [Laughter] Everyone's favorite brand, Ekioh.

No, I'm sure -- I'm just joking because it's not one of the major five. But they're redoing everything. They're posting their whole progress on Twitter. You can follow Flow Browser.

It's kind of BA. They're like, "Hey, look. Amazon works now," or, like, "Hey, look." Who is the CodePen? The CSS, like painting, the old -- the baroque paintings in CSS.

Chris: Oh, yeah.

Dave: Do you know what I'm talking about?

Chris: Yeah, like Deanna Harlow or whatever.

Dave: Yeah. They got those running. They got The Guardian running and stuff like that. They're admitting, like, "It's not perfect but, hey, we're getting there." Start basic. Apparently, it's mega fast.

Chris: They didn't fork Chromium. That's what's so fascinating about it. I always like to bring that up. I don't know how relevant people think it is. The losing of Microsoft's rendering engines are hit to an ecosystem, I guess, but not an open-source one. None of that stuff was open source. Chromium is, and it's pretty loosely open source. You literally can just fork it and do something.

Chromium itself was a fork of WebKit, you know. Theoretically, having more of the browser landscape be open source could be read as a positive, at least for me.

Dave: Well, and I think that's one of the wizard's arguments is, "we lost a closed-source browser - hallelujah. Mission accomplished. That's great."

But I think the prophet side is like, "Well, people are just going to care less about the other things." People already assume WebKit is--blink--the same as Chrome but it's totally not. It's way different.

Chris: Yeah. Yeah.

Dave: WebKit's little kingdom is not disappearing, but it's shaken, I'd say. It's just mobile Safari at this point, I'd say. If I get really critical of its support, it's just mobile Safari.

You have bleeding-edge Chrome on Android and kind of--I don't know--limited capability iOS browser, you know, like those other two browsers.

Chris: It's so complicated. Remember the last browser company that forked Chromium to go their own road and compete on browser features? They were called Opera. Opera now does predatory, short-term lending in Africa, so super-cool pivot from Opera.

Dave: Oh, good. Good pivot. That's great, everybody. We are doing good.

I saw that. It's unbelievable. I just want to--

Chris: A bunch of VC got involved and Opera tanked because their browser market share was just plummeting, and so they had to do extreme stuff to fix it. This is as extreme as it gets.

Dave: Them in their proxy browser already had a lot of users. Yeah, that's too bad. That's really too bad.

Chris: All right. Well, we made this about that anyway. So, good job.

Dave: Hey. Sorry for the bummer.

[Laughter]

Dave: I did want to say, our whole episode last week was, like, we came to the conclusion, don't eject your app from Create React App or even Create Gutenberg Block or whatever.

Chris: Right.

Dave: I was going to say, I don't have the links here, but I was reading blogs and I think it was a Dan Abramov post or something from React. It was, "We created the eject concept in Create React App, and so it's wonderful because you can eject whenever you want if it doesn't fit your style."

I just wanted to say, there's a very positive viewpoint of ejecting there. I just want to give you the fair and balanced reporting here. [Laughter] I think, for us, we were thinking of the maintainability.

Chris: Never do it. Yeah. Yeah.

Dave: Yeah, but I think it is cool that they offer you that. You're not stuck in a tool for life.

Chris: Yeah.

Dave: That's a positive--

Chris: Fair enough.

Dave: --aspect of it.

Chris: I think we mentioned that if you're in this for the long-haul, this is your main project, this is your day job, this is your meat and potatoes work, I'd eject right away, probably. Get in there. Start doing stuff.

But remember that Bastian Allgeier post, Simplicity, from a while back that was just like the worst thing about development, practically, is build processes? That's what goes stale.

Two years from now, your build process, whatever it is, it's not going to work. There's no way. Your website might still work because it's already been built and deployed. Fine. Browsers will take care of that. But if you need to go update green to red in a color declaration, well, chances are there's a build process for your CSS. You're going to try to run it. Your node version is going to change. These dependencies have gotten weird in those two years. You've got a new computer. Stuff isn't installed the same way. It's not going to run.

When you need to change green to red, now you've got to spend your day rejiggering that build process to get fixed up. To me, that's similar to this ejecting concept. Once you've ejected, now you have a bespoke build process that's on you to keep up. It's going to go bad.

Dave: Mm-hmm.

Chris: Whereas, the Create React App, it might happen too, but it's one dependency to update or maybe it won't happen at all because it's so isolated and boxed away that it might just run just fine. Anyway, that's what kills websites.

Dave: It would be cool if there was a dollar amount appended to ejecting or, like you said, bespoke build processes. It's like you have a choice to hop into a client project. One is like 11ty and one is some bespoke Webpack doodad. How much do you charge for each one? It's basically the same blog but one is like 11ty and one is some custom bespoke Webpack config. I think my price quadruples on the custom Webpack config. [Laughter] I don't know, but it would be rowdy. I don't know.

Chris: Yeah. I like it when you're always trying to attach dollar signs. When was the last time you did that? It was like dollars per commit or dollars per dependency?

Dave: Oh, if statement.

Chris: Oh, per if statement.

Dave: Every if statement costs $10,000.

[Laughter]

Dave: When it gets you, Chris, is over the lifetime of the if statement, so of course we know if statements are only about $5,000 each, but I'm billing $10,000 so that, over the lifetime of this thing in your codebase, it's well maintained over years and years or decades that it's going to linger in your codebase.

Chris: Yeah.

Dave: This one custom bespoke piece of business logic that you are putting inside your view template, I'm just offering you a service, a flat fee, $10,000 per if statement.

Chris: Flat fee, I think that's almost generous of you, Dave. I'd say I write my if statements for $5,000 each. If I write your app and there are zero if statements, then it is a flat fee. The second there's one, then you have to sign up for a monthly maintenance plan with me.

Dave: Yeah. Yeah, that's the monthly maintenance cost. Other companies, Chris, they're going to sell you a cheap if statement.

Chris: [Laughter]

Dave: You know what? They're hiding the costs of the long-term maintenance.

Chris: Yeah.

Dave: You know what I mean? I'm being very generous.

Chris: They're using really flimsy curly brackets that will almost certainly deteriorate over time.

Dave: No, they used a bitwise operator in there.

Chris: [Laughter]

Dave: That's not going to work. That's not going to work. JavaScript has bitwise. That's a surprise, but there you go.

Chris: Yeah. Get out of here with your switch statement.

Dave: Yeah. Yeah, oh, man. [Laughter] Oh, there's a video game. Somebody open-sourced a video game. I can't remember the name of it. Darn it! They put the source code online and I saw some nerds commenting. They were like, "Oh, wow. That was the first 3,000 case switch statement I've ever seen in my whole life.

[Laughter]

Dave: Somebody was basically just like, "Yeah, video games are pretty rowdy." [Laughter] Sometimes you just phone it in and you just put up the codes.

Chris: I can't write them because of the word "break." I just hate writing "break." Don't you?

Dave: Over and over and over?

Chris: Yeah.

Dave: Yeah, and then you get to the bottom and you're like, default. [Laughter] As the switch statement gets bigger, default means nothing.

[Laughter]

Dave: It just means less and less and less and less.

Chris: Oh, that's true.

Dave: Then you know what grinds my gears? TryCatch has made a comeback in a lot of things. It still bothers me. I think I learned it's a bad practice and so I think it's bad, which is maybe not wholly true but, for me, I'm just like, it seems so crossing your fingers and hoping, "Oh, could you just try this code and see if it works? Oh, it didn't? Okay. Well, my bad."

It's so funny to me. I don't know. I try to write code that works, me personally. But then you tell the browser, "Hey, try this code and see what happens." It's silly to me.

[Banjo music starts]

Chris Enns: This episode of ShopTalk Show is brought to you by Clubhouse. Clubhouse is a fast and enjoyable project management platform that breaks down silos and brings teams together to ship value, not features.

Let's face it. Slow, confusing UX is so last decade. Clubhouse is lightning fast, built for today's software teams with only the features and best practices you need to succeed and nothing more.

Here are a few highlights about Clubhouse. Flexible workflows: you can easily customize workflow states for teams or projects of any size. Advanced filtering: you can quickly filter by project or team to see how everything is progressing. There's sprint planning. Set your weekly priorities with iterations and let Clubhouse run the schedule for you.

It also integrates with the tools you love. Clubhouse ties into your existing tools, services, and workflow. Get notifications or create a story in Slack, update the status of a story with a pull request, preview designs from Figma links, or build your own integration with the Clubhouse API and more.

It also has enjoyable collaboration, easy drag and drop UI, dark mode, emoji reactions, and more. When you're doing your best work and your team is clicking, life is good.

Clubhouse has recently made all core features completely free for teams with up to ten users and they're offering listeners of ShopTalk Show two free months on any paid plan with unlimited users and access to premium features. You can give it a try at clubhouse.io/shoptalk. Thanks again to Clubhouse for sponsoring this episode of ShopTalk Show.

[Banjo music stops]

Chris: Let's say your goal then is to have a webpage that lasts a long time. This is just kind of a lead-in because I just posted about this today. I saw an article by Jeff Wang (phonetic) who is, I think, a professor somewhere who teaches technology of some kind and literally uses the bookmark feature of his browser a lot and happened to do some tending of his bookmarks recently and had kind of a sad revelation as he was clicking through the links of interesting things he's saved, presumably over the years that tons of them were just dead. They just aren't URLs anymore.

Dave: Wow.

Chris: That's the bit rot of the Internet. I don't know if we have a percentage that people like to throw around, but it's definitely over 50%. Some part of me thinks it might be something like 99% of webpages created that just eventually get gone after, say, a decade; just don't exist anymore. Probably a lot.

Dave: Yeah, I wonder what the rot rate is on that, right?

Chris: He's saying, as a thought exercise, what if you don't want that to happen to you? What are choices that you can make on your site to make this thing last? He has seven of them. I looked at them. I don't necessarily hate these seven of them, but I just didn't get the feeling that these are the seven things that matter, that are going to keep a URL around for a long time.

I could be wrong because who knows. I'm just one guy. Jeff is just one guy. It's not that I disagree with his seven, necessarily. I just don't think they're putting a finger on the thing that keeps a URL alive.

I know I'm just throwing it at you for the first time, but what's your gut? What do you think it takes, technological or otherwise, which isn't necessarily a hint but could be? Open your mind to things beyond HTML, CSS, and JavaScript.

Dave: Hmm. Good question. Maybe I'm in the JAMstack favor here. I feel like static sites would fare better, some kind of static compilation because, otherwise, you have to depend on somebody paying their database server hosting bill forever. A static site seems easier to maintain or just exist. Does that make sense?

Chris: Yeah.

Dave: Otherwise, it's going to get crusty and hacky or hacked. I don't know. That would be my first, like, possibly a statically deployed site would fare better, but I don't know. Do you have thoughts? Maybe you can read what he had posted.

Chris: Well, his list, I'll just do it because I'm sure, after you're listening to this, you're like, "What did he say?!"

Dave: Yeah. [Laughter]

Chris: Okay, podcast listeners. One of them is like what you said, "Just vanilla HTML and CSS, so author in those technologies." I have thoughts on that, but let's wait.

"Don't minimize the HTML." He has thoughts on these too. It's not just a flat list. He's got whole paragraphs that explain his thinking on these things.

Number three: Prefer one page over several, so not like an article that has multiple links. Although, who does that?

Okay. Stop with the thoughts, Chris. End all forms of hotlinking. Stick with the 13 Web safe fonts plus 2.

Dave: Okay.

Chris: Obsessively compress your images. Seven, the last one: Eliminate the broken URL risk.

There are seven of them. Like I said, it's fine. I think the fonts one is the weirdest one. What do your fonts have to do with how long a webpage lasts? Even if the fonts die on it, it'll fall back to something. It's not going to kill the website.

Dave: Yeah. I wonder if he came across people who quite paying their Typekit bill and, all of a sudden, it's just waiting like WFF wait loading or whatever.

Chris: Oh, my God! Would it? I guess, depending on how it's implemented. Is it possible that it's just a white page? I don't know. Still--

Dave: It would. Yeah.

Chris: To be on the top list of seven seems unlikely. The hotlinking one seems like a big deal. If you're linking to very important resources that aren't hosted by you, those are going to rot too and hurt your website. If it's a broken image, fine. If it's a font, fine. But if it's some old CDN that doesn't exist anymore for necessary JavaScript resource for your page to render, that could be bad.

Again, it's probably not going to ruin your website for the most part. Minimizing HTML, I don't know if that's going to destroy your website or not. But what I like about that one is that it eludes to a build process. HTML doesn't minimize itself.

If you're minimizing your HTML, it's because you have some weird build process. Most build processes don't even optimize HTML. I think of it as one of the more rare forms of optimization that I don't see that often. A lot of times if you see it on a website, it's just Cloudflare doing it on the way out.

Dave: Mm-hmm.

Chris: But anyway, sure. If it's because you have a complicated build process, I think that's what hurts you in the long-term that you forget about it. You don't know how it works anymore. It doesn't run anymore. You don't feel like investing the time to do it, so your desire to work on your own website really falls off the map. You're just like, "You know what? Shut it down."

I think, if I have to pick a single thing, technologically, it's build processes. Even though I like them, I live by them, and they're important to what we do, the more complicated it is and the more dependencies it has, the more likely it is to rot. When it rots, then your website is doomed.

Dave: Mm-hmm. Mm-hmm.

Chris: Secondarily, what you need is some stake in the game, some motivation. Like, "I want this website to live because it matters to me." A website will last when somebody cares about it existing.

Dave: Mm-hmm.

Chris: As soon as nobody cares about it anymore. It's also doomed. It's worse than doomed. It's definitely gone.

Dave: No, I mean that's great. I couldn't really put it into words, but that was something I was thinking about is, if it makes money--

Chris: Yeah.

Dave: --you'll keep it up. Somebody will. You can even probably sell it after you're dead.

Chris: Right.

Dave: If it generates revenue. Not that it has to. Let's break out of the "has to" mindset, but I would think a page would have more chance to live if it had.

Chris: Yeah. Money is cool, but I'd say most websites don't make money. I'd say I like the money one. You're probably right, especially if it makes some non-trivial amount of money, it will almost definitely be kept up.

Dave: Yeah.

Chris: Even aside from money, it's just some reason that you care that it exists because it represents you personally or benefits you just in some way.

Dave: Mm-hmm. Yeah, I think tooling or ease. I think about, like, not a lot of people do it but Jekyll static sites or something like that on GitHub. It's so easy because it's just done. It's up there. it lives there. I didn't do anything. Even static HTML, I didn't even touch it. It just got its own website by accident. Stuff like that, like the home is also where the code is. Your home page is where your code lives. [Laughter] I don't know.

Chris: I don't know. Just imagine it in cross-stitching and it will come to life.

Dave: Yeah. Yeah. [Laughter] Can somebody cross-stitch that for me? Your home is where your webpage is. Your homepage is where your Web host is? Anyway.

Chris: I saw a great one that said, "My house is a mess but my homepage is immaculate," and written in that really cheesy script lettering on a piece of wood.

Dave: Oh, good.

Chris: I walked right by it and then I was like, "You know what? I'm going to buy that. That's so awesome. I walked back and it was gone. Somebody bought it. I was like, "Mother - gosh darn it!"

Dave: You know what I want to do? This is my quit Web business. Are you ready, Chris? [Laughter] Here it is. I want to build -- you know those almost like sermon signs outside of churches with the little letters you can stick on. I want to build "Home Sweet Home" signs with really crappy floral paintings but it says, "Wi-Fi Sweet Wi-Fi" or "Mi Wi-Fi Su Wi-Fi." Then you use the little church letters to spell out your wi-fi password. It just hangs in your house. It's totally insecure, but it's just this idea of, like, "Hey. Welcome to my home. Here's my wi-fi password. It's XP395321," but that's my wi-fi password. Welcome to my house.

[Laughter]

Chris: It's amazing Yeah. Ship it.

Dave: It's stupid. Anyway, that's my…. Everyone is going to buy one. Preorders on Kickstarter.

Chris: Did you see the QR code thing? Is that going to be an option for them?

Dave: What's that?

Chris: You can make a special QR code that all cameras, Android and iPhone, if you just point it at it, it'll just be like, "Oh, I see. This is one of those wi-fi QR codes," and it just hops on your wi-fi.

Dave: I love that. I could totally…

Chris: You could burn it into a piece of walnut. Yeah, yeah, Matt Haughey did it and wrote up a little blog post about how he did it. Apparently, he did a fancy one just because he's a fancy man. It's an Etsy thing, you know. Just look around on Etsy.

Dave: Yeah.

Chris: That's where half your income will be Etsy, I think, in your new life, Dave.

Dave: Yeah, my new life. I'm good at selling stuff online. I think we've established that over the 400 episodes.

[Laughter]

Chris: Hey! For the listeners out there, I just realized how the title of 395, the episode before this one, is 2020 Don't Eject! I feel like I don't even -- it's not me who invents the titles for these. I don't have any -- I don't care who titles them. Just title them whatever you want. But listeners should know that it almost seems like that's what we're going to talk about in that episode is ejecting. We had no plan to do that. It's probably about one of 50 things we talked about in that episode. Titles on ShopTalk Show, let's just call them loosely related to the content of the episode.

Dave: Yeah.

Chris: Any episode, just click it and play it. It's going to have all kinds of stuff in it. It's not just going to be about whatever the dumb title is. Even if there's a guest, we talked with Andy about a heck of a lot more than 11ty.

Dave: Yeah. No, it's usually one of 50 things we probably addressed during the course of an episode, so we appreciate you listening.

[Banjo music starts]

Chris: This episode of ShopTalk Show was brought to you in part by AWSAmplify. You know AWS, right? Amazon Web Services. It powers most of the Internet, it feels like.

There are a ton of things that go in the AWS bucket like EC2 allows you to spin up servers of your choice and has all kinds of configuration. And like S3 is for file storage and Lambdas is for running cloud functions. All kinds of stuff that, individually, you can set up, use, and are great. There's so much more than that. There are a ton of different things AWS does.

AWSAmplify is kind of a package of tools to help you build full-stack apps for the Web. It's like, just give me the stuff that I need that usually, you need to build an app. Amplify is hosting. You need Web hosting? It's got that. It's got authentication for logins for your users.

It's got GraphQL as a first-class citizen of it. It's got serverless functions like I need the Lambda thing. I want to run some code in the cloud to hit APIs and do whatever else I need to. And it's got file storage if you need it. It's got some machine learning stuff in there if you need.

Amplify is this easy to use, full-stack framework for getting started quick with building Web apps. It's really cool. The auth stuff alone is cool. It's just a few lines of code in there. GraphQL has taken over the world of how to get things from a database, put things back in a database; really front-end development-friendly way to do database stuff.

Love GraphQL. It's just built-in as a first-class citizen. It's this scalable API. You don't have to provision your own servers. It just does it up for you. Pretty cool.

AWSAmplify is really cool. Definitely worth checking out, especially as a front-end developer. Check all that out.

[Banjo music stops]

Dave: Hey, Chris.

Chris: Yeah.

Dave: Do we have any questions today? Should we hop into some regular old Q&A?

Chris: Yeah, just because we talked about Edge already, this is Raymond Selzer. He wrote in about cross-browser testing in IE. Say you're even on a Windows machine or you're on a Mac and you want to test on different versions of IE and Edge, now, because now that your Edge has updated to Chrome Edge, there'll be some portion of your audience that didn't do that upgrade on purpose or they're just enterprise and just don't for whatever reason, you know. Now you're like, "Oh, crap! But I need to test Edge, pre-Edgium."

Dave: Mm-hmm.

Chris: Microsoft give these away for free, so that's just a good thing to know. Didn't it used to be modern.ie, right?

Dave: Yeah. I think that might…

Chris: It kind of forwards to where you need to get. You need to run a VM, which is a virtual machine, and there's a free way to do that. There's this program, a virtual box, which runs on a Mac and probably on Windows too, right?

Dave: Mm-hmm.

Chris: It seems like a cross-browser thing.

Dave: Mm-hmm. Yep, yep, yep.

Chris: It's a way to spin up a VM, a VM just being another operating system on your computer already, which is pretty cool. Edge gives these away -- or Microsoft gives these away for free. You just download a copy of Windows that has, preinstalled, the version of Microsoft Edge or even IE, if you're going that far back, which is starting to be crazy town.

Dave: Oh, I've been in IE 11. It's my life this week.

Chris: Oh, sorry. That sucks.

Dave: Yeah, I think this is great. I have some coworkers who are running for kind of other reasons like administrative profiling reasons with Office 365 Active Directory. But they're running Windows in a VM like parallels or something but a full version of Windows that cost $100.

Chris: Yeah. I'd say I like parallels too just because it's just a way nicer UI and a little speeder.

Dave: Yeah, nice UI, pretty dependable operating system, like interaction loop or whatever that is. If you're on a Mac, I have coworkers who are running Windows in a VM and you get access to Edge, New Edge, IE 11, like right in a Windows 10 install.

Chris: You might have spin down one VM and up another one, though, don't you, to get multiple?

Dave: No, no. If you're on Windows windows, it'll have everything in there. But I'm saying these developer VMs are just one browser, I think. It's like one version on Windows with one browser and it expires after 90 days and you have to redownload. But if you buy a legit copy of Windows for, like, $100, you get a copy of IE on your system. I don't know.

Chris: Yeah. Yeah, and if you're doing serious testing, a fairly minor investment gets you a lot nicer setup, perhaps.

Dave: Yeah, DX, UX.

Chris: Yeah.

Dave: I mean you just have it and you can local tunnel to it if you want.

Chris: All that stuff just needs to work, but you know the extreme DX to me is just like instant everything. I really feel like that's got to be the future we're heading towards, although I'm sure we'll never get there because we'll always fight at the wrong direction from the other side, just like how 5G is probably going to make websites slower because we'll chew it up and then some.

Dave: Yeah.

Chris: I want it to be like every letter I type is instantaneously reflected in the state of what I'm looking at. CSS changes, I don't want to wait ever. I want it to be instant.

We get there sometimes. If you have a really nice, clean setup with hot module reloading and all that stuff, you can kind of get there but it's still not as fast as you'd like it to be. That's an important aspect of CodePen that we hope to keep around.

Dave: Yeah. No, I mean I think that makes a huge deal. The instant feedback, I think that's a huge part of, like, rapid application prototyping or development, RAD. Prototyping, the quicker you can see changes and get feedback, that's a big deal.

I was griping in a Slack chat we're in. I was griping about, this morning I was waiting. I waited 11 minutes for a server to deploy, a VM to spin up and deploy my code to a staging environment so that I could finish a Jira ticket to send a link. I just was like, "This is lightyears away from my Netlify experience where I push code and, almost before I can open Netlify to get the branch URL, Netlify is like, 'Oh, I deployed it already. It's on this URL.'"

Anyway. It's so -- not making people wait or even just eliminating friction time is probably the hugest friction for developers because I just sit around for ten minutes and I'm like, "Dude, what am I going to do for ten minutes? Just sit here and spin in my chair? Read Twitter? No, thank you."

Anyway, I think if we can fix time and reduce time, I think everything gets better.

Chris: Yeah. Good stuff.

Dave: Thank you, Raymond, for the tip on Edge VMs. We'll put a link in the show notes.

We have another question. Are you ready for this?

Chris: Yeah, I'm ready.

Dave: Cameron Ahler writes in, "Do you have any pros or cons to mind using Rails plus React or even Rails plus Blink front-end framework? I'm a designer but looking to have a conversation with developers who have been in the Rails realm for a while."

Chris: Hmm.

Dave: You work on a Rails with a React front-end, don't you, Chris?

Chris: Yeah. That was a pretty intentional choice by us. Our situation is not unique because so many people are working with legacy stuff but React wasn't a choice that we made on day one. It's a choice we made after many, many years, like seven years of developing a Rails app. Things would be a lot different now if we were green fielding it.

Although, because we're green fielding it, I think you even said this too that a Rails backend and a JavaScript framework front-end like Vue is pretty suite; Rails as an API and Vue as the front-end thing. Maybe not even so much an API. You could still render ERB but then use something like Vue Inline Templates so that, once it's loaded, it's still ready to go Vue components. That seems pretty dreamy to me.

Dave: Yeah, I mean of course I'm going to recommend Vue because I'm a scumbag. I'm so impressed. Evan You, we talked to him last year. Part of the design of Vue, one of the design requirements, was that it could work with legacy applications, like help upgrade legacy applications.

If you think of your Rails ERB templates as legacy, although they're probably not, I think you can sneak it in, almost like a jQuery, and start writing Vue components that then just sort of start spitting out lists with data that you got from your own Rail server. All that is really easy to do with Vue, out of the box, I would say.

Chris: Right.

Dave: With very few dependency hell trees.

Chris: People really like Vue, files.vue, but you probably would like -- there's a world that you just don't use that at all because that's a really special Babble fancy compiled way of using Vue. You can just use HTML with Vue.

Dave: Yeah. You can also just -- yeah, you can just have a div where your app mounts.

Chris: Right.

Dave: But then you're writing JavaScript like vue.component.define or whatever. I forget the syntax right off the top of my head, but you're basically writing components in JavaScript and they load like a jQuery plugin or something like that. That's going to make your developers very comfortable with how I guess it's integrating into the application. You're a very light footprint.

To get the full power Vue, you do need to eject. Again, don't eject 2020. [Laughter] You need to eject and then pull all these components out into a proper Vue app. At some point, you'll want to do that.

For baby-stepping in, I think it's a good pathway forward. You can do this with React too. That's what Facebook does. Facebook also has a thousand engineers. CodePen, you all did it but you all have six, seven engineers and you've been working on this for seven years after day.

I would say that the maybe drawback of going to a front-end framework is, you need to be sure it's solving problems. Where you click a button and it sends a hit to the database, like a favorite or something and it lights up red, that's great. I think that solves a problem in Rails because that sucked in Rails and you had to do turbo links or some kind of big, long fetch.

If you write your form in Vue, well, now you have to handle all the validation and stuff like that. All that crap is now your job whereas Rails handles it with a form helper. It's built into Rails, basically. Form validation, error handling, all that stuff, that's all built into Rails, so I would be careful. That's what I want to say. I would be careful what pieces you're touching first.

Chris: Yeah, that's kind of a good point. There is a world in which you literally only use it as an API. I'd be tempted too. Otherwise, you're going to do all your routing in Rails and then you throw React or some framework on top of it that eventually you're going to be like, "But I want to do my routing there because then it's all fast and SPA'd out."

Then you're like, "Well, too bad because you did your routing somewhere else." Those are at odds to some degree.

If I were doing it and I really wanted to use React and I needed Rails because we have this complex internal API that Rails excels at, I'd probably start with Next and just be like, "This is just going to be a Next app. Then whatever API stuff it needs to consume will just be generated by Rails." That way the front-end just totally does its own thing and the back-end kind of totally does its own thing.

Dave: Mm-hmm.

Chris: It should be mentioned that the creators of Rails, Basecamp and gang, don't do that but they obviously build front-ends that are pretty JavaScript-powered still; have their own framework. They're also the creators of Turbo Links, so that's a possibility too, although, that doesn't solve a desire to write in a JavaScript framework front-end. That's almost you ignoring a JavaScript-powered front-end.

Stimulus is their version of a JavaScript framework plus Rails, which allows you to just ship functionality attached to your HTML elements. It looks cool. I've never built anything serious in it, but I would give it a thumbs up from its philosophy. It looks nice, doesn't it? I don't know.

Dave: Mm-hmm. Yep.

Chris: There's a brand new one that shipped last week that looks fascinating to me. I bet you'll like it, Dave. Look up Alpine JS.

Dave: Okay. Okay, Alpine JS.

Chris: [Laughter]

Dave: I was completed for Alpine, Texas, and I got very excited. That's a good place in Texas.

Chris: Well, if you scroll down their Read Me to the "use" section, it looks similar to Stimulus, in a way, that you have data attributes with state in them.

Dave: Yeah, ex-data and you just pass some JSON. Ooh, beautiful.

Chris: You see that click handler.

Dave: Yeah.

Chris: And they even have a click away handler, which is pretty hot.

Dave: This is like Vue. This is what the parts of Vue I like.

Chris: Yeah.

Dave: Or Vue's -- the directives. That's it, the Vue HTML directives that kind of make Vue superpower-y in your templates. That's, again, people don't like that. A lot of React people are like, "I'd rather do it in just JavaScript." You know? But this is great. I think you'd like this. I think this would be a good place to start.

Chris: It looks good.

Dave: If you just want a little interactivity.

Chris: I played with it a little bit. It looks pretty cool.

Dave: It's got a transition that's kind of helpful because--

Chris: But it's not just UI stuff only. They clearly have a demo a little later on that does a fetch for the data it's going to use and stuff.

Dave: Yeah.

Chris: It looks pretty darn robust. Ex-dash attributes all day long.

Dave: Yeah, that's cool. I would also, too, like in your discussions with the developers, I would probably be like, "We want to push the UI a bit more or have a bit more ownership of the UI," because that's what it sounds like to me. But I would also make sure you understand what the developers use Rails for or why or what value they're getting out of it because that's a big part of it too, right? You don't want to come in and be like, "I am taking your cheese and I'm creating a bunch of problems over the next two years as we build this thing out."

Chris: Yeah.

Dave: That doesn't solve any problems. You're going to get the cackles from the old developer guys and girls and people who are just like--

Chris: It could be the exact opposite, though. They could be like, "Rails? I don't know. We don't really love Rails. If we could do this in Node, that'd be way more fun."

Then you'd be like, "Oh, well, let's do that then." You know? [Laughter]

Dave: Yeah.

[Laughter]

Dave: Great, because I had an idea.

Chris: Yeah.

Dave: I was playing with--

Chris: Mongo or whatever.

Dave: If you have a little app, too, like a Next or a Nuxt app, like a prototype that sort of is just a rough idea, like, don't spend more than two days on it. Just a rough idea of, like, here's getting data because I think the conversation is about that. How does data, session, and all this stuff? That's the hard part.

We built out a whole Angular app for a client and we were like, "Hey, look at this." They were like, "Cool! We need a Java session." We were just like, "Oh… Yikes! How do we get J-session into our Angular app?" That became the bottleneck.

Again, it's sort of like you don't know the problems right now but start a conversation just from the idea of, like, we'd like to push the front-end as much as we can and have a bit more flexibility or whatever you're looking for. Don't go in adversarial. They're your friends and coworkers. That's all I'd say.

Chris: This next one is pretty funny. His name -- Oh, did I copy that right? -- Hyme? Well, whatever. Sorry if I screwed it up.

Dave: You probably just said a curse word. [Laughter]

Chris: Oh--

Dave: In German. They tricked us.

Chris: He did. You bastards. Now I just swore for real.

You got a new job. It uses a lot of old tech. It was a longer question but here's an example. Most of the JavaScript this whole app works on is CoffeeScript. Hyme is saying--

Dave: It sounds like you're using Rails…

Chris: Oh, it kind of does.

[Laughter]

Chris: Yeah, Rails used to ship with CoffeeScript. I wonder when they stopped. Anyway, it did for a minute. Bad-bad, unfortunately.

"I find CoffeeScript extremely hard to read and write, coming from a vanilla JS background. Any tips to gently move them over to using just ES6+?"

Dave: Oh, man. This is tough.

Chris: I don't know.

Dave: I don't know. This is a very -- you'd have to rewrite a lot.

Chris: There is a project called Decaffeinate, which is kind of great. [Laughter]

Dave: Oh, really?

Chris: Which you paste I your CoffeeScript and it kind of barfs out stuff.

Dave: Standard JavaScript?

Chris: What I like about it is that it retains your comments and stuff. That's what I'd worry about. There is one world in which you're just like, "I don't know. Just compile it. Take the compiled stuff. Throw away your JavaScript."

Dave: Beautify.

Chris: Beautify, yeah, and there you go. This looks like it goes a step further and cleans it up into a way that might look like a human being wrote it. That's the danger. Compile JavaScript, even Beautify doesn't have that human feel to it. It might actually be worse to move away from it than just leave it.

Dave: Oh, man. This might work. I think I know Brian Donovan who wrote this. Yeah, I think this might be the best choice. I think at some point you have to be like, "Hey, we need to talk about the future proof-y-ness of this application. A lot of things have moved off of CoffeeScript."

If you like CoffeeScript and you're having success with it, keep doing it. that's great. But it sounds like you're not having success with it, Hyme.

Chris: Well, aren't you locked in because CoffeeScript isn't getting updated anymore, probably? If there are some cool ES6+ feature, it's possible that CoffeeScript just doesn't let you write it.

Dave: Right.

Chris: That's going to have to be your argument to the bosses or whoever to be like, "Hey, this is useful stuff and we can't use it because this technology is limiting us."

Dave: Well, and I think a lot of what was -- I think a lot of the good pieces, the good parts of CoffeeScript, the good parts have kind of been put into JavaScript now. I think you're going to have less of a pushback. I'm trying to think of what features CoffeeScript really had.

Chris: Here's one that's so great. I was just playing with it the other day because I had to test it and write some tests to make sure we weren't breaking stuff at CodePen. You can write name=dave. Like in CoffeeScript, you don't even have to say const-let-var. It just does it for you.

Dave: That's Rails-y.

Chris: Yeah. It is Rails-y. Yeah.

Dave: Okay.

Chris: Name="dave" and then you can just say if-true. You can put a condition at the end of it, which is also Rails-y.

Dave: Oh, okay. Yeah. Yeah.

Chris: You can be like, if -- you'd really put a condition there like if logged in or whatever equals true, also, or something. If-true won't do anything. It'll just assign the string because True is always true. You know?

Dave: Yeah.

Chris: But it's a very modern feel, you know, to be like const-result-huge-if-true. [Laughter]

Dave: Right. Well, but you could do if whatever user.id=12345 or whatever. You know, equals-equals. Yeah, it just compiles to an if statement.

Chris: Yeah. It just reverses it.

Dave: If brackets, if true brackets fonts name equals dave. That's beautiful. I would do this Decaffeinated thing. This looks pretty good.

Chris: The white space of it is weird. How many of us write white space languages anymore? Although, thanks, GraphQL, bringing it back. Don't love that.

[Laughter]

Dave: Please deprecate.

Chris: Just because you hate commas, is that why? I hate it.

Dave: I don't know.

Chris: GraphQL with commas, bring it on.

Dave: Yeah. Well, I think about, too, people who rage against the semicolon at the end. "I'm not going to write those," and, "We lint those out," or whatever.

Chris: Ay-ah-ay.

Dave: Oh, god forbid it just -- you tell the computer to stop doing something. [Laughter] Anyway. Hey… Computers are smart. People have figured it out.

Again, this is probably the same conversation as the previous person. I think the start of the conversation, like, what things are we getting out of CoffeeScript?

Chris: I really like that approach, Dave. That's smart.

Dave: There's always a reason. Sometimes the reason is dumb and sometimes the reason is smart. It's like, "Oh, we're using CoffeeScript because the CTO invented it," or whatever. You're just like, "Oh, yeah. That's cool. I didn't realize that," or whatever. Or, "He had big buy-in," so the job to move off CoffeeScript is actually convincing the CTO, "Hey, your bet project, your baby that you love that we've written now 3,000 lines of CoffeeScript or 300,000 lines of CoffeeScript isn't that popular anymore." That can be insulting. Now you have a human problem.

I think getting to the core of what value is this providing and not just trying to shoot it down. That's not it. But trying to understand what value that is providing. Maybe people just hate JavaScript. You have a lot of people who just -- I'm a backend person. I don't like JavaScript. This makes me feel like I'm not writing front-end code or something, so maybe that makes a big difference.

Or, like you said, maybe they're just like, "Oh, I've been waiting for someone like you, eager enough to port all of our CoffeeScript over." Maybe you don't have tests. That's probably it, too, right? Somebody would be like, "We don't have the tests, and so we could do a major refactor but it'd probably break everything because we don't have the test suite." Well, maybe you volunteer to write all the tests. Get better test coverage and that makes the whole product better going forward.

Chris: Heck yeah, it does.

Dave: I say that as somebody who is terrible at writing tests, but that would helpful.

Chris: It's so hard, isn't it? We need a testers anonymous club or something. Some days I'm all high on the world because my tests are running good and I wrote some tests. I'm like, "We're never going to ship broken code again. Our tests are amazing." Then they start not working good and then you get off the testing bandwagon for a minute. Then you're too busy doing other stuff to worry about them. Aww… Poor tests.

Dave: Yeah.

Chris: I find unit tests are a lot easier to just keep up and stick around and grow and stay robust over time. But the end-to-end stuff is very fragile, to me, I think.

Dave: Yeah. Nah, well, totally. That's always my thing. Unit tests, okay, if one plus one equals two, assert that. Great. Yeah. Sure. Cool.

But then it's like, my tests are more like, okay, on Internet Explorer, this div cannot be three or four pixels more than this div because of some weird Flexbox collapsing thing. Those are the tests. I'm at 382-pixel viewport. That's the problems I have. I don't know how to solve those.

I would say this is hot testing news. Microsoft just dropped a thing called PlayWright. It is a cross-browser Web automation platform, like Puppeteer.

Chris: What?!

Dave: But it works with Chromium, WebKit, and Firefox.

Chris: No way. Microsoft just dropped this?

Dave: Yes way. Microsoft just dropped this.

Chris: Oh, we should get somebody on the show for that.

Dave: Microsoft PlayWright.

Chris: That's so cool.

Dave: I'm not sure that -- that doesn't solve the CoffeeScript problem. [Laughter] I'm just like, ooh, now this maybe makes it kind of closer to a very helpful browser -- I don't know -- integrated browser testing or whatever.

Chris: This is one, and just a heads up for the world, what these things need, to me, table stakes is a really, really, really, really reliable way for it to know when the page is ready to do the work. You can't wait for window.load because then all your tests will take hours because that hangs all the time for weird reasons. It can't be DOM ready because that's not necessarily perfect because then there's Ajax requests for data that have to come back and stuff.

There needs to be real intelligence, I think, built-in that's just like, "Okay. Now you can click that button." I just want to write a test that's like, "Click this button and see if the H1 says, 'Hi, Dave,' in it." In order for that to reliably run, it needs to heuristically somehow know that that line of code is ready to be run and tested. That's a hard problem to solve.

Dave: Not simple but, anyway, I just thought this was pretty cool. Anyway, it seems like--

Chris: That fricken' is cool. I'm going to show everybody this today.

Dave: Literally, a yesterday thing - last night. But it is going to -- I think it could possibly be the precursor. I don't know. Brett Frost has talked about--

We're coming up to the hard stop. I've got to be careful.

Brad Frost had talked about, "Wouldn't it be cool to have a browser engine that just randomly changed on you?

Chris: Oh, yeah.

Dave: Like, "Oh, sorry." Now it's like Firefox. Now it's Opera. Now it's--

Chris: That's such a Brad Frost thing. Didn't he make that tester tool that randomly loaded your website at different widths?

Dave: Yeah. Yeah, I think he was putting that in there too. It's just like you open a page and it's just random.

Chris: Yeah.

Dave: You don't even know. Just from the, I guess, stress testability or the, like, "Hey, how does this look? Does this work and feel good?" sort of perspective in different browser engines. I'm not saying this accomplishes Brad's dream but, hey, maybe this touches it. I don't know. It gets close to it. At least you could maybe chump out a screenshot of something. There you go. What's this look like in a random browser? Give me a random screenshot or whatever. [Laughter] There you go.

All right. Hey, we've got a hard stop here. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris, do you got anything else you'd like to say?

Chris: [Loud inhale] ShopTalkShow.com.