Noam Rosenthal has worked in both web and native technologies. He leads off with a discussion of the history of the web, browsers, and specifically webkit. The panel then goes into how browsers and built and discuss the differences between the different browsers.

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Noam Rosenthal.

DAN_SHAPPIR: Hello everybody and welcome to another episode of JavaScript Jabber. Today on the podcast, we have Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. 

DAN_SHAPPIR: We have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

DAN_SHAPPIR: And we have Noam who just, we just lost Noam Rosenthal as our guest. I guess we need to wait for him to join back up. So in the interim, 

STEVE_EDWARDS: who are you? 

DAN_SHAPPIR: Yeah, I'll say that I'm Dan Shappir and I'll be your host from today. Coming to you from Tel Aviv. Still under lockdown. Even though they are starting to relax these things a little bit around here, so we'll see what happens. Anyway, Noam, you want to say hi? 

NOAM_ROSENTHAL: Hello, everyone. 

DAN_SHAPPIR: So Noam, where are you coming from? 

NOAM_ROSENTHAL: I'm currently in Tel Aviv right by the beach. 

DAN_SHAPPIR: That's definitely a nice place to be, assuming you're allowed to go to the beach. 

NOAM_ROSENTHAL: And not allowed to go to the beach, but allowed to see the sun. 

DAN_SHAPPIR: Ah, the promised land. 

 

Are you stuck at home climbing the walls when you should be hanging out with the community at the latest conference to get cancelled? Are you wondering where to hear your JavaScript heroes like Amy Knight and Douglas Crockford and Chris Heilman? After the cancellations, I decided to put on a JavaScript conference for you, online. I invited my favorite folks from around the web and got them to come speak at an online event just for you. Go to jsremoteconf.com and check out our speakers and schedule. The conference is on May 14th and 15th. Come join us at an online conference that we guarantee will keep you safe and keep you informed. jsremoteconf.com 

 

DAN_SHAPPIR: So today we're going to be talking with Noam about a really interesting topic. I think one that we're all excited about, which is contributing to the browsers and to the various web standards. So Noam, before we begin, can you tell us a little bit about who you are, what you do? Like Chuck says, what makes you famous? 

NOAM_ROSENTHAL: What makes me famous? Apart from my very successful albums that made me a rock star that nobody knows about. 

AIMEE_KNIGHT: You do have guitars in the back. 

NOAM_ROSENTHAL: Yeah, apart from that, for several years, I've been kind of switching around between the web world and the native world. And an interesting scene between them is the browsers. And since over 10 years ago, I've been contributing to browser code. First at Nokia, where we were building mobile browsers and I was working on TV browsers and kind of switching back and forth from working on the browser to working on the websites and web platforms. Like how I was working at Wix until recently with Dan. Currently what I do is I am a freelance work by myself. And what I do is I help a web companies by web companies, I mean, anybody who has a website to help them improve the platform, which is a most rely on which is the browser. So that's what I do now. And I started that about a year ago, and it's been pretty successful. 

AIMEE_KNIGHT: I'd love to know kind of how you got interested in that how you got started into you know, diving into the browsers themselves. It's something that I've been really, really interested in in my career in the past. And I think for whatever reason, not everyone is, but it is so valuable when you're trying to debug things. So I think a lot of people just kind of like throw up their hands sometimes and you know, the reaction is like, well, this is dumb. Or at least that's like, you know, when I was like digging into CSS and stuff and how the browser renders things. But how did you get interested in it? And how has it affected the way that you write code? 

NOAM_ROSENTHAL: So at the beginning of my career, I worked on web like HTML, JavaScript, and the.com era of 20 years ago. And after that, I somehow found myself in the C++ world. And working a lot in C++ UI and C++ frameworks, predominantly I was working on the Qt framework, which is a popular C++ UI framework. As part of my work on that, I've kind of rolled into working for Nokia. And at that time, there was a big fight between web and native. I was talking about 10 years ago. Like, should we do this in an app or should we do this on the website? I just never liked the idea of the app stores and about big companies like Apple and Google deciding what we can or can't do provide to users. But the problem with web at the time was that it wasn't fast. Like doing stuff in HTML was slow and was difficult and was memory consuming. Specifically, animations were very slow. And I remember that going to some contributor meeting inside Nokia and I was like, okay, I'm just going to go into the browser code and try to fix it so that we can solve this problem of the web being slow. I guess having a C++ background helped with that and the strong determination, I guess. 

AIMEE_KNIGHT: And down the rabbit hole you went. 

DAN_SHAPPIR: Now, correct me if I'm wrong, Noam. I'm kind of a history buff, so this is my recollection, but you probably know about this more than I do. But WebKit was actually born out of this browser inside Qt, which was being worked on in Nokia, correct?

NOAM_ROSENTHAL: Right. WebKit was born from the KHTML project, part of KDE Linux open-source built by, you can say, enthusiasts, open-source enthusiasts that later worked on the Qt framework. Apple had forked it the same way Google later forked WebKit and made it their own, changed it a lot. KHTML was originally Qt based. Later Apple took it outside of Qt and then it went back into Qt. All of this speaking around 2008 timeframe, 2007. 

DAN_SHAPPIR: So first of all, all of us who happened to see KHTML in the user agent string and had no idea what this meant, this is actually what KHTML means. Like the archeology of the web inside the user agent string. 

NOAM_ROSENTHAL: Right. Exactly. Predecessor of WebKit.

DAN_SHAPPIR: So at the time you were working on this stuff or starting to work on this stuff, was it already after Apple had adopted WebKit or before? 

NOAM_ROSENTHAL: After, after. Apple has adopted WebKit in the mid, in like early 2000, 2005-ish. I don't remember the exact years. When I joined that, it was already about applying implementing browsers for Nokia with WebKit. WebKit was already a pretty mature project at that time and used in iPhones etc. 

DAN_SHAPPIR: And how is it delving into browser code? I mean how from you know obviously I assume a lot of our listeners don't really have experience in C++ but how readable is this code? If I decided to dive in you know is this something that a regular mortal can do?

NOAM_ROSENTHAL: I believe so. Like it's good to have some C++ background or to learn some C++ for that. But in some ways, browser code is cleaner than a lot of the JavaScript code I've seen. C++ is type-centric and compiled. Browser code has tons of tests. Unlike a lot of the JavaScript code I've seen, tons of tests.

AIMEE_KNIGHT: I have a follow-up question too. So when I was digging into this a while back as far as the rendering engine in Chrome, it was kind of the hard part was getting it running locally to contribute back. Can you kind of talk about that process? 

NOAM_ROSENTHAL: Yeah. You know, I guess that's because I've had a leeway with C++ for quite a few years. I'm familiar with the tool chain for C++. I think it's much easier than it used to be. They improved on it a lot, both in Chrome land and in WebKit land. I've recently had to run Chrome locally, and it seemed easier than before. I don't think it's more complicated than the crazy JavaScript toolchains we have today with all the web pack things that run on top of each other and try to find NPM modules in all kinds of places. It requires patience, though.

DAN_SHAPPIR: So you made a distinction between WebKit land or maybe FireLand and Chrome land. Can you contrast these two a little bit? Or maybe even throw, I don't know how much experience you have in that, but maybe even throw Firefox into the mix? 

NOAM_ROSENTHAL: Yeah. It was very interesting to work with the three of them. Also in StandardLand, I worked with all three entities, let's say. From a code. From code perspective, WebKit is much smaller. It's more like a library for rendering web that relies on the existing platform, like relies on the Mac, the OS six libraries or the iOS libraries or Linux libraries to do most of the work or a big chunk of the work is huge. Chrome is like a whole OS. Like everything is in there. It's like Chrome replaces a lot of the things the OS would normally do. That makes Chrome and WebKit very different. On one hand, Chrome is a lot more complete. On the other hand, WebKit is a lot more portable. Let's say if I go write a browser for a new platform, I would start with WebKit. It's what's used today for browsers on TVs or PlayStation, and platforms that are a little more niche than the regular desktop and mobile platforms. 

DAN_SHAPPIR: By the way, you're saying Chrome, but I assume you actually mean Chromium. 

NOAM_ROSENTHAL: Yeah, Chromium, WebKit, and Chrome versus Safari. 

AIMEE_KNIGHT: Can we make that distinction really quickly for listeners who might not be aware? 

NOAM_ROSENTHAL: Yes. One of them is the project, like the repository. And one of them is the browser, the product. So WebKit is managed like a code project. It's not on GitHub, but think of it like a GitHub repo. It has like a contribution model, it has branches, it has comments, it has reviewers. Safari is a product run by Apple. So Safari takes a specific cut, a specific revision from a web kit, says that this is going to be used for the next Safari. They have their own Safari code, which is not open source, which has, let's say, the Safari UI or integration with search engines. And they bring it all together and say, here is the Safari technology preview. Here is the new Safari for iOS. Same for Chromium and Chrome. Chromium is a project that is managed like a code project chrome is a browser with a logo, with a UI, with integration to Google services, with all the extensions. I hope that's clear. 

AIMEE_KNIGHT: It is. I was going to ask another question too. So can you kind of talk about architecturally, like how things are laid out? I know like from when I was digging into things, like the browser is broken up into the rendering engine and then like if we're talking about Chromium V8, can you go into more details about that? 

NOAM_ROSENTHAL: Yeah. I don't have an architecture picture in my head and browsers are very big. 

AIMEE_KNIGHT: Probably high level, high level. 

NOAM_ROSENTHAL: High level. Yeah. So a big part of the browser is the parsing and rendering. Like a parsing is about making text into some kind of internal data structure. Yeah. After that, there is all, there's the JavaScript engine, which is VA, Chromium and JavaScript core for WebKit. There is a big chunk which is the network layer, which handles all the HTTP protocols and web sockets. There are lots of other things like accessibility, editing, the different APIs, dealing with history, support for Web Inspector like the DevTools and Chrome, everything to do with the page, support for different platforms. Everything to do with styling. So SVG, which is a world of its own, is part of those projects. And Chromium has additional projects. One of them is Skia, for example, which is the painting library that is not included in WebKit. WebKit does not come with a painting library. You have to use whatever is in the OS. Same with the low level networking and a few other things. 

DAN_SHAPPIR: So as you just described the browsers are huge. They're kind of at the same level where we used to have operating systems. You mentioned Chrome, which essentially does everything within itself, like the networking and the painting and handling the user inputs and whatnot. So that's obviously kind of intimidating. And yet we're talking about, in this talk, about contributing to the browsers. So if this stuff really seems intriguing to me and interesting to me and something that I want to be involved in. How do I overcome this fear? How do I get into it? 

NOAM_ROSENTHAL: First of all, willpower really helps. But there is another side to it. It's countered by a very rigorous style, for example, style and guidelines that are enforced. So browser code is very consistently styled. You can search the code in a good way. Variable and function names need to mean something and use consistent English. The tests are extremely comprehensive. How things are laid out in the directories and filenames is very well layered. That's the other side of it. It's very well managed. It's also the very nice thing about working on those big open source projects is that you learn to work on these highly rigorous environments and it makes you think that way. You need to be covered with tests. You need your English that you write a code with to mean what it does. You need to not fall into those Boolean trap pitfalls and other anti-patterns of coding. So there are two sides. You can always ask. WebKit has recently moved from IRC to Slack, which I was very happy about. And there is a newbies channel and lots of material online on how to do things. 

AIMEE_KNIGHT: I'm not sure if it's open to everyone, but there's also a Chromium Dev Slack. I just know this as part of the GDE program. I'm assuming that if people were interested, they'd probably love to have people in there as well. 

NOAM_ROSENTHAL: Yeah. I mean, it takes some awkward moments to be a newbie. 

AIMEE_KNIGHT: Definitely. 

NOAM_ROSENTHAL: But just make a list of how many awkward moments you're going to have this week and you make sure you do all of them so that you can pass it. It's part of the drill is having some awkward moments. My first patch to WebKit had so many revisions to it dozens of revisions until it got accepted. So many little awkward mistakes before I could get it in. 

AIMEE_KNIGHT: I always say to, I mean, people looking for, you know, now obviously I don't think that this would necessarily be the best thing to like bite off as, you know, a brand new developer, but even as you're like later on in your career, you kind of sometimes want mentorship. And I always think like contributing to an open source project is a really good way. Like you're describing, there's so many revisions, but you probably learned a lot in that process. It's kind of like free mentorship. 

NOAM_ROSENTHAL: Yes, I got a lot of mentorship through my work in WebKit that I could never get in a closed source project. But actually, as a new project, I really recommend the web platform tests. It's the project that browsers use to maintain interoperability and compatibility. It's just a bunch of HTML, JavaScript tests, that all the browsers run to see that they didn't break the web. 

DAN_SHAPPIR: You mentioned your first contribution. So how many contributions have you had so far? 

NOAM_ROSENTHAL: I think around 150. 

DAN_SHAPPIR: Wow. 

AIMEE_KNIGHT: I'm impressed. Wow. 

NOAM_ROSENTHAL: Most of them were at the time where I was a WebKit contributor for Nokia and I became a WebKit reviewer at that time. And I was working very hard on making animations go work fast and applying that to phones and TVs. At the time Netflix were using what we were doing at WebKit and we were working together with them. And there was a phone called N9 which had all those improvements as part of its browser. And lately, in the last year, I had just a few, maybe 10. 

DAN_SHAPPIR: Can you give an example of some of the stuff that you recently added? 

NOAM_ROSENTHAL: Yeah. What I'm working on now, which I hope that by the time of airing this would be in, I'm right now in the review process, is implementing paint timing for a WebKit. 

DAN_SHAPPIR: Wow, that would be awesome. I want it now. 

STEVE_EDWARDS: What is paint timing?

NOAM_ROSENTHAL: So basically it's measuring when the first contentful paint happened. 

STEVE_EDWARDS: So is that measuring like the first bit of graphics or when a complete image or something is rendered? Is it like the beginning or the end of the process? 

NOAM_ROSENTHAL: It's when something is rendered on the screen that you can say is contentful. And part of my work was in standards. I did a massive editing to the paint timing spec together with Google, Apple, Mozilla. I'm now also an editor of the spec based on that work. Yeah, it measures... We had to define as part of that what it actually means that something is contentful because the definition of that was, oh, Promi implemented something. And it was like kind of a phrase that says what it is. And now you can look at the spec, but there is a very a specific definition of what the first contentful paint means. Basically, when the first text arrives or the first loaded image, or video starts. To do that, I also added about 25 web platform tests that cover all the different cases. 

DAN_SHAPPIR: Before you continue, Noam, just to mention that I'll plug myself, but if you listeners may recall, in episode 428, I actually did the alphabet soup of performance measurements. And paint timings, first paint, first contentful paint, largest contentful paint, were a part of that episode and some of the topics explained. So if people want to get more information about that, they can check out that episode. But please go on, I'm sorry. 

NOAM_ROSENTHAL: So I wanted to say that who came up with this project is Wikimedia, which is the Wikipedia company. They use rigorous performance measurements and they wanted to and make sure that they don't regress on Safari, on iOS and Mac. So they decided instead of asking Apple over and over again whether or not they would implement it, they contacted me to bridge it, to do it with them. And a lot of the work was getting everybody on board one spec. Interesting thing was that Apple did not want first paint, but only first contentful paint. That's because Safari has this optimization where it waits a bit before showing you stuff. It waits until it has a few characters or some pixels of loaded images before showing you stuff. So they don't believe in developers optimizing for first paint. And that was another interesting difference between Safari, between the WebKit folks for the Apple folks and the Google folks. It's that the Google were very quick to implement it. And the Safari folks were, WebKit folks were like, we want the spec to be very exact and rigorous or we write one line of code. And we got to a point where we have no blocking issues in the pain timing spec. And now I'm going through review cycles and hopefully by the time this is aired. WebKit is going to have this in. Another thing I've recently done is complete the image set, which is responsive images in CSS. Image set spec for WebKit. Actually, this is ready for WebKit before it is for Chromium. It allows better support for kind of like defining source set inside CSS. This is part of the work I'm doing for Cloudinary for improving images and responsive images in browsers. 

DAN_SHAPPIR: Just to understand what it is, so this is kind of like the picture element but for CSS? 

NOAM_ROSENTHAL: Yes, image set is kind of an old spec but didn't get enough love. It allows you, for example, to define a source set for a background image. So I did the work on unprefixing it and totally completing the spec for WebKit, and Chromium is still behind, and prefixed, etc. 

DAN_SHAPPIR: So in those two cases, at least in the first one, it seems that you actually were doing two things, that you were first contributing to the standard, and after you contributed to the standard, you then went and implemented that standard in WebKit. Am I correct? 

NOAM_ROSENTHAL: I would say three things. The third one being web platform tests. So contributing to three projects, yes. Sometimes for another project I'm currently working on, I also go to something called the WICG, which is the incubator for new standards. It's like a forum where you can discuss ideas for new standards. So yeah, I work on three projects at the same time. By the way, standards...And more platform tests are just GitHub projects with issues and pull requests. Very easy to get into. If you see something in the standard, you don't like, like don't keep it to yourself, there's Slack for it, for it, there's a GitHub for it. And there are sometimes video calls where web developers can just join. Yeah. I was recently in a video call about pain timing where we flashed out a lot of the issues and a lot of web devs joined and gave their feedback and it was great.

DAN_SHAPPIR: Yeah, I can certainly identify. I recently was involved in a conversation about effective type, which is the browser exposing what it estimates your network quality to be like. So it might say that your network quality seems to be like 4G or seems to be like fast 3G or stuff like that. And there was a whole discussion about, is this something? Chrome implements it. Other browsers do not. And there was a discussion about whether or not it's actually something that other browsers want to implement and what might be the use case. So I chimed in as somebody who is interested in other browsers implementing it and providing some use cases of where we at Wix would like to use it when it's available.

NOAM_ROSENTHAL: Yeah, that's extremely valuable and those calls and the web devs get a lot of say. Actually, you know, somebody implementing those specs, like web devs is who I want to hear from. I still do web projects also. It keeps me real in that way. But yeah, I highly recommend joining in, joining in like

a platform. 

 

Are you building applications with Vue.js? Then you need to check out the Vue's on Vue podcast. Every week we bring in a guest panelist from the Vue community and talk about the interesting things being built with Vue, or the changes coming in its ecosystem. You can find it all at viewsonvue.com. 

 

DAN_SHAPPIR: So if I decide to start contributing and I'm kind of, you know, not sure which one, which project to choose, WebKit or Chromium or Blink or Firefox, how do I choose which one to contribute to? 

NOAM_ROSENTHAL: Well, it really depends on what on why you want to do that, what you want to achieve. I think WebKit is a little easier to get into because there's something more straightforward about it, about how you build WebKit, about how you write, about how the whole thing works. Also about the project's goal, it's just about web rendering. There's no WebKit OS, like there is Chrome UMS. So I would say if you're looking for something that's easier to start with, I would say WebKit. On the other hand, it also relates to what you were saying the thing with the effective type. WebKit folks are a lot more conservative in what they put in the platform and allow to come in. In general, I see Apple as the more conservative companies than Google. Google are about a lot of trial and error. Apple are more like, let's see if it's right for the web first, let's see if it's right for compatibility, let's see if it's right for security and privacy. So that's the flip point of that. 

DAN_SHAPPIR: So question about that. So how much of control does Apple have over the WebKit project? I mean, you said that Apple are very conservative. So does that mean that in order to put something into WebKit, let's say I implement something as a pull request, somebody from Apple has to agree for this to go in? What's the process like?

NOAM_ROSENTHAL: So you would need a reviewer to approve it. However, reviewer, not every reviewer review every NOthe convention. Like, let's say when I worked on the, on the Nokia specific parts of WebKit, WebKit has a lot of platform specific things. And so when I worked on platform-specific things in WebKit that had to do with Nokia, I would review them and I wouldn't need somebody from Apple to look at them also. Right now, when I'm implementing a pain timing or an image set, I would need somebody who is familiar enough with the code to review it. And mostly that would be Apple folks. I actually believe that once that's in, I would be able to review parts changes to it or some changes to that. And so the answer is it depends. 

DAN_SHAPPIR: Out of curiosity, we were talking C++ all this time. Firefox, the code is, are they totally moved to Rust or is it some C++ still? Do you know? 

NOAM_ROSENTHAL: I don't think server is out yet. Server is the Rust engine. 

DAN_SHAPPIR: So the Firefox stuff is also still C++? 

NOAM_ROSENTHAL: Yeah. Unless I missed some very big news about it, which happens, but yeah, it's C++. 

DAN_SHAPPIR: Homework for our listeners. Anything else you would like to cover or mention in this context? 

NOAM_ROSENTHAL: I love the fact, you know, I mentioned who sponsors these projects. I love the fact that I can work on all of this in the open. That I can take pride in what I do, I can get feedback for what I do, I can get, you know, criticism for what they do and it's all in the open. There's no like, I don't, there's no secrecy. I love that part about what they work on currently. What I think is super important is that a lot of us as web developers take the browser as a sort of, as a given, as a fact of life, as you know, as something that's either immutable or something that we have zero control over it. So for example, if something in the browser doesn't work as we would like it to work, there's a feature that we would have liked to be different, or is missing from the... You know, we have it in one browser but it's missing from others, then we just complain a lot and then make do without. And I think one of the main points that you made here and I really liked a lot, is that we can actually fix these things. So if there is something in the browser that we don't like, if there's missing functionality, we can actually go in and add it and just implement it. And then we benefit from it. And later on, everybody benefits from it. So I think that that's a really important point to take away from all this. 

NOAM_ROSENTHAL: Yeah. I wanted to give an example, which not my work, but it's work I've been highly inspired by, which is CSS Grid. A lot of the CSS Grid work was done by a company called Igalia. It's friends of mine from Spain. And who sponsored it was Bloomberg. Bloomberg has a lot of web applications and websites and they realized that fixing layout in browsers would be cheaper for them than doing all those workarounds in their JavaScript and CSS code. They just hired this company to make browsers do CSS layout, which is CSS grid, sorry, which solves all of these problems. Again, the flip point of that is that it's a long lead time. It takes a while for a browser to get released from the point you write your code, you fix until it's available for users. It's measured in a few months to a year. So that's the other side of it. If you need to fix a browser bug immediately, sometimes you want to fix it in the browser and have it work around at the same time and hopefully get rid of the workaround a little later. 

STEVE_EDWARDS: So Noam, I have a question for you. And this is tangentially related to what we've been talking about. One topic of discussion that I've heard around different podcasts and different. Places around the web is the speed of change to the HTML spec itself as compared to CSS and JavaScript. The one example that I've heard many times is that it took 10 years just to get the main element added to the HTML spec. So I'm just curious to get your thoughts on that and why the HTML spec seems to move much slower as compared to, say, the specs for CSS and JavaScript. 

NOAM_ROSENTHAL: I'm actually not sure if that's still the case. And I'm not sure if I'm the right person to answer this question. Right now, all of those specs are kind of like, uh, divided to multiple, uh, little specs, like there is no CSS specs. There is CSS images. There's a CSS backgrounds. HTML is divided. There's rendering, there's images, there's a form elements. Also performance is divided to a lot of little specs. I think in the end it's up to particular editors. But I think it's a matter of opinion. It will be interesting to look at a particular use case, particular case, like the main element, and see why it took a long time. But I'm not sure it's true for everything you want to add to HTML. I had a good experience so far with adding things to it. 

STEVE_EDWARDS: I'm sorry. You had a what experience? Good experience? 

NOAM_ROSENTHAL: Yeah. The few things I was involved in, it was mainly in the pain timing spec, but the few things that were added to the HTML spec were done pretty quickly. 

STEVE_EDWARDS: Okay, all right, thank you. 

DAN_SHAPPIR: I think also that the division between all these different parts is sometimes a little bit fuzzy. I mean, for example, if we're looking at certain parts of the DOM API, like the pain timings which you were talking about, is this part of the HTML? You know, it's part of the DOM, but it's not really about HTML elements. So where exactly does that fit? And I think that, for example, in the DOM world, a lot of stuff is currently going on. For example, all the effort that Google is doing with Project Fugu. I don't know if and when it will make its way to other browsers. But that's certainly a lot of activity going on there. And another thing that I really like that's happening in the browsers is that browsers have become more extensible even from the web development side. So before I go in and add functionality in C++, these days with modern browsers, I can often prototype it or will be able to prototype it using JavaScript and HTML and CSS. So for example, we have web components as a mechanism that enables us to define new HTML elements, try them out and see how they work. Or soon, and soon we will have those aspects of CSS Houdini, which will enable us to try out new layouts implemented in JavaScript before we decide, hey, this is a great-looking layout. We want to make it a native part of the browser itself. So hopefully all these capabilities will actually make it easier to enhance and extend these standards. At least that's what I hope. 

NOAM_ROSENTHAL: Right. That's kind of how things work today. There's usually a polyfill that comes with a new standard. CSS is a little harder to polyfill than HTML. JavaScript is easier in some cases. But what you said about specs is true. Main timing is not part of anything. What was in charge of it is the web performance workgroup. It's divided more by workgroups and by technologies, but part of pain timing is in the HTML spec, like there's a part which reported is in a spec called the rendering, so it's all true. 

 

Early in my career I figured out which jobs were worth working at and which ones weren't, mostly by trial and error. I created a system that I use to find jobs and later contracts as a freelancer. If you're looking for a job or trying to figure out where you should go next then check out my book, The Max Coder's Guide to Finding Your Dream Developer Job. The book walks you through figuring out what you want, vetting companies that meet your criteria, meeting that company's employees, and getting them to recommend you for a job. Don't settle for whoever has listed their job on the job board. Go out and proactively find the job you'll love. Buy the book at devchat.tv slash job book. That's devchat.tv slash job book. 

 

DAN_SHAPPIR: Okay, then let's start with picks. Steve, you were the last one to ask, so let's have you as the first one to provide picks.

STEVE_EDWARDS: Actually, can you just get me for a bit and come back to me? 

DAN_SHAPPIR: No problem. AJ, you've silently joined us. Are you up for picks? 

AJ_O’NEAL: I had a good one, but then I didn't sleep very well, and it's on the tip of my tongue, but I'll have to pass for the moment. 

DAN_SHAPPIR: OK, then we'll skip you as well and move over to Amy. Amy, hopefully you have some picks for us.

AIMEE_KNIGHT: I do. Third time's a charm. I have picked this in the past, I think, but I'm going to pick it again because it's been a little while and it's related to what we're talking about today. And that is a Blink on YouTube channel. So it's a Google conference that they put on every year. Blink is a rendering engine that Chromium uses and it's a bunch of talks about that. And this is what I use to kind of help me better understand what the rendering engine was doing when I was digging into all the CSS stuff that I dug into a couple years ago. So that is going to be my pick. Man, I'm trying to think if I have anything else. I'll leave it at that for now. 

DAN_SHAPPIR: This CSS stuff is actually going to be some of the stuff that you're going to be talking about in the upcoming remote conference? 

AIMEE_KNIGHT: Oh, yep, yep. I completely forgot about that. It is. 

DAN_SHAPPIR: So we're all going to benefit from the time going into the rendering engine.

AIMEE_KNIGHT: Yes. Some good stuff. 

DAN_SHAPPIR: I'll go with my pick. My pick is going to be a bit weird and it's going to be eggs. And the reason for this pick is that currently in Israel, we have this kind of strange situation where there's a shortage of eggs. You can hardly get any eggs in supermarkets. 

AIMEE_KNIGHT: Yeah. It'd be terrible because I love eggs too. Oh my gosh, I would die.

DAN_SHAPPIR: So yeah, they actually, you go to the supermarket and they either don't have eggs at all or they'll ration them out and tell you you can only buy like the one, like 12. 

AIMEE_KNIGHT: I would send you some eggs if I could. 

DAN_SHAPPIR: Yeah, so they're even selling this disgusting thing where it's like a milk carton, but it's filled with egg mix. 

AIMEE_KNIGHT: I buy those too. I make all of them. Every day. It's egg whites. I mix my eggs with those to make omelet. 

STEVE_EDWARDS: Yes, that's my second breakfast every day is my egg white omelet. 

DAN_SHAPPIR: So I never realized how much I'm dependent on eggs for everything. I've got like three young adults living at home with my wife and I, and the amount of eggs that we consume on a daily basis is ridiculous. And all of a sudden to be in a situation where there are not enough eggs is is interesting. It's like we have a full fridge but no eggs and then the kids will say but there's nothing to eat. Yeah, exactly. So we currently do have some eggs in the fridge. I've been able to round up some eggs but hopefully, it's a situation that will be soon resolved. So that was my pick. Noam, how about you? Do you have any pick for us? 

NOAM_ROSENTHAL: I'm not familiar with your terminology so I just stay pick something that they want to recommend in any subject? 

DAN_SHAPPIR: Yes, absolutely anything at all that you want to talk about in any context whatsoever. I apologize for that. I assume that, for those of you who don't recall, Nom was actually on an episode of my JavaScript story. And I think there are picks there as well. So I assumed that you were familiar with that. But that was a while ago. 

NOAM_ROSENTHAL: Great. I didn't remember the name.

DAN_SHAPPIR: If you want, we'll skip you and see if Steve or AJ remember their own picks by now. 

STEVE_EDWARDS: Yeah, I've got something. And by the way, Dan, I was going to mention that you seem to be quite the egg-centric family. But that sort of leads into my pick. I'm going to go with something sort of real general, but something I'm a very large practitioner of, and that's called the dad joke. So just sort of general bad puns. And mostly puns. I have a tradition that I started a couple of years ago at a previous place of employment that started out as words of wisdom as sort of evolved or as some would say devolved into a dad joke. And so I post one a day on my Facebook page. And it's quite interesting to see the reactions of people that get used to them because they see me in the hallways and say, keep doing the dad jokes. And a classic example is probably one I posted today where I gave an example when I was at a restaurant ordering dinner and the waiter says, are you ready to order? And I said, I'll have the rabbit stew. And he says, only if you promise not to say waiter, there's a hair in my soup after I bring it. And I think about it and say, I'll have the chicken. So stuff like that. But there are a number of Instagram accounts that I follow that post various and sundry dad jokes and I can put those in the show note, but it's quite entertaining. 

DAN_SHAPPIR: So if you recall Bruce Lawson who was our guest a while back, episode 421, talking about semantic HTML. He's actually a champ of these kinds of jokes, and he posts these regularly in his Twitter account. So if you're interested in these types of jokes, I highly recommend following Bruce on Twitter. I recommend following Bruce on Twitter in any event. He has some excellent content, but if you're into those kinds of jokes, you'll enjoy it even more.

STEVE_EDWARDS: You can never have too many sources of good bad jokes. 

DAN_SHAPPIR: that's true. AJ, how about you? Is it moved past the tip of your tongue? 

AJ_O’NEAL: Well, no, but it's OK because I can still do this. I can still do this. So this is going to be more like storytime times two and a pick. That's still storytime. It's all storytime. All right. So first of all, I ordered a clothes, a portable clothes, garment steamer on eBay with some eBay bucks that I got for back when I bought my new iMac. And it got shipped to me, and in the description, it's like, shipping is going to take up to a month from China or something like that. And I'm like, whatever. But then it got shipped to me from Amazon Prime the next day. And it turns out that the same item on Amazon Prime was like a dollar cheaper. So literally, I bought from someone on eBay who just made a buck by shipping it to me from Amazon instead of actually having it to sell. 

AIMEE_KNIGHT: That is ridiculous. 

AJ_O’NEAL: But it was like rewards certificates, so whatever. It was fine. So number two, a lot of us, actually very few of us, well, about a middle amount of us remember Nickelodeon Gack and the annoying thing about Nickelodeon Gak was that it would get gritty and discolored because as you played with it, it would pick up like salt from the table or sugar or dirt or breadcrumbs or whatever, you know, like the more you played with it, the more it'd get like little granules of stuff in it or like it'd get hair from the carpet, you know, et cetera. 

DAN_SHAPPIR: I apologize for interrupting you, but it may be just me for not being from the States, but can you explain what that is? 

AJ_O’NEAL: Yeah, so I'll get there. Man. I'll get there. So it turns out that it wasn't, you know, a long lasting successful product. It probably didn't even have as good of a history as Pogs did. Certainly hasn't had the longevity of Yo-Yos. But it got re-appropriated as keyboard cleaner. Cause what it does best is pick up dirt and hair and grime. So now you can, you can buy this stuff and you get this bottle of Nickelodeon Gak, which is like silly putty, or I mean, I'm sure they have different names for the type of putty that it is in different countries, but it's just like a putty that's made with like gar gum and glycerin and, you know, like common household cleaners. It's one of those like kids science experiments that you can find in a lot of books. Anyway, so it's like a mix between jello and silly putty, if you can imagine that, or gelatin for people that aren't familiar with Jell-O. And it turns out that it's being sold as keyboard cleaner, which is just genius. And I got mine, of course, you know, on eBay with my, with my like $20 that I had, I was able to buy three things. And this one's really great. It's, it's called Super Clean. Do not rub, just press, use with body hands. Ingredients. Vegetable gum. Back. Bactorside, Quaternium, fragrance, glycerin, water storage condition. Keep away from direct sunlight and keep in a dry place. Keep away from children, don't eat it. Check if you need to replace your SuperClean. Compare the color. Bright Mexican flag, new in maximum cleaning and absorbing capacity. Dirty Mexican flag that's been drug through the mud, unavailable, replace your SuperClean. Absorbs dirt and dust and cavities ideal for all devices and surfaces. I just felt like people needed to know about that. And number three, which is actually important. Back on September of 2016, something happened that changed the world and no one knew. Vemate came out that natively supported packages. So all the while for the past four years where these battles have been going on between like pathogen and bundle and Vimplug, et cetera, et cetera, et cetera, Vim has native package management. All you have to do is put pack load all in your Vimrc, which might already cascade in there by default from the system Vimrc. And then you just create a directory that's.vim slash pack slash doesn't matter what the name is slash start and then you get clone into that directory, whatever plugin you want. So typically people just call the directory plugin. So you get clone into.vim slash pack slash plugin slash start. And then the folder name in there would be like sensible or centastic or prettier, et cetera. And if you want to get your name on some high-profile projects in the contributor list, just go pick any of your favorite Vim plugins. And in the install section, just add the three lines of instruction of how to install it with Vim 8 plugins because no one is putting it in their README. Everybody still has like, here's how you do it with pathogen or bundle or blah blah blah blah blah blah blah. And it's like, no, you don't have to do any of that mess anymore. Like Vim does this on its own now. So that, I mean, like this is revolutionary. No one knows. 

DAN_SHAPPIR: I'm curious, aside from AJ, who here is using Vim? 

AIMEE_KNIGHT: I have had a history with Vim. I use it off and on. I like to keep my Vim RC updated so that if I do decide to use it, it's ready to go. That said, most of the time I'm using VS Code right now, but if I'm... I'm just weird. It depends on the code I'm writing. If I just know off the top of my head exactly what I want to do, I'm going to pop up in Vim. But if I am exploring a code base, then I want more just all the stuff that VS Code offers, then I use that. 

DAN_SHAPPIR: I actually used to use VI in the very old days, but I kind of left it and never looked back. So maybe I'm heretical or something. 

AJ_O’NEAL: Well, if you don't have Vim sensible as a plugin for Vim, then it behaves just like VI. And that is a terrible experience, not being able to use the arrow keys or backspace. 

AIMEE_KNIGHT: Interestingly, I, so I've been doing a lot of the GCP tutorials and they use nano for everything and it's driving me nuts. I'm like, why do they not use Vim? 

STEVE_EDWARDS: What? I love, I always change my default editor to be nano from VI whenever I get a new computer, I've never taken the time to, you know, learn all the keystrokes and all the VI ins and outs used to drive me nuts. And so I just like nano cause it's a little more, to me, it's a little more intuitive.

AJ_O’NEAL: Well, it has the documentation in the bottom bar there. 

STEVE_EDWARDS: Yeah, that helps. 

AJ_O’NEAL: Which like if, if Vim had something like that, which it totally could, somebody could make that plugin or it could suggest to be shipped as a default. You could just have a status bar at the bottom that has all the documentation and like a set no help or something, make it disappear. So you don't have to worry about it anymore. But yeah, Nano is definitely easier for someone that wants to be able to exit the text editor successfully and has never used them before. 

AIMEE_KNIGHT: My muscle memory is still there, even though I don't use it like every single day intensely. 

DAN_SHAPPIR: And finally, Noam, have you managed to come up with a pick for us? 

NOAM_ROSENTHAL: Yeah, a couple of things that are present in my life during this interesting times. One of them I call hyper isolation. Like when something goes wrong because of all this isolation, I try to make it more wrong. Like, just to see how it feels. Like, for example, yeah, I can't go out and meet friends. So I also exit at Facebook to see how much I really need all this social stuff. Can't get eggs, remove eggs and something else, something in addition from my menu to see how much I really need them. That has been an interesting game, albeit some might not consider it fun. But it was interesting for me. And the other one is just, I find recently more about the art of storytelling, kind of like as its own art and its own performance. My, my partner is a, she's a storyteller in her profession. So every, I'm surrounded with stories all the time. And I find that what they do on this podcast is a story when I create a patch for a web kit and has to explain what it is, it's a story. When I talk to a client, it's a story. So just the art of storytelling and everything is something that's what's present for me lately. 

DAN_SHAPPIR: That's just such an amazing tip. That's an excellent one. So everybody, I think this is another episode of JavaScript Jabber over. I really enjoyed it a lot. I hope our listeners have as well. So every...