Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to the final episode of the year of ShopTalk Show. I'm Dave Rupert. With me is Jingle-Jingle Chris Coyier. [Laughter] Hey, Chris.

Chris Coyier: Ho, ho, ho!

Dave: Hey.

Chris: Hey.

Dave: Chris.

Chris: Yeah.

Dave: What's happening? It's the final episode--392, I believe, is what this will be numbered--of the year; wrapping up our eighth season here of the ShopTalk Show. Very exciting [Laughter] We missed -- we missed--

I don't know how the math works out but we missed 400 by, like, whatever, 8 episodes. That's too bad, huh?

Chris: Yeah. I wonder if we never missed a single episode the entire time, we probably would have hit it but, once in a while, we skip an episode. We're going to skip this one over--

Dave: Take two weeks off or something.

Chris: Yeah.

Dave: I don't know.

Chris: Maybe next year we'll take a little more time off for the holiday. I know I've said that before, but we'll see.

Anyway, you know what I have on my calendar for January 1st? Remember we had Laurie Voss, who was at NPM at the time who had all this data about usage of NPM, which was totally fascinating? Part of that data was like this massive rise of TypeScript.

Dave: Yeah.

Chris: That everything is written in it and people are using it. There's a surge like has never been seen before in a technology.

Dave: TypeScript apocalypse. Yeah, typapocalypse.

Chris: [Laughter] Which is funny. I don't know… I don't know. The thing on my calendar was that, by January 1st, Laurie said that React would be written in TypeScript, which I'm afraid that we're not going to hit that one. I don't think so, right? That's not--

Dave: I don't think so, but wasn't Laurie saying, or maybe I'd heard it, that Redux is written in TypeScript. I know Vue is going to be written in TypeScript, Vue 3, I think.

Chris: Hmm. Hmm. Hmm. That's cool. That's cool.

Dave: You know it's tough. I get confused when I just skim the old headlines. [Laughter]

Chris: Yeah.

Dave: When something adds TypeScript support, as I understand it, you can supply type definitions that TypeScript can pick up on or something. How that works is magic to me. But then there's the difference between just supporting TypeScript and then actually written in TypeScript.

Chris: Being written in TypeScript? Yeah, I don't quite understand it all either. I'm afraid I have to claim some ignorance here, but it does make me think of, when there are new technologies in the world, I try to be aware of them and be like, "Where do they fall into the spectrum of building websites? When might I reach for it?" I never really grok it until I actually have a project that uses it and then all the dominos fall and I'm like, "Oh, I get it. Wow!" You know, like Sass was like that and any new CMS you pick up. JavaScript libraries are like that. You can kind of conceptually get it. Then you really get it when you actually have a real project that requires that you use that technology and it has never happened to me in TypeScript. I don't have any projects at all in TypeScript, so that shoe has not dropped for me.

But I did listen to a nice Tools Day episode the other week with--

Dave: Tools Day, Tools Day. Is that their theme song? [Laughter] It's a musical podcast.

Chris: They had a frank conversation about it which was pretty interesting. There are these real basics of TypeScript like types. [Laughter]

Dave: Yeah.

Chris: You're like, "Okay. TypeScript does types." When I'm working on my projects day-to-day, I'm not like, "Gawd! I really wish I could type these variables because every week we have bugs in our software that are a result of variables being of the wrong type." No, not really; not that often. That surely can't be the whole reason that TypeScript has blown up across the world is just types. That doesn't seem to make sense to me.

Dave: Yeah.

Chris: They cover that and they're like, "Well, that is actually some of it," but the bigger deal is that it adds, you know, because your IDE, like VSCode, can understand so much more about TypeScript because of its typed nature that it can be a lot more helpful as you write code. This is particularly true with libraries that, when you use the functions of those libraries, it can just be a lot more helpful in telling you what it expects as you use the functions of that library. That seems like a big deal to me and that doesn't have to be for third party levers. It could be just for functions that you declare yourself in your own app, like, "Here is our little login function," or whatever the function may be that takes these three things. Then when you go to call it, like the IntelliSense kicks in an app and it starts being like, "Okay, this is what I want. Please give it to me correctly and in the right order and all that."

Dave: If I type "is active equals" and if I defined it as a bullion, true or false, it'll give me a dropdown, true or false. It'll say, "Oh, which one of these two options are you trying to--?"

Chris: Yeah.

Dave: Which is pretty cool.

Chris: Even if you don't like TypeScript, you might like it when other people write their stuff in TypeScript because it certainly does make for a nicer author experience. What's funny is, is this just a VSCode thing? I don't think I've seen it. I don't know that if you're using Sublime, Atom, or something that you get quite that level of integration.

Dave: Yeah. I think it's a product that was honed for Visual Studio, big VS.

Chris: Mm-hmm.

Dave: Like big VS, not VSCode, this IntelliSense stuff, and then they managed to port it down to this kind of--whatever--build your own ID, not the big ID for C#.net. You know? It's really handy. There's a lot. You can even experiment with types and TypeScript. You do a comment in your JavaScript. There's an enable -- I forget the word but you can experiment with types and it can sort of infer what you're trying to do, too. It knows how to do that in VSCode already.

Let me figure it out. Let me tell you. I have to do some Googling. This is too bad.

Oh, yeah. Okay, //@ts-check to any JavaScript and it'll kind of infer what you're doing. If you have JS documentations like this is a parameter, @parameter string, name, or something like that, it'll know it's a string. If you start trying to say, like--whatever--this.name=false, it'll put a little red dot or whatever, a squiggly underline and say, "This is not valid. You said it was a string."

Chris: Meaning, you can kind of baby step to TypeScript without having to change your file extensions.

Dave: Yeah.

Chris: And change your file processing and all that.

Dave: Yeah. I'll put a little link in the show notes here but, yeah, it's just kind of this little way to sort of experience what TypeScript might be like. I've worked on Angular projects that are written in TypeScript. I think it's cool, but I don't know. For me, it's a lot of action. It introduces a lot.

That said, I went on a bit of a code bender this weekend and made two apps in Vue. It was awesome. I was having a lot of fun just writing in CodePen. There was a point where it's throwing. It's just like, "Uh, this doesn't have a length," you know, and I'm like, "It should have a length. It's an array. I set it as an array." Something must have been setting it to false or something like that. I don't remember what the exact answer was but it was like, "Oh, okay, so I have to set something. I have to make sure it's an array or else it'll just bomb out." Anyway, that's what's weird about JavaScript. Something can be false, zero, or an empty quote and those are all the same interpreted value: empty, basically. Yeah, I think that's the problem….

Chris: I kind of want to be dragged into it at some point just to experience it. I was snake bitten once too. I worked on a little project that didn't get very far. It was kind of a hackathon kind of a thing where the original creator of the project was like, "Well, we're going to do this thing in Next.js or something, but I want to do it all in TypeScript too." It seemed like a little experimental-ish at the time to get TypeScript working with all the necessary other tools. There were wrappers and extra packages to make it all work.

I found it all really challenging in that most of the time was spent trying to shoehorn TypeScript into it all to the point where I spent 80% of the time on that, couldn't really get it going, spent another 10% of the time ripping TypeScript all out of it because I just couldn't get it going, and then another 10% would be like, "Well, I guess I'll do a little bit of work on this thing before just having to call it a day," to the point where then, obviously, after an experience like that, you're like, "Why?"

[Laughter]

Chris: That was not fun.

Dave: What are we doing here?

Chris: Yeah.

Dave: Yeah. No, I think you have to be dragged in. For me, it's like a Webpack thing too. Somebody had to set it up for you. You're not just going to parachute from the sky and be ready to use it, like getting it going from the ground up. I don't know that it's that intuitive - for me.

There is some data to suggest, and I've read research papers from Microsoft. I was going to try to find it. Again, I'm live Googling. There is something like having strong types in a language like JavaScript can basically reduce 15% of bugs. It catches 15% of all bugs.

Chris: Hmm. I buy it.

Dave: Yeah and so, for Dave Rupert, where I have zero bugs--

Chris: Yeah.

Dave: --that doesn't mean anything.

Chris: Ha-ha-ha.

Dave: [Laughter] But I don't know. If you're working on a team and you're regularly like, whatever, the whole system is crashing -- and that's the thing about JavaScript, too. It hits an error and it's like, "Dude, I'm sorry. We're gone. We left. We peaced-out. Everything is broken. Shut it down."

Chris: I wonder if it reduces the need for it with optional chaining now. Just put a question mark after literally everything.

Dave: See.

Chris: [Laughter]

Dave: Yeah. Undefined? Are you undefined? Are you undefined?

Chris: Doesn't matter. [Laughter]

Dave: Is everybody? Sorry. Question period is the new period.

[Laughter]

Dave: That'll be it, dude. That's it. That's a T-shirt. We should get it on the old -- that new Web dev T-shirt company….

Chris: It's almost kind of true, though. You almost put a question mark before almost everything, you know. Why not, kind of thing. At least it won't break. I don't know.

Remember, there was a call for when backticks came out? There was a little bit of a campaign for, like, just only use them.

Dave: Mm-hmm.

Chris: They're just better in all circumstances. Even if you're just saying quote Dave, use backticks. Just give yourself the muscle memory of it because it's just better.

Dave: Man, it is. I use them in query selectors and stuff like that. [Laughter]

Chris: Yeah.

Dave: Or jQuery, I'll use a backtick. Whatever. It doesn't care. It can work.

Chris: The only time I don't like seeing it is in React code when you could have wrote just data-name equals "Dave" that people go, like, data name equals {`Dave`}. You've invoked JavaScript just to use backticks. Maybe that's one step too far.

Dave: You broke out of JSX to use JavaScript to just echo a variable. Hey, man, websites are complicated.

[Banjo music starts]

Chris Enns: Hey, there. This episode is brought to you by WordPress.com. Whether you want to share your ideas, start a business, or run a store, you can do it all on WordPress.com.

Maybe you're like me and you've set up a lot of self-hosted WordPress sites over the years and it's great that WordPress gives you that option but sometimes you don't want to have to worry about servers, infrastructure, backups, and cron jobs. You just want to start a website now and that's why you should check out WordPress.com.

You can open a store, process payments, configure taxes and shipping, build a marketing plan. You make the widgets. They'll help you make the website. You could start a blog. Make your mark online with the world's greatest blogging tool and join a community a million strong that's waiting to hear what you have to say. You could design a portfolio. Thousands of themes means there's a layout that's just right for you while storage and design options ensure you can upload anything you need and give your work the stage it deserves.

You could build a fanbase, promote your products, use advanced statistics and SEO tools, and connect with built-in audiences on social media to grow your business. You can start it all today on WordPress.com for free. Whether you want to create, share or sell, do it right on WordPress.com. Our thanks to WordPress.com for sponsoring this episode of ShopTalk Show.

[Banjo music ends]

Chris: Well, we've got a bunch of questions. Should we do some?

Dave: We do have some questions.

Chris: Let's do some of that and then we can sprinkle in some 2019/2020 talk. If there's any standout stuff, that'd be cool.

Dave: Sure.

Chris: Here's one from Michael Reed. Speaking of JavaScript stuff, "Is it worth using a JavaScript bundler for a WordPress or CMS site? The company I work for uses a large enterprise CMS and the JavaScript for that site is just a minified mash of several different JavaScript files most of which are several hundred lines of spaghetti code." Been there, buddy.

"It would be nice to break these files up into smaller modules as well as have the benefit of adding Babble for writing more modern JS, but the bundled JavaScript that kind like Webpack, Parcel, or Rollup spits out seems massive. Won't that bundled file hurt the performance of the site?"

This feels very up my alley right now. I just published my Gulp file because I was just cleaning up some Gulp processing I was doing on CSS-Tricks. CSS-Tricks is not a React site, a Vue site, or anything. It's a pretty standard grade WordPress site. It has some JavaScript on it, though, for, like, I need to click the hamburger menu open and open it; I need to do some syntax highlighting; or I need to fetch some ads and display them on the site.

Okay. Cool. I need some JavaScript to do that and I still use jQuery because jQuery is bundled with a bunch of WordPress plugins. It feels a pretty natural fit these days.

Dave: Sorry. Am I wrong? jQuery happens by default. You have to unset it in a WordPress site, or do you have to enqueue it?

Chris: On the front-end, 90% of the sites you're going to get it because something is going to trigger it, like a Jetpack thing is going to trigger it or something. I don't think it necessarily 100% of the time gets added, but anything and its sister will trigger it to be added.

Dave: Okay. Okay, okay.

Chris: I use that and I have my spaghetti code, too; although, I keep it kind of modular. My main global.js file that's responsible for 80% of the functionality is somewhat well organized but I just kind of have it in a big object and call the functions that I need and stuff. It's not total spaghetti, but it's a little spaghetti-y.

Then I got FitVids in there and I've got prism.js.

Dave: Oh, yeah.

Chris: Okay, there are two examples. Neither of those are ES 6 ready. Sorry. I don't think you ever got around to making FitVids.

[Laughter]

Dave: How dare you!

[Laughter]

Dave: Hey, I'll give you a little hint. Okay?

Chris: Yeah.

Dave: On my gist page, there is a vanilla version of FitVids that you could copy.

Chris: Which you could export? Yeah.

Dave: You have to copy and paste and put in your own damn site because I'm not maintaining an NPM module ever in my whole life ever again. [Laughter]

Chris: No. Fair enough. There are probably four or five JavaScript files, none of which -- they just happen to not be importable. You know, classic ES 6 style, kind of. I can't write my global.js file with a bunch of import statements at the top of it and run it through Babble and Webpack and have it just all smashed together that way that we're used to working on so many other projects. It's just not available to me.

Dave: Mm-hmm.

Chris: I still run Babble over it, but I just run Babble over it individually so I can use optional chaining and stuff like that if I really care to. But then I need something else to smash them all together, so I use Gulp. I just old school style be like, okay, process them all with Babble, minify them, smash them together just with bespoke instructions. Part of that makes me feel like, all right, well, that sucks. Maybe in the future that could be cooler or maybe I'll use Gatsby to build the site next time and just go full bore crazy! Probably not, but maybe. Anyway, that's just the world. I get where, Michael, you're coming from in that this Babble Webpack JavaScript bundling type of stuff kind of doesn't fit with CMS-y type of builds sometimes just because of the tools in use, in a way.

Dave: WordPress is interesting because, to update WordPress, you can do it all locally but I would imagine most people are still just like, "Click the blue button," that updates WordPress when it asks you to. You know?

Chris: Right.

Dave: That all happens. All the content is done online. You don't pull down any of the content or you don't have to. But it's that theme development that happens locally or whatever. That's what powers the site. That's what gets the e-commerce working. That's what does all the -- you know.

He was saying several hundred lines of spaghetti code. I think that's easy to achieve. I think there's nothing to say, like, you can't use WPnQ script for all your dependencies, I guess, and just let WordPress or whatever kind of minify or bundler you have on WordPress, minify those things. But then the code you write, that can be tiny. That could be split up and written into using Parcel or something like that.

The output, I wouldn't worry about it. You are smashing together five files, so you need to pay attention to what you're doing there. I have good luck with Parcel and Rollup, just getting something going that bundles files. It can do the tree shaking and stuff like that.

Chris: Mm-hmm.

Dave: I think if you're doing that, you're in a weird position with WordPress, specifically. Now, how do you map that to each view, the file generated to each view? Like single.123456789. How are you going to get that uploaded to your single template or whatever, your global? I forget what the names are. Main and whatever.

If you're splitting the code, now you're responsible for getting it in but you could also just do the thing where that code loads late or async or something like that. You just get it to spit out the files, the chunks, and then maybe you deal with the chunks. I don't know. That's where it gets tricky because then there's caching involved in all that too.

Chris: Yeah. It confuses me how it all works. For example, if you just had an index.js file and you wrote constx=2 and then you're just like, "Okay, here you go, Webpack. Webpack this thing."

Dave: Yeah.

Chris: You get, in my experience here, 8,912 lines of code. At the very bottom of it, it says, "Use strict varx=2." But the whole top of it is all this stuff for dealing with modules and packages and requires. Have you ever seen this? It blows my mind, in a way.

Dave: No. That's the modern world. I think I was reading there's a good Perf Planet, which they do an advent calendar kind of thing. It was just about the cost of React, CSS, JS, and stuff like that. It was just saying every CSS and JS library is about 20KB of overhead just from the functions that get it, inject it, recap all the classes and stuff like that.

Chris: That sounds about right.

Dave: On the client, that's going to cost you 20K or something.

Chris: Twenty K!

Dave: Yeah. I hope I'm not misrepresenting.

Chris: Not from a library but from the bundler!

Dave: You know I think "There are Some Unseen Performance Costs" is what the article is called. You know some of this stuff isn't free.

Okay. CSS and JS is 12 to 15K or something. In this article, they're advocating for Linea. Are you familiar with what library? It's kind of a slight alternative to what the CSS and JS are doing. It's kind of more like -- it's more -- it doesn't work on IE 9 or IE 11 because it uses CSS variables to do all the manipulating. Anyway, it may not work for your system, but they're advocating for it because it's only 2K on the client or something like that.

Chris: Okay.

Dave: 3K.

Chris: There's just something funky with the processing I've got. It's so much more extreme than that. I sent you this little project. It makes one line of code into un-minifier anything, 328K. That can't be right. There's something funky there.

Dave: Whoa!

Chris: Listeners, don't worry about it too much. I'll dig into that.

Dave: We have processed the world. Yeah, this is wild, dude. What happened? That's the thing, too. Webpack has dependencies, so it imports all those things - blah-blah-blah. Then it all bundles up and spits out something. Maybe some of those bundles aren't even -- I don't know.

Chris: Whatever. This is perennial stuff. What is JavaScript doing to us? That probably was a hot topic in 2019, but I think it was kind of a hot topic in 2018, too.

Dave: Yeah.

Chris: This will continue to be a hot topic because people care. They're always caring about performance, accessibility, and stuff.

I would say, as we head into 2020, I don't see a particular surge in it above and beyond any other surge. I think when you're in an optimistic mood, you're like, "Yeah, we're doing better at performance." When you're in a pessimistic mood you're like, "No, we're not."

Dave: [Laughter]

Chris: The same with performance.

Dave: I have a post about this. I always feel like I was doing good and then I ran Webpage Test Easy on my site and it was taking 33 seconds to load. I just was like, "What?! Thirty-three seconds and I care about it? What the hell is going on?" I was loading my fonts bad, basically.

Chris: Thirty-three seconds meaning like a slow 3G mobile connection?

Dave: Yeah.

Chris: Yeah.

Dave: Yeah. That's the only way to test. You're kidding yourself if you do otherwise.

Chris: Yeah. Yeah.

Dave: Hard mode only.

Chris: Then is that DOM ready or window.load or is that your first meaningful paint?

Dave: I think that was full load, but yeah. I forget what the actual stats are. I could pull it up.

Chris: There are always interesting new perf stats, right? This year, Drop does a couple of new performance stats. One of them was an interesting one. It would try to find the largest, meaningful looking element on the page.

Dave: Meaningful paint.

Chris: Yeah, was that the meaningful paint one? It was often an image. Obviously, this image is import to the page and takes up a lot of screen real estate. When that thing paints, then that's your metric because that's the thing that matters to people, which is a little bit different than the first render, the first rendering pass, although that one matters too because that's the moment from light to something. Something certainly is a pivotal moment in the feeling of loading a website.

Dave: Yeah, you almost need the three in tandem, like first paint. When did it get stuff and it could paint a pixel? When did it paint stuff and the user could read it? Now it gets into the time to interactive. I actually don't care about load so much as time to interactive. When can the user scroll the page or click the search bar? You see it on the Verge all the time. If you ever go to that website and then try to search, it takes a good, like, 25 seconds even on Fiverr to get the actual--

Chris: Gosh, that's too bad.

Dave: --search UI is going. Yeah, you've got to think about that stuff. No offense to people who work on Verge. I'm sure you're working very hard and advertisements are against you.

For bundling, I was on the search for what is the easiest way to bundle. I landed on Parcel.

Chris: Mm-hmm.

Dave: I have just one line NPM script that parses my JS and spits it up.

Chris: That's kind of its promise, isn't it? I'm intrigued by it, in a way. I considered it because you could almost possibly think of it as a Gulp alternative. As I set up to write this Gulp file I was like, I guess with Parcel you don't have to write anything at all because it looks at, for example, a template file and it says, "Oh, I see they're loading up a CSS file here, so I guess I pretty process that for them. They're loading up this JavaScript file. I guess I better process that for them."

In a sense, it's like you're punting your configuration to a template then and it made me feel a little uneasy to put .CSS in a link. Like, ewww, that doesn't--

Dave: Yeah, and I will say, similar to your, "Oh, this Webpack spit out 8,000 lines of code," [laughter] which that seems weird and wrong, but we'll just say that's the fact because you showed it to me, so it's real.

Chris: I know.

Dave: But the bundle that's spitting out here, it starts off with a parcel require function. My bundle is 33K and I'm really not using a super hell of a lot of JavaScript per the usual. I literally--

Here, I'll tell you what's going in there. I guess I have one, two, three, four Polyfills and two tiny jQueries and Prism. I guess Prism is 20K, so that's a big chunk of the total 33K or whatever. Anyway, it's interesting what goes in and what goes out. There are tools like source-map-explorer. Have you used that? It's similar to webpack-bundle-analyzer. Source-map-explorer….

Chris: Yeah, but it's looking at your actual code, not your packages.

Dave: It kind of doesn't care if you use Sass or if you use Webpack or whatever. It just looks at a source map. You compare a file to a source map and it'll spit out a tree graph, which is kind of these boxes inside boxes and it'll show you what's inside of that bundle. Anyway, it's pretty cool.

Chris: It is cool.

Dave: Anyway, maybe I should write a CSS-Tricks post, man. This is maybe the easiest way to process JavaScript. Really, I'm very minimalist. I didn't want to overcommit and make some big, gigantic Webpack flow and then we go to a client and they're like, "Oh, we are on Gulp 3," or whatever. It's like, "Oh, shoot. Okay. We'll switch it." I didn't want to over-buy into something, like into a tool.

Chris: Is there some sort of -- we covered that Prism is not -- you can't import Prism from Prism. It's not ready for that. How did you deal with that in Parcel land? Does it have comment directives or something?

Dave: No. Let me tell you what it does here. Prism.

Chris: Just link up a bunch of scripts at the bottom of your template?

Dave: Yeah, it basically calls it a function, like A equals the Prism object or whatever. [Laughter] Once it's in there, it can negotiate. It's just part of the big bundle. It's sucked up like you did with a Gulp file, basically. It's kind of the hybrid of Gulp and a Webpack….

Chris: You just called Prism globally?

Dave: Here's my command: npm-run-process:js. That's what I called it. Right?

Chris: Mm-hmm.

Dave: Then that runs parcel-build-source-assets-js-app.js, which has all my imports.

Chris: Yeah, so at the top of app.js, does it call Prism or something?

Dave: Yeah. I just have import in app.js and it comes in.

Chris: So you can import Prism.

Dave: Well, yeah, I mean it might be cheating, but yeah. [Laughter] Maybe it's not doing it right, but it's just saying, "Pull in these scripts," you know. I have it as prism.js. I'm importing the whole file, not just the--

Chris: Oh, maybe that's how. Yeah, okay, because you can do that, right? It's not a named import. You're just saying, like, "Just give me this whole file, please."

Dave: Yeah. Yeah, yeah, because I do nothing with it and it auto-executes or whatever.

Chris: You could probably teach Webpack how to do that too. That's the beauty of a bundler, in a way. Bundlers follow ES 6 import style but only because they can, right? Bundlers have extra abilities, right? When you write import-react from React, that's not ES 6. That's special, weird syntax that just happens to work with bundlers and bundlers just happen to agree that, when you write that, that means, "Please grab that from my Node modules folder." That's just like a handshake agreement with how bundlers work, right?

Dave: Mm-hmm.

Chris: Your import statement also is not ES 6 friendly. It's just a line of code that bundlers happen to understand because of some handshake agreement that that's how bundlers, this bundler is going to work.

Dave: Yeah, and I think it's sort of just the Node style of importing, like CommonJS sort of style. You know require. You could probably use require too.

Chris: Right.

Dave: It's just sort of like require this file and do something with it. Yeah, maybe it's totally hacking around it but, no, that's how I do it. It's pretty good. Then you say outDir=source-js and outFile is bundle.js and then it's done. It gives me a source map too.

Chris: Just my thinking here then is that that app.js file a little bit ties you to Parcel, just a smidge. It's not totally friendly. You couldn't just stop using Parcel.

Dave: Yeah, I mean I guess so. I think it would -- yeah, I guess you're right. I don't know how you'd get around that. You just have -- if something is not modularized. I think we're going to be in that situation for a long time where some code is not modules and some is, for a long time.

Chris: Probably, yes, quite a long time. There already is. I feel like we're almost past peak people begging for people to rewrite their libraries to be import-friendly, you know.

Dave: Mm-hmm.

Chris: It's not even solved yet. Isn't that the promise of Pica or whatever? It's like this problem sucks so we'll just deal with it for you.

Dave: Yeah. Yeah, but Pica has a hard requirement for modules. You have to be--

Chris: Oh, it's got to be ES 6 and then it helps you? Oh, wow.

Dave: Yeah.

Chris: Well, that's not that helpful then.

Dave: Yeah, I think they have some cheater scripts because Preact or something can't do it, so they cheat it or something like that. Yeah, it's sort of this idea. In NPM package land, you can do module:my-file. What is it in NPM? It's like main-index.js or whatever. In your package.json, you set a main file and that's where everything will look for the JavaScript to start. Then it also has a module directive now or whatever, a property in the package.json that you can set to whatever your module is, so index.mjs or whatever. I think Pica picks up on repos that have that.

Then it can kind of build out a thing. If you say, "I want Preact," it'll go get all the stuff it needs for Preact and give you just one file.

Chris: That's cool.

Dave: Yeah. Then I found out the other day, unpackage, you can do ?module or something and it'll trigger the multiple….

Chris: Yeah, it's been years that's been in beta or whatever. It depends on if it's able to do it or not and I don't know what--

Dave: Some of that stuff I just don't get. [Laughter] That's a big project, so I'm just like, "How do you do this?"

Chris: It would be nice -- I don't really understand how it works either, but there's stuff on NPM that you can't use in the browser. You have to run it. It's like a required thing or whatever. But wouldn't it be nice if every single thing on NPM was available to use in the browser through some magic? That would kind of be a ticket there if you were like, "Okay, force this lib to be in module so then I can import it." Then I wouldn't even need to run Webpack or whatever. I can just ES 6 import it. That opens some doors. Anyway, we're still in the throws of working on that at CodePen, actually.

Dave: Yeah.

Chris: If I take this lib and we run it through Webpack, we can learn a bunch of interesting stuff about it. You try to use React DOM. There has a peer dependency of React, but you only really know that if you actually try to process code in it so then we can go get React for you and bundle it all together and make it work in a way.

Libs depend on a bunch of other libs and so you'd think you'd have to get that right in your package.json, but you kind of don't. The package.json is just kind of like a suggestion of what its dependencies are. Until you process that code, then you really learn what the dependencies are.

Dave: [Laughter]

Chris: Then you can get the real dependencies.

Dave: Yeah. Oh, man. Well, and even like source or dev dependencies and dependencies, right? I have Sass in my dependencies folder on this one project. I'm like, that's a dev dependency, I think. But if I move it there, does Netlify do the dev dependencies or do they just do the dependencies? What does Netlify…?

Chris: Probably just dependencies, but they probably have this problem all the time and so they don't trust you. I bet it works on Netlify because they don't trust you to have it right.

Dave: Yeah, they're basically like, "This guy does not know what he's doing. We will install both." [Laughter] There you go.

Chris: Probably. I can't say that that's for sure the case, but it sounds about right to me.

Dave: Maybe this line is getting weird too. I think dependencies is supposed to be more for like--I don't know--this was code that would end up in Browserify or something like that. Dev dependencies was supposed to be only for a development environment, but this is going to production so what do I do?

Chris: That's what it was supposed to be and then peer dependencies, yeah, just good luck trying to explain that.

Dave: I'll move it. I'll move it to dependencies. Hopefully, that helped - NOT. It probably didn't help, but I've had good luck with Parcel, so try that, Michael. It's a one-liner. It should be pretty good to just do. Parcel-build-input-file outDir and outFile, that's what I use. I get pretty good results. Who knows what's in there but pretty good results.

[Banjo music starts]

Chris Enns: This episode was brought to you by GiveWell. Imagine that you want to help children. You found two trustworthy organizations but they run different programs. One can save a child's life for every $300,000 donated while the other can save a child's life for every $3,000 donated. If you could tell the difference, you'd donate to the one that was 100 times better at saving children's lives. But in reality, it's often hard to know what charities will actually be able to accomplish with your donation.

GiveWell spends 20,000 hours each year researching charities. They review academic studies, charity budgets, and visit charities on the ground to figure out which ones are the best at saving or improving lives. All of their research is public and free on their website. Go to GiveWell.org/ShopTalk to find out more or make a donation. First-time donors will have their donation matched up to $1,000 if they donate through GiveWell.org/ShopTalk. Our thanks to GiveWell for sponsoring this episode.

[Banjo music ends]

Dave: Okay, Allan Reeder, no relation to Michael Reed… [Laughter] "Chris, recently blogged about Parallax breaking in iOS 13. I'm working up a tasteful! Parallax experience for a client and just discovered that Apple are being [explicit used] in breaking the Web. Is there any point in trying to do Parallax then?" Chris, is Parallax dead?

Chris: Well, that's extreme because what I blogged was that there's one particular way that you can do Parallax in CSS in which that you -- I don't know -- you basically use a Z translate, like 3D translate to kind of push an element away from the screen. You can imagine that, right? Like a div and this one is set further back than another one is.

Dave: Yeah. This one is a thousand. This one is 300. It's up in my face.

Chris: Yeah. Now when you scroll, the one that's further back, it scrolls a little slower because it's further away. That's what Parallax is. It's like you're driving down the road and the fence right on the side of the road is moving fast but the barn in the distance is moving slow. Because you've pushed this element back like barn, it moves slow, which is fine. You can actually leave it like that and that's still Parallax, I'd say.

Sometimes, Parallax is thought of as, like, what if there's text on the side of this? Let's bring it back to the forefront so that different things are scrolling at different speeds, but they're not necessarily sized differently. You can use a scale to bring it back up to the regular size that it was before you did the transform or somewhere in between or whatever you want. Now you've got CSS Parallax going on. As you scroll up and down the page, different elements are scrolling at different speeds. Was it Keith Clark maybe blogged that in, like, 2012, '11, or something?

Dave: Yeah….

Chris: Yeah, made it in Sass. Did it great. It doesn't work anymore in iOS 13 and Safari, which means it doesn't work in Chrome and Firefox on iOS either because they all use the same rendering engine on iOS. That's a hot topic recently. Anyway, a little bit of a bummer, right? Like, what the hell?

I also noticed -- I don't know if I've mentioned this on the show recently. One of my favorite CSS-Tricks or, literally, not my site but CSS-Tricks of all time is this one that Lea Verou kind of popularized of using for shadows, some of them with background-attachment-local and some of them with background-attachment-scroll on an element that shows the shadow if you can scroll in that direction. Then once you've maxed out your scrolling in that direction, the shadow goes away and it works both directions. It's really clever and I think a nice UX touch too because it's nice to indicate to a user when you can scroll in a direction and when you're at maximum scroll there without necessarily seeing a scroll bar.

On mobile, it's particularly useful. In fact, I read an article recently about somebody's mom. I know that's a terrible cliche but the mom could not find some very important action in the sharing panel of iOS. It was really weird because the kid that was helping could find it easily and whatever. It all boiled down to the way that the sharing panel was laid out had some options that you could scroll down to but there's no element that was half cut off or anything.

A half cut off element is a good cue that you can scroll to see the rest of it but it was designed perfectly so that you couldn't see any. There was no indication that you could scroll whatsoever. If there is a little subtle shadow there, you could do it.

My point is, whatever technique that thing uses, it's broken in the same way on iOS 13. iOS 13 doing some pre-rendered layer thing for performance reasons, surely, that makes all these techniques not work. It paints it and then it won't repaint it like it used to, so it's broke! They literally broke it.

Some people are saying, "Oh, well, those aren't stable specs. There are no promises to be made." If something works for seven, eight years on the Web, it doesn't matter what the state of the spec is. That's an established thing. You broke it. You broke it.

Dave: Maybe in 2020, it will get a fix. [Laughter]

Chris: I mean that's why I wanted to blog about it and make a stink about it because you can't just go around, "Hey, blue beanie day." Fricken' Zeldman just blogged this. It's like on the decline a little bit, you know. To me, it always meant not so much like let's celebrate Web standards. It was kind of like a reminder because I was kind of later in the game anyway. I think the early days of blue beanie day were very much like Web standards. I don't know. I can't describe the meaning of it perfectly. I always thought it meant, let's stay vigilant about Web standards instead of ignoring it. This is an example of staying vigilant. You broke something. Please fix it.

Dave: Yeah. No, I mean how many marketing sites just took a dump right here. Even Apple's own sites use a lot of Parallax. [Laughter]

Chris: Yeah.

Dave: I can't imagine how it made it through the QA system. All their sites never used that one technique? That's wild.

Chris: Maybe they do. I'm not sure. I'd say most Parallax, Allan, is done with JavaScript. It's done with scroll position, intersection observer, and stuff like that. There are a bunch of different kind of meanings of Parallax and how it's implemented. This was just one way, so don't take my writing as all Parallax in the entire world is broken. It's just this one way, but it happens to be a good way, so that bugs me a little.

Dave: Yeah. I was going to say I have a blog post on my site. I'll do a link to myself called "Cheap Ass Parallax." It uses CSS variables to sort of set a scroll amount as you scroll. You can fake these kind of slow dropping effects pretty easy with like six lines of code. For the same reasons I would probably use the CSS thing, like, "Oh, it's just less code," and it's not some big, 20-megabyte library. That's great. What's cool is you can also have a fallback for IE 11 where everything is in the right position. This one, you're just like, "Okay, now use the variables."

Chris: Yeah, that's nice. It's an un-debounced window scroll listener. That's kind of funny how we care less about that over time.

Dave: Yeah. It's debounced. It's that thing where, if you use translate, you get a little more performance just because of the compositing and stuff like that. I don't know what the rules are exactly, but you could use the passive scroll listener too, like comma.

Chris: Yeah. I hear that suggested regularly. What does that mean, really?

Dave: It's kind of like request-idle-call. How I describe it is request-idle-callback+scroll.

Chris: Mm-hmm.

Dave: It's like I'm going to do -- I think the idea is you're not recalculating layout on every piece of scroll, which maybe I still am because I do query-document-scroll-top or something like that. The idea is you're okay with it being called maybe not on right as the event fires or whatever. Does that make sense?

Chris: Yeah.

Dave: Maybe I'm explaining it bad.

Chris: I wonder if it will run all over them anyway or if it's willing to drop a few.

Dave: I think it could maybe drop a few. I'm not sure but, yeah, I could probably see here.

Chris: Oh, it looks like somebody did it with requestAnimationFrame too, huh? If you really cared, you could do that.

Dave: Yeah. No, totally. I mean there are other ways to do it too. Yeah, requestAnimationFrame would be cool just because you just wait and the browser will tell you when it's ready to do it.

Chris: Yeah, you have a fork of it in your own blog post on how to do it. It turns six lines to ten lines. Big deal.

Dave: [Laughter] Yeah, anyway, check it out. I think that might bail you out of your problem.

Chris: Is there any other 2019 things that you feel like typified the year?

Dave: Well, 2019, I guess you did your end of year series here.

Chris: Mm-hmm.

Dave: The, like, what I'm excited about sort of series, right?

Chris: Yeah, it's kind of like what's got your attention this year on CSS-Tricks? We got a little over 20 authors kind of answering the question of what about building websites has you interested this year. The subtext was in a positive way. I didn't want it to all be dunking on the world of tech just because there's a lot of that already and I think my spin for this series is, like, what's got your attention in a positive way?

Dave: No, I liked it. I felt like a lot of people were like, "Hey, the tools are actually pretty good," which is kind of interesting because, for the longest time, Web development has been like, "We had tools like Dreamweaver but they spit out really terrible code." You're like, "Ah, this is terrible," or, "Drupple, everything was in a table for a while there."

But I feel like we're kind of at a place where we have some good tools. Even on the design side, we have tools that are rendering more Web-ish now. I think that's a big deal. That was one thing I got out of that series.

Chris: I like that. That's a great typification of the series. Scott Jehl's article was directly about that, but there's more going on of that. There's a lot of JAMstack talk with the idea that JAMstack is just kind of like a good idea and so it's a tool that gives us a lot. It's here, so use it.

Rachel Andrew talking about how CSS slowly now has given us a real system. It's not this kind of tower of hacks. If you felt like that was the case in the past, it's moved its way out of that and it's going to be more and more true over the next few years. We can use logical properties more and we can use, if you're still a holdout on Grid, that we can use. It's becoming this much more cohesive system of laying out rectangles on a page in a very logical way, almost totally free of hacks. That tool has arrived.

The CDN tools have arrived and our ability to kind of manipulate HTML in good ways are here. Extending CSS has arrived. These variable fonts are so amazing. They've arrived.

Ruth John talking about all this hackery we had to do with values in JavaScript because they tend to be strings. Well, there's the Type Object model. Now that's arrived. There are so many, like, this stuff has arrived. Use it.

Dave: Yeah. No, I mean I even think, like, Grid is here. It's so fricken' easy. Subgrid just hit Firefox last week or whatever. That's going to make layouts even more better. Grid-gap or Flex-gap is coming to Flexbox. I don't know when that's ever happening but that's coming and that's going to make Flexbox actually great. [Laughter] Man, we're so close.

Even smooth scrolling or Netlify is a huge one of me. It's like, man, all my deployment; I just Git and then it's deployed and then I don't have to -- you know, it's just done and I get a little CI out of it and I'm going to start playing with Netlify plugins or build plugins to see if I can do some more cool stuff as I build a site. That's cool stuff. The tools or even accessibility, man. It used to be very hard to even figure out your accessibility on your site, but now you have acts, like in the browser, in dev tools, in every Lighthouse report. It just tells you what's going on.

Lighthouse will tell you the latency of every single third-party script on your website. That's huge for me, for clients, stuff like that. I can walk in and just be like, "You know that user replay? That's adding four minutes to your website," or whatever. That's very cool stuff. The tools are here or getting better all the time.

Do we have somebody pitching us on a no-code talk or something? I feel like we did. That's okay if that was you. I don't know that we're full no-code Webflow yet or that's the future, but I'd be curious. I don't know. It seems like a lot of tools are here and making it a lot easier to do stuff.

Chris: Well, good eye there. I think that's very true with all this. I tried to get one of my own for the series and didn't quite make it. [Laughter] I was too busy editing.

Dave: What was your going to be about? Got spoilers?

Chris: Well, I just don't know that I landed on a perfect topic, but I think I am going to publish one kind of asking a different question, which is, has all this gotten easier or harder? Is building websites easier or harder than it was, say, ten years ago? Is the bar higher or lower? Then kind of like trying to explore that idea a little bit, with the idea that I am interested in that. That's highly interesting to me. I kind of have some evidence both ways of things like CSS getting so much easier and things like HTML really is a wash. It's not an easier or not.

But then those are just really base technologies. Does that actually help you get a website up live from nothing? Not really. Of course, you can just use HTML and CSS to build a website but dang near nobody does. It's all about tooling around that. What's that world like? Are those tools easier or harder to use?

Then just because there are some easy things out there, do people actually use them in mass. Are they marketed in a way that people know about them? What are people actually doing? I don't know that I have answers to that. It's just fun to think about.

I think spinning up an average WordPress site is such a common thing to do. I want a self-hosted WordPress site. I don't think it's dramatically easier or harder than it was ten years ago. It's just wild to me.

Dave: Yeah. Delicious Brains had a tool kind of for that.

Chris: They did but it's a pretty developer-focused tool, though, you know.

Dave: Yeah.

Chris: I don't think they would disagree, in a way, but yeah, yeah, yeah. I know what you mean.

Dave: A lot of the world, too, is going -- I mean Squarespace, Wix, and stuff too. I think that's cut out a huge chunk of the potential websites, but also for good. You do those when you're young or eager, which that maybe is a problem because it cuts young and eager people out of the industry a bit. It was a lot of work to, like, "Okay, now I've got to maintain this big WordPress site for this client even though they don't have money." WordPress or Squarespace and those sort of sites--

Chris: That is easier than it was ten years ago. That is significant. Those choices, just click a few buttons and have a website, there's no doubt that that's easier and people are doing it, for sure.

Dave: Yeah.

Chris: To that degree, to go from zero to website with a tool that wants to hand it all to you, there's no doubt about it that that's gotten easier.

Dave: Yeah. I think of my small business owner. It used to be some guy with a stack of paper files. [Laughter] Like a Glen Gary, Glen Ross, or whatever. Just an analog man and, "I need a website to make my life better."

Now, my vision of a person who needs a website is like a Twitch streamer. It's somebody who is like, "I just play video games on the Internet all day and now I have a business. I make ads. I sell ads. I have an online presence and then people wanted me to go to conferences to talk. They needed a contact point."

Chris: Hmm.

Dave: They probably have a Twitch page, but they probably need a website, like Ninja needs a website for some reason. [Laughter] That's interesting to me. There are different kinds of small businesses now even from when I started out. It's almost like websites are getting personal. Influencers need a website of some kind, maybe, but those are weird jobs. Anyway, that's my vision of who needs a website. Small businesses still need a website. I just took a bunch of paper to get shredded by a paper shredder and they needed a better website, so there are a lot of websites that need to be improved.

Chris: Let's do it. Let's wrap up a little final WordPress question here just so we mentioned it anyway.

Dave: Okay. The last one.

Chris: Yeah. Motten, "I work on a client site that runs WordPress. We use templates for most things but I frequently get asked to build bespoke pages, like a mini sales page or an FAQ page that's totally bespoke from the rest of the templates. Sometimes using the Gutenberg editor suffices but, for larger pages, I write them up from HTML and CSS from scratch in an editor or whatever, get it how I like it, and then I paste it into Gutenberg and hit 'convert to blocks.' I'm thinking there must be a better way to do this. I wish I could find some kind of templating system where I can create custom blocks, components, and reuse them throughout the page or even across different pages. I'm currently learning Svelte," etc. That's probably not going to happen in the Gutenberg editor.

Yeah, okay. Wants to make bespoke templates using Gutenberg and the way they do it right now is just like drop some chunks of HTML in there, which is a pretty interesting approach. [Laughter]

Dave: Yeah.

Chris: It's certainly easier than writing a Gutenberg block from scratch with React and all that stuff. I don't see a ton of people dipping their toes in that. I just need a custom block so I'm going to write an entire Gutenberg plugin to do it? Mmm, not so much.

Dave: I may be way off. In WordPress, you can make pages. What was the example? Mini-sales.php or whatever, like mini-sales-template or mini-sales-2019.php. You can write code for it and it's pretty well documented what it was for just by the file name.

Chris: Right.

Dave: You can do that. You don't have to use the Gutenberg editor.

Chris: I do that all the time. I don't know if that's old school or what, but that's how I did the series. In fact, I think it worked out tremendously well.

You need an FAQ page? Make a page called page-faq.php. Throw it in your theme. Throw the comment at the top of it that says this is a page template and this is its name.

Publish the page. Pick it from the dropdown menu. Now you have a PHP file in your theme that is totally customizable however the hell you want it to be, which is great, I think.

Dave: You could chuck in some custom fields or some blocks if you need to customize something, products, or whatever. That's how I would do it.

Chris: It does mean you're writing code and you're not editing it from the editor then. There is a theme editor in there that you could do stuff, but I wonder if the reason he doesn't do that is because, "Well, I want to be able to edit this page from the editor." I wonder if that's where this Gutenberg thing comes in. It makes me think about, you know, like in a WordPress theme, there's "The Content," which is just like blah-blap, it just barfs out whatever is in the main content field of a post or page. That's usually what I think of is that's where Gutenberg lives. It's not really a page builder because, in your templates, all the Gutenberg stuff just gets output just in whatever column you have set up for the content.

I wonder. It might be kind of cool or, if people are actually doing this--maybe they already are and I don't know--is to make a page template like we just described for an FAQ page or something, but just call it "Totally blank Gutenberg canvas."

Dave: Mm-hmm.

Chris: It's a page template and all it does it output the content. That's it. There's no header, footer, nothing. You know? Then you build. It's just a full-width thing and you build the whole page with Gutenberg blocks that way. That would be kind of cool.

Dave: Oh, man. There's a Gutenberg custom HTML block. I don't know. Maybe that's it? I don't know. Hey, I don't know.

Chris: But I get the point where it's like, then you make a block that you want that's pretty custom. Then what? You just did it once because it's just HTML. I wouldn't doubt that there's some plugin out there that's like, make a block in Gutenberg to your liking and then save it to some kind of like not temporary but just some kind of like special place where it becomes a reusable block. Then you can manage the blocks in one spot. I think that's such a cool use case that I bet that plugin already exists. I'm not sure what it is, but I bet it's out there.

Dave: Well, and I would, too, like, you've got to get into some systems thinking but figure out, like, "Oh, this is a repetition. On the sales page, it's not just this big hero thing with a custom graphic or SVG or something. Just below that, we always do those three little icon plus bullet point thing. We always do that. You've got to think, like, okay, that's going to be like, maybe I should spin that out into a Gutenberg block or something like that.

I think, to write Gutenberg blocks, you have to use React. Am I wrong in that? Am I mistaken or is there an API now like a functions.php you can write a block with?

Chris: I don't know. I don't know exactly. Can you write a Gutenberg plugin with just writing PHP only?

Dave: Yeah.

Chris: Yes, I think so, but I don't know.

Dave: Okay. We're going to redesign the ShopTalk site here, so maybe we'll get into some Gutenberg blocks. [Laughter]

Chris: Yeah, maybe. I just think if you want to do something really fancy and custom, you generally do the JavaScripting yourself.

Dave: Yeah. That's wild. It's wild how it gets in there, even. Anyway -- [Laughter]

Chris: Yeah, I think advanced custom fields has done some cool stuff too, like you use an ACF block and then an ACF block is full of custom fields and that those things then are reusable. I think they stepped up to the plate and did some cool stuff with ACF in Gutenberg, together.

Dave: Sweet.

Chris: That's all I've got.

Dave: All right. Well, cool. Hey, we should wrap it up. Thank you, dear listener. I hope you're having Happy Holly Jolly Holidays. We are going to take two weeks off. We'll be back the first week or first Monday-ish of January. We appreciate you. Hope you have fun coding. I know I've got some little side projects bugging me here, so that should be a lot of fun.

Or not coding. Literally, throw your computer in a safe. That is also a good time. [Laughter]

Chris: We have a couple of -- there have been a couple of lines coded to the new ShopTalk website, so it's real.

Dave: We've got at least six lines of code--

Chris: [Laughter]

Dave: --so we're in good shape. Anyway, there are some tricky bits that have been designed and I spent every shower mapping it out trying to figure out how to code it up.

Chris: [Laughter]

Dave: I don't know. Anyway, yeah, I hope you're having good Holidays. Don't delete us from your podcatcher because you'll need to know the show to get us back next year as we launch into another season.

If you hate your job, New Year's is a good time to get a new job. Head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

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

Chris: ShopTalkShow.com.