JS Party ā€“ Episode #39

Experimenting with some new ideas šŸ”¬

All Episodes

Jerod, Nick, KBall, and Chris pre-party for JSConf by testing out some brand new segment ideas: Story of the Week, What the WHATā€¦ WG, and Protip Time. What do you think of these segments? Like ā€™em? Love ā€™em? Not sure why we even? Please let us know!

Featuring

Sponsors

Rollbar ā€“ We catch our errors before our users do because of Rollbar. Resolve errors in minutes, and deploy your code with confidence. Learn more at rollbar.com/changelog.

Algolia ā€“ Our search partner. Algoliaā€™s full suite search APIs enable teams to develop unique search and discovery experiences across all platforms and devices. Weā€™re using Algolia to power our site search here at Changelog.com. Get started for free and learn more at algolia.com.

Indeed ā€“ Indeed is the worldā€™s #1 job site with a mission to help people get jobs. They need talented, passionate people working together to make this happen. Learn more and take the first step to working at Indeed at indeed.jobs/changelog

Fastly ā€“ Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com.

Notes & Links

šŸ“ Edit Notes

Story of the Week

What the WHATā€¦ WG

Protip Time

paste {
 pbpaste > ${1}
}

copy {
 cat ${1} | pbcopy
}

Transcript

šŸ“ Edit Transcript

Changelog

Play the audio to listen along while you enjoy the transcript. šŸŽ§

Hello, world! This is JS Party, where weā€™re throwing a party every week about JavaScript and the web. My name is Jerod Santo, and hey, itā€™s the pre-party this week for next weekā€™s live party at JS Conf. If youā€™re going to JS Conf, do not miss it; we will have four awesome JS Party panelists live at lunch hour on Tuesday, August 21st.

If youā€™re not going to JS Conf, well, I guess emoji sad face; youā€™re in the same group as me. I sadly will not be there, but KBall, Nick, Suz and Feross will be live on stage. Do not miss that.

But we have a show for you today, and as always, awesome panelists. Welcome back, Chris! Whatā€™s up, Chris?

Hello! How are you doing?

All good. Nick Nisi is hereā€¦ Whatā€™s up, Nick?

Hello!

Tell the people all youā€™re doing at JS Conf next week, so we can all pity you.

[laughs] Well, Iā€™m part of the JS Party live panel, and then immediately following that, Iā€™m doing a Track B talk. The title is No Time For Types. Itā€™s secretly about TypeScriptā€¦ Then Iā€™m also there with the TalkScript Podcast, doing interviews.

So very busy and nerve-wracking, of courseā€¦ KBall is also here. KBall, youā€™re gonna be running the JS Party show next week. Whatā€™s up, man?

You got it! Iā€™m excited to be MC-ing that JS Party live, and then Iā€™ll also be interviewing folks for JS Party. If youā€™re gonna be there, especially if youā€™re a speaker, but even not, if you have something awesome you wanna talk about, come find me in the hallways.

There you have it. So for this show today we have a few new things; we always like to experiment here on the show, and find out what works well, what doesnā€™t work wellā€¦ You know, that old-fashioned iteration that we developers love so much. So Iā€™ve kind of ginned up a few new segments that weā€™re gonna give a try. If you like these, let us know. If you think these are the worst ideas ever after having listened to them, please tell us. We want a show that is good, not necessarily a show that is just new and unique.

[03:48] Weā€™re gonna try out a few different things this week and see how it goes. The first segment we are calling Story of the Week. Now, the way this works is we have all found different stories around the ecosystem throughout the week, maybe even going back a little bit further than a week, no big dealā€¦ But whatā€™s the biggest thing that happened this week or the most important news? Maybe just to you personally, maybe for everybody involved.

We will all share a new story, and we will try to convince one another why itā€™s a big deal, why itā€™s important, why perhaps itā€™s the story of the week. So letā€™s give it a shot, Nick, you are up first, my friend. Whatā€™s your story of the week?

Mine is probably one that falls in the ā€œnot actually this weekā€ part, because I was really struggling, it seems like a slow week, in the JavaScript world at least. So I was going back through the recent things that were popular on Twitter, and I found this tool ndb by Google Chrome Labs on GitHubā€¦ Itā€™s an npm module that you can install that vastly improves debugging Node with the Chrome DevTools.

If you havenā€™t done that before, itā€™s really cool. I think we might have talked about it on a previous episode, butā€¦ You can type in nodeā€“inspect-brk or ā€“inspect and then give it a command to run, or a file to run in Node, and it will give you a link that you can paste in the Chrome DevToolsā€¦ Chrome Canary at least also immediately puts a dedicated Node DevTools button in your DevTools, if you have that open, so thatā€™s pretty cool. Completely unrelated to this, what this is is a Node module that will streamline that process for you a little bit. It will automatically open up the Chrome DevTools and you can actually open it for your project. So you can just say ndb, space, period, and it will open it up for that project. And I donā€™t know if itā€™s broken or if Iā€™m not running it correctly, but it actually lists out all of the scripts from my package.json in there, with a little Run button next to them, but when I try and do that, I canā€™t actually get it to runā€¦ So Iā€™m not sure if thatā€™s just broken the way that I had it, but if that works, that would be really cool, because Iā€™m constantly having to go look up what scripts are actually available in whatever projectsā€¦ And just having them listed there and immediately being able to run them is kind of like a ā€“ a dashboard that also does the debugging would be really cool.

And then finally, the big thing that this does thatā€™s way better than just running Node with the ā€“inspect flag is, typically, Iā€™ll want to debug scripts. Iā€™ll want to actually be running Ts-node, or Iā€™ll wanna be running Gulp or Grunt or something, and I wanna be able to debug thatā€¦ And if you wanna do that with Node, you have to run Node and then point to the binary for thatā€¦ So like, Gulp, youā€™d have to go look in your Node modules directory, in the ./bin directory, the Gulp script there, and then it will run for that and you can set breakpoints in there.

This will just automatically let you say ā€œndb gulp testā€, or whatever. It will immediately set that up, and it sets up watchers for all of the child processes that might get kicked off in there.

The other cool thing that it does is it ā€“ anything thatā€™s not in your sources directory, like anything thatā€™s in your Node modules, for example, it black-boxes that by default. That means that when youā€™re looking at a stack trace, you donā€™t actually see the code from your Node modules directories, you just see the code that youā€™re actually running and debugging, and you just kind of assume that the Node modules are correct.

Iā€™m just looking at this now, and this thing actually looks pretty cool. At first, I was like, ā€œWell, whatā€™s the difference between this and just using Chrome DevTools?ā€, but it looks like it definitely streamlines things. If you want to debug tests, say, in Mocha, and you wanna do that with Chrome DevTools, you have to call the ā€“ not Mocha executable, but the _mocha executable, because this is a child process that Mocha launchesā€¦ And you canā€™t just attach to Mocha, because the inspector wonā€™t know that youā€™re actually running your tests in the child processā€¦ But if this thing actually works - I havenā€™t tried it, but Iā€™m looking at the interfaceā€¦ Yeah, thatā€™s awesome. This is really going to make things a lot easier for a lot of people.

[08:14] Yeah, definitely. And I love that itā€™s Google Chrome Labs, so itā€™s - I would assume - going to be well supported going forward.

I donā€™t know if you can assume that from Googleā€¦

Like Google Reader? [laughter]

Yeah, good point.

Uuuh, salt in the wounds. It still hurts.

Yeah, too soon, Jerod.

Too soonā€¦ Itā€™s been like five years.

I am curious what theyā€™re using Puppeteer for. I assume itā€™s just to launch the browser, and then basically launch DevTools and fiddle with DevTools, and stuff like that. Thatā€™s pretty neat.

Yeah, this is really cool. I installed it, and it took a few seconds, and it works, and itā€™s pretty awesome, soā€¦ Thanks.

Alright, Nick. It sounds likeā€“

So far Iā€™m winning.

You might have one vote for Story of the Week there, as Chris might be voting for you. Chris, what did you bring to the table here? Whatā€™s your story of the week?

Yeah, slow weekā€¦

It really was.

You know, Babel 7 is going to be released very soon, and if you havenā€™t been keeping tabs on whatā€™s happening there, the big thing that people are probably going to get up in arms about is that Babel is deprecating the stage modules. So you canā€™t go in in Babel 7 and say ā€œInstall Babel preset stage 3ā€, or whatever. Theyā€™re not gonna support those anymore.

Theyā€™re going to basically expect you to more or less figure out which features you needā€¦ I think it sounds like babel-preset-env will help with thatā€¦ But it sounds like theyā€™re encouraging people to make their own presets. The rationale - and thereā€™s a blog post on their site (babeljs.io) where Henry talks about ā€œWell, this is why we are deprecating stages.ā€ One of the reasons is that people will be like ā€œHey, how can I use feature X?ā€ and then somebody will say ā€œOh, use Babel preset stage 0ā€, or something like thatā€¦ So people install Babel preset stage 0, and they donā€™t really know what theyā€™re getting into. For those that also donā€™t know, stage 0 contains features that have not been approved for the JavaScript spec, and may not ever be approvedā€¦ So theyā€™re very experimental, and if youā€™re using that in your production code, you may have kind of coded yourself into a corner, because those features that you may be using - you might need to back those out at some point.

So Babel doesnā€™t want this to happen, because I think they feel like they are partly responsible for people doing this, because theyā€™re making it essentially too easy to shoot yourself in the foot. So theyā€™re gonna drop these presets, and if you need a feature, you have to go and basically add the plugin, or (again) create your own preset.

So thatā€™s kind of a big changeā€¦ There is a tool that they wrote to help you upgrade to Babel 7 from (I assume just) version 6, where they probably will go and see which stage presets youā€™re using, and actually go and change all your stuff to use the individual plugins.

[12:17] It does stuff like ā€“ thereā€™s all sorts of things. It changes a bunch of dependencies, it modifies ā€“ if youā€™re using Babel with Mocha, it will find that in your package.json, which is really neat, and itā€™ll change some of the module names.

Theyā€™re now going to publish all of their modules, because you know, thereā€™s hundreds of Babel modules. Theyā€™re gonna use the @babel scope namescape now at npmā€¦ So youā€™re gonna be using that, instead of babel-loader, or whatever, babel-register, youā€™re gonna use @babel/register.

So thereā€™s all these things that theyā€™re working on to help you migrate, but once youā€™re thereā€¦ Yeah. I havenā€™t read anything that people have written, but I assume somebodyā€™s going to get really upset at thisā€¦ I hope they donā€™t, but things happen. So heā€™s gonna write this big thing about how this is the wrong thing to do, and it makes everything really difficult, and it was already difficult, blah-blah-blah.

I wanna see how this shakes up, but I agree with the direction theyā€™re heading, even though it maybe makes things a little more ā€“ it makes you think a little bit more about how youā€™re using Babel in what youā€™re doing, and I donā€™t think thatā€™s a bad thing.

Questionā€¦ You said theyā€™re going to release soon, and I just googled for ā€œ7.0 Babel releaseā€, or ā€œBabel 7 releaseā€ and I see articles going back a year saying ā€œWeā€™re nearing the releaseā€¦ā€, so whatā€™s different this time? How do we know theyā€™re actually releasing soon?

[laughs] They just keep saying it.

Well, so thereā€™s been betas for quite a while, and now theyā€™re at like rc2, or whateverā€¦ I mean, itā€™s being actively developed. I donā€™t know. It seems like itā€™s coming pretty soon to me, but it sounded like from the release notes that they donā€™t intend to make any more changes, they donā€™t intend to add anything or fix anything necessarily. Unless thereā€™s some last-minute critical deal, it sounds like theyā€™re gonna release soon. I donā€™t know, but it sounds like it from the changelogs.

Itā€™ll be good to get this out, for sure. Itā€™s been confusingā€¦ The website specifically has been confusing for me for a little while now. If you go to the Docs section of babeljs.io, under Tooling it talks about all of the different modules that they have, including Babylon, but you click on that and it just takes you to a 404 on the live page right nowā€¦ But if you switch over to the pre-release docs, then itā€™s a Babel parser and it does correctly point you to that.

So Iā€™m excited for this to get out, so that things become less confusing around all of this tooling.

Yeahā€¦ I mean, people are still gonna be using Babel 6, and theyā€™re probably gonna be looking for the documentation and have trouble finding it, butā€¦

Sure.

Again, Babel, as far as I know, doesnā€™t have any corporate sponsorship directly. Itā€™s pretty much Henry and some other people that are volunteering their time to work on it, so I assume they donā€™t have a whole lot of resources to do things like keep old documentation up to date.

Sure.

I sympathize, butā€¦ yeah.

[15:53] Definitely sympathize. I thought they did have some success, at least, on Open Collective, in terms of corporate sponsorship, but surely nothing thatā€™s driving full-time ā€“ well, maybe they are. I donā€™t know.

I think Henry has a Patreon, or somethingā€¦ Heā€™s basically working on open source full-time now. But you know, you can have all the money in the world, and if you donā€™t have ā€“ you know, thereā€™s 24 hours in a day, so if youā€™re the only person working on it, thereā€™s only so much you can do. Or if people donā€™t have time to dedicate, you can be flushed with cash and not be able to get much done, because you know, timeā€¦

It keeps on slipping, slipping, slippingā€¦ Thatā€™s for you, KBall.

Ainā€™t that rightā€¦?

Into the future, speaking of Kball - hey, your turn, man. Whatā€™s your story of the week?

Yeah, so the thing I wanted to talk about was thereā€™s been a resurgence of interest and focus on JavaScript performance, and in particular JavaScript load and parse performance. We had all this stuff about, okay, is React making it faster to update the DOM? Or how fast are these things to do a lot of updates? But weā€™ve also gotten into this world where everybodyā€™s just adding more and more JavaScript, and there hasnā€™t been as much attention on what the impacts of load and parse time areā€¦ So weā€™re coming back around. That used to be a huge issue, then people forgot about itā€¦

Coming back around to it, Iā€™ve seen a ton of articles in the last few weeks looking at this. I think the one that sparked it was Addy Osmani from Google did an article on the cost of JavaScript in 2018 that blew up, and he sort of talked a lot about how expensive it is, particularly on less than cutting edge devices. Then thereā€™s been lots of follow-ons - how do you do this? Is code-splitting good enough? What sort of other thingsā€¦?

Another article I saw on this that I thought was really interesting was looking at the impact of the push to make everything HTTPS, and the fact that that essentially kills your ability to create local caching servers, because local caching servers are essentially the man in the middle. So itā€™s better for security, but this article was highlighting ā€“ he did something in rural Uganda, and their connection to the internet is a satellite internet access, so thereā€™s a ping latency of half a second, and lots and lots of draft packets, so not being able to have a local caching server essentially kills their ability to access the internet for a very large number of things.

There are pros and cons to this, but it got me thinking a lot about the people who are not in the first world. This has come up before on the podcast; this last week I was in Costa Rica; T-Mobile lets you access data for free if youā€™re on one of their main plans, from like 100 countries, but the speed of access in Costa Rica is like 2G. So Iā€™m on a fast phone, Iā€™m on an iPhone, but I had 2G internet, and it was amazing how slow things wereā€¦ Just appallingly bad, and it reminded me how much you get used to bandwidth feeling essentially free; things are so fastā€¦

So this resparking of the interest in ā€“ you know, we actually need to cut down, we need to have a JavaScript budget, we need to think about the impact of all of these millions of libraries weā€™re pulling inā€¦ Code-splitting is a nice thing and our tooling is improving for that, but having all of these things front of mind when weā€™re developing, if weā€™re developing things that are not just for folks who are in countries with ridiculously fast internet accessā€¦ Which the U.S., even though ā€“ well, actually I donā€™t know about the rural parts of the U.S. Certainly in California, even with just mobile access, itā€™s ridiculously fast. 4G LTE is wicked fastā€¦ But not everybody has that.

[20:18] Yeah, this is something thatā€™s been on the top of my mind recentlyā€¦ We had Ben Halpern on The Changelog this week, talking about dev.to, which is a developer community platform he founded; you may know him as @ThePracticalDev on Twitterā€¦ And heā€™s taken huge steps to make dev.to very fast, but not just fast in the Americas, but fast all around the world. Heā€™s really leveraging CDNs in order just to bring his content as close to the users as possibleā€¦ And it made me rethink a little bit of some of our architecture. We try to make Changelog.com as fast as possible and as accessible as possible as well, and I think weā€™re doing a pretty good job on that, but we definitely have the speed of light problem, having America-based server, and we can serve those pages really fast, but latency is just something we cannot solve. Of course, we CDN all of our assets, but Iā€™m referring to rendered pages.

So something thatā€™s very important, and often - like you said, Kevin - we just donā€™t think about it very much, maybe because weā€™re on fast networks, but also maybe because weā€™re just geographically close to AWSā€™s us-east-1, where most of the internet gets served from, right?

Right.

Okay, for my story of the week - Vue CLI 3.0. And as has been said a few times, this was probably a bad week to try out this segment, as there hasnā€™t been huge news in our space this weekā€¦ But definitely some releases, definitely some stuff going on, conversations being had.

One of the big releases from August 10th, which is pretty close - I guess thatā€™s this week - was Vue CLI 3.0. Evan You writing on Medium about the release says that itā€™s a completely different beast from its previous versions. This is the command line interface thatā€™s built into Vue or provided with Vue, specific for that toolset. This is a trend that weā€™ve seen really started I think by the Ember team years ago, having Ember CLI, and weā€™ve seen it kind of matriculate across to all the different frontend frameworks; React has one, Angular has one, now Vue has one, and of course, this is 3.0, so the CLI is not new, but the guts, the feature set, all these things are brand newā€¦ And some cool stuff going on.

The goal of that rewrite that they did was twofold. The first one was to reduce configuration fatigue of modern frontend tooling, which I think we can all agree ā€“ maybe JS fatigue isnā€™t a thing, but configuration fatigue is definitely a thingā€¦ And this is especially when theyā€™re mixing multiple tools together, which is what tends to happen on the frontend.

Then they wanted to incorporate best practices in the toolchain as much as possible, so it becomes the default for any Vue app. Thereā€™s a lot more detailsā€¦ One of the big things that I noticed was that they preconfigured Webpack features. All that stuff ā€“ you know, if youā€™re gonna preconfigure Webpack for me, Iā€™m just gonna give you a big fat kiss, because Iā€™m gonna love thatā€¦ Because I donā€™t wanna configure Webpack.

Theyā€™ve preconfigured hot module replacement, code-splitting, tree-shaking, efficient long-term caching, error overlays etc. So all the good stuff there, ready for you to go. The cool thing about this is theyā€™ve been very cognizant of developersā€™ need to tweak those configurationsā€¦

What happens a lot of times when you have tools that kind of wrap other tools is they will hide, they will sweep all of the complexity under the table, which is what we want, right? Because we donā€™t wanna deal with the complexity; we wanna provide a better experience. But then when it comes time and you actually get to using it and you actually need to reach underneath the table and tweak that thing, you either have to eject, which is basically say ā€œOkay, Iā€™m no longer going to stick with this tool. Iā€™m going o stop the world and fork it, or vendor itā€, or something like thatā€¦ Or you just donā€™t have the option; you just canā€™t reach underneath the hood and tweak things as you will.

[24:17] So theyā€™ve taken great pains to make this configurable, with no need to eject, which I know is hard to do, and an admirable goal, soā€¦ Hopefully theyā€™ve achieved it. It definitely looks very good. Weā€™ll link up the announcement post. This seems like big news. Iā€™m not a Vue user; KBall, I thought maybe I would steal this one from you when I put it into the document, because I know youā€™ve been using Vue quite a bit lately, and I thought maybe this one would be on your radarā€¦

Yeah, thereā€™s actually something pretty interesting about it too that you didnā€™t cover yet, which is that it adds a GUI access to a lot of the CLI pieces. So it gives you within the ecosystem ā€“ like if youā€™re installing plugins, normally you just do that on the CLI, npm etc; it lets you do a lot of that stuff from a GUI and manages the configuration, and updating your package.json and all that sort of thingā€¦ Which to me personally - I couldnā€™t care less, because Iā€™m a terminal guyā€¦

Yeah, me too.

But one of the things that Vue has historically done very well is making this advanced JavaScript framework feel accessible to people who do not consider themselves hardcore coders. Itā€™s way easier if youā€™re coming from a design background, itā€™s way easier if youā€™re coming from less of a coding background. Folks routinely say they can pick up Vue far faster than if they try to do React, or somethingā€¦ And I think this is leaning into that trend as well, of saying hey, a huge part of what youā€™re doing with a non-trivial application is configuring and pulling in plugins; letā€™s make that more accessible to folks who are newer, to folks who are more visually-oriented, to folks who donā€™t live in their command line.

Yeah, that is very cool, and definitely a blind spot for me, as also a command line junkie. I didnā€™t even pick up on the GUI in the post. I mean, I saw it, but I was like, ā€œOh, thatā€™s cool-lookingā€, but I didnā€™t think about it very much. So that is definitely great for accessibility and really for making more difficult things easier, which is what weā€™re definitely trying to do as library and framework authors. Very cool, check that out.

As for my pitch - I wanna pitch this as the story of the week, and hereā€™s my two reasons. The first one is 15,000 claps on Medium, soā€¦ A pretty big deal. Secondly, Iā€™ve found this ā€“ although we did log it on Changelog News, but I was reintroduced to this by basically going to the r/javascript and sorting by Top, and then setting Week as my filter. So thereā€™s a life hack if youā€™re ever going to be on Story of the Week againā€¦ And this was number one, so I think itā€™s pretty much unequivocally the story of the week. Sorry, guysā€¦ I think I win. [laughter]

Can I give a pro tip on finding stories, too?

Yes, please do.

Thereā€™s this tool called Nuzzel, and you OAuth into it with Twitter, and it looks at your Twitter timeline and what everybodyā€™s posting and then it sorts links by the ones that are talked about the most on Twitter. I used that to find ā€“ and I had to go back a little ways to find ndb, but I did find it.

Now weā€™re giving up all of our secrets, and someone else is gonna start their own Story of the Week podcast and totally dominate us.

Can I give a little slightly self-serving story or pro tip on this?

What if I said no? Just kidding, go aheadā€¦ [laugh]

Then I wouldnā€™tā€¦

Please do. [laughs]

So the slightly self-serving pro tip is if you sign up to the newsletter that I publish, youā€™d see a lot of this, like that UI piece of the CLI, in the last episode of July, was in my newsletter, soā€¦ Itā€™s a little self-serving, but if you go to zendev.com/fridayfrontend.html you can sign up and you hear about all of this every Friday.

But then you wouldnā€™t have to listen to our podcast anymore.

No, we do so much more cool stuff.

[laughs]

Okay, next up we are going to do a segment called WHATā€¦WG. Iā€™ll just say that again, because itā€™s fun: WHATā€¦WG. The idea here is that we are going to discuss some of the stuff that WHATWG has been up to lately. For those who donā€™t know what the WHATWG is - it stands for the Web Hypertext Application Technology Working Groupā€¦ Which is why they use an acronym, because nobody wants to say that five times fast.

Itā€™s a community of people interested in evolving the web through standards and tests. Now, thereā€™s kind of an in and out between the WHATWG and the W3C or the Worldwide Web Consortium, who does what and why, and when and howā€¦ So before I get into some of the standards that the WHATWG are working on, KBall is gonna explain to us a little bit - as much as you can, KBall - some of the history there, and really what the difference is between the two, and all the ins and outs. Help us out.

Yeah, so I started researching this when you brought up WHATWG, because Iā€™d seen a little bit flow by as you were reading stuff, of like controversy, like ā€œWHATWG and W3C fighting about this or thatā€, or people trash-talking one or the otherā€¦ So the history is related to XHTML. W3C started going down the road of XHTML and XML that is very rigid and unambiguous, and they started pushing more and more in that direction, and the browser vendors basically said ā€“ instead of WHATWG, they said WHATTH. This is going to break backward-compatibility, which is the key value prop, or one of the key value props of the webā€¦ Itā€™s that anybody can throw this stuff up and it just keeps working.

So in 2004, a bunch of browser vendors kind of banded together and said ā€œWell, you know what? Yā€™all are failing us, because youā€™re trying to do this in a way thatā€™s not gonna keep the value prop of the web. Weā€™re gonna create our own specification.ā€ And they kind of tried to work together, but they had very different approaches to it. W3C likes to kind of create frozen specifications. So if you remember the whole ā€œWeā€™re gonna have HTML5, and thatā€™s gonna be the new version of HTML5 and itā€™s gonna be frozenā€ - that was what W3C wantedā€¦ And WHATWG said, ā€œYou know what, weā€™re changing all the time. This should be a living standard. We should be constantly evolving it.ā€ So theyā€™ve kind of split in different ways, and the split was a little bit ā€“ this was a bad breakup, in a lot of waysā€¦

[32:22] Well, breaking up is hard to do.

Breaking us is hard to doā€¦ If you start looking through forum stuff or GitHub issues or things where the standards are being debated, thereā€™s a lot of bad blood, as far as I can tell.

Thatā€™s too bad.

What seems to happen now, according to WHATWG, and this is a direct quoteā€¦ ā€œThe W3C publishes some forked versions of our specifications. Weā€™ve requested that they stop publishing these, but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes and sometimes unintentional changes to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.ā€

Wowā€¦ Talking about bad blood.

Yeahā€¦ But the vast majority of the work - for HTML in particular - seems to be happening at WHATWG, and while W3C keeps publishing updates, they appear to be primarily bad forks of the work that WHATWG is doing.

So WHATWG is worth watching and paying attention to is mostly people working for the browser vendors. A lot of these times, specific vendors will add features - and weā€™ll talk about one of those here soon with auto-capitalize - and they will add it to their browser and put it out in the wild for a while, and kind of prove it out as something thatā€™s useful or good for whatever reason, and then the WHATWG will go back and standardize around that if everybody agrees that that is something worth standardizing around.

Itā€™s interestingā€¦ Weā€™re talking about bleeding edge - itā€™s not that bleeding, because some of these things already exist in certainā€¦ You know, ā€œOnly in Chromeā€ or ā€œWorks best in Edgeā€, that kind of thing. But as we see specific features and changes formalized and turned into specs, then the other browsers are more likely to add it as well.

So whatā€™s interesting, especially if youā€™re gonna stay up on like the new stuff going into the web platform, is to find out what the WHATWG is working on, or at least considering, and then also what has been added as of recent.

With that in mind, letā€™s talk about a couple of things here. The first one is the one thatā€™s really been on my plate lately, which is why Iā€™ve been thinking about this, and I was excited to find out that it might be coming to browsers soon, which is lazy-loading images and iFrames.

Now, if youā€™re on Lighthouse or any sort of performance tool, one of the very first recommendations they will say is you should be lazy-loading off-screen images. For example, Changelog.com has a whole bunch of avatars and images on the news feed or news items that you may never scroll down toā€¦ And when you load our page, the browser is going to go down and fetch all of those images into the page, no matter whatā€¦ Unless you tell it not to. Unfortunately, thereā€™s no built-in way to tell it not to. You have to basically do some JavaScript, which I think is a very big hack, which includes not adding the src attribute to your image tags until the JavaScript adds it for you, basicallyā€¦ And thereā€™s lots of ways of doing this; the most modern way is to use Intersection Observer, which as weā€™ve learned lately, has some issues, as well. But this is something that pretty much every website wants to do in terms of performance - we have 75 images, and the user has only seen three of those. Do not waste time and bandwidth downloading all those images.

[36:14] Iā€™ve been complaining for a while now, as I want to do - just to complain, mostly to Adam and other members of the Changelog development teamā€¦ Why is this not a browser feature? Every browser performance tool says ā€œYou should be doing this.ā€ Pretty much every website wants it, and then everybody has to go implement it for themselves, which sucks.

Jerod, you said you had to do it with some sort of observer, or somethingā€¦ Is that what you said? Intersectionā€¦

Yeah, Intersection Observer is the most modern way of doing this, so basically using that API, which is in modern browsers, to detect when an element or an image comes onto the viewport. So instead of loading them all, you wait until theyā€™re on-screenā€¦ So Intersection Observer is a way of detecting when something has come into the viewport or is close to the viewport, and so then it will go out and grab the image.

Basically, what it does at that time is it takes the data-src attribute, which is the URL of the image, and it just sets it as the sourceā€¦ And the browser goes ahead and does that.

So thatā€™s a modern way of doing itā€¦ People have been doing this for years, because like I said, everybody has to or wants toā€¦ And Iā€™m not sure how they used to do it. KBall, do you know how older implementations of lazy-load would detect on-screen elements? Or maybe they would just defer the loading ā€“

You do it basically the way that the polyfill for Intersection Observer works, which is you literally check over and over again, ā€œIs this thing in my viewport?ā€

Which yeah, thatā€™s what you setā€¦

Yeah, you set up an interval, and it just checks every now and then.

There we go. Yeah, because Intersection Observer ā€“ Nick just linked to it there in the chatā€¦ If you go to Can I Use, youā€™ll find that itā€™s on most modern browsers. I think maybe Mobile Safari and Safari are the ones that itā€™s not on; I donā€™t rememberā€¦ But you have to use a polyfill if youā€™re gonna use the modern wayā€¦

Wouldnā€™t you just pull like on a scroll event, or something? Or, first, is there a reason to do that all the time?

Yeah, you can do thatā€¦ But you still need to debounce, soā€¦

The overarching theme here is itā€™s a lot of work, and everybody needs to be doing it, so thatā€™s prime candidacy toā€¦ Do you know who knows the best in terms of like when a user would desire an image to be actually fetched? Probably the software closest to the user; probably the browser itself. Thatā€™s my take.

Thankfully, the WHATWG has been working on this, and thereā€™s a draft spec.. If you are on the GitHubs, itā€™s on the WHATWG Organization HTML repo, and itā€™s pull request 3752. Weā€™ll link that up if you wanna read it. You dive into the details here and you realize why these things donā€™t necessarily move very fast, because thereā€™s so many different things for them to considerā€¦ So itā€™s a very active process, but there is a draft spec for lazy-loading of images and iFrames built right into the browsers. So basically, what youā€™ll do is add an attribute to your images - I think itā€™s like lazy-load=true, or thereā€™s a few different things you can do in order to control itā€¦ But itā€™s something that is coming and is not here quite yet, but it is actively being worked on, so that in an unknown future, we wonā€™t have to be working quite so hard to do this for people.

Jerod, do you know how they manage the ongoing split of things between W3C and WHATWG? Because HTML ended up in WHATWG, but CSS is in W3C working groups, and JavaScript things seem to be split randomly across the twoā€¦ [laughter] Do you have any sense of like whoā€“

[40:10] Yes, I donā€™t know the politicsā€¦ I feel like maybe if we had Feross on this episode, or maybe even Alex would know the actual split-out. I know what WHATWG works on - like you said, HTML, the DOM, Fetchā€¦ These different things; they have a list of like ā€œThese are our territory. URL streams, storageā€¦ā€, and then like you said, CSS is on the W3C side; Iā€™m not sure what else is on the W3C sideā€¦ But you would think that you would want all of these things to be worked on together, because why have CSS in a silo? It seems like thatā€™s not goodā€¦ But no, I do now know why or how that all shook out.

Well, and different JavaScript are split across the two, I thinkā€¦ Audio APIs and things like that are in W3C, but XHTML requests are in WHATWG; the notifications API is WHATWGā€¦ Yeah, it seems pretty random from the outside.

Yeah, and itā€™s very opaque as well. As I proposed this segment, like ā€œHey, letā€™s talk about what theyā€™ve been up to and what theyā€™re doing, because I think thatā€™s helpful to shine a light on.ā€ At least people know ā€œOkay, lazy-loadā€¦ Hey, itā€™s coming soonā€, or ā€œThis stuff gets rejected.

One of the things Chris asked was ā€œWell, how do you even do that? How do you even look at it?ā€ and basically, youā€™re just scrolling ā€“ in terms of the WHATWG, youā€™re just going through GitHub issues and clicking on different tags, like addition/proposal, seeing whatā€™s been merged, seeing whatā€™s been going on, some things were approvedā€¦ Lots of discussion going on. This could be like a full-time job to participate in, and I think a lot of the people who are participating - like Jake Archibald, for instance - work at like web platform teams for Google, for Apple, for Microsoftā€¦

So it really is a full-time job by multiple people to do these things.

Iā€™m just going through their listā€¦ They have a spec on Quirks Mode. It includes such fun things as defining quirky colors, and quirky lengths, and all these otherā€¦ Basically, backwards-compatibility things for really old HTML, or really old CSS.

Sounds fun.

They also have a console spec, and I didnā€™t realize that that was actually a specā€¦

Yeah, I noticed that as well, and I was kind of scrolling through the different areas to see what has the most activity in terms of the WHATWG organization, and the console one is like ā€“ thereā€™s just nothing; itā€™s like tumbleweedā€¦ A lot of them ā€“ like, the Fetch one has some activity, then the Quirks Mode one is completelyā€¦ In terms of people proposing things, talking about things, merging docsā€¦ And then the HTML and then the Fetch and a few of them are super-active. They do have a Console Working Group, or whatever itā€™s called, but thereā€™s just not much activity going on there.

One other example I wanted to pull in - we had the image lazy-loading, which is a proposal; it has a spec drafted, itā€™s not there yetā€¦ Who knows, it could be years maybe before these things are found in enough browsers to use themā€¦ But hereā€™s an example of (I guess) the process working, which is the autocapitalize attribute. This is one thatā€™s been mergedā€¦ Weā€™ll link to this as well if you wanna read through everything yourselfā€¦ But itā€™s past tense - itā€™s been merged; itā€™s even on Mozilla Developer Network Docs, all that kind of stuff is finishedā€¦ And itā€™s kind of cool watching the way this works.

The autocapitalize attribute is in iOS, specifically on input fields. You can set autocapitalize equal to true or whatever the values are, and it will instruct the deviceā€™s keyboard to capitalize first words and whatnot on behalf of the userā€¦ Because on mobile devices - you know, these things are more cumbersome.

[44:13] So Apple just added that. They didnā€™t ask anybodyā€™s advice, they didnā€™t put it out there as ā€œThis is something everybody should do.ā€ Theyā€™ve just put it in iOS, and I think itā€™s been there for yearsā€¦ But it doesnā€™t exist anywhere else; itā€™s just there. But iOS is a big enough market share, and so therefore Mobile Safari has enough people using it that it became something that the developers have been adding to their sites. Does anybody use this attribute or had to deal with it?

Noā€¦

Not yet, but I hate itā€¦

[laughs]

Yeah, I hate it when I run into ā€“ actually, itā€™s not true that I havenā€™t used it. I have used it to say ā€œautocapitalize=falseā€

Yes, turn it off.

ā€œTurn it off, Apple. Itā€™s terrible!ā€

So hereā€™s where Iā€™ve also turned it off once, and specifically on email fields, where theyā€™ll autocapitalize the first letter of an email address, and if your site isnā€™t set up to normalize those or downcase them before searching, it wonā€™t find the user because you have case-sensitive searching, or something like that.

So yes, it can be annoyingā€¦ But now it can be annoying in all the browsersā€¦ [laughter] Because it has been merged into the WHATWGā€™s HTML spec. Iā€™ll just read this comment on it, because I think itā€™s instructive of how these things shake out. This is a member of the Chrome team. He says:

ā€œThe Chrome team is currently attempting to update our implementation of the autocapitalize attribute in Chrome for Android (currently a non-standard extension introduced by apple), to match the behavior of iOS Safari, specifically to add support for autocapitalize on editable regions, inheritance from the form owner for in-text area elements etc.

As part of this work, we would like to standardize this attribute in the HTML spec. The goal with the spec change is to document iOS Safariā€™s behavior, so ideally, Apple wonā€™t have to make any changes to their implementation, so that other browsers such as Chrome or Android can implement the attribute with the same behavior.ā€

This is how this process happens - often, I think; or at least I heard it happens often - and hereā€™s a good exampleā€¦ Somebody goes out and implements a thing - in this case Apple. We know Chrome leads the way on many new features, some of which end up getting into other browsers, some that donā€™t, sometimesā€¦ Speaking of Apple, a lot of times Apple is the last to hold out on specific features that lots of us developers want.

But in this case they added it, and despite the three of us - I donā€™t know Chris if youā€™ve dealt with this, being on IoT and back-end mostly - not liking it and turning it off, apparently it serves a valid use for enough users that this is something that they decided to formalize around.

So the goal here was not to make Apple change their behavior, because probably they wouldnā€™t do it anyways, but to just say ā€œOkay, this is a feature that we think should be in all browsers, and Apple has led the way, so weā€™re just going to formalize a specification, basically using exactly the way that Apple has implemented it.ā€ So they moved forward with that, they all got in agreement, you can read all the comments, and it rolled out.

Interesting just seeing the ins and outs of such a small thing. Itā€™s a single attribute on a few element types, and 40 conversations here, 6 commits to get this thing mergedā€¦ So a lot of work going in behind the scenes that I think maybe we take for granted, maybe we get mad about, but a lot of effort involved in even the smallest changes to these issues.

The improvements in the way that we deal with specifications and updates and the fact we now have browsers that are evergreen and are all (more or less) collaborating - I feel like that is an under-noticed reason why the web has become so powerful. Weā€™ve gotten so much better as an industry at working together to improve these thingsā€¦ But it is often just behind the scenes.

[48:11] Good point. Yeah, itā€™s definitely gotten better, and I think the workflows specifically around GitHub - a lot of these things have been transparent for a long time, but thereā€™s something about a common platform that everybody knows how to use and is very accessible that makes them more transparent.

I would have never in the past dug into this stuff, but the fact that itā€™s like ā€œOh, just the GitHub issuesā€¦ Start reading them. Hereā€™s the labelsā€¦ā€ - it all is very familiar; I feel like the transparency and the ā€“ even though theyā€™re driven very much by the big players, the ability for people to get involved is better than ever.

Alright everyone, it is now Protip Time. This is where we share our pro tips; itā€™s pretty straightforward. Whether or not weā€™re actual pros, thatā€™s for you to decide. These could be life hacks, they could be lessons learned from doing dumb thingsā€¦ Not that you would do that, but I surely have done some dumb thingsā€¦ And letā€™s share them, so other people can learn and perhaps take away things and avoid fails, if possible.

Chris, pro tip time.

I have some pro tipsā€¦ I use a Mac. If you use a Mac, maybe a thing you need to do is copy and/or paste text files (source files or what have you) in their entirety. I discovered not too long ago - maybe this is one of those things that everybody knows except me, but I discovered that there were actually a couple command line tools that come in Mac OS that help you do just this thing. They are pbpaste and pbcopy.

[52:16] Pbpaste outputs to a STDOUT. It takes whatever is in the clipboard, and it sends it to STDOUT so you can pipe it to whatever you wanna pipe it to. Maybe you wanna pipe that to a file, and so if you copy some source and then you go to your command line and you say pbpaste, and then you do a write ā€“ I donā€™t even know if thatā€™s less than or greater than [laughs], but youā€™re piping to the right with the direction, and you say foo.jsā€¦ It will paste the contents of your clipboard into a new file, foo.js.

I wrote a little tiny Zsh function called Paste, which does just this - it takes its first parameter and it says ā€˜pbpasteā€™, and it writes to this new file. So I say ā€˜paste foo.jsā€™, it takes whatever is in my clipboard and throws it in a new file, foo.js.

Likewise, pbcopy - you can cat a file and then pipe it to pbcopy and that fileā€™s content will end up in your clipboard. Again, I wrote a little function to help with that, so it just accepts its first parameter, and it cats it (this file) and it pipes it off to your clipboard, which is really cool.

Along the same lines, thereā€™s another little thing called z, and people may or may not know about z; maybe weā€™ve talked about z before, I donā€™t knowā€¦ But thereā€™s this command line tool for your shell called z. Just search GitHub for z.

It basically looks at all your shell history, it looks where youā€™ve been, and if you say something like ā€œz nodeā€ or something, it will find the last directory that you were in called Node and it will just pop you right back there. Itā€™s a great way to navigate to frequently visited directories or working copies, and itā€™s really neat.

Another tool I use is called ā€“ and apparently thereā€™s science behind this; I canā€™t say whether or not thatā€™s true, but itā€™s brain.fm. Itā€™s a service that you pay a nominal fee for and they give you a mobile app and a web app. The best way to maybe explain it is itā€™s generative music; thereā€™s many different styles, butā€¦ Thereā€™s some science behind it that says ā€œIf you listen to this music, itā€™ll help you, for example, focus on a task, or itā€™ll help you relax because of various tones and tempos and frequencies in the music.ā€

I donā€™t know about that, but I wanted to try it, and so I did try it, and I found out that itā€™s really helpful when Iā€™m trying to focus on coding, and it helps me get and stay into the flow.

I feel like if you do a lot of coding, maybe you recognize that sometimes you get into this flow state and I feel like the music generated by brain.fm may help you do that; maybe it wonā€™t, maybe youā€™ll find it boring, but itā€™s supposed to be actually kind of ā€“ itā€™s not supposed to engage to engage with you. Itā€™s supposed to be kind of in the background.

A lot of popular music, or even maybe you listen to ā€“ I donā€™t know, techno, or trance, or something with that beatā€¦ It kind of drives you forward to help, but maybe sometimes that type of music is a little too engaging, and the brain.fm music is like Techno Elevator music, or somethingā€¦ Itā€™s really interesting; you just throw it on the background, forget about itā€¦ And it helps me focus. Check that out, itā€™s cool.

[56:31] The last thing - there is a thing called Astral. If youā€™re like me, you have a million GitHub stars and you may be like ā€œWhat was that thing I was thinking of? How do I find it?ā€ I donā€™t even know how to do that with GitHubā€¦ So thereā€™s this app called Astral App. Itā€™s astralapp.com. Itā€™s just like an OAuth style GitHub app, and it helps you manage and view all your stars, and you can even tag your stars into categories, and it sorts stuff by language, and itā€™s really neat.

So if you are like me and have a lot of stars, check out Astral App, and that will help you manage them and find things. Those are my pro tips.

Very cool. Iā€™ve also used Brain.fm and I do think it is good programming music, so Iā€™m with you on that one.

I was gonna say the same thing.

I havenā€™t used Brain.fm, but I use a similar service called Focus At Will, and it is also excellent.

I didnā€™t know that. Itā€™s cool to find out that people are actually using it besides me, and Iā€™m not just some sort of like crackpot. Maybe I am a crackpot, but Iā€™m glad to hear itā€™s working for you guys, too.

Youā€™re amongst crackpots. You have crackpot friends. Nick?

Yeah, Iā€™ve got two quick pro tips. The first one is jscodeshift, which is really cool. Itā€™s a way to create what they call codemods for your code. If you need to do some kind of repetitive change throughout your code base, you can do that in a lot of different ways, like Find & Replace, which Iā€™ll typically do in a Vim macro or something like thatā€¦ But if you want a reproducible way to make changes to your code that is very safe, because youā€™re actually going to be using the abstract syntax tree to do it, jscodeshift and codemods are for you.

Itā€™s just a really cool way to be able to traverse the tree, and the tool does all of the traversing for you, so you just have to know what tokens you want to look for. For example, you could look for import statements in your code, and then change those in some programmatic way, so you can be guaranteed that youā€™re not going to change some commented out import, or a value in a string somewhere, but youā€™re actually going to be changing the From string on an import statement to a new value. You can be very specific about what you want, make those changes, and then have that as a codemod that you can share with friends and have a reproducible way of doing that. Really cool.

Then the second thing is two-factor authentication in 1Password. If you havenā€™t been using it, itā€™s amazing. If you havenā€™t been using 1Password, itā€™s also amazing. My life revolves around that. Thatā€™s the first thing I need on every device to get anything elseā€¦ But they have kind of hidden in there a way to do two-factor authentication, where if you were going to use Authenticator, or Authy, or one of those other apps in the past, you can just do it within 1Password, and the big benefit that you get is when 1Password auto-fills your username and password, it puts the one-time token on your clipboard and then you can just paste that in when that screen comes upā€¦ And it works on iOS and on Mac, and itā€™s just great. I recommend using that.

1Password will also tell you if an application that you have a saved login for has two-factor authentication and you donā€™t have that set up, it will tell you about that so that you can go in and be safe. Thatā€™s it.

Is it technically two-factor if itā€™s the same thing doing it?

That is a good question, but it would be my phone in both cases, so I guess itā€™s a level of abstraction that you have there.

[01:00:11.15] If you guys ever have a situation where you do a SMS-based two-factor auth and then your Macā€™s continuity feature brings the SMS right back onto your Mac and itā€™s right there in your notifications center, and youā€™re like ā€œOh, I guess itā€™s one-factor againā€¦ā€

Security is hard. Alright, KBall, youā€™re up.

Alright. Mine is less of a tool and more of a life hackā€¦ And that is to identify and validate your assumptions at every level of your life. This can play out in the technical sense, like the first step to debugging a problem for me is to go in and sort of identify for me what am I assuming, and just check that those things are true.

So often, particularly if Iā€™m helping a junior dev or something, we can find it; itā€™s almost like being a rubber duck - we find it just by saying ā€œWhat are we assuming? Can we validate that those assumptions are actually true?ā€ Usually, the bug comes from one of those assumptions not actually being true.

But this plays out throughout your life, itā€™s not just code. Some of my biggest personal breakthroughs have been from discovering that there was some mental model I had that I had just been assuming this was the way the world worked or the way that I had to be doing things, or somethingā€¦ And discovering that that was only an assumption, not actually the truth, and that I could change that.

This occurs in things like money and pricing. If you run your own business or youā€™re a consultant, you probably have an assume idea of how much money you can charge for things, and usually you havenā€™t validated that. When I discovered that assumption ā€“ I had an assumption that as a consultant I had to charge things by the hour, and I ran into this writer, a guy named Jonathan Stark, whoā€™s big thing is like ā€œHourly billing is nuts. Itā€™s a crazy thing to do. It sets up all your incentives wrong, so you should be charging in other ways - value-based pricing or project-based pricing, or even retainersā€, and kind of highlighting all the ways in which hourly billing sets you up for failure and sets your incentives at cost purposes to the people youā€™re working with or working for.ā€

That totally shifted the way I conceived of my business, and has made my life so much better. So every level of your life - figure out what are the assumptions youā€™re making, and then test them. And they might be right, but if theyā€™re not, youā€™re probably screwing yourself over somehow.

That is definitely a good pro tip. Hey, you and I should talk business at some point, in terms of billing and all that kind of jazz, because Iā€™ve been running a one-man consultancy like yourself for many years, and so we might bounce ideas off each other.

Letā€™s do it.

Letā€™s do that for later. So my pro tip is how to validate an email addressā€¦ And here is the hard-earned experience on how you validate an email addressā€¦ The only thing that you can reliably do to validate an email address is that you send it an email. You send it an email. Thatā€™s the only way you can do it.

I know what youā€™re thinking, ā€œI have the best regular expression for this.ā€ No, you do not. You think you do. Your regular expression is invalid; itā€™s not good enough. You know the old adage, ā€œThe developer, when faced with a problem, thought ā€˜I know. Iā€™ll use regular expressions.ā€™ Now he has two problems.ā€ Thatā€™s what you have - you have two problems.

Iā€™ve known this for years, and yet I was still convinced to add a regular expression-based email validation server-side; first of all, never trust a client, right? You can do it all you want there, but it can by-pass all your checks. Itā€™s gotta be server-side.

[01:03:59.10] I put a regular expression-based email validation and I thought ā€œThis oneā€™s pretty good.ā€ In fact ā€“ man, I donā€™t know what came over me; I was actually even talked into copy-pasting one off of a gist. It looked pretty good, and it covered most of the bases, and sure enough, last week I got an email from a prospective user saying ā€œHey, Iā€™m trying to sign up for Changelog Weekly, but it says my email address isnā€™t valid, and it obviously is valid, because Iā€™m emailing you with it right nowā€¦ā€ and I thought ā€œIā€™m an idiot. Why did I put a regular expression-based email verification on my system?ā€ So donā€™t do that.

I know you can find one on Stack Overflowā€¦ Iā€™ll tell you right now, itā€™s not good enough. Email addresses are so complicated, thereā€™s so many valid thingsā€¦ If youā€™re going to do it ā€“ and Iā€™ll admit that I kept it in there, but I just check that thereā€™s some stuff, and then an @, and some stuff. Thatā€™s pretty much what youā€™re gonna be able to doā€¦ And thatā€™s just to basically make sure that you donā€™t get some junk into your databaseā€¦ But still, all youā€™ve gotta do is send them an email, and if they click on it, well thatā€™s a valid email address. If they donā€™t click on it, then who caresā€¦?

Thatā€™s a hard-learned lesson. If you want to validate an email address, send it an email. Problem solved. Until bots start clicking on emails, then weā€™re gonna have a whole new issueā€¦ But so far I donā€™t think thereā€™s bots that will create a fake email address, sign up for your thing, and then access that email address and click on the link. When we get there, then weā€™ll have to come up with something else. But until then, just send it an email.

Alright, thatā€™s our show for this week. Like we said, make sure, if youā€™re at JS Conf, donā€™t miss us. Find KBall, find Nick [01:05:57.28] running around like a chicken with its head cut off. Find Suz, say hiā€¦ Weā€™d love to connect with you. We have stickers, weā€™ll have a limited amount of T-shirts, we have a live show on Tuesday, participate in thatā€¦ Itā€™ll be lots of fun.

Thanks for listening today, and we will see you live at JS Conf next week, and then the following week Feross is back and heā€™s got an awesome show all about decentralized web, soā€¦ Look forward to that, and we will see you next time.

Changelog

Our transcripts are open source on GitHub. Improvements are welcome. šŸ’š

Player art
  0:00 / 0:00